I’m so excited about this trend.
As a result, it feels like every single time I have to interact with Webpack (or its many peers) something has changed or I’ve forgotten a step and as a result stuff breaks.
This makes revisiting older projects an exercise in frustration!
It fades if you keep working in the same stack of tools atop JS. A new project often means the same hurdles, just with a contextual leg up. Even a new major version of a stack component like Next.JS can mean you need to cope with changes in other components they bake in but still affect you.
And to bring it full circle, the unusually high depth of packages importing packages in NPM has to do with the fact that baseline JS offered very little in terms of standard features, so small libraries like left-pad would be imported and depended on instead of deemed trivial. Improve the baseline and you can cut out a lot.
Yep. I have a personal site that I work on. It’s mostly static, with a few APIs and a few key generated files, with hand-written HTML and CSS and vanilla JS. It works fine, and it’s basically unbreakable, but I would like to add some new features. Those new features want new libraries. And those libraries are very “oh, just add this to your packer”. I don’t have a build process or any of the stuff that they expect me to have, I’ve been out of mainstream web dev for 10 years, and I don’t have the time to learn how to get from my current state (“works great”) to a new state of “works hopefully almost as good but is usable as a base for all this new shit” because it’s an unpaid side project.
I increasingly feel the opposite of this; continuously integrating new features into the browsers proper, when folks can already get those via transpilers and the like, serves to further bloat the web platform without a huge upside.
Fussing with import maps seems like it would be just as bad as fussing with the tooling that exists now. And the tooling could be much better than it is without the browsers lifting a finger.
What I’d like to see instead is for web platform development to focus on being a good platform for targeting with said tooling. Fill in gaps that make things harder on tool authors, and work to smooth out the experience of using the offline toolchains.
Tools like snowpack and vite should probably be mentioned. They build on the same premise that ESM is the future, and provide a bridge. UMD modules, React and TypeScript get converted on the fly to ESM modules during development. And it’s still possible to produce bundles for production. The people who benefit the most from ESM are the frontend developers as it provides a fast feedback loop.
This approach is nice, but it seems very early to push it as a default.
I’m not sure which versions introduced which features, but between the time I left JS and returned to it, they added for…of loops, const and let, arrow functions, and class syntax. Each of these made a big difference to me.
Also Map, promises and then async…
Do you know which ES6 feature got pulled but I wanted? Tail call optimization. Not supporting it because debuggers would be ‘harder’ was pretty weak–which oddly means only WebKit supports it. Entire styles of application building could be unlocked with it.
Here’s a list of features, you can also check what will be missing without compilation by checking 2016+ tab https://kangax.github.io/compat-table/es6/