5 ms·

This is an article about ecosystems and package managers, not particularly about JavsScript, which is a scripting language around which one can chose to partici

by dusted 4y ago

This is an article about ecosystems and package managers, not particularly about JavsScript, which is a scripting language around which one can chose to participate in ecosystems and use package managers. The distinction is not as subtle as one would think. It's the same with any program.. dependencies are future liabilities. You pay for fast development now with a future burden of upgrading and incompatibility. That's why I enjoy coming back to the software I've written with that mindset, it does not matter which language.. If I was in the supposedly wrong NIH mode when I wrote it, it still builds..

xnorswap 4y ago
But there's something very different in the JS ecosystem that makes things worse. In the .net world, even with packages managed with Nuget, it doesn't have the same "constantly breaking" problem. For example being "stuck" on an old version of react, because dependency X version 6.x requires react < 17, but dependency X version 7 completely re-wrote their entire API and has so many breaking changes it's not reasonable to upgrade. So you're faced with either being stuck on an old react, or re-writing half your application around the new version of your dependency. In the .net world, things don't move so fast, don't break so much and it's rare that both your dependencies and frameworks all break all at the same time leaving you stranded. The .net 5 transition was the closest thing, but the .net standard pathway mitigated the worst of that, and crucially, .net framework is still well supported. Also in the JS ecosystem, it's not just your application packages but your whole build toolchain that quickly gets out of date and breaks. For example finding that you can't move to the latest version of something because it breaks something else in a "random" location. For example finding out that you when you upgrade node, suddenly node-gyp doesn't work, and this package you likely haven't previously heard of is crucial and central to your build. There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge. There's no such thing as "LTS" in javascript. Node in theory has an LTS release but it's useless as soon as libraries start requiring non-LTS releases. Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility and constant upgrade grinds that it's a significant part of every month, it they shouldn't force you to live on the bleeding edge.
- cxr 4y ago
  Don't you find it odd that you're willing to distinguish .NET as a concept from e.g. a language like C#, but when it comes to what is, in reality, the NodeJS ecosystem that you have an issue with, you pin it broadly on what you call "javascript" (also a language)? > There's no such thing as "LTS" in javascript. In fact, there is. The language is stable—it's at least as backwards compatible as C# (if not moreso). There are even very stable platform APIs available outside the language core, e.g. the non-experimental stuff that the WHATWG/W3C standardizes. What you're doing though is opting for an opinionated, incompatible, vendor-specific fork (NodeJS), then experiencing the ensuing pain that comes with that decision. Maybe if you like the stability of .NET and you find yourself having to use JS, you should rally for a JS-for-.NET cause instead of tacitly feeding the ongoing JS-with-NodeJS hegemony even though it keeps hurting you.
  - xnorswap 4y ago
    I refer to .net as the language a lot of the time too, they are tied even more strongly together, as described in https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... . I'm probably just not being precise about the language. I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that. The javascript ecosystem and it's breakage is down to Node, but the javascript ecosystem is node. Even if you only do web work now you still need node for the build toolchain, it's essentially impossible to escape it. You can't realistically develop without it, even projects like react have given up on trying say anything but "just use create-react-app".
    - cxr 4y ago
      > the javascript ecosystem is node It's not. NodeJS is NodeJS. JavaScript is JavaScript. The James Webb Space Telescope isn't running Node LTS or pulling in left-pad. If you want to make a lateral move and draw comparisons elsewhere: the Java ecosystem is not Sun/Oracle's mobile platform—which never took off, while Android thrives. Languages are absolutely separable from the big loud noisemaker (and the problems they bring with them). As for build toolchains: even taking the comment that "if you only do web work now you still need node for the build toolchain" charitably, we could understand it to mean that NodeJS-based toolchains save you time, rather than that you strictly need them in a literal sense. Even that argument is dubious. It's worth considering, if people spent half as much time working on the drudge work that these toolchains are ostensibly supposed to be saving them time on, instead of dealing with the dysfunction that comes with these tools, where might they be? Ivan is doing a-okay with Photopea despite repudiating basically everything about NodeJS. In practice, those toolchains have proven to be a false economy for many circumstances where they end up being (mis)used. More honestly, they're shiny distractions that people put at the forefront of their attention because that's what they like doing—and they're willing to lie to themselves by saying they're doing something essential. > You can't realistically develop without it Sorry, bud, this is wildly exaggerated. It's simple bullshit. I won't concede to such an argument that doesn't have a firm basis in truth. Or, if you want a pithy rejoinder, here's one: "You can't realistically develop with it!"[1] Firefox is one of the most advanced early codebases that made extensive use of JS for serious use—and still more serious than many of the things that people are writing in JS today—and there was no use of NPM—because neither it nor NodeJS (nor V8!) even existed yet. 1. <https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646>
amadeuspagel 4y ago
Even if you write something yourself, it might not work on a future version of your OS.
constantcrying 4y ago
>JavsScript, which is a scripting language It clearly is not. Whatever it was supposed to be, or might have been in the past JS is not a scripting language.
zelphirkalt 4y ago
Dependencies being future liabilities is one reason why core programming skills are so important. A team with weak core programming skills will quickly make a mess of dependencies, because they will not dare to implement that left pad or that tree recursion themselves. The mess will work, but the cost will be inflicted for as long as the dependencies are in there. Of course there are some things which getting into is not so recommended, because of high initial time cost. Like writing your own web framework. Or correctly implementing data structures or difficult to understand mathematical algorithms, or cryptography stuff.

