8 ms·

Yikes, what is it about node/npm/javascript that makes it feel like a house of cards?

k__ 9y ago
Almost all problems I have with JS projects have to do with npm. It got better with lockfiles, but it seems they're inventing new problems...
mamcx 9y ago
I wonder how much damage need to be done with JS/Node until seriously is put to rest the madness. Is absolutely necessary to break backward compatibility and rebuild JS from the start. With WebAssembly this is doable (without excuses!) and we already have a nice tag to declare what script language to use. This is not possible, you ask? In fact, JS/CSS is the most viable of all the stacks to move forward. Let's use the "advantage" that any JS library/ecosystem die fast and put enough hipster propaganda declaring the ultimate solution. Is too hard? JS is so bad that fix it is too easy. You only need more than the week it originally take to build it.
joezydeco 9y ago
How about the idea that Node has been a hack from day one?
- fiatjaf 9y ago
  What hasn't?
  - jcsnv 9y ago
    Good point
  - nine_k 9y ago
    Quite a few. E.g. ssh definitely was not, Rust was not, TeX was not. But these were mostly second-thought projects of the "let's now finally do everything right" kind.
    - joezydeco 9y ago
      They certainly weren't the cores of other projects, ripped out and made into a standalone thing.
    - happy_rust44 9y ago
      to be fair rust was completely different way early its start and changed dramatically for good when it dropped few things like gc and focused on borrow-checker/concurrency
- briandear 9y ago
  Reminds me of this genius talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- 8n4vidtmkvmk 9y ago
  Node seems OK. NPM OTH is pretty sketch.
- gkya 9y ago
  Node was a very interesting thing back when it started. It was a hack, but a nice kind of hack. You could write some efficient servers with it. But then the community that formed around it, with it the project went berserk.
  - roywiggins 9y ago
    A bit like PHP in that way?
    - gkya 9y ago
      Well, kind of. Node was not a general purpose tool as conceived initially. You would write some I/O bound servers in it. And PHP too is not a general purpose tool, it is for writing interactive web pages (in its pre-Web2.0 sense) easily. Though Node.js was way more intellectually designed. I don't know much about PHP, but there's lots of literature (see https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/).
      - lillesvin 9y ago
        I really wish that people would stop referencing that "Fractal of Bad Design" article. It's outdated and mostly irrelevant now (April 2012, PHP was at 5.4 then, it's at 7.2 now). It's not that I want to defend PHP, I just think people should judge PHP for what it is now instead of what it was several major changes ago. Besides, the author seems to misunderstand a great many things about PHP and languages in general. Here's a short rebuttal (also from April 2012): https://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html https://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.h... that explains some of the misunderstandings.
        zkomp 9y ago
        Hmm are you sure? I've read the fractal of bad design many times. Some issues might be "fixed" but could they fix the actual *fractal of bad design"? Isn't it still a mix of c-style, java-style, inconcistent, left associative, horribly broken language it always was? I always thought the bugs were anecdotal backing of the main point: php is badly designed, non programming language for non programmers, who suffer stockholm syndrome from all php abuse...
megaman22 9y ago
Because it is... It's mollochian complexity heaped on top of layers of excrement and ducktape, and we have collectively entered a state of mass Stockholm Syndrome about the situation. I really would love to ditch web dev and all its myriad tendrils, and go back to native desktop software.
- Pica_soO 9y ago
  Somehow i imagine a native C-Desktopdev and a Webdeveloper meeting in No-Mans Land each party escaping from its own nightmare with that line on the lips, starting with a "Dont run into this direction-"
  - badsectoracula 9y ago
    Eh, i like desktop development and i make desktop apps for 20+ years. Before i got Windows 95 i was even trying to make my own DE for DOS in Turbo Pascal and before that in GW-BASIC :-P. I love the desktop. Web stuff on the other hand can die in a fiery death, as far as i am concerned together with mobile stuff they are the source of everything wrong with the desktop today :-P.
  - none_to_remain 9y ago
    At my job we do native C and C++, some Java, some C#, scripting in Shell, Python, and Perl. When the left-pad incident happened someone said something to the room about it, we all looked it up, and spent a good 15 minutes mind-boggled, laughing and being grateful we weren't web devs. "Wait, you're telling me these people need NPM and GitHub to deploy? Seriously?"
    - nawgszy 9y ago
      >these people need [their package manager] and [their source code management tool] to deploy? Seriously? Not really sure I understand what you're implying there
      - rabidrat 9y ago
