4 ms·

This probably either sounds nuts or over opinionated but I don't think the NPM ecosystem is as valuable as people think it is... stuff is deprecated continuousl

by tomxor 6y ago

This probably either sounds nuts or over opinionated but I don't think the NPM ecosystem is as valuable as people think it is... stuff is deprecated continuously anyway - when you find a way to move away from 10k dependencies (because your shortsighted previous self decided to depend on a single package without looking closer), it's a damn relief. I hate how needlessly complicated the NPM ecosystem is, I would actually like it if no one built bridges to Deno, it could be a clean start with lessons learned. Most of the packages on NPM are complete garbage - most not all - (and I say this as a full time JS dev who actually likes JS), liking the technology does not have to mean liking what people do with it, and JS is the worst, both in terms of the crap on NPM and the web.

TimTheTinker 6y ago
> I don't think the NPM ecosystem is as valuable as people think it is Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted. There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.
sublimefire 6y ago
Your thoughts and experience resonate with me. Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it. It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.
cloverich 6y ago
I mostly agree with this, after using Node the last several years. IMHO the primary valuable components are making it free to implement the commenest kinds of concurrency correctly. I.e. most programmers don't even know they are doing it, other than "Oh I have to use `await` here". Even in something as simple as Go, you still have to intentionally set it up. And in Java, I run into very slow very low volume apps all the time because programmers don't realize they added a blocking call somewhere.
notJim 6y ago
> Most of the packages on NPM are complete garbage And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code. The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.
- ggregoire 6y ago
  So if you need that package in your 10 projects, do you copy those 20 lines of code in your 10 projects? Yikes. Then what happens when it requires a change? Do you make the change in all your projects? Double yikes. When it becomes 30 lines, do you still copy/paste those 30 lines in all your projects? Do you also copy/paste the tests related to those 30 lines in all your projects? ... Having reusable code wrapped into packages is basic software engineering.
  - nightski 6y ago
    Or you create a library which contains a collection of 10-20 line of code modules and share it among your projects.
    - ggregoire 6y ago
      Yes I agree it's better to have one library with 20 helper functions than 20 libraries with 1 function each. Think Lodash. Although some people will then complain about the size of the library...
      - speedgoose 6y ago
        Yes. Every Lodash function is available in its own npm package too. I use it like this, I rather have 4 lodash packages than the big whole lodash library in one package with almost everything left unused.
kybernetikos 6y ago
> I don't think the NPM ecosystem is as valuable as people think it is I generally think the NPM ecosystem is pretty cool, but I have noticed that even simple stuff like creating a RESTful service doesn't seem to have stablised in the ways I would have expected given node's target audience, and you end up writing a lot of the boilerplate yourself. Hopefully this will result in hundreds of replies telling me how I should be doing it, but even the fact that it's not trivial to find that out is a sign of a fragmented ecosystem.

by tomxor 6y ago

TimTheTinker 6y ago

> I don't think the NPM ecosystem is as valuable as people think it is Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted. There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.

sublimefire 6y ago

Your thoughts and experience resonate with me. Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it. It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.

cloverich 6y ago

I mostly agree with this, after using Node the last several years. IMHO the primary valuable components are making it free to implement the commenest kinds of concurrency correctly. I.e. most programmers don't even know they are doing it, other than "Oh I have to use `await` here". Even in something as simple as Go, you still have to intentionally set it up. And in Java, I run into very slow very low volume apps all the time because programmers don't realize they added a blocking call somewhere.

notJim 6y ago

> Most of the packages on NPM are complete garbage And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code. The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.

ggregoire 6y ago
So if you need that package in your 10 projects, do you copy those 20 lines of code in your 10 projects? Yikes. Then what happens when it requires a change? Do you make the change in all your projects? Double yikes. When it becomes 30 lines, do you still copy/paste those 30 lines in all your projects? Do you also copy/paste the tests related to those 30 lines in all your projects? ... Having reusable code wrapped into packages is basic software engineering.
- nightski 6y ago
  Or you create a library which contains a collection of 10-20 line of code modules and share it among your projects.
  - ggregoire 6y ago
    Yes I agree it's better to have one library with 20 helper functions than 20 libraries with 1 function each. Think Lodash. Although some people will then complain about the size of the library...
    - speedgoose 6y ago
      Yes. Every Lodash function is available in its own npm package too. I use it like this, I rather have 4 lodash packages than the big whole lodash library in one package with almost everything left unused.

kybernetikos 6y ago

> I don't think the NPM ecosystem is as valuable as people think it is I generally think the NPM ecosystem is pretty cool, but I have noticed that even simple stuff like creating a RESTful service doesn't seem to have stablised in the ways I would have expected given node's target audience, and you end up writing a lot of the boilerplate yourself. Hopefully this will result in hundreds of replies telling me how I should be doing it, but even the fact that it's not trivial to find that out is a sign of a fragmented ecosystem.