Sooooo...

why does everyone use a million and 2 modules when working with node? I understand the speed of development goes up pretty quickly by not having to reinvent the wheel by retyping code that already exists, but...

the worst case tradeoff I've personally seen to date is someone who doens't know the difference between a string and an array but they "coded a web app" and it runs like soupy diarrhea.

maybe there's something I'm missing about node development, but I personally like writting code that does some task or function for myself to learn/understand how to do it and implement it. Usually, that also helps me figure out how and where to speed things up.

I'm just postulating that maybe reinventing the wheel can be a good thing, that's probably why we don't see formula1 cars using pennyfarthing wheels. 🧐

Because many "developers" using Node have no idea what they're doing and probably don't even want to improve. Their goal is to do many small jobs and fast.

NB: It's also how you end up with unusable shit.

Of they don't know array Vs string, it's unlikely it's because they are using third party packages. There is a much more fundamental problem there xD

Anyway in answer to question, it's not always about learning. You might be at a level you can certainly write the code yourself in a number of different ways, but if someone *trustworthy* has done it for you in a package with a bunch of features you want, chances are it's a generic set of code that doesn't help your business to write your own for. It's also quite boring to write functionality which is so trivial, it's better to get onto the unique part of the software, the reason you're bothering to write it to begin with.

That said I won't use a package written by some random person. Too much risk. And if the generic problem is very very small, then I write my own.

@craig939393 You don't even know who has written which code because of recursive dependencies.

That will pull in gigabytes of JS trash written by random people from all over the internet, and you have no idea which parts of that will even end up in your project.

The final build shakes the tree and mixes the code through so that you can see what code is being used, but AFAIK not from where it came.

@Fast-Nop You can look at the dependencies, but yes I agree. Trust has to be very selective.

In the .net ecosystem I feel like this is not as big a problem since the amount of tooling offered by highly trusted vendors (including Microsoft) is staggering.

@craig939393 Highly trusted vendors such as Microsoft, haha! It's rather the other way around. If you are on Windows, you are already MS-fucked anyway so that it doesn't really matter.

@Fast-Nop maybe in the past, but modern .NET is very nice. C# and F# with .NET Core is a pleasure to work with compared to most of the other stuff out there imo and Kestrel's performance is great. Plus it runs on Linux.

I think you're conflating two things - small modules vs. shitty apps. They have nothing to do with each other.

@RememberMe And true to form, .net core has the "telemetry" spyware feature enabled by default, or has that changed?

@Fast-Nop it's enabled by default but when you run the cli it shows you text saying that it's on and also how to disable it. And that's for the tools, not the stuff you make.

I’d say laziness and not understanding how to write JavaScript. Recently I saw a seasoned dev use a base64 encoding module instead of the native approach which is simply `Buffer.from(value, ‘utf8’).toString(‘base64’)`

Not worth pulling in a dependency IMO.

@RememberMe I don't trust Microsoft, not even with OSS, and crap like "spyware by default" is just one of the reasons. Too much trust burned over the years.

Another one is that MS hasn't changed and is the same old scumbag company it has always been, and they won't change either. They're just using different tactics to fool devs into believing "now they're nice".

@Fast-Nop yeah well, if you're given a whole bunch of business logic to scale and only like 5 servers to do it, and no option of using C++ or Rust for various reasons, alternatives start drying up pretty fast. Not saying it's the best and my experience is outdated, but it got the job done.

@RememberMe I guess that's one thing MS is good at - knowing what bait to put on the hook.

@Fast-Nop good performance, clean architecture, and a pleasant language that a good chunk of the workforce knows or can follow? Pretty decent "bait".

What would you have done instead, out of curiosity?

@RememberMe Not using it in the first place so that you don't end up with a workforce that has swallowed it hook, line and sinker. Rust is still too fast of a moving target, and too few devs, but C++ is there. Or maybe Java instead of MS' shot at "embrace, extend, destroy" with C# if that's what you have underneath. With OpenJDK of course because Oracle is even worse than MS.

Any ecosystem where anyone is allowed to publish packages suffers with this problem. The bigger problem is that people use unnecessary packages, that's a sign of bad developer and that is irrelevant to node.js, bad developers can write bad code in any language.

let's not forget this exists:

https://npmjs.com/package/is-odd/

@Hazarth it's supposed to be satirical, it's not used by any serious project.

@Hazarth lmao

@theabbie

ye I know, I love the dependencies it pulls as well. But it's essentially a self contained cute little example of what OP is talking about. I love it

@Fast-Nop all options we looked at.
1. There's only one major c++ framework that can offer enough to be useful (drogon) but we wanted a language with a GC because rapid development and change was a need, would prefer to not run around fixing memory bugs (although it's pretty clean with modern c++). The other problem was that people weren't as comfortable with advanced c++, which does need experience because it's trying to solve difficult problems.

2. Looked at Go frameworks, which is a Google dependency. I personally have a love/hate relationship with go - it's a spiritual successor to Erlang which is a language that I adore, but the type system is meh and I don't like a lot of its design choices. Plus it was relatively unknown in the team.

3. Java and C# were our only real options. .NET Core did better in testing, plus most of us preferred C# as a language and .NET Core's architecture. Like I said, it's pleasant. So it won.

Could still have gone C++ but the final nail was safety. I'd rather take a framework supported by a major company rather than an iffy community project that you have no guarantees on whether it'll be alive tomorrow (this is just your point about the problem with Node packages). Support is not about the competence of the team - it's about removing a potential problem and freeing up resources for more useful stuff. Kinda like exception handling - it's not the hot path and is okay if it's excruciatingly slow compared to yours, but it's *there*.

Also, in that side of dev, Java and C# are staples. You can't say I don't want to do this because it's bait, because they're established (and pretty damn good at what they do). It would be like trying to be an embedded dev without knowing C.

I would be concerned with how you have any hope of vetting the code.

> that's a sign of bad developer and that is irrelevant to node.js

@theabbie no kid, that's very specifically a js dev problem - I mean to the extent, afaik no other lang suffers from this horridity.