Preferences

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.

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.
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.

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.
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...

We need a Behind the Javascript VH1 show.
Probably not coincidentally, 2016 was the year that I decided I was done with front-end after about decade of focus.
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.

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal