12 ms·

Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building

• paradite 11mo ago
  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.
  • monooso 11mo ago
    This a common refrain on HN, frequently used to dismiss what may be perfectly legitimate concerns. It also ignores the central question of whether NPM is more vulnerable to these attacks than other package managers, and should therefore be considered an unreasonable security risk.
    • deleted 11mo ago
      [deleted]
• sublinear 11mo ago
  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.
  • pxc 11mo ago
    The only way a worm like this spreads is usage of the affected packages. The proliferation itself is clear evidence of use.
  • DJBunnies 11mo ago
    Ok, I'll bite; which package repos are "the same or worse" than those of nodejs?
    • cluckindan 11mo ago
      All of them. The issue at hand is not limited to a specific language or tool or ecosystem, rather it is fundamental to using a package manager to install and update 3rd party libraries.
  • macNchz 11mo ago
    I see a bunch under major SaaS vendor namespaces that have millions of weekly downloads…?
    • sublinear 11mo ago
      Popular junk is still junk
  • rlpb 11mo ago
    You need to explain how one is supposed to distinguish and exclude "namespaces pretty much nobody uses" when writing code in this ecosystem. My understanding is that a typical Node developer pretty much has no control over what gets pulled in if they want to get anything done at all. If that's the case, then you don't have an argument. If a developer genuinely has no control, then the point is moot.
    • sublinear 11mo ago
      How is this situation any different from any other ecosystem? I think you don't have an argument here other than that npm is a relatively large public repository. Bad actors and ignorant developers are everywhere else too. There are plenty of npm features to help assess packages and prevent unintended updates, but nothing replaces due diligence.
      • rlpb 11mo ago
        Debian does not excuse security compromises by saying "oh nobody uses that far corner of our repository anyway".