by dusted 4y ago

xnorswap 4y ago

But there's something very different in the JS ecosystem that makes things worse. In the .net world, even with packages managed with Nuget, it doesn't have the same "constantly breaking" problem. For example being "stuck" on an old version of react, because dependency X version 6.x requires react < 17, but dependency X version 7 completely re-wrote their entire API and has so many breaking changes it's not reasonable to upgrade. So you're faced with either being stuck on an old react, or re-writing half your application around the new version of your dependency. In the .net world, things don't move so fast, don't break so much and it's rare that both your dependencies and frameworks all break all at the same time leaving you stranded. The .net 5 transition was the closest thing, but the .net standard pathway mitigated the worst of that, and crucially, .net framework is still well supported. Also in the JS ecosystem, it's not just your application packages but your whole build toolchain that quickly gets out of date and breaks. For example finding that you can't move to the latest version of something because it breaks something else in a "random" location. For example finding out that you when you upgrade node, suddenly node-gyp doesn't work, and this package you likely haven't previously heard of is crucial and central to your build. There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge. There's no such thing as "LTS" in javascript. Node in theory has an LTS release but it's useless as soon as libraries start requiring non-LTS releases. Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility and constant upgrade grinds that it's a significant part of every month, it they shouldn't force you to live on the bleeding edge.

cxr 4y ago
Don't you find it odd that you're willing to distinguish .NET as a concept from e.g. a language like C#, but when it comes to what is, in reality, the NodeJS ecosystem that you have an issue with, you pin it broadly on what you call "javascript" (also a language)? > There's no such thing as "LTS" in javascript. In fact, there is. The language is stable—it's at least as backwards compatible as C# (if not moreso). There are even very stable platform APIs available outside the language core, e.g. the non-experimental stuff that the WHATWG/W3C standardizes. What you're doing though is opting for an opinionated, incompatible, vendor-specific fork (NodeJS), then experiencing the ensuing pain that comes with that decision. Maybe if you like the stability of .NET and you find yourself having to use JS, you should rally for a JS-for-.NET cause instead of tacitly feeding the ongoing JS-with-NodeJS hegemony even though it keeps hurting you.
- xnorswap 4y ago
  I refer to .net as the language a lot of the time too, they are tied even more strongly together, as described in https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... . I'm probably just not being precise about the language. I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that. The javascript ecosystem and it's breakage is down to Node, but the javascript ecosystem is node. Even if you only do web work now you still need node for the build toolchain, it's essentially impossible to escape it. You can't realistically develop without it, even projects like react have given up on trying say anything but "just use create-react-app".
  - cxr 4y ago
    > the javascript ecosystem is node It's not. NodeJS is NodeJS. JavaScript is JavaScript. The James Webb Space Telescope isn't running Node LTS or pulling in left-pad. If you want to make a lateral move and draw comparisons elsewhere: the Java ecosystem is not Sun/Oracle's mobile platform—which never took off, while Android thrives. Languages are absolutely separable from the big loud noisemaker (and the problems they bring with them). As for build toolchains: even taking the comment that "if you only do web work now you still need node for the build toolchain" charitably, we could understand it to mean that NodeJS-based toolchains save you time, rather than that you strictly need them in a literal sense. Even that argument is dubious. It's worth considering, if people spent half as much time working on the drudge work that these toolchains are ostensibly supposed to be saving them time on, instead of dealing with the dysfunction that comes with these tools, where might they be? Ivan is doing a-okay with Photopea despite repudiating basically everything about NodeJS. In practice, those toolchains have proven to be a false economy for many circumstances where they end up being (mis)used. More honestly, they're shiny distractions that people put at the forefront of their attention because that's what they like doing—and they're willing to lie to themselves by saying they're doing something essential. > You can't realistically develop without it Sorry, bud, this is wildly exaggerated. It's simple bullshit. I won't concede to such an argument that doesn't have a firm basis in truth. Or, if you want a pithy rejoinder, here's one: "You can't realistically develop with it!"[1] Firefox is one of the most advanced early codebases that made extensive use of JS for serious use—and still more serious than many of the things that people are writing in JS today—and there was no use of NPM—because neither it nor NodeJS (nor V8!) even existed yet. 1. <https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646>

amadeuspagel 4y ago

Even if you write something yourself, it might not work on a future version of your OS.

constantcrying 4y ago

>JavsScript, which is a scripting language It clearly is not. Whatever it was supposed to be, or might have been in the past JS is not a scripting language.

zelphirkalt 4y ago

Dependencies being future liabilities is one reason why core programming skills are so important. A team with weak core programming skills will quickly make a mess of dependencies, because they will not dare to implement that left pad or that tree recursion themselves. The mess will work, but the cost will be inflicted for as long as the dependencies are in there. Of course there are some things which getting into is not so recommended, because of high initial time cost. Like writing your own web framework. Or correctly implementing data structures or difficult to understand mathematical algorithms, or cryptography stuff.