foepys 9y ago
I have recently taken over an Angular project (with a C# backend, thankfully) at my job. It took two hours to get it to even compile correctly because some dependencies were apparently outdated in package.json and it just ran on the other dev's machine by accident. I don't understand why I need over 100 dependencies for a simple Angular Single Page App that pulls JSON from the backend and pushes JSON back. Meanwhile, the C# backend (a huge, complicated behemoth of software) ran on the first click.
- __s 9y ago
  Thankfully we now have package-lock.json
- tgtweak 9y ago
  Does that backend use nuget for dependencies?
  - foepys 9y ago
    No. It needs nothing but the .NET Framework (not .NET Core) because .NET is already providing everything we need.
- ep103 9y ago
  Three developers on my team spent the last 4 years pushing for angular. Four years ago, I was 50/50 on it vs react, so whatever, but if my team's really for it, let's do it. Fast forward to angular 2, and we're down to two developers who are still for it. Fast forward to today, I'm down to one angular dev who's still for it, and two of the original three have left for react jobs. Meanwhile, I'm left with a bunch of angular 1 code that needs to be upgraded to angular 2, and a few testing-out-angular-2 projects that are dependency hell. The only reason I ultimately embraced angular 1 to begin with (above reasons aside), was because it was so opinionated about everything, I could throw it at my weaker developers and say: "just learn the angular way to do it", and there was very little left they could meaningfully screw up. Angular proponents on the team would see it as a point of expertise to teach the "angular way" to more junior devs, and everyone left the day feeling good. When it comes to Javascript 95% difficulty with writing good maintainable code is ensuring that your team is all writing to a very exact, and consistent quality and style, since there are so many different ways you can write js, and so many potential pitfalls. And if the team all wants to embrace Google's Angular standard, that works for me. Its far easier to be able to point to an ecosystem with an explicit, opinionated way of writing code, than it is to continuously train people on how to write maintainable code otherwise. But with angular 2, if you haven't been drinking to cool-aid for a while now, it requires so much knowledge just to get running, I can't even have junior devs work on it, without a senior dev who's also an angular fanboy there to make sure everything is set up to begin with. Its absurd. And I'm supposed to sell to the business that we need to migrate all my Angular 1 code to this monstrosity? And then spend time again every 6 months making the necessary upgrades to stay up to date? Get real.
lioeters 9y ago
As a counterpoint, couldn't any sufficiently complex structure be called a hack and a house of cards, when you really dig down into how it's put together? Mm, maybe not any - as some complex systems are well-tested with solid architecture - but just some, or most..
- notatoad 9y ago
  A "house of cards" implies that you don't have to dig to topple it. If you have to really dig down into how it's put together in order to start pulling it apart it isn't really a house of cards. I don't use npm or node for anything serious, and i don't really have any knowledge of how NPM works, but this isn't the first time i've read this story of a whole bunch of packages disappearing and everybody's builds breaking. If everything is a house of cards, then why don't i hear the same stories about PyPI or gems or crates?
  - lioeters 9y ago
    It reminds me of this article, Everything is Broken. Perhaps a house of cards becomes solid architecture through the test of time..? https://medium.com/message/everything-is-broken-81e5f33a24e1 https://medium.com/message/everything-is-broken-81e5f33a24e1
    - sebazzz 9y ago
      The issues with the NPM Registry are not technical but management issues and decisions not properly thought through.
      - zbentley 9y ago
        As of this writing, aren't we still waiting to see what the problem was inside NPM that caused this user's packages to disappear? It might well have been technical. It might well have been managerial. It very likely involved elements of both. But don't you think it's best to save the Monday morning quarterbacking for Monday morning, when all the facts are in?
taurath 9y ago
This in particular is a huge trust failure - working with mutable/replaceable libraries is like working with mutable/replaceable APIs.
- allover 9y ago
  Well they aren't mutable/replaceable, at least not since after the left-pad incident where npm announced new rules to prevent package unpublishing. It seems this was a operational bug at npm inc.
DougWebb 9y ago
Yikes, what is it about node/npm/javascript that makes it feel like a house of cards? I think the (short) answer is "node, npm, and javascript". The longer answer has something to do with the automatic installation of dependencies, and the common use of shell scripts downloaded directly off the internet and executed using the developer's or sysadmin's user account. I used to use CPAN all the time. CPAN would check dependencies for you, but if you didn't have them already you'd get a warning and you'd have to install them yourself. It forced you to be aware of what you're installing, and it applied some pressure on CPAN authors to not go too crazy with dependencies (since they were just as annoyed by the installation process as everyone else.) These days I use NuGet a lot. It does the dependency installation for you, but it asks for permission first. The dialogs could be better about letting you learn about the dependencies before saying they're ok. (In general, NuGet's dialogs could be a lot better about package details.)
- corpMaverick 9y ago
  Also. In CPAN there was a culture of having comprehensive unit tests. If something broke, you would likely see it at installation.
