5 ms·

If you have to depend on a external library for a simple function which can be written in a intro programming course, it's a red flag.

tinco 5y ago
If you have to depend on Node.JS to run your service, it's a red flag. Still I'm seriously considering Node.JS for every backend project we start, just because it's so much easier to hire for, and the ecosystem is so healthy. We're living in a red flag time for software development.
- xupybd 5y ago
  Isn't Go starting to gain popularity without the downside of Node? I'm saying this as someone that hasn't used either.
- quonn 5y ago
  There‘s nothing wrong with NodeJS in principle, especially when combined with TypeScript. Can you point to something specific?
  - georgyo 5y ago
    For me personally, the fact that even a simple node project will have well over 1000 dependencies is a problem. Slightly more complex projects will have more than 10k dependencies. Auditing is nearly impossible. The complete lack of a standard stdlib means always relying on community packages. Also, not a complaint directly against node directly, but for the ecosystem and developers. There is not a culture of compatibility, further fueled by the fact that multiple versions of the same dependency can be included in the same code base by different dependencies. Coming from any other language were it is a goal to keep external dependencies down, nodejs is nightmare fuel.
  - michaelt 5y ago
    Many people judge programming languages as not just the language, but also the tools, library, community, conventions and so on. After all, if I love Java but hate AbstractSingletonProxyFactoryBeans, I'm probably going to hate being a professional Java developer. Some would see the left-pad incident not as an isolated oddity, but as representative of the entire NodeJS ecosystem - showing a weak standard library, a culture of pulling random, unaudited code from the internet, and rats-nest dependencies.
onion2k 5y ago
It's much worse than that. String.prototype.padStart has been available in Node since 8.0, and browsers for a long time. It's not in IE but polyfills are common. If your first thought is a library, whether you wrote it yourself or not, then you're doing JS badly.
- Vinnl 5y ago
  To be fair, Node.js 8 was released in 2017; this happened in 2016.
Cthulhu_ 5y ago
One big problem here is that Node (and Javascript)'s standard libraries do / did not have a lot of these utilities yet. It's the same with e.g. Java, so Apache Commons is one of the most common libraries to find in a Java application. Go seems to have done a better job with a lot of utilities found in its standard library. But, it also has a mindset that it's better to just copy code than to add a dependency. Another factor there was of course that dependency management was a bit painful and fragmented until a few releases ago, unlike NodeJS which had NPM and its ecosystem not long after it came out.
rShergold 5y ago
It seems to be really common to sling mud at the JavaScript/NPM ecosystem from developers who work in other domains. One of the big constraints we have in front end development is that every added feature adds to the bundle size of code we have to send down the wire to the end user. When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app. JavaScript has more of a culture of many many small hyper focused packages. The logical conclusion being single function packages like left pad. This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free". If everyone did what you are suggesting you would find multiple instances of leftpad. One version you wrote. One version your dependency wrote. One version your dependency's dependency wrote etc.
- ginko 5y ago
  >When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app. Surely there have to be tools to process dependency libraries to strip out any unused code.
  - rShergold 5y ago
    yeah it's called Tree Shaking. It's been a massive area of improvement over the last few years. However JavaScript being dynamic can be very difficult to effectively statically analyse. A good example: There is a library called Moment for handling dates. Due to the way the interface was built it basically can't be tree shaken. It's an excellent library but it's on the heavy side. For a while now people have been moving to libraries like Date-Fns which are collections of individual functions. This library can be tree shaken as it's obvious which functions you are using and which you are not
- austincheney 5y ago
  As a front end developer with nearly 20 years of experience I can objectively call bullshit. The problem is Invented Here syndrome and coddling. https://en.m.wikipedia.org/wiki/Invented_here https://en.m.wikipedia.org/wiki/Invented_here The reason this exists is due to a lack of leadership in the front end space. More specifically, a need to hire untrained entry level developers and deliberately not train them whether due to insecurity elsewhere and a complete inability to write documentation. > If everyone did what you are suggesting you would find multiple instances of leftpad. It was about 8 lines of code a child could write that you probably don’t need in the first place.

