Right, but that is basically saying we should all go back to something similar to before npm/bower/etc.
I love using plain ESM and I prefer to pull in stuff that only relies on that. But when I need graphing on a single page I'm not going to try to vendor Vega and I'm not going to pull it in on all pages. When I need xls parsing I don't want to vendor xls.js and maintain the diff myself.
So I have to use something like snowpack to make it work with my ESM system and dynamic imports.
If you don't have to require heavy libraries for certain pages then that's great and I encourage to use pure ESM without build systems for that, but you should also recognize that not all use-cases are ready for it.
Currently I use snowpack to handle dependencies but still run all my own code unbundled and unminified.
> Right, but that is basically saying we should all go back to something similar to before npm/bower/etc.
That position isn't without good reason. Refer, for example, to the linked post, explaining the engineering decisions behind esbuild. ("It's Golang, not JS" is only part of the answer to "Why is esbuild fast?" The implications seem to be lost on many of esbuild's users, given the nature of esbuild itself and the job it's supposed to do.)
I love using plain ESM and I prefer to pull in stuff that only relies on that. But when I need graphing on a single page I'm not going to try to vendor Vega and I'm not going to pull it in on all pages. When I need xls parsing I don't want to vendor xls.js and maintain the diff myself.
So I have to use something like snowpack to make it work with my ESM system and dynamic imports.
If you don't have to require heavy libraries for certain pages then that's great and I encourage to use pure ESM without build systems for that, but you should also recognize that not all use-cases are ready for it.
Currently I use snowpack to handle dependencies but still run all my own code unbundled and unminified.
reply