- username223 9y ago
  > I used to use CPAN all the time... CPAN has a setting that force-feeds you dependencies without asking, but I don't think it's on by default. Also, CPAN runs tests by default, which usually takes forever, so users get immediate feedback when packages go dependency-crazy. The modern Perl ecosystem is often stupidly dependency-heavy, but nothing like Node.
- bartread 9y ago
  I had very limited contact with CPAN some years ago but I imagine it was slightly more sane in terms of granularity of dependencies. Whereas a lot of npm modules are relatively small - some tiny - and have their own dependencies. So a simple "npm install blah" command can result in dozens of packages being installed. Dealing with that manually would, in fairness, be a giant chore. Now of course there's a discussion to be had about whether thousands of weeny little modules is a good idea or not but, to be honest, that's a religious debate I'd rather steer clear of.
nanodano 9y ago
Left-bad, I mean, the left-pad fiasco should have been the wake up call.
- setr 9y ago
  How do you not feel embarrassed using such low quality insults..?
  - nanodano 9y ago
    It was just a bad joke, but in all seriousness, that was a big wake up call for a lot of people about the tangled web of npm dependencies.
    - allover 9y ago
      Disagree, it was mainly a wake up call that npm shouldn't allow package deletion, a policy they changed as a result. Every other 'these kids and their dependencies' opinion over the left-pad incident was highly subjective.
borntyping 9y ago
The npm repository is the largest package repository in the world. A lot of the major incidents they've could have happened to other ecosystems (e.g. PyPi allows a user to delete packages that other packages depend on), but they've either not happened or haven't had as large an impact. When npm breaks, everyone notices, because everyone either uses npm or knows someone who does.
- megaman22 9y ago
  Largely because Javacsript is so broken by default that it is almost required to depend on a whole slew of dependencies for functionality other languages contain in their built-in standard libraries. And furthermore, NPM dependencies are broken down into stupidly small units, versioned rapidly, and enforces very little consistency among transitive dependencies. Other languages and package management systems don't encourage this kind of insanity.
  - abritinthebay 9y ago
    I’m impressed. Not one thing you just said is accurate.
    - kevingadd 9y ago
      I'm impressed, because everything they said is accurate.
      - abritinthebay 9y ago
        I know HN is basically an industry wide joke for JS discussion but no, none of that is accurate. Most of it is plain wrong, though some of it is misapplied frustration to the wrong target. But again, I guess I shouldn’t expect more from HN.
        megaman22 9y ago
        What exactly is wrong?

