I generally avoid third-party JavaScript modules for performance and maintainability reasons. When I do use them, I'll frequently vendorize them (put them in my source tree) and make ESM modules for them.
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.)
So you’re the one writing everything from scratch even though the wheel has already been invented and perfected and tested over years by many developers.
Also your website is serving dozens of cascading files instead of a single minified one.
Bundlers aren't the "wheels" here. The real "wheels" here are ESM modules, which have been available in every modern browser for a while. Bundlers are just pre-wheel, prehistoric, stopgap technology from the 2010s that we should be moving away from.
And there's no problem serving multiple files in 2020 because we have HTTP2 multiplexing now. In fact, it's probably more efficient than using bundling, because you can cache much better. Minification is also virtually unnecessary with Brotli, and not minifying has the added benefit of making the debugging experience much better.
And bundlers haven't been "perfected". Not even close. Webpack is without a doubt the worst piece of technology in my stack right now, together with Babel. Those two are terrible by themselves, but they also manage to "infect" other things elsewhere in my stack: for example, ESLint and Jest need Webpack/Babel plugins to work.
Basically everything you wrote is wrong. Loading multiple files is never more efficient because compression works on a file at a time in that case, plus subdependencies start loading only after their parents finish downloading. This is CSS’ @import cascades all over again.
The wheels I’m talking about are the actual modules that exist on npm used in production by millions daily. Everyone here can write some code that does something common like, say, left-pad, and then they screw it in some obvious way that was fixed in 2014 by the third user of that library.
Sure I agree that having no build is nice, but user performance is not comparable and you’re limited to your own code.
You seem to be still holding a lot of assumptions from 2010.
In practice compression is not a big issue if you use something with a pre-defined dictionary specialized for HTML/CSS/JS, which is Brotli. The advantages of bundling are not exactly too large. Sure you might not be deduplicating some identifiers, but the lion's share of code in practice is normal javascript/CSS/html.
Also, in the long term, caching and the removal of code added by bundling more than makes up for any losses from compression.
Also, with Multiplexing there's no problem with download multiple files sequentially, because you don't need TCP handshakes and HTTPS negotiation, which were the reason for bundling in 2010. In fact, multiplexing multiple files might be faster in some cases, because you're able to parallelise the downloads and the parsing, rather than having to download a big bundle before parsing it.
There are of course caveats to this, but neither bundling or separate assets are silver bullets.
When I do, I use a script tag, and put it before my ESM modules:
Use them via global variables.I generally avoid third-party JavaScript modules for performance and maintainability reasons. When I do use them, I'll frequently vendorize them (put them in my source tree) and make ESM modules for them.