3 ms·

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 mod

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

tyingq 8y ago
"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.
- gbuk2013 8y ago
  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.
- Klathmon 8y ago
  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.

tyingq 8y ago

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

gbuk2013 8y ago
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.
Klathmon 8y ago
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.