4 ms·

From the author's discussion of Node's "enterprise" popularity: > The visceral rejection of Node.js that you see from some quarters is often > the spidey-s

From the author's discussion of Node's "enterprise" popularity: > The visceral rejection of Node.js that you see from some quarters is often > the spidey-sense of an experienced enterprise developer zapping them between > the eyes. JavaScript? No! The author shouldn't be so quick to chalk this uneasiness up to discomfort with JavaScript itself but rather with the perceived instability of the NPM ecosystem. While NPM is filled with high-quality libraries, each has a bird's nest of dependencies like what you see with CPAN packages. To use Node, you need to use NPM. To trust NPM, you need to trust Open Source. Until the enterprise really trusts open source, Node will never be very popular there, regardless of how heavily it is used elsewhere. PHP overcame this hurdle because you can use PHP productively with no third-party packages. The second problem for Node to overcome is that its design requires asynchronous I/O for good performance, and you need decent developers to write good asynchronous code. While this is a real problem, I'm not sure that many decision-makers are aware of this (or would care about it) because so much "enterprise" software is dog slow and resource hungry.

shtylman 13y ago
You don't have to trust anything. If you want to NIH everything yourself, nothing is stopping you. It is however more likely that many packages on NPM are better than the ones you or your team can create if simply for the fact that they may have been created by a person very versed in the particular domain the package is for. Or maybe it will be shit but whatever :)
- oinksoft 13y ago
  I have no such reservations about the NPM/CPAN style, but your assertion that the only other choice is "NIH" isn't quite true. With Python for instance, you can choose SQLAlchemy for your ORM. It has no depencencies. In JavaScript, Mongoose (a good comparison) depends on "hooks, mongodb, ms, sliced, muri, mpromise, mpath, regexp-clone, mquery". Who knows what those in turn depend on. In a strict place, you need to get every one of those things approved, and each represents a moving target if you want to upgrade Mongoose later. Those shops begrudgingly let open source in as it is, so it's a tough sell.

shtylman 13y ago

You don't have to trust anything. If you want to NIH everything yourself, nothing is stopping you. It is however more likely that many packages on NPM are better than the ones you or your team can create if simply for the fact that they may have been created by a person very versed in the particular domain the package is for. Or maybe it will be shit but whatever :)

oinksoft 13y ago
I have no such reservations about the NPM/CPAN style, but your assertion that the only other choice is "NIH" isn't quite true. With Python for instance, you can choose SQLAlchemy for your ORM. It has no depencencies. In JavaScript, Mongoose (a good comparison) depends on "hooks, mongodb, ms, sliced, muri, mpromise, mpath, regexp-clone, mquery". Who knows what those in turn depend on. In a strict place, you need to get every one of those things approved, and each represents a moving target if you want to upgrade Mongoose later. Those shops begrudgingly let open source in as it is, so it's a tough sell.