Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?
Zoom out and think about how mad this is. Like if we tried to build “Web 2.0” inside Adobe Acrobat Reader.
Apple has prescribed front-end frameworks like AppKit and UiKit and now SwiftUI, Linux had Gnome and GTK and whatever (I’m not an expert and my knowledge here is out of date)… there’s never been a Correct Way to build a web app because the browser doesn’t have an Apple Microsoft or Linux Foundation, so we’ve been winging it all along.
I’m similarly tired of framework churn, NextJS server components might be the breaking point for me. But there’s no way I’m going back from component driven architecture, and I’m not sure what a vanilla js answer to a static site builder like Next (back when it was good) or Gatsby would be like.
It's too bad Java sucked so much. Maybe we could have had applets that worked like desktop apps, keeping the app-type stuff within applets and leaving the document reader alone. Probably not.
(But yes, I think this is a good assessment, and it matches my experience.)
Gen 1 wars (up through 2010-ish), we had: jQuery-UI, Prototype, SproutCore, YUI, MooTools, Google Web Toolkit, Dojo, ExtJS, BackboneJS, etc. There were no survivors.
Gen 2 wars (up through 2015-ish): Angular, KnockoutJS, Ember, Enyo, React, Vue, Meteor, Polymer, Aurelia, Elm, Mithril, etc.
Gen 3 wars (up through today): React, pReact, Vue, Angular 2, Svelte, SolidJS, AlpineJS, InfernoJS, Lit, etc.
We're actually more stable than we have been in a long time. The difference in performance changing frameworks could often get 10x or sometimes even closer to 100x performance increase. Today, even the slowest framework is generally within 20-30% of hyper-optimized VanillaJS. You really can't go wrong with any of them anymore.
I remember the divisions slightly differently . There seemed to be a core movement from Ember.js and backbone onto Angular. Then from angular to react. Now I am seeing some movement off of react onto alternatives like Vue and Svelte, but almost everyone still is using react. Most shops have issues with the React part of their stack. It's still hard to get buy in for the alternatives in production. No one is using web assembly or even knows what a web component is.
I disagree about the comment about not going wrong with either. This assumes you or your team have the time to maintain the stack with the large amount of dependencies, as there are security patches often and deprecations often. It's a waste when it seems like a large portion of the actual market is just creating dashboard products. You can handle this with a much lighter frontend if you can get buy in (you can't).
React, Backbone, jQuery.
SwiftUI, AppKit, Cocoa, Carbon, Toolbox.
WinUI 3, UWP, WinRT XAML, WPF, WinForms, Win32 GDI.
---
Of course this is misleading, because React has had so much internal churn. But desktop toolkits also have churn.
(And sure you could view AppKit/Cocoa/SwiftUI as distinct frameworks, but ultimately they're all just different interfaces to the same event loop and there's typically a clear indication which one you should be using in which context. The transition from Carbon to Cocoa took more than a decade to complete!!! Most of my Cocoa code from the era can be gotten to compile with modern macosx in under an hour, and most of the performance lessons from then apply directly to AppKit. SwiftUI can and should be used as a wrapper around these views if possible.)
imo a real "lineage" would be something like…
- pre-AJAX, server-rendered sites (PHP, JSP, ASP, ColdFusion; no division of front/back-end)
- the monolithic framework era (Drupal, Ruby on Rails, Laravel) with some AJAX Javascript and jQuery sprinkled in
- the modern era of reactive frameworks (front-end fully decoupled)
Even within the most popular modern framework, NextJS, the first question a developer has to ask is “how do I manage state?” Actually that's the second question; the first is “how do I manage styling? should I use Tailwind, or something that doesn't suck?"
Immediately you're looking at dozens of conceptually different choices, which makes one wonder if it even makes sense to call NextJS a framework at all. A real framework would have prescribed methods.
This is why there's front-end churn, there's never been a right way to do any of this, because the web wasn't designed to be an app platform. It's all hacks, from top to bottom.
- storing data in JavaScript, not in DOM elements
- separate models and views before JavaScript even had the class keyword
- decoupling from your back-end through a RESTful API
- templates that would be filled with data in the browser
- client-side routing
However, it was not in the same league as reactive frameworks like Angular.js or Ember. It was missing two big things, which destined it to be a bridge from the jQuery era to the present.
- Reactivity that stretches to the DOM. Backbone's views had a `render` hook you had to implement that expected you to either replace the HTML wholesale or go fiddle with the DOM yourself.
- Partials or Components. Backbone didn't support subviews at all.
I'd add another major category and that's ExtJS and friends (large integrated MVC GUI component frameworks), which successfully replicated the [developer] feel of desktop GUI toolkits in the browser, somewhere between your last two categories.
(and I'm not talking about simple static websites)
WebGPU is new, but WebGL came out in 2011.