[ptx]

The post dismisses native browser support (a huge benefit of ES modules) as "an utterly useless feature" that's "unavoidably slow" because of the additional roundtrips needed as the dependency tree is traversed.

But this problem has been solved by modulepreload[0], also natively supported in the browser, which lets you specify the modules upfront in the HTML, avoiding the need for additional roundtrips. Tooling could help with generating the list of preloads but is not necessary.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

[jampekka]

Tooling could also analyze the dependencies and create appropriate bundles of the code to avoid roundtrips. Actually such tooling has existed for over a decade and are used by practically all but simplest Javascript applications.

I'm all for development without a compilation step. I've written hacks to resolve node modules and transpile in browser to avoid compilation. Implementing prefetching even with this hack would be less hacky than going full circle and injecting HTML tags to do the prefetching.

ESM is like XML: The problem it solves is not hard, and it doesn't solve the problem well. Actually ESM it isn't even close to solving the problem after trying for almost 15 years.

[ptx]

As you say, tooling can solve the problem. But with ES modules and modulepreload, we can now (contrary to what the post argues) also solve it without the tooling, which is an improvement.

Yes, all but the simplest applications currently use the tooling-based solutions, because there was no other way. But now that we have an alternative solution, perhaps all but the most complex applications will manage just fine without tooling, using just the built-in module support.

[jampekka]

So without tooling you need to specify the preload tags by hand. And of course import the modules in the JS.

A simple sync and/or async function/statement would had solved the problem of having modules in the browser. E.g. RequireJS solved this in 2010 or so. There were straightforward proposals for native modules even before this.

[ptx]

> So without tooling you need to specify the preload tags by hand. And of course import the modules in the JS.

Yes. This is exactly what I want. It's helpful for simple apps, and without all the toolchain complexity more apps can be simple.

ES modules solve the problems I care about:

1) Eliminating the extra roundtrips.

2) Nice and simple syntax.

3) Tooling not required.

[jampekka]

RequireJS solved 1 and 3 over a decade ago and better than ESM.

2) ESM syntax is objectively more complicated than CJS while managing to be less expressive. It's one of the most complicated module syntaxes out there. Subjectively it's not nice at all, much due to the objective difference.