Agree on everything. Plus, things like mentioned building phase are not strictly necessary anymore: you can build pages/apps in JavaScript nowadays and rely on native modules support. Of course with TypeScript it’s a bit different as you need to transpile it to JavaScript, but essentially all computers out there that have modern browser out there are ready to use development environment, with debugger, profiler, development tools you need to start dabbling in programming and that’s a value on it’s own!
hubertlepicki
wanton7
Back then we used .NET and .NET has Microsoft library called Microsoft.TypeScript.MsBuild that supports compiling TypeScript files directly without NPM so it was pretty easy with that.
1
hubertlepicki
wanton7
coen.bakker
I’m glad to see movement in the browser API space. Looking forward to view transitions. GitHub - WICG/view-transitions · GitHub
New great browser capabilities are a absolute win for web dev, I’d say.
Was a bit surprised it didn’t exist yet, when I first started looking for something like it… But I appreciate the work being done.
1
dimitarvp
Yeah. I was about to say to @hubertlepicki: it’s obviously unrealistic to wish that JS just disappeared tomorrow. Most people’s problem with JS is how it’s practiced; its ecosystem is an ever shifting sand. I remember trying super hard to get into JS years ago; the entire project was always just one npm and/or node patch version (e.g. 1.6.10 → 1.6.11) upgrade away from not working or getting a ton of new warnings. Same with webpack; suddenly half your config doesn’t work after the tool got upgraded.
It’s hard to be productive – or even want to work at all – in such conditions.
And before you say “just use X and Y, do packaging using Z, and transpile using ABC”, I am not contesting that there are productive combos of tools. The problem is the community agreeing upon best practices and promoting them – something that the JS community is famously bad at.
And then you get to the best part: analysis paralysis because nowadays there are so many tools that if you’re new you’d need to spend weeks just researching and trying stuff before settling on your own unique blend of JS development process. Which, surprise surprise, you won’t be able to [readily] Google for because you have 5 tools interacting in unique ways.
As a guy who’s paid handsomely to be highly productive this gives me huge anxiety. Surely you can see how 50-70% of the time spent on picking tools and then also pampering them constantly, is a problem. I am OK with going deep and taming my setup but JS never made me feel like my knowledge will have any staying power.
6
hubertlepicki
I agree with you on all accounts. One thing to add, is that I am seeing the rise of the “JavaScript frameworks” nowadays, that largely - or completely abstract away the building process, and to an extent - package management from the user. Excuse me to give you the same example again, but in things like Next.js/Nuxt.js the user doesn’t see the webpack.config.js, for all I know they could switch to an entirely different build system, and we (optimistically) wouldn’t notice it. It’s similar to Rails or Phoenix this way: the developer has to know the conventions, the usage, but it’s the framework’s job to build the app. This also allows you to avoid the “every developer sets it up differently” problem. It’s something Ruby and Elixir figured out years ago, but JavaScript only now shifts toward, but does indeed nevertheless.
2
dimitarvp
hubertlepicki
Indeed. It’s somewhat a pitty that when you google “JavaScript frameworks” you will get results like Vue.js, Angular.js or React. They’re not really frameworks, they miss the frame altogether that binds it all. In my mind Framework is like Rails, Phoenix, Laravel or Spring, where developer code is the focus of the programmer, and not setting up build system or figuring out a different and original directory structure. React/Angular/Vue etc. these are just libraries, not frameworks at all.
1