3 ms·

So, a really great example of this is over in Node land. I was trying to install some basic boilerplate HAPI demo scaffolding, and I watched with horror as depe

So, a really great example of this is over in Node land. I was trying to install some basic boilerplate HAPI demo scaffolding, and I watched with horror as dependencies were pulled in (as third or fourth level deps!): isarray, isstring, three different versions of underscore and lodash, and so on and so forth. I've never seen developers so lazy or just uneducated about their own language that they blantantly pull in libraries for such trivial operations. On the server even, no excuse about compatibility!

XorNot 12y ago
Javascript is weird and the library you're talking about are all about trying to make it sane. The problem is they're libraries, with potential breaking changes between versions. You want to be sure your code runs? You pull in the exact version you wrote it against. And by and large, this doesn't really get better with more centralization unless the centralization is good: if something doesn't work, then you'll still get 50 different wrappers which fix it in slightly different ways. Because you have to.
- regularfry 12y ago
  What I don't understand is the justification for supporting more than one version of a single library at a time. That just seems crazy to me, and an utter pain for maintenance.
josephg 12y ago
This is by design. The node community actively encourages you to break every module into the smallest possible pieces, then make a parent module which reassembles them. This is seen as good, modular design - you end up with small pieces which can be individually tested, patched, understood, documented and maintained. Some extra effort gets pushed to developers in that when you want to do something simple, you have to trawl through dozens of small libraries which will all accomplish the goal. But those small libraries should each be readable and understandable - unlike the mammoth size of most C/C++ libraries. I asked isaacs about documentation on the way back from nodeconf this year (isaacs is the CEO of npm and former maintainer of nodejs). I asked him what he prefers when it comes to documentation of nodejs packages. He said that if your package needs anything larger than a readme, its probably too big and you should just break it up.
- angersock 12y ago
  I'm all for libraries that do one thing and do it well. But again, that's not what I was complaining about. Consider: https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray Compare with: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... And again, for browser stuff, sure--but this is a controlled runtime on the server. This shouldn't even be a question. What I've also noticed is the tendency to use lodash and underscore in places where there are completely reasonable standard language features, like _.forEach(). Again, the Javascript language is a bit weird, and lacking perhaps in a lot of functionality that a default Ruby installation (say) might get you, but this is just silly.

XorNot 12y ago

Javascript is weird and the library you're talking about are all about trying to make it sane. The problem is they're libraries, with potential breaking changes between versions. You want to be sure your code runs? You pull in the exact version you wrote it against. And by and large, this doesn't really get better with more centralization unless the centralization is good: if something doesn't work, then you'll still get 50 different wrappers which fix it in slightly different ways. Because you have to.

regularfry 12y ago
What I don't understand is the justification for supporting more than one version of a single library at a time. That just seems crazy to me, and an utter pain for maintenance.

josephg 12y ago

This is by design. The node community actively encourages you to break every module into the smallest possible pieces, then make a parent module which reassembles them. This is seen as good, modular design - you end up with small pieces which can be individually tested, patched, understood, documented and maintained. Some extra effort gets pushed to developers in that when you want to do something simple, you have to trawl through dozens of small libraries which will all accomplish the goal. But those small libraries should each be readable and understandable - unlike the mammoth size of most C/C++ libraries. I asked isaacs about documentation on the way back from nodeconf this year (isaacs is the CEO of npm and former maintainer of nodejs). I asked him what he prefers when it comes to documentation of nodejs packages. He said that if your package needs anything larger than a readme, its probably too big and you should just break it up.

angersock 12y ago
I'm all for libraries that do one thing and do it well. But again, that's not what I was complaining about. Consider: https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray Compare with: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... And again, for browser stuff, sure--but this is a controlled runtime on the server. This shouldn't even be a question. What I've also noticed is the tendency to use lodash and underscore in places where there are completely reasonable standard language features, like _.forEach(). Again, the Javascript language is a bit weird, and lacking perhaps in a lot of functionality that a default Ruby installation (say) might get you, but this is just silly.