The Node.js Community is Quietly Changing the Face of Open Source
1–10 of 106 posts
Re: The Node.js Community is Quietly Changing the Face of Open Source
#2While I understand the benefits the author presented about having many small packages, I still wonder what kind of effect this has on resolving overlapping dependencies.
EX: I have package X that depends on A, B, and C and I decide to use package Y that depends on C, D, and E.
D and E may very well be an alternative implementation of A and B, given the large number of packages and a finite solution space.
On the one hand it's easy to think that the best libraries for a particular task will rise to the top, but as a newer node dev, having to reinvent so many wheels for use in node is not very attractive. (However, this is almost counteracted by having to only write in one language).
Re: The Node.js Community is Quietly Changing the Face of Open Source
#3To speculate a little about the huge rate of package growth (none of this should be taken as critical of the article, which makes no claims about this):
1. Reuse - a lot of NPMs also work in the browser. There are good reasons to make your browser code run in Node too; it makes command-line-driven testing easier and it requires little additional work to add support to a whole platform. And it should be obvious why there is so much JavaScript in the world; in fact, one of Node's biggest advantages is JS monoculture.
2. Take-off time. Node itself has gotten really popular really fast (there are good reasons for this too), which means its ecosystem needs to do some catching up. It has half the packages, but Node developers still need to get the same things accomplished. I've contributed more to the Node ecosystem than the Ruby one even though I write more Ruby in general, mostly because more needed to be done. You look around for a good existing solution, and if it's not there, you roll your sleeves up and you write it.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#4To speculate a little about the huge rate of package growth (none of this should be taken as critical of the article, which makes no claims about this): 1. Reuse - a lot of NPMs also work in the browser. There are good reasons to make your browser code run in Node too; it makes command-line-driven testing easier and it requires little additional work to add support to a whole platform. And it should be obvious why th…
It's also the case that Node modules are sometimes inspired by those in other ecosystems, like Rails.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#5To speculate a little about the huge rate of package growth (none of this should be taken as critical of the article, which makes no claims about this): 1. Reuse - a lot of NPMs also work in the browser. There are good reasons to make your browser code run in Node too; it makes command-line-driven testing easier and it requires little additional work to add support to a whole platform. And it should be obvious why th…
It's also the case that Node modules are sometimes inspired by those in other ecosystems, like Rails.
Ah, yeah, that's a good addition. A lot of not needing to reinvent the wheel conceptually.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#6I assume half of the packages are outdated plugins for grunt.js. If we then subtract all the packages without tests (aka the ones that are almost useless for open source) I guess the numbers should be pari. Doing such comparisons reminds me of the days were LOCs were a meter of productivity.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#7To speculate a little about the huge rate of package growth (none of this should be taken as critical of the article, which makes no claims about this): 1. Reuse - a lot of NPMs also work in the browser. There are good reasons to make your browser code run in Node too; it makes command-line-driven testing easier and it requires little additional work to add support to a whole platform. And it should be obvious why th…
It's also the case that Node modules are sometimes inspired by those in other ecosystems, like Rails.
It's just like technology transfer into a booming (developing) country. Happens rapidly until they've caught up to the frontier.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#8"I’ve only very rarely seen a node.js project that wasn’t on github."
To an extent, that's due to npm's git integration and lack of strong free (for open source) git hosting alternatives. You can specify a git endpoint for a module import.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#9Seems a bit unfair to show a rate of packages per year based on the full life of each language, as the principle package repos haven't been around as long as the packages/year implies.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#10To speculate a little about the huge rate of package growth (none of this should be taken as critical of the article, which makes no claims about this): 1. Reuse - a lot of NPMs also work in the browser. There are good reasons to make your browser code run in Node too; it makes command-line-driven testing easier and it requires little additional work to add support to a whole platform. And it should be obvious why th…
> mostly because more needed to be done
I agree, and think your comment is insightful, but let me add a little nuance to it.
I've been doing a lot of work with Node lately. In my experience:
1. I generally don't have trouble finding a module (library) that addresses my particular need. (I.e., when I go look for a library that does X, I generally find it.) It does happen, but a lot less often than I expected.
2. I generally don't have the opposite problem either. While in some ecosystems one finds so many libraries to address a particular need that it is hard to choose among them, in my experience that isn't (yet) a big problem with Node. It does happen, but less than it does in, say, Ruby (or for that matter emacs-lisp) and it is generally pretty easy to identify the "market-leader" as it were.
3. The problem that I do run into in Node (with greater frequency than most ecosystems I've worked with) is that I'll stumble across minor bugs in the modules I'm using. These tend to be moderately easy-to-fix issues that crop up in moderately-rare edge-cases, but they are definitely there. (I suppose this speaks to the relative maturity of the ecosystem.)
Counter-intuitively, I think this may actually be a good thing for the Node ecosystem. I'm reminded of the advice to open source developers to essentially "leave something broken" (or incomplete) so that potential contributors can make small-scale contributions [1]. A library that is too complete and well-designed is hard to contribute to (without investing a lot of time in understanding the architecture and direction of the project overall), but if you've got a library that does 95% percent of what you want, but fails on that one small edge case, more contributors are both willing and able to roll up their sleeves to scratch their particular itch.
[1] I can't remember or google-conjure the source of this advice right now. For some reason I think it might have been Marc Andreessen, but it sure sounds like something ESR would say.