[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.