[lampe3]

Not sure it the author tried a new build tool like vite, esbuild and so on.

Working on large projects and having everything first loaded and then you can load it in the browser is a waste of time that every web developer has every day.

Some real world times FOR DEVELOPMENT: Storybook first load: 90 sec, Storybook after first load changes: 3 sec, Vue App first load: 63 sec, Vue app change after that: 5 sec, Vue App with Vite first load: 1sec, Vue App with Vite after that: the time it takes me to press command+tab to switch to the browser

Do we really have people that use unminfied unbundled esm in production? If Yes, please comment why?

I would also ask the author what about cyclic dependencies? ES Modules resolve them automatically. Something which in large code bases can happen.

Why do we still put it through babel? Because most of us don't have the luxury of not supporting old browser... https://caniuse.com/?search=modules Even if the not supported browsers for our company is 1% it is still a big chunk of money in the end.

and this example: ``` app.use("/users", require("./routers/users")); ```

Really? this is "good code" having a require in the middle of a file?

Also funny: The author is annoyed that rollup did not support tree shaking in commonjs and then complains that people are wasting time on esm. Maybe the rollup team does not want to waste time on commonjs? Also then he points to a package which did not got any update in 3 years and would make the hole process he complains is to complex even more complex by introducing a new dependencies.

Sorry but the more I read that thing the more it sounds to me like a Junior Dev that does not want to learn new things and just likes to rant about things.

[joepie91_]

Hi, author here. I'm going to ignore the personal attacks and simply point out that my dev build processes typically have a startup time of under 5 seconds even for large projects, and a rebuild time of under 500ms. This is with Browserify.

If you are having very slow build times with your existing toolchain, the problem isn't the bundling, which is an extremely fast operation. It's almost certainly going to be one specific computationally-intensive plugin that you either don't need, or would also need if using ESM.

[lampe3]

"Wie man in den Wald hinein ruft, so schallt es heraus" since your from NL it should be easy to translate.

These heavy plugins are usually for old browsers to also run in them. That is the only job ob babel.

CJS has some deeper problems. - Check if your fav CJS lib freezes the objects? - ESM is more http friendly (mime type)

[joepie91_]

The build times I listed are including a Babel plugin.

[wruza]

It’s usually senior devs who don’t want to learn new things just because these are new. And aren’t afraid to use 3 years old packages (how dare they!). Imagine having a subroutine which is “done” doesn’t get updates for years, laughable! Who makes it “done” when you can fuck it up at the start and fix a little every day, filling that activity grid with green dots.

All of this js-related stuff is just a fast fashion, the bad part is web developers are locked into it with no chance to relax and to just create their boring services and apps.