tinco 5y ago

If you have to depend on Node.JS to run your service, it's a red flag. Still I'm seriously considering Node.JS for every backend project we start, just because it's so much easier to hire for, and the ecosystem is so healthy. We're living in a red flag time for software development.

xupybd 5y ago
Isn't Go starting to gain popularity without the downside of Node? I'm saying this as someone that hasn't used either.
quonn 5y ago
There‘s nothing wrong with NodeJS in principle, especially when combined with TypeScript. Can you point to something specific?
- georgyo 5y ago
  For me personally, the fact that even a simple node project will have well over 1000 dependencies is a problem. Slightly more complex projects will have more than 10k dependencies. Auditing is nearly impossible. The complete lack of a standard stdlib means always relying on community packages. Also, not a complaint directly against node directly, but for the ecosystem and developers. There is not a culture of compatibility, further fueled by the fact that multiple versions of the same dependency can be included in the same code base by different dependencies. Coming from any other language were it is a goal to keep external dependencies down, nodejs is nightmare fuel.
- michaelt 5y ago
  Many people judge programming languages as not just the language, but also the tools, library, community, conventions and so on. After all, if I love Java but hate AbstractSingletonProxyFactoryBeans, I'm probably going to hate being a professional Java developer. Some would see the left-pad incident not as an isolated oddity, but as representative of the entire NodeJS ecosystem - showing a weak standard library, a culture of pulling random, unaudited code from the internet, and rats-nest dependencies.

onion2k 5y ago

It's much worse than that. String.prototype.padStart has been available in Node since 8.0, and browsers for a long time. It's not in IE but polyfills are common. If your first thought is a library, whether you wrote it yourself or not, then you're doing JS badly.

Vinnl 5y ago
To be fair, Node.js 8 was released in 2017; this happened in 2016.

Cthulhu_ 5y ago

One big problem here is that Node (and Javascript)'s standard libraries do / did not have a lot of these utilities yet. It's the same with e.g. Java, so Apache Commons is one of the most common libraries to find in a Java application. Go seems to have done a better job with a lot of utilities found in its standard library. But, it also has a mindset that it's better to just copy code than to add a dependency. Another factor there was of course that dependency management was a bit painful and fragmented until a few releases ago, unlike NodeJS which had NPM and its ecosystem not long after it came out.

rShergold 5y ago

It seems to be really common to sling mud at the JavaScript/NPM ecosystem from developers who work in other domains. One of the big constraints we have in front end development is that every added feature adds to the bundle size of code we have to send down the wire to the end user. When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app. JavaScript has more of a culture of many many small hyper focused packages. The logical conclusion being single function packages like left pad. This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free". If everyone did what you are suggesting you would find multiple instances of leftpad. One version you wrote. One version your dependency wrote. One version your dependency's dependency wrote etc.

ginko 5y ago
>When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app. Surely there have to be tools to process dependency libraries to strip out any unused code.
- rShergold 5y ago
  yeah it's called Tree Shaking. It's been a massive area of improvement over the last few years. However JavaScript being dynamic can be very difficult to effectively statically analyse. A good example: There is a library called Moment for handling dates. Due to the way the interface was built it basically can't be tree shaken. It's an excellent library but it's on the heavy side. For a while now people have been moving to libraries like Date-Fns which are collections of individual functions. This library can be tree shaken as it's obvious which functions you are using and which you are not
austincheney 5y ago
As a front end developer with nearly 20 years of experience I can objectively call bullshit. The problem is Invented Here syndrome and coddling. https://en.m.wikipedia.org/wiki/Invented_here https://en.m.wikipedia.org/wiki/Invented_here The reason this exists is due to a lack of leadership in the front end space. More specifically, a need to hire untrained entry level developers and deliberately not train them whether due to insecurity elsewhere and a complete inability to write documentation. > If everyone did what you are suggesting you would find multiple instances of leftpad. It was about 8 lines of code a child could write that you probably don’t need in the first place.