It's not "node" or "Javascript" the problem, it's this convenient packaging model.

This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself.

The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine.

I've started to feel it is much more an npm problem than a node problem. One of the things I've started leaning on more is prioritizing packages from JSR [0]. JSR is a part of Deno's efforts, so is often easiest to use in Deno packages, but most of the things with high scores on JSR get cross-published to npm and the few that prefer JSR only there's an alright JSR bridge to npm.

Of course using more JSR packages does start to add more reason to prefer Deno to Node. Also, there are still some packages that are deno.land/x/ only (sort of the first version of JSR, but no npm cross-compatibility) worth checking out. For instance, I've been impressed with Lume [1], a thoughtful SSG that's sort of the opposite of Astro in that it iterates at a slow, measured pace, and doesn't try to be a kitchen sink but more of workbench with a lot of tools easy to find. It's deno.land/x/ only for now for reasons I don't entirely agree with but I can't deny that JSR can be quite a step up in publishing complexity for not exactly obvious gain.

[0] https://jsr.io/

[1] https://lume.land/

The problem isn't specific to node. NPM is just the most popular repo so the most value for attacks. The same thing could happen on RubyGems, Cargo, or any of the other package managers.

I’m not a node/js apologist, but every time there is a vulnerability in NPM package, this opinion is voiced.

But in reality it has nothing to do with node/js. It’s just because it’s the most used ecosystem. So I really don’t understand the argument of not using node. Just be mindful of your dependencies and avoid updating every day.

We chose to write our platform for product security analytics (1) with PHP, primarily because it still allows us to create a platform without bringing in over 100 dependencies just to render one page.

I know this is a controversial approach, but it still works well in our case.

"require": { "php": ">=8.0",

        "ext-mbstring": "*",

        "bcosca/fatfree-core": "3.9.1",

        "phpmailer/phpmailer": "6.9.3",

        "ruler/ruler": "0.4.0",

        "matomo/device-detector": "6.4.7" }

Node is fine, the issue lies in its package model and culture:

* Many dependencies, so much you don't know (and stop caring) what is being used.

* Automatic and regular updates, new patch versions for minor changes, and a generally accepted best practice of staying up to date on the latest versions of things, due to trauma from old security breaches or big migrations after not updating for a while.

* No review, trust based self-publishing of packages and instant availability

* untransparent pre/postinstall scripts

The fix is both cultural and technological:

* Stop releasing for every fart; once a week is enough, only exception being critical security reasons.

* Stop updating immediately whenever there's an update; once a week is enough.

* Review your updates

* Pay for a package repository that actually reviews changes before making them widely available. Actually I think the organization between NPM should set that up, there's trillion dollar companies using the Node ecosystem who would be willing and able to pay for some security guarantees.

Professionally I am a fulltime FE Dev using Typescript+React. My Backends for my side projects are all done in C#, even so I'd be fluent in node+typescript for that very reason. In a current side project, my backend only has 3 external package dependencies, 2 of which are SQLite+ORM related. The frontend for that sideproject has over 50 (React/Typescript/MaterialUI/NextJS/NX etc.)

There's only two kind of technologies.

The ones that most people use and some people complain about, and the ones that nobody uses and people keep advocating for.

It's not just npm, you should also not trust pypi, rubygems, cargo and all the other programming language package managers.

They are built for programmers, not users. They are designed to allow any random untrusted person to push packages with no oversight whatsoever. You just make an account and push stuff. I have no doubt you can even buy accounts if you're malicious enough.

Users are much better served by the Linux distribution model which has proper maintainers. They take responsibility for the packages they maintain. They go so far as to meet each other in person so they can establish decentralized root of trust via PGP.

Working with the distributions is hard though. Forming relationships with people. Participating in a community. Establishing trust. Working together. Following packaging rules. Integrating with a greater dynamic ecosystem instead of shipping everything as a bloated container whose only purpose is to statically link dynamic libraries. Developers don't want to do any of that.

Too bad. They should have to. Because the npm clusterfuck is what you get when you start using software shipped by totally untrusted randoms nobody cares to know about much less verify.

Using npm is equivalent to installing stuff from the Arch User Repository while deliberately ignoring all the warnings. Malware's been found there as well, to the surprise of absolutely no one.

Node doesn't have any particular relation to NPM? You don't have to download 1000 other people's code. Writing your own code is a thing that you are legally allowed to do, even if you're writing in Javascript.

You can go very far with just node alone (accepts typescript without tsc, has testing framework,...). Include pg library that has no dependencies. Build a thin layer above node and you can have pretty stable setup. I got burnt so many times that I think it is simply impossible to build something that won't break within 3 months if you start including batteries.

When it comes to frontend, well I don't have answers yet.

Hell no.

You need standalone dependencies, like Tailwind offers with its standalone CLI. Predators go where there prey is. NPM is a monoculture. It's like running Windows in the 90's; you're just asking for viruses. But 90% of frontend teams will still use NPM because they can't figure anything else out.

Node itself is still fine and you can do a lot these days without needing tons of library. No need for axios when we have fetch, there's a built-in test runner and assertion library.

There are some things that kind of suck (working with time - will be fixed by the Temporal API eventually), but you can get a lot done without needing lots of dependencies.

Just lock your packages to patch versions, make sure to use versions that are at least a week old.

And maybe don't update your dependencies very often.

Serious answer: no.

Just keep the number of packages you use to a minimum. If some package itself has like 200 deps uninstall that and look for an alternative with less deps or think if you really need said package.

I also switched to Phoenix using Js only when absolutely necessary. Would do the same on Laravel at work if switching to SSR would be feasible...

I do not trust the whole js ecosystem anymore.

If I had to bet, the most likely and pragmatic solution will be to have dependencies cooldown and that's it

You have this issue with ALL external code though. npm/node and javascript overall may exacerbate this problem, but you have it with any other remote repository too - often without even noticing it unless you pay close attention; see the xz-utils backdoor, it took a while before someone noticed the sneaky payload. So I don't think this works as a selective filter against using node, if you have a use case for it.

Take ruby - even before when a certain corporation effectively took over RubyCentral and rubygems.org, almost two years ago they also added a 100.000 download limit. That is, after that threshold was passed, the original author was deprived of the ability to remove the project again - unless the author resigns from rubygems.org. Which I promptly did. I could not accept any corporation trying to force me into maintaining old projects (I tend to remove old projects quickly; the licence allows people to fork it, so they can maintain it if they want to, but my name can not be associated with outdated projects I already abandoned, since newer releases were available. The new corporate overlords running rubygems.org, who keep on lying about "they serve the community", refused to accept this explanation, so my time came to a natural end at rubygems.org. Of course this year it would be even easier since they changed the rules to satisfy their new corporate overlords anyway: https://blog.rubygems.org/2025/07/08/policies-live.html)

If you're looking for practical recommendations how to work with npm maintaining reasonable safety expectations, my post here mostly covers it: https://worklifenotes.com/2025/09/24/npm-has-become-a-russia...

Building websites =/= Developing new technologies.

Node and npm are not the same things. I'm not even a developer. You're seriously a developer?

> Serious question: should someone develop new technologies using Node any more?

I think we have given the Typescript / Javascript communities enough time. These sort of problems will continue to happen regardless of the runtime.

Adding one more library increases the risk of a supply-chain attack like this.

As long as you're using npm or any npm-compatible runtime, then it remains to be an unsolved recurring issue in the npm ecosystem.

The list of affected packages are all under namespaces pretty much nobody uses or are subdependencies of junk libraries nobody should be using if they're serious about writing production code.

I'm getting tired of the anti-Node.js narrative that keeps going around as if other package repos aren't the same or worse.

> Serious question: should someone develop new technologies using Node any more?

Please, no.

It is an absolutely terrible eco system. The layercake of dependencies is just insane.