If I understand correctly, they say this is only the case when you have less than 1000 flies:
@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."
Our app is certainly over that, and I suspect most apps quickly grow to this (most of the files are dependencies). I'm not sure where the 50 moderate number comes from (we have an unfortunate dearth of information when it comes to "real world test cases" -- it seems common for bundlers to just check whether it performs better for the app they were working on at the time), but I would be surprised if most the 50 file threshold is maintained for very long for highly dynamic sites (vs., say, a company brand site or a blog where this may be the case forever? Again, I honestly have no idea).
"Our app is certainly over that [1000 files]...I suspect most apps quickly grow to this"
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.
The current JS ecosystem leans heavily on bundlers and packers to enable this kind of workflow, and IMO it's a good thing that we do.
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.
As a counterpoint: I have a reasonably complex app that gets data via WebSocket pub/sub and dashboards it, does things like stream logs from remote devices, open up SSH consoles, draw canvas diagram with network map etc. It’s split up into lots of component files and I think I still have less than 50 files. So no, I would not say 1000 file app is normal (which is not to say they are not doing something grand that justifies it).
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.
Comments
Wow, they claim that this is equal to or better than most apps that are bundled into a single bundle file due to the cache benefits!
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?
If I understand correctly, they say this is only the case when you have less than 1000 flies:
Our app is certainly over that, and I suspect most apps quickly grow to this (most of the files are dependencies). I'm not sure where the 50 moderate number comes from (we have an unfortunate dearth of information when it comes to "real world test cases" -- it seems common for bundlers to just check whether it performs better for the app they were working on at the time), but I would be surprised if most the 50 file threshold is maintained for very long for highly dynamic sites (vs., say, a company brand site or a blog where this may be the case forever? Again, I honestly have no idea)."Our app is certainly over that [1000 files]...I suspect most apps quickly grow to this"
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.
The current JS ecosystem leans heavily on bundlers and packers to enable this kind of workflow, and IMO it's a good thing that we do.
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.
As a counterpoint: I have a reasonably complex app that gets data via WebSocket pub/sub and dashboards it, does things like stream logs from remote devices, open up SSH consoles, draw canvas diagram with network map etc. It’s split up into lots of component files and I think I still have less than 50 files. So no, I would not say 1000 file app is normal (which is not to say they are not doing something grand that justifies it).
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.
https://www.pikapkg.com/ will show you which packages export modules.
There is apparently more than 40.000 packages that are es module ready, that is quite a lot, more than I imagined!