k__ 9y ago

Almost all problems I have with JS projects have to do with npm. It got better with lockfiles, but it seems they're inventing new problems...

mamcx 9y ago

I wonder how much damage need to be done with JS/Node until seriously is put to rest the madness. Is absolutely necessary to break backward compatibility and rebuild JS from the start. With WebAssembly this is doable (without excuses!) and we already have a nice tag to declare what script language to use. This is not possible, you ask? In fact, JS/CSS is the most viable of all the stacks to move forward. Let's use the "advantage" that any JS library/ecosystem die fast and put enough hipster propaganda declaring the ultimate solution. Is too hard? JS is so bad that fix it is too easy. You only need more than the week it originally take to build it.

joezydeco 9y ago

How about the idea that Node has been a hack from day one?

fiatjaf 9y ago
What hasn't?
- jcsnv 9y ago
  Good point
- nine_k 9y ago
  Quite a few. E.g. ssh definitely was not, Rust was not, TeX was not. But these were mostly second-thought projects of the "let's now finally do everything right" kind.
  - joezydeco 9y ago
    They certainly weren't the cores of other projects, ripped out and made into a standalone thing.
  - happy_rust44 9y ago
    to be fair rust was completely different way early its start and changed dramatically for good when it dropped few things like gc and focused on borrow-checker/concurrency
briandear 9y ago
Reminds me of this genius talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
8n4vidtmkvmk 9y ago
Node seems OK. NPM OTH is pretty sketch.
gkya 9y ago
Node was a very interesting thing back when it started. It was a hack, but a nice kind of hack. You could write some efficient servers with it. But then the community that formed around it, with it the project went berserk.
- roywiggins 9y ago
  A bit like PHP in that way?
  - gkya 9y ago
    Well, kind of. Node was not a general purpose tool as conceived initially. You would write some I/O bound servers in it. And PHP too is not a general purpose tool, it is for writing interactive web pages (in its pre-Web2.0 sense) easily. Though Node.js was way more intellectually designed. I don't know much about PHP, but there's lots of literature (see https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/).
    - lillesvin 9y ago
      I really wish that people would stop referencing that "Fractal of Bad Design" article. It's outdated and mostly irrelevant now (April 2012, PHP was at 5.4 then, it's at 7.2 now). It's not that I want to defend PHP, I just think people should judge PHP for what it is now instead of what it was several major changes ago. Besides, the author seems to misunderstand a great many things about PHP and languages in general. Here's a short rebuttal (also from April 2012): https://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html https://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.h... that explains some of the misunderstandings.
      - zkomp 9y ago
        Hmm are you sure? I've read the fractal of bad design many times. Some issues might be "fixed" but could they fix the actual *fractal of bad design"? Isn't it still a mix of c-style, java-style, inconcistent, left associative, horribly broken language it always was? I always thought the bugs were anecdotal backing of the main point: php is badly designed, non programming language for non programmers, who suffer stockholm syndrome from all php abuse...

megaman22 9y ago

Because it is... It's mollochian complexity heaped on top of layers of excrement and ducktape, and we have collectively entered a state of mass Stockholm Syndrome about the situation. I really would love to ditch web dev and all its myriad tendrils, and go back to native desktop software.

Pica_soO 9y ago
Somehow i imagine a native C-Desktopdev and a Webdeveloper meeting in No-Mans Land each party escaping from its own nightmare with that line on the lips, starting with a "Dont run into this direction-"
- badsectoracula 9y ago
  Eh, i like desktop development and i make desktop apps for 20+ years. Before i got Windows 95 i was even trying to make my own DE for DOS in Turbo Pascal and before that in GW-BASIC :-P. I love the desktop. Web stuff on the other hand can die in a fiery death, as far as i am concerned together with mobile stuff they are the source of everything wrong with the desktop today :-P.