• sph 11mo ago
  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.
  • fouronnes3 11mo ago
    Surely in this case the problem is a technical one, and with more work towards a better security model and practices we can have the best of both worlds, no?
  • dotancohen 11mo ago
    Historically, arguments of "it's popular so that's why it's attacked" have not held up. Notable among them was addressing Windows desktop security vulnerabilities. As Linux and Mac machines became more popular, not to mention Android, the security vulnerabilities in those burgeoning platforms never manifested to the extent that they were in Windows. Nor does cargo or pip seem to be infected with these problems to the extent that npm is.
    • mschuster91 11mo ago
      > Nor does cargo or pip seem to be infected with these problems to the extent that npm is. Easy reason. The target for malware injections is almost always cryptocurrency wallets and cloud credentials (again, mostly to mine cryptocurrencies). And the utter utter majority of stuff interacting with crypto and cloud, combined with a lot of inexperienced juniors who likely won't have the skill to spot they got compromised, is written in NodeJS.
    • whizzter 11mo ago
      Compared to the JS ecosystem and number of users both Python and Rust are puny, also the the NPM ecosystem also allowed by default for a lot of post-install actions since they wanted to enable a smooth experience with compiling and installing native modules (Not entirely sure how Cargo and PIP handles native library dependencies). As for Windows vs the other OS's, yes even the Windows NT family grew out of DOS and Win9x and tried to maintain compatiblity for users over security up until it became untenable. So yes, the base _was_ bad when Windows was dominant but it's far less bad today (why people target high value targets via NPM,etc since it's an easier entry-point). Android/iOS is young enough that they did have plenty of hindsight when it comes to security and could make better decisions (Remember that MS tried to move to UWP/Appx distribution but the ecosystem was too reliant on newer features for it to displace the regular ecosystem). Remember that we've had plenty of annoyed discourse about "Apple locking down computers" here and on other tech forums when they've pushed notarization. I guess my point is that, people love to bash on MS but at the same time complain about how security is affecting their "freedoms" when it comes to other systems (and partly MS), MS is better at the basics today than they were 20-25 years ago and we should be happy about that.
• dkdbejwi383 11mo ago
  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.
• anonymous908213 11mo ago
  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.
  • AIorNot 11mo ago
    So your supposed to write your own posthog? be serious
    • dkdbejwi383 11mo ago
      If they have a HTTP API using standard authentication methods it's not that difficult to create a simple wrapper. Granted a bit more work if you want to do things like input/output validation too, but there's a trade-off between ownership there and avoiding these kinds of supply-chain attacks.
      • jacquesm 11mo ago
        > Granted a bit more work if you want to do things like input/output validation too, A bit? A proper input validator is a lot of work.
        • dkdbejwi383 11mo ago
          If you aim for 100% coverage of the API you're integrating with, sure. But for most applications you're going to only be touching a small surface area, so you can validate paths you know you'll hit. Most of the time you probably don't need 100% parity, you need Just Enough for your use-case.
          • jacquesm 11mo ago
            That's an excellent way to get bitten.
            • 11mo ago
• Gigachad 11mo ago
  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.
  • vintagedave 11mo ago
    The concern is not 'could' happen, but _does_ happen. I know this could occur in many places. But where it seems highly prevalent is NPM. And I am genuinely thinking to myself, is this making using npm a risk?
    • cluckindan 11mo ago
      Just use dependency cooldown. It will mitigate a lot of risk.
      • yoavm 11mo ago
        If you started your Node project yesterday, wouldn't that mean you'd get the fix later?
        • cluckindan 11mo ago
          Obviously you bypass the cooldown to fix critical issues.
        • flexd 11mo ago
          no, because if you used dependency cooldown you wouldn't be using the latest version when you start your project, you would be using the one that is <cooldown period> days/versions old edit: but if that's also compromised earlier... \o/
    • Ygg2 11mo ago
      NPM is the largest possible target for such an attack. Attack an important package, and you can get into the Node and Electron ecosystem. That's a huge prize.
• sandruso 11mo ago
  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.
  • viraptor 11mo ago
    You can write simple front-end without reactive components. Most pages are not full blown apps and they were fine for a very long time with jQuery, whose features have been largely absorbed into plain js/dom/CSS.
• zwnow 11mo ago
  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.
  • jacquesm 11mo ago
    Did Phoenix not require npm at some point or is that not true?
    • allanmacgregor 11mo ago
      At the beginning, but not anymore. You still have the option to pull libraries and packages but is not really required by default.
      • jacquesm 11mo ago
        Oh that's great news I will have to look at it again then. That was a huge turn-off for me, to take one of the most well respected and reliable eco systems and then to pull in one of the worst as a dependency. Thank you for clearing that up.
• rvz 11mo ago
  > 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.
• jacquesm 11mo ago
  > 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.
  • cluckindan 11mo ago
    Node the technology can be used without blindly relying on the update features of npm. Vet your dependency trees, lock your dependency versions at patch level and use dependency cooldown. This is something you also need to do with package managers in other languages, mind you.
    • jacquesm 11mo ago
      If everybody in your country drives on the right side of the road you could theoretically drive on the left. But you won't get very far like that. People use Node because of the availability of the packages, not the other way around.
      • cluckindan 11mo ago
        That’s not a very good analogy. Doing what I suggested is not illegal and doesn’t prevent you from using packages from npm. It’s more akin to due diligence: before driving, you check that your car is safe to drive. At the gas and service station, you choose the proper fuel, proper lubricants and spare parts from a reputable vendor which are appropriate for your car.
        • jacquesm 11mo ago
          Nobody - and I mean absolutely nobody - using Node.js has fully audited all of the dependencies they use and if we find somewhere in a cave a person that did that they are definitely not going to do it all over again when something updates.
          • cluckindan 11mo ago
• weregiraffe 11mo ago
  Building websites =/= Developing new technologies.
  • fragmede 11mo ago
    Yup! No new technologies have been invented or discovered thru building websites since CSS 1.0 in 1996.
    • reconnecting 11mo ago
      Even worse! We lost <FRAME> along the way.
• reconnecting 11mo ago
  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" } 1. https://github.com/tirrenotechnologies/tirreno https://github.com/tirrenotechnologies/tirreno
  • embedding-shape 11mo ago
    Not sure what the language has anything to do with it, we've built JavaScript applications within pulling in 100s of NPM packages before NPM was a thing, people and organizations can still do so today, without having to switch language, if they don't want to. Does it require disciple and a project not run by developers who just learned program? You betcha.
    • reconnecting 11mo ago
      I might say that every interpreter has a different minimum dependency level just to create a simple application. If we're talking about Node.js, there's a long list of dependencies by default. So yes, in comparison, modern vanilla PHP with some level of developer discipline (as you mentioned) is actually quite suitable, but unfortunately not popular, for low-dependency development of web applications.
      • embedding-shape 11mo ago
        > If we're talking about Node.js, there's a long list of dependencies by default. But that's not true? I initialize a project locally, there is zero dependencies by default, and like I did five years ago, I can still build backend/frontend projects with minimal set of dependencies. What changed is what people are willing/OK with doing. Yes, it'll require more effort, obviously, but if you want things to be built properly, it usually takes more effort.
• skwee357 11mo ago
  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.
  • shortrounddev2 11mo ago
    it's interesting that staying up to date with your dependencies is considered a vulnerability in Node
    • skwee357 11mo ago
      People who live on the edge of updates always risk vulnerabilities and incompatibility issues. It’s not about node, but anything software related.
    • bichiliad 11mo ago
      Having a cooldown is different from never updating. I don’t think waiting a few days is a bad security practice in any environment, node or otherwise.
      • vrighter 11mo ago
        But only if most of everyone else doesn't do so.
  • Aperocky 11mo ago
    It has everything to do with node/js. Because the community believes in tiny dependencies that must be updated as often as possible and the tooling reflects that belief.
• throwawayffffas 11mo ago
  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.
• jimbohn 11mo ago
  If I had to bet, the most likely and pragmatic solution will be to have dependencies cooldown and that's it
  • creata 11mo ago
    If everyone does it, then it becomes less effective, because there'd be fewer early testers to experience and report issues, no?
    • jimbohn 11mo ago
      Yes, it's gonna be heuristics all way down. This problem isn't solved formally but the ecosystem(s) having these issues are too big to be discarded "just" because of that.
• matheusmoreira 11mo ago
  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.
  • doug713705 11mo ago
    There are far too many languages and many packages for each of them for this (good) idea to be practicable.
• taleodor 11mo ago
  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-russian-roulette/ https://worklifenotes.com/2025/09/24/npm-has-become-a-russia...
• jollyllama 11mo ago
  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.
• Cthulhu_ 11mo ago
  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.
  • dboreham 11mo ago
    Microsoft owns npmjs.com. They could pay for AI analysis of published version deltas, looking for backdoors and malware.
• shevy-java 11mo ago
  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 https://blog.rubygems.org/2025/07/08/policies-live.html)
  • Yokohiii 11mo ago
    You forget to account for the fact that the xz-utils backdoor was extremely high effort. Literally a high skilled person building trust over time. While it's obviously possible and problematic, it's still a scaling/time issue.
• littlecranky67 11mo ago
  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.)
  • noveltyaccount 11mo ago
    .NET being so batteries-included is one of its best features. And when vulnerabilities do creep in, it's nice to know that Microsoft will fix it rather than hoping a random open source project will.
