Comment by mattdesl | Hacker News Reader

Comment by mattdesl | Hacker News Reader

Parent Full thread

There are a lot of reasons to break modules into really tiny pieces, even if they are only a dozen lines or less. Some benefits:

- a terse and frozen API (like "domready" and "xtend") does not end up with the scope creep and bitrot that monolithic frameworks and "standard libraries" tend to carry

- it encourages diversity rather than "this is the one true way"

- it generally leads to less fragmentation overall (and tighter and more robust apps)

- each piece can be versioned, tested and bug-tracked independently

- once you get used to it and start finding modules you like, it can be incredibly easy to prototype and rapidly iterate with existing solutions. My 100+ modules are in a similar domain (graphics) and my efficiency for prototyping has improved because of them.

- it is better for reusability. If you have an algorithm that depends on jQuery or another monolithic framework for just a single function, it is hard to reuse. (ie version issues, bundle size)

It took me a while to come around, but npm has really given me a better appreciation for small modules. :)

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.

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.

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.

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.

Reply on news.ycombinator.com