- none_to_remain 9y ago
  At my job we do native C and C++, some Java, some C#, scripting in Shell, Python, and Perl. When the left-pad incident happened someone said something to the room about it, we all looked it up, and spent a good 15 minutes mind-boggled, laughing and being grateful we weren't web devs. "Wait, you're telling me these people need NPM and GitHub to deploy? Seriously?"
  - nawgszy 9y ago
    >these people need [their package manager] and [their source code management tool] to deploy? Seriously? Not really sure I understand what you're implying there
    - rabidrat 9y ago

foepys 9y ago

I have recently taken over an Angular project (with a C# backend, thankfully) at my job. It took two hours to get it to even compile correctly because some dependencies were apparently outdated in package.json and it just ran on the other dev's machine by accident. I don't understand why I need over 100 dependencies for a simple Angular Single Page App that pulls JSON from the backend and pushes JSON back. Meanwhile, the C# backend (a huge, complicated behemoth of software) ran on the first click.

__s 9y ago
Thankfully we now have package-lock.json
tgtweak 9y ago
Does that backend use nuget for dependencies?
- foepys 9y ago
  No. It needs nothing but the .NET Framework (not .NET Core) because .NET is already providing everything we need.
ep103 9y ago
Three developers on my team spent the last 4 years pushing for angular. Four years ago, I was 50/50 on it vs react, so whatever, but if my team's really for it, let's do it. Fast forward to angular 2, and we're down to two developers who are still for it. Fast forward to today, I'm down to one angular dev who's still for it, and two of the original three have left for react jobs. Meanwhile, I'm left with a bunch of angular 1 code that needs to be upgraded to angular 2, and a few testing-out-angular-2 projects that are dependency hell. The only reason I ultimately embraced angular 1 to begin with (above reasons aside), was because it was so opinionated about everything, I could throw it at my weaker developers and say: "just learn the angular way to do it", and there was very little left they could meaningfully screw up. Angular proponents on the team would see it as a point of expertise to teach the "angular way" to more junior devs, and everyone left the day feeling good. When it comes to Javascript 95% difficulty with writing good maintainable code is ensuring that your team is all writing to a very exact, and consistent quality and style, since there are so many different ways you can write js, and so many potential pitfalls. And if the team all wants to embrace Google's Angular standard, that works for me. Its far easier to be able to point to an ecosystem with an explicit, opinionated way of writing code, than it is to continuously train people on how to write maintainable code otherwise. But with angular 2, if you haven't been drinking to cool-aid for a while now, it requires so much knowledge just to get running, I can't even have junior devs work on it, without a senior dev who's also an angular fanboy there to make sure everything is set up to begin with. Its absurd. And I'm supposed to sell to the business that we need to migrate all my Angular 1 code to this monstrosity? And then spend time again every 6 months making the necessary upgrades to stay up to date? Get real.

lioeters 9y ago

As a counterpoint, couldn't any sufficiently complex structure be called a hack and a house of cards, when you really dig down into how it's put together? Mm, maybe not any - as some complex systems are well-tested with solid architecture - but just some, or most..

notatoad 9y ago
A "house of cards" implies that you don't have to dig to topple it. If you have to really dig down into how it's put together in order to start pulling it apart it isn't really a house of cards. I don't use npm or node for anything serious, and i don't really have any knowledge of how NPM works, but this isn't the first time i've read this story of a whole bunch of packages disappearing and everybody's builds breaking. If everything is a house of cards, then why don't i hear the same stories about PyPI or gems or crates?
- lioeters 9y ago
  It reminds me of this article, Everything is Broken. Perhaps a house of cards becomes solid architecture through the test of time..? https://medium.com/message/everything-is-broken-81e5f33a24e1 https://medium.com/message/everything-is-broken-81e5f33a24e1
  - sebazzz 9y ago
    The issues with the NPM Registry are not technical but management issues and decisions not properly thought through.
    - zbentley 9y ago
      As of this writing, aren't we still waiting to see what the problem was inside NPM that caused this user's packages to disappear? It might well have been technical. It might well have been managerial. It very likely involved elements of both. But don't you think it's best to save the Monday morning quarterbacking for Monday morning, when all the facts are in?

taurath 9y ago

This in particular is a huge trust failure - working with mutable/replaceable libraries is like working with mutable/replaceable APIs.

allover 9y ago
Well they aren't mutable/replaceable, at least not since after the left-pad incident where npm announced new rules to prevent package unpublishing. It seems this was a operational bug at npm inc.

DougWebb 9y ago

Yikes, what is it about node/npm/javascript that makes it feel like a house of cards? I think the (short) answer is "node, npm, and javascript". The longer answer has something to do with the automatic installation of dependencies, and the common use of shell scripts downloaded directly off the internet and executed using the developer's or sysadmin's user account. I used to use CPAN all the time. CPAN would check dependencies for you, but if you didn't have them already you'd get a warning and you'd have to install them yourself. It forced you to be aware of what you're installing, and it applied some pressure on CPAN authors to not go too crazy with dependencies (since they were just as annoyed by the installation process as everyone else.) These days I use NuGet a lot. It does the dependency installation for you, but it asks for permission first. The dialogs could be better about letting you learn about the dependencies before saying they're ok. (In general, NuGet's dialogs could be a lot better about package details.)

