3 ms·

I'll share a thought or two while I wait for $ npm install to finish. I agree that other ecosystems could learn a lot from the Node philosophy. And in general

I'll share a thought or two while I wait for $ npm install to finish. I agree that other ecosystems could learn a lot from the Node philosophy. And in general I enjoy working with the technology. But it's not all roses. In an ecosystem of small modules, you often find yourself wading through many -- equally small -- annoyances which can add up to a lot of friction. Here's a contrived fake example: Your app needs ABCXYZ. So you go shopping for a module. The most popular one looks good, but when you Browserify it your bundle ends up with 1,000s of extra lines of code for the Buffer shim. So much for keeping that footprint small. So you keep looking and find another one that has a good footprint, but a weird API and it hasn't been updated by the maintainer since 2011. The next one you find looks great, but the maintainer decided they were tired of ES5 and didn't feel like adding a distfile, so you would have to install a bloated transpile toolchain to use it. You're getting annoyed but you keep going. The next one's author inexplicably decided to implement everything with streams. But you're too busy to spend a day grokking streams and reworking your entire API to be compatible. The next one is packaged as a jQuery plugin. The next one doesn't have a license. The next one uses Web Workers for no reason you can see. Etc. etc. etc. Repeat. Any of these could be problems with a monolith (and monoliths certainly come with their own pile of frustrations), but monoliths are less likely to hit these problems simply because they consolidate effort and personal emotional investment around a certain set of techniques and standards, which leads to more consistency overall.

substack 11y ago
I'm not sure which xhr module you're referring to but the `xhr` package doesn't have this problem: $ npm install xhr $ browserify -r xhr | wc -c 11147 $ browserify -r xhr | wc -l 390 $ browserify -r xhr | grep Buffer $
- matthewtoast 11y ago
  Correct and I shouldn't have mentioned XHR -- it was just a fake example for the sake of my point. I just went back and ninja-edited my original comment above to call it "ABCXYZ" so that it's clear I didn't intend to call out any specific package/author.
tracker1 11y ago
Or, fork the light library, and work around the troubling bits? Many (most?) npm modules are ISC, MIT or something equally permissive. There are several times I've found something close to what I want, I fork it on GH, change the bits I want, update the name everywhere and publish it... many times they continue to work as-is without much grief. Of course that's part of why there are so many options for any problem. I usually look at the following, when was the last commit, and how many issues have been sitting stale for over a month... if the last commit was several months ago, but there aren't any recent issues, I'll check through the backlog issues.... some libraries reach maturity and don't change much, if the issues aren't recently curated, I move on...
- matthewtoast 11y ago
  I agree and that's what I like to do too when these issues come up (time permitting). Still, I hope my basic point came through: the small modules approach isn't a panacea; it can add its own set of problems; "monoliths" can be a good choice, not always, but sometimes.

substack 11y ago

I'm not sure which xhr module you're referring to but the `xhr` package doesn't have this problem: $ npm install xhr $ browserify -r xhr | wc -c 11147 $ browserify -r xhr | wc -l 390 $ browserify -r xhr | grep Buffer $

matthewtoast 11y ago
Correct and I shouldn't have mentioned XHR -- it was just a fake example for the sake of my point. I just went back and ninja-edited my original comment above to call it "ABCXYZ" so that it's clear I didn't intend to call out any specific package/author.

tracker1 11y ago

Or, fork the light library, and work around the troubling bits? Many (most?) npm modules are ISC, MIT or something equally permissive. There are several times I've found something close to what I want, I fork it on GH, change the bits I want, update the name everywhere and publish it... many times they continue to work as-is without much grief. Of course that's part of why there are so many options for any problem. I usually look at the following, when was the last commit, and how many issues have been sitting stale for over a month... if the last commit was several months ago, but there aren't any recent issues, I'll check through the backlog issues.... some libraries reach maturity and don't change much, if the issues aren't recently curated, I move on...

matthewtoast 11y ago
I agree and that's what I like to do too when these issues come up (time permitting). Still, I hope my basic point came through: the small modules approach isn't a panacea; it can add its own set of problems; "monoliths" can be a good choice, not always, but sometimes.