• WorldMaker 11mo ago
  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/ https://jsr.io/ [1] https://lume.land/ https://lume.land/
• venturecruelty 11mo ago
  Serious answer: no.
• knowitnone3 11mo ago
  Node and npm are not the same things. I'm not even a developer. You're seriously a developer?
• deleted 11mo ago
  [deleted]
• willtemperley 11mo ago
  > Serious question: should someone develop new technologies using Node any more? Serious answer: no. I think I'm going to just use a static site generator, maybe add some WASM modules built with a language that has a sane package manager and enjoy my life instead of getting involved with this cluster of a show.
• 0manrho 11mo ago
  Npm has been a shit show from day 1. Unfortunately, Industry momentum and vc funded "fail fast, fail often" is a hell of a drug. EDIT: Coffee hasnt kicked in yet, that was harsher than I intended. For what it's worth, it's not specifically/solely NPM/nodes fault, more of a convergance of the above and the ecosystem/users just as much as any of the Node/NPM devs/maintainers in combination with it having such a large attack cross section. Even if it had a reputation for being bulletproof and secure as fuck there's still such a large userbase with huge potential if exploited that'd it'd almost assuredly inevitably be compromised from time to time regardless. While I feel we could use a whole lot less javascript on the web (client and server side both), without a competitor or something, it's shear size ensures any such expliot/issue gets amplified 1000x versus nearly any other project save for maybe major OS's and Browsers themselves.
• serial_dev 11mo ago
  Couldn't similar issues happen with Rust, Python, Dart, C#, Java, Ruby? Supply chain attacks are not unique to Node / NPM. I'm sure the list of available attacks are somewhat different, but you can get pwned in all of these ecosystems.