I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party libraries I use there also tend to deprecate things rarely and carefully. But, if we stop working on a JS codebase for more than a few months, there's a very real chance that it will no longer build with current tools or that an upgrade to fix e.g. a security vulnerability will turn into a gordian nightmare.

I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React.

My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer.

As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...

LOL 2015 was a banner year for the trendy web-dev influencers...I can remember junior developers tripping over themselves trying to implement "flux" to handle some form input. Needlessly complex bullshit libraries got forced down everyone's throat because AngularJS was passe and React was "very mindful, very demure". Eventually flux became "redux", which I gather was a "state management" framework that ripped off a post graduate students custom niche language. And I want to say the redux kid's background was literally microsoft powerpoint scripting. Very surreal time in development.

We need a Behind the Javascript VH1 show.

FWIW, I'm the current Redux maintainer, and that is an absolutely horrible and unfair description of how Redux was created.

Elm was _an_ influence on Redux, but there were many other influences as well. Dan Abramov's prior experience did include some VB (possibly VB.NET, I think), but also a lot of actual JS.

See the actual "History of Redux" and "Prior Art" docs pages, and a couple of my blog posts, for an accurate description of the influences that led to Redux's creation:

- https://redux.js.org/understanding/history-and-design/histor...

- https://redux.js.org/understanding/history-and-design/prior-...

- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

Probably not coincidentally, 2016 was the year that I decided I was done with front-end after about decade of focus.

And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.

It seems that in addition to the issue were some things were actually tedious to do, there has also always been a drive to wow users (or really other devs?) by doing something that pushes the boundaries of what's possible. Once someone has done it, everyone is expected to do it and now work is tedious again. A simple example is how back in 2009/10 everyone was all excited about rounded corners. You had to cut all these assets and got a more complex DOM but it became table stakes. So CSS got an attribute for this. Then we needed fancy grids everywhere and fourteenth elements on mobile which was tedious till frameworks did some of it. I think the wow-treadmill doesn't exist like this on the backend because nobody sees it. The closest equivalent is scaling your architecture for a level that your app will never need.

I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another).

I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.

Hooks were great. But yeah eslint flat config is probably also better than the old format but we could have easily done without that breaking change you're right.

The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.

Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI.

Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language.

React is far more stable to build with and far less experimental.

People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere.

You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.

"Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI."

"People who have never touched any UI tech until HTML/JS have no clue how good they have it"

Tech like:

- Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments?

- Qt, developed and maintained for over 30 years, currently at 6th major release?

- Win32, and frameworks built on top of it like MFC, WinForms, WPF?

Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.

Just to reinforce how stable the desktop environment can be:

- Qt has had a mostly stable interface since Qt 4.0 and that was twenty years ago.

- Win32 has had barely any breaking changes since it was introduced with NT 3.1 in 1993 or so.

Most of the UI/UX churn in that space comes from fashion changes in UI design.

On the other hand, I can write a very complicated graphics-related app in React+tons_of_libs within _days_. It took me months to do that in Win32 API in 2005.

The developer velocity enabled by React is insane.

Yes, saying that calling Win32 APIs is not the most ergonomic approach to writing UIs would be an understatement, but if any software can be called stable, this is it.

I would compare win32 API to vanilla JS. Whatever framework you might want to use on top of win32 is what's comparable to the criticized web tech in the article.

Your win32 app would have been much faster with much less memory hogging though. I would prefer to run that compared to your React app.

The choice really is between React and nothing. React (and Electron) enabled a lot of apps to be written that would not have existed otherwise.

Calling Win32 directly was already old fashion when Windows 95 came out in 1994, let alone 2005 when .NET was four years old.

The only folks already doing Win16 development with pure C code, instead of a C++ framework (OWL, MFC, VCL), VB or Delphi, were stuck in jurassic park.

The only valid reason for raw Win32 applications are games.

I liked it in the Jurrasic park

> Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments

Not always. I attempted to upgrade some open source 32bit Delphi frontend code to 64bit/ARM, but the specific GUI toolkit was never ported.

It's similar for Java frontends, JavaFX in particular seems to be a moving target.

QT is a bit of an outlier in terms of frontend stability, but at the cost of the UI looking pretty dated.

Qt apps UI can look very good if QML is used with some effort. I wrote about it here: https://rubymamistvalove.com/block-editor

This is strange to hear because I switched over to SwiftUI/Native from web-based(react native) because I was so frustrated with the JS UI ecosystem. I would be stuck for a long time from conflicting package dependencies after updating/adding a new library. JS seems like the only ecosystem where adding a few simple libraries results in hundreds of added packages.

People have a lot of opinions of javascript because it really is the Statue of Liberty. You really can know a subset of Algol and have portable apps in the browser asap.

Well gosh darnit, then everyone and their mother is going to come to America

It's an age old envy.

> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.

This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).

It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.

> backed by a SasS service and VC money

While it's valid to distinguish this from "FOSS volunteers working for fun" in a narrow sense, I hope most here recognize by now that this is a very big red flag in exactly the same way.

A highly ambitious business soliticing VC funds will not be prioritizing the stable, long tail support for the boring little users that most of us represent.

By necessity, in their best times, they'll be chasing rocket launch opportunities that may rapidly pivot strategy, and in their worst times, they'll find themselves hunting for costly efforts to prune.

The prior invites radical rearchitecture with deprecations and breaking changes, and the latter is how things just become dusty and abandoned (or -- if a backing service was involved -- wholly inoperable).

If you want your original code to hold up for 3 and 5 and 10 years with zero/light maintenance so you can focus on emerging opportunities ofyour own, rather than endless maintenance churn, (it's reasonable that you might not need this) these "SaaS businesses with VC money" need to be seen as the pied piper luring you into the dark wood.

Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too.

But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK.

I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.

I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency.

For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:

1) Can't update react without updating react-router because react deprecated some API

2) Can't update react-router without updating react because the new version of react-router is using some new API from react

And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.

I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...

I'm a back-end dev, I've avoided being paid to do any front-end work (and/or my bosses have avoided paying me to do any front-end work? hahaha) for getting on a decade now. So no doubt front-end devs will cringe at what I'm about to say (not that I care!). But for the occasional personal front-end stuff that I still do, my "dependency management" is just "copy-paste versioned CDN script tags / CSS link-rel tags into my index.html file". Which is equivalent to (but better than) old-skool copy-pasting into a "vendor" directory" (which of course I also did, back in the day). And my "front-end build system" is just "write vanilla javascript in .js files and include it un-minified un-typescripted un-anything via script tags". I've got better things to do in my spare time, than deal with npm / gulp / yarn / whatever they've invented this week.

At this point in time this is absolutely a "people and process" problem. But also the process that is there has been excercised and is known to folks you may hire. Trying to come up with less of it (or with a different version of it) dramatically shrinks the number of people who can be productive on your product from day 1, and is not a choice to be made lightly. There is also a number of people who will then be spending time convincing you that the "none" or "less" process you have imposed is wrong and you should "just get on with the program".