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.
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.
What I hear you say is that some publicly available third-party libraries written for use with JS are changing very often, and introduce incompatibilities and breaking changes.
And you write that some publicly available third-party libraries written for use with .NET change less often and/or do not introduce incompatibilities and breaking changes (as often).
Two true statements, which are totally and entirely unrelated to the JavaScript and .net.
> Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility.
I agree, but it does, and the more active the library, the worse.. If you don't believe me, try writing absolutely cutting edge stuff in C, using whatever the most active and hip libraries you can find..
You'll have better success, not because C is a better language (though, I very much like it), but because stuff moves at a slower pace, even the hip C stuff is not _that_ hip, when you look at the amount of code contributed per unit of time, or the amount of new features implemented per release.
Of course I'm being general, you can certainly find JS libraries that are extremely solid, and you can certainly find C libraries that are very fragile, but in general.. they correlate well to the popularity/activity of the language.. but not with any inherent property of the actual language.
.net is a cathedral platform, well manicured by a small trusted force that tries to make eveything fit together, that works semi-cohesively, to produce a manufactured industrially syitable one-solution to everything.
js is a bazaar language, that had many intertwingular existences in different places, doing different in similar things in thousands of different ways. it's innovation & history is chaotic & messy, with many onetime behemoths left by the wayside (jquery, gulp/grunt, backbone, moment, request). everything is a bit messy & organic & grown together, pieces breaking off & advancing one direction then being woven back with another library to work a third way.
> There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge.
i dont disagree.
work has spent considerable time dragging a couple dozen old fairly complex react apps & services we inherited out from node 6, node 8 this year, freshening things up.
it is however amazing how much stuff did just work. how many deps we could look through the changelog on, say, that's fine, and upgrade, and tests pass & on deployment things keep moving along. did we get bleeding edge? eh, like 50% of the time. in many cases we didnt even bother trying to get current. we checked dependabot vulnerabilities & did what we had to, stayed in the past for now. these apps were all running, live, with traffic... it's amazing how much of this messy organic tangle does work.
we did run into some of the version conflicts & problems, some of the conservative concerns, the reasons for fear & trepidation you cite. it wasnt fun work. no one wanted to be here. but we got through it in quick order, and it ended up being a whole lot less pain than us engineers expected & budgeted for. we were left with the impression of ease. confidence grew.
as others have tried to point out, i dont think your real complaint is with JS specifically. the organic nature of this world doesnt suit your desires. and i think that's a reasonable stance, these arent unreasonable values/complaints. but on the other hand, the organic has, i think, taken over with rightful cause. Azure OS is in huge part React, huge part JS. the tech adapts much faster. not being a carefully staged industrially-focused cathedral, being an organic place that values & cherishes idea & potential, has let us try a lot of things & keep exploring where real value is, and has kept leading us to better places. we understand more through the experimentalness of the process, we see such vistas that the cathedral makers could not have dreamed, find higher heights & ascend. & yes, sometimes as we rise above the clouds, we spy yet higher peaks, and we must decide whether & how long to stay where we are, or to try again, move onwards.
personally this organic world has brough me great joy & a wonderful continual sense of progress. that we have kept honing ourselves, reshaping. it feels finally like we are starting to really settle down more, that we have made finer cuts at iteration. apis are much more stable. the platform has amassed a more solid core, as groups like WinterCG bless & spread more of the much developed web platform as stable trustworthy systems. React has spent years building towards Suspense & it seems uncharacteristically humble, for a framework that had iterated so much & so heavily for so long, & there's little on the radar that gives us a sense there will be a next breathtaking new era. the organic has settled, become over time more like the cathedral you might have hoped for.
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.