Anecdata from a JS developer who has been in this ecosystem for 14 years.

I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.

Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.

Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.

Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.

That won't happen, because time to market is the biggest obstacle between the developers and the monies.

If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret.

Because an app is not built to help you. It's built to make them monies. It's not about the user, never.

Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".

I think we've pulled way too much towards "software must be a constantly maintained, living item, and users should update often", thus the recklessness with dependencies. This has also exacerbated the other aspects of dependency hell. But not only does this not match reality, it makes projects very vulnerable to this supply chain hijacking stuff.

I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.

> but there must be a healthy middle ground between that and a library that lets you pick font color.

When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN.

But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.

My opinion on "don't re-invent the wheel" has really shifted with these supply chain attacks and the ease of rolling your own with AI.

I agree that I wouldn't roll my own crypto, but virtually anything else? I'm pretty open.

I would say the solution is to make it small and ugly, back to the way it was in the pre-Web-2.0 era, but SQL injections were a thing back then, and they're still a thing today, it's just now there are frameworks of frameworks built on top of frameworks that make fully understanding a seemingly-simple one liner impossible.

I agree.

I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses.

I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately.

I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example.

Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.

The only time I would agree with that is crypto. Don't roll your own crypto. Otherwise there's minimal downside to rewriting basic things directly, and often its unnecessary if your language has a complete standard library. The only place I feel differently is with something like C, where the standard library is far from complete, in that case it makes perfect sense to rely on many third-party libraries, however you should assess them for robustness and security.