3 ms·

Just to add to your list, small modules are incredibly useful for browserify/webpack apps. For example, if I just want to md5 some strings and do a `require('cr

by STRML 12y ago

Just to add to your list, small modules are incredibly useful for browserify/webpack apps. For example, if I just want to md5 some strings and do a `require('crypto')`, I've just pulled about 100 KB of code into my app. Instead, I can find some simple md5 lib (in this case I used one called "js-md5"), and get the same functionality in about 3KB. It seems a lot of Node projects have gone the small module direction. Given that npm is a package manager that (mostly) works correctly - which is so much harder than it sounds - we can actually use small modules in our app to little detriment. Yeah, an npm install might take a little bit longer than you'd like, although it's really not that slow. The duplication of modules isn't really an issue in server-side apps, and in webpack apps you can dedupe code pretty easily with webpack.optimize.DedupePlugin + gzipping, so it's not an issue there either.

MichaelGG 12y ago
That sounds like poor tooling in JS, something solved by say, linkers, in other systems. And I'm not exaggerating about build times. A simple grunt build doing some basic template stuff would take about 20 minutes. The majority of that time was bringing in the ~13,000 files a rather simple static website needed to build. I ended up tossing the idea of independent builds and just made a persistent build machine that symlinked in node_modules. I've got a million lines of C program that takes less time to fully compile and link.
- mattdesl 12y ago
  I would be curious to see what kind of tool could do this. It sounds like "tree shaking" (like dead code removal) which may be possible in the far future with ES6 imports. I imagine it would further add to build times. Not sure how your rant about grunt tasks and templating relates to small npm modules. A 20 minute build time sounds like something was vey wrong. My browserify (incremental) build time is < 100 ms which I can handle.
  - MichaelGG 12y ago
    Yeah perhaps current JS tools can't do dead code elimination because of the highly dynamic environment? Each module could provide some metadata on what it actually needs. I only target JS via cross compilers so I've never dealt with this problem. The small module system ends up requiring a ton of files, which is slow. Incremental builds don't really apply to a clean build server where you are basically doing "git clone ... && make". The actual processing isn't my complaint, just the enormous overhead npm's style imposes. I mentioned grunt since just having that plus uglify or so ends up bringing in 13k files or something.

by STRML 12y ago

MichaelGG 12y ago

That sounds like poor tooling in JS, something solved by say, linkers, in other systems. And I'm not exaggerating about build times. A simple grunt build doing some basic template stuff would take about 20 minutes. The majority of that time was bringing in the ~13,000 files a rather simple static website needed to build. I ended up tossing the idea of independent builds and just made a persistent build machine that symlinked in node_modules. I've got a million lines of C program that takes less time to fully compile and link.

mattdesl 12y ago
I would be curious to see what kind of tool could do this. It sounds like "tree shaking" (like dead code removal) which may be possible in the far future with ES6 imports. I imagine it would further add to build times. Not sure how your rant about grunt tasks and templating relates to small npm modules. A 20 minute build time sounds like something was vey wrong. My browserify (incremental) build time is < 100 ms which I can handle.
- MichaelGG 12y ago
  Yeah perhaps current JS tools can't do dead code elimination because of the highly dynamic environment? Each module could provide some metadata on what it actually needs. I only target JS via cross compilers so I've never dealt with this problem. The small module system ends up requiring a ton of files, which is slow. Incremental builds don't really apply to a clean build server where you are basically doing "git clone ... && make". The actual processing isn't my complaint, just the enormous overhead npm's style imposes. I mentioned grunt since just having that plus uglify or so ends up bringing in 13k files or something.