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.
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".
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.
But when I say "javascript ecosystem", I'm talking about Node, and that's clear from my writing.
I don't care for pedantry about what it might also refer to, I'm talking about NodeJS, npm and the problems with it, and that's clear because that's also what the original article is talking about.
> when I say "javascript ecosystem", I'm talking about Node
Can you change your habits?
> I'm talking about NodeJS, npm and the problems with it
So how about just saying that?
> and that's clear
It's not. A person doesn't have to go all in on Sapir–Whorf to recognize that this is fraught with peril.
The original article that you fall back on for support doesn't even agree with you; the argument that the author makes (explicitly, even) is that this actually is a JS-and-not-just-NodeJS problem.
Nor do your earlier remarks agree; you're ignoring now the pushback on your earlier remarks that escape is essentially/almost "impossible". Feels like you're going for a motte-and-bailey here (a type of bait-and-switch argument; see <https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>).
> 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)?
Does that matter? Both for front-end or back-end you generally use NodeJS now, if you are not using an entire other language (like WebAssembly for front-end and PHP for the back-end). Even if you get rid of javascript for the front-end, you'il still have it likely to compile or minify CSS.
Millions of desktops will boot into Gnome Shell today. Millions more people, including people using Windows and Mac and not Gnome Shell, will open Firefox. There will be no NodeJS process running in the background in order to achieve any of this, nor will there be API-compatible runtime involved.
There's absolutely no reason not to say NodeJS when that's what you mean. There is a problem with blanket generalizations about "javascript" that implicate other software and software developers that have absolutely nothing to do with NodeJS or the any of the NodeJS-specific problems that are well past due (read: should have been solved by now). The world is bigger than the back-end/front-end dichotomy that webdevs spend all day thinking about.
I have no idea how to even respond to your CSS comments. Without even getting into whether it's true or not, it's just totally irrelevant. Painfully so. ChatGPT writes more salient responses.
> 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.