4 ms·

The problem with standard libraries is they are a standard library. A place where good code goes to die. Standard libraries also mean you can't use the particul

by l1ambda 11y ago

The problem with standard libraries is they are a standard library. A place where good code goes to die. Standard libraries also mean you can't use the particular version of the module you need; now you are pinned to the version of the standard library comes with the version of the language you are running on. The workaround there is to fork out the standard library code into...a module. Now, a lot of these modules are designed for old JS runtimes like old versions of IE, so you wouldn't have a standard library anyway. There's plenty of good libraries like lodash and math.js that are pretty much the next best thing to a standard library. If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault. That's like blaming git because you pushed some crappy code. The problem was fixed 10 minutes later anyway. This whole discussion surrounding this is a combination of knee-jerk reaction, "waah", and realization of "Oh shit, depending on external code means we are dependent on external code!" If you want to code without dependencies, go write JavaEE. Everything is included, you don't need any third party dependencies, and you can use cutting-edge tech like JSP, app servers and JavaServer faces.

the_mitsuhiko 11y ago
> A place where good code goes to die. Oh I agree. But maybe the answer is neither extreme? A healthy ecosystem with both established "standard" libraries and larger than single-line packages.
vlunkr 11y ago
> If your dependency tree sucks, that's a personal problem What about the fact that React and other popular projects have apparently bought into this ecosystem? You can't use them without also using their dependency tree.
talideon 11y ago
I don't Armin would disagree with you. The problem here is the sheer number of micromodules developed under different banners that would be better suited to be part of a larger coherent effort like lodash, and all the problems that come with having such functionality spread across so many micropackages with many separate maintainers. Dependencies aren't bad in and of themselves, but when you've lots of tiny dependencies, the costs mount rapidly.
- jessaustin 11y ago
  "Larger coherent efforts like lodash" already exist and are used by many people on many projects. Perhaps Node's real problem is that it allows developers to structure each project in exactly the way that they feel is best for that project, rather than enforcing a "Java way" etc. A greater variety of techniques naturally yields more techniques that bother any particular developer's sensibilities. Those who don't like the "Java way", for instance, are likely to simply avoid Java rather than tweeting, "OMG I just realized that you can write Java the Java way!" It's a matter of taste, and Node accommodates various tastes.
  - talideon 11y ago
    You could say that about just about any modern-ish packaging system. Sure, npm gives you plenty of rope to hang yourself with, but you can't really blame people for pointing out that what you were doing was a bad idea when you end up dangling from the noose you just created.
    - jessaustin 11y ago
      Haha I was saying "real problem" ironically. I don't think it's a problem at all to flexibly support a variety of approaches. Let a hundred flowers bloom, I say. Neither do I think it's inherently misguided to use the "micromodule" approach. That will work for some projects, if not for others. This episode has been entirely overblown. I'm sure some people went offline over it, but that wasn't entirely or even mostly due to the assholes at Kik. Rather, it was one or more fragile parts of their own infrastructure, exposed by an untimely missing dependency.
pbreit 11y ago
"If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault. That's like blaming git because you pushed some crappy code." How is it even remotely similar? In one case it's all your code and in the other it's none of your code.
- jessaustin 11y ago
  Like git, npm does only what it is told to do. One writes one's own package.json file. Depending on a module one doesn't own is an action one takes oneself.
mrweasel 11y ago
>If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault. While I sort of agree, in the case of JavaScript, the language is so limited that people are attempting to make it into a general purpose language by gluing on stupid dependencies that really did belong in a "standard library", or directly in the language. The "isarray" function is silly, if you write code that need that kind of inside into data types, then you shouldn't have picked JavaScript. I agree that it's a knee-jerk reaction, and only a few people where really affected. It does however highlighted a major short coming of JavaScript, the fact that it's not a usable language in it self, it needs libraries to be usable as a general purpose language. Hopefully ES6 will fix a lot of this.
- emodendroket 11y ago
  Well, first of all, you don't have a choice on the client, and secondly, Array.isArray is in ES5 (see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).

by l1ambda 11y ago

the_mitsuhiko 11y ago

> A place where good code goes to die. Oh I agree. But maybe the answer is neither extreme? A healthy ecosystem with both established "standard" libraries and larger than single-line packages.

vlunkr 11y ago

> If your dependency tree sucks, that's a personal problem What about the fact that React and other popular projects have apparently bought into this ecosystem? You can't use them without also using their dependency tree.

talideon 11y ago

I don't Armin would disagree with you. The problem here is the sheer number of micromodules developed under different banners that would be better suited to be part of a larger coherent effort like lodash, and all the problems that come with having such functionality spread across so many micropackages with many separate maintainers. Dependencies aren't bad in and of themselves, but when you've lots of tiny dependencies, the costs mount rapidly.

jessaustin 11y ago
"Larger coherent efforts like lodash" already exist and are used by many people on many projects. Perhaps Node's real problem is that it allows developers to structure each project in exactly the way that they feel is best for that project, rather than enforcing a "Java way" etc. A greater variety of techniques naturally yields more techniques that bother any particular developer's sensibilities. Those who don't like the "Java way", for instance, are likely to simply avoid Java rather than tweeting, "OMG I just realized that you can write Java the Java way!" It's a matter of taste, and Node accommodates various tastes.
- talideon 11y ago
  You could say that about just about any modern-ish packaging system. Sure, npm gives you plenty of rope to hang yourself with, but you can't really blame people for pointing out that what you were doing was a bad idea when you end up dangling from the noose you just created.
  - jessaustin 11y ago
    Haha I was saying "real problem" ironically. I don't think it's a problem at all to flexibly support a variety of approaches. Let a hundred flowers bloom, I say. Neither do I think it's inherently misguided to use the "micromodule" approach. That will work for some projects, if not for others. This episode has been entirely overblown. I'm sure some people went offline over it, but that wasn't entirely or even mostly due to the assholes at Kik. Rather, it was one or more fragile parts of their own infrastructure, exposed by an untimely missing dependency.

pbreit 11y ago

"If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault. That's like blaming git because you pushed some crappy code." How is it even remotely similar? In one case it's all your code and in the other it's none of your code.

jessaustin 11y ago
Like git, npm does only what it is told to do. One writes one's own package.json file. Depending on a module one doesn't own is an action one takes oneself.

mrweasel 11y ago

>If your dependency tree sucks, that's a personal problem. It's not npm, JavaScript or node's fault. While I sort of agree, in the case of JavaScript, the language is so limited that people are attempting to make it into a general purpose language by gluing on stupid dependencies that really did belong in a "standard library", or directly in the language. The "isarray" function is silly, if you write code that need that kind of inside into data types, then you shouldn't have picked JavaScript. I agree that it's a knee-jerk reaction, and only a few people where really affected. It does however highlighted a major short coming of JavaScript, the fact that it's not a usable language in it self, it needs libraries to be usable as a general purpose language. Hopefully ES6 will fix a lot of this.

emodendroket 11y ago
Well, first of all, you don't have a choice on the client, and secondly, Array.isArray is in ES5 (see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).