I never would have guessed they could manage that and keep it this easy to use!
How common is the es module entry point in major packages?
@pika/web's installation most closely matches the study's moderate, "50 file" bundling strategy. Jung's post found that for HTTP/2, "differences among concatenation levels below 1000 [small files] (50, 6 or 1) were negligible."
I've not had a need to do much JavaScript since the days when you just directly used a few external libraries via <script>, so this just sounds nuts to me.
I suppose it's probably common, and the various packers make it work fine, but wow.
With my app size I can get away with no Webpack, just a Makefile that links together required file list into a template file, which is then included into the page template on the backend.
For example, lodash (a somewhat common set of utility functions and general helpers) is a single package, but internally it's broken up into hundreds of individual packages which lean on the dependency module system to resolve among themselves, deduplicate, and enable the ability to include only a few of them (and their dependencies) if you only need those in a project.
Many libraries are setup like this, because there's not much of a reason not to. Adding complicated functionality to an existing package is often worse for everyone than just creating a new package which implements what you want and setting it as a dependency.