1. 29
  1. 18

    I’m so excited about this trend.

    Something I think the JavaScript development world doesn’t really take into account is the burden all of their build tooling puts on us occasional JavaScript developers.

    I mainly work in Python, but I work on JavaScript maybe once a month - which is just infrequently enough that I’ve never managed to build a permanent mental model of how all of the JS build tooling works.

    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!

    I imagine if you are a full-time JavaScript developer immersed in that ecosystem this problem fades, since you work with it every day.

    1. 3

      I imagine if you are a full-time JavaScript developer immersed in that ecosystem this problem fades, since you work with it every day.

      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.

      1. 2

        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.

      2. 9

        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.

        Furthermore, especially with things like typescript, and languages that compile to wasm or javascript, off-line tooling isn’t going away, no matter what. Browsers will never be able to keep pace with what the latest tooling has to offer, and everything they add is code that has to be carried forever – whereas off-line tooling has softer constraints here.

        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.

        1. 5

          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.

          1. 3

            This approach is nice, but it seems very early to push it as a default.

            1. 2

              Being able to program using this much better JavaScript

              Genuine question: did programming in JavaScript really change that much? Is ES6+ really “much better”? If Iook back at ES6 in hindsight, the only thing that really brought an improvement is async/await. Everything else turned out to be just another way of expressing something that’s already there. I’ve got the feeling my entire team finds itself writing a more old school flavor of JS each day, soon we’ll be back in 2012. Plus async.

              N.B.: I do enjoy writing JavaScript, both 10 years ago and today so this is not supposed to be a slur.

              1. 13

                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.

                1. 6

                  Also Map, promises and then async…

                  1. 3

                    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.

                2. 3

                  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/