corpMaverick 9y ago
Also. In CPAN there was a culture of having comprehensive unit tests. If something broke, you would likely see it at installation.
username223 9y ago
> I used to use CPAN all the time... CPAN has a setting that force-feeds you dependencies without asking, but I don't think it's on by default. Also, CPAN runs tests by default, which usually takes forever, so users get immediate feedback when packages go dependency-crazy. The modern Perl ecosystem is often stupidly dependency-heavy, but nothing like Node.
bartread 9y ago
I had very limited contact with CPAN some years ago but I imagine it was slightly more sane in terms of granularity of dependencies. Whereas a lot of npm modules are relatively small - some tiny - and have their own dependencies. So a simple "npm install blah" command can result in dozens of packages being installed. Dealing with that manually would, in fairness, be a giant chore. Now of course there's a discussion to be had about whether thousands of weeny little modules is a good idea or not but, to be honest, that's a religious debate I'd rather steer clear of.

nanodano 9y ago

Left-bad, I mean, the left-pad fiasco should have been the wake up call.

setr 9y ago
How do you not feel embarrassed using such low quality insults..?
- nanodano 9y ago
  It was just a bad joke, but in all seriousness, that was a big wake up call for a lot of people about the tangled web of npm dependencies.
  - allover 9y ago
    Disagree, it was mainly a wake up call that npm shouldn't allow package deletion, a policy they changed as a result. Every other 'these kids and their dependencies' opinion over the left-pad incident was highly subjective.

borntyping 9y ago

The npm repository is the largest package repository in the world. A lot of the major incidents they've could have happened to other ecosystems (e.g. PyPi allows a user to delete packages that other packages depend on), but they've either not happened or haven't had as large an impact. When npm breaks, everyone notices, because everyone either uses npm or knows someone who does.

megaman22 9y ago
Largely because Javacsript is so broken by default that it is almost required to depend on a whole slew of dependencies for functionality other languages contain in their built-in standard libraries. And furthermore, NPM dependencies are broken down into stupidly small units, versioned rapidly, and enforces very little consistency among transitive dependencies. Other languages and package management systems don't encourage this kind of insanity.
- abritinthebay 9y ago
  I’m impressed. Not one thing you just said is accurate.
  - kevingadd 9y ago
    I'm impressed, because everything they said is accurate.
    - abritinthebay 9y ago
      I know HN is basically an industry wide joke for JS discussion but no, none of that is accurate. Most of it is plain wrong, though some of it is misapplied frustration to the wrong target. But again, I guess I shouldn’t expect more from HN.
      - megaman22 9y ago
        What exactly is wrong?