5 ms·

The performance data is great to have, but gives me more reassurance than concern. Between browserify and closure compiler, we're looking at a 15ms to 40ms dif

The performance data is great to have, but gives me more reassurance than concern. Between browserify and closure compiler, we're looking at a 15ms to 40ms difference until we get well over 1000 modules. Even complex SPA apps I've written come in nowhere near 1000 modules, a few hundred at most. Interestingly the performance difference between mobile and desktop on a fast connection was negligible. Browserify and webpack are really developer friendly, so it's an easy business decision to sacrifice 15ms in overall load time and instead pre-hydrate the first page or use another trick to provide responsiveness while modules load. I think front end dev process can still use plenty of improvement, but my primary takeaway here is to be conscious of the tools being used and the dependencies they import. It doesn't need to be a complex issue.

asimuvPR 10y ago
A few hundred modules? Could you talk more about that?
- jahewson 10y ago
  "Modules" refers to individual source files, not npm packages. A single npm package can contain many source files, each of which is a separate CommonJS module. Most npm modules are small, so I'd expect in the average case that the majority of modules are actually your own app code.
- doublerebel 10y ago
  Anything with assets expressed as JavaScript modules is easy to get to 100. Architectures that include compile-to-JS templates like hyperscript/react/jade. Or where there are many variations on a theme, like game characters and sprite components. But once we're into gaming, users are way more tolerant of load times. Any standard CRUD app or BI dashboard should be nowhere near 1000, imho.
nolanl 10y ago
As I say in the post, I'm not sure it's safe to say "I have _n_ number of modules, therefore my overhead is the same as the '_n_ modules' benchmark." For runtime perf it's about the total number of require()s; the "_n_ modules" benchmark is more reflective of the bundle size cost. E.g. consider the m.reddit.com example - 1050 modules, yet an order of magnitude slower than the "1000 modules" example. I might need to follow up with more benchmarks to reduce the confusion. ^_^;;
- nolanl 10y ago
  Oh yeah and also - "modules" !== "packages." ;) Not sure many folks are really counting the number of _modules_ in their code as well as packages.
twhb 10y ago
> Even complex SPA apps I've written come in nowhere near 1000 modules, a few hundred at most. Just to be sure, you're definitely counting modules using browserify-count-modules, not the number of directories in node_modules, right?

asimuvPR 10y ago

A few hundred modules? Could you talk more about that?

jahewson 10y ago
"Modules" refers to individual source files, not npm packages. A single npm package can contain many source files, each of which is a separate CommonJS module. Most npm modules are small, so I'd expect in the average case that the majority of modules are actually your own app code.
doublerebel 10y ago
Anything with assets expressed as JavaScript modules is easy to get to 100. Architectures that include compile-to-JS templates like hyperscript/react/jade. Or where there are many variations on a theme, like game characters and sprite components. But once we're into gaming, users are way more tolerant of load times. Any standard CRUD app or BI dashboard should be nowhere near 1000, imho.

nolanl 10y ago

As I say in the post, I'm not sure it's safe to say "I have _n_ number of modules, therefore my overhead is the same as the '_n_ modules' benchmark." For runtime perf it's about the total number of require()s; the "_n_ modules" benchmark is more reflective of the bundle size cost. E.g. consider the m.reddit.com example - 1050 modules, yet an order of magnitude slower than the "1000 modules" example. I might need to follow up with more benchmarks to reduce the confusion. ^_^;;

nolanl 10y ago
Oh yeah and also - "modules" !== "packages." ;) Not sure many folks are really counting the number of _modules_ in their code as well as packages.

twhb 10y ago

> Even complex SPA apps I've written come in nowhere near 1000 modules, a few hundred at most. Just to be sure, you're definitely counting modules using browserify-count-modules, not the number of directories in node_modules, right?