Hacker News Reader

Comment by recursive | Hacker News Reader

npm, babel, webpack, module compatibility, et al

You are free to develop everything in vanilla JavaScript and run your coded scripts straight in the browser. Very non-complex.

But the team that uses npm, babel, webpack etc will crush you both on development speed and stability.

Yeah it's not like the complexity doesn't come with some wins. The tradeoff has some serious negatives but there are good reasons those tools are used so widely.

let's be real. nobody is crushing anybody in development speed with webpack. Use rollup esbuild or vite

and this is why I have to use nitter or invidious to avoid the wrath of the complexity demon

i think the crux of the matter is to use the right tool for the job once you fought hard not to use that tool. Too many devs see something shiny and want to incorporate it into their workflow somehow, this is what introduces bad complexity, instead you should try very hard not to use something shiny until you realize overwhelmingly that using it would be a net win.

Speed maybe. But stability? Hard to imagine how that stack of build tools is going to provide more stability.

Modularization, encapsulation, coordination, safely scaling contributors/features.

Vanilla js can do all that.

Just `import` and done. No build steps.

As a front end dev I am all-for vanilla JS. I hate maintaining a webpack, postcss, dependency hell. I still long for the simpler days of plugging javascript into a static page for some helpful dynamic utility.

Where I find vanilla JS struggles is (for example) rendering a big tree of data, and then needing to update some data dynamically within the tree without re-rendering the whole thing. You end up with some horrible queryselector hell, or keeping some immense table of pointers to the elements. Fortunately for us, we have some tiny libraries like lit-html that can help accomplish this. In the theme of grug I think the ideal solution is somewhere in between.

IE users are now complaining that your site doesn't work.

Like I said, stability.

I wouldn't call that stability. You might. I have the luxury of never caring about problems like that. Most people can probably achieve it now that IE is officially super-dead or whatever.

“Can do” doesn’t always (or even often) mean “can do well” or “can do well according to our needs” or “works for all our use cases” or “works for all our users” or…

If vanilla JS checks off all those boxes for you, that’s genuinely fantastic and I’m happy for you. And a lil envious tbh. But there are a myriad reasons I/we currently can’t justify ditching the build toolchain, and most of them relate to scaling in a way that fulfills our requirements. I can’t imagine I’m alone in that.

The obvious ones: Typescript + eslint + jest + Selenium. More complexity, high return on investment.

The non obvious ones: Without babel you are either writing legacy JavaScript (which is arguably not as clean and easy to read), or users will complain your site is not working on their older browser.

How old is legacy? I seem to do ok using most ES6 features. I still am not a fan of javascript, but the newer features don't do much. It's not really a readability thing, but the one JS feature I'm holding my breath for is native decimals. I could really use that.

Webpack is by far the worst tool I've ever used in my development career so far. I never want to see it again, yet using it has allowed me to do things that otherwise would have been a major problem. Something can be useful, but still hideous beyond belief in terms of complexity.

I feel similarly after diving into Terraform for the first time

Hahahaha that’s a good one. The quality of the end product depends 99.99% on the quality of the developers. Not the tools they use.

The whole CJS/AMD/UMD/ESM nightmare has included some prominent devs intentionally breaking packages for certain build types because 'ESM has been around for a while, why haven't you updated yet?'

Reply on news.ycombinator.com