Yes, of course. In good faith, I'm not trying to accuse specific WWW frameworks of being less-backwards-compatible—react has actually done a pretty damn good job of guiding people along upgrades. But culture-wise there's a massive difference in discourse, and native apps still have the best quality. Spotify's app is horrifically bad; slack and notion could be worse, but these are hardly examples of excellence. Apps that do perform well seemingly need to hook directly into native widgets to compete (see: tiktok).
(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.)
Hi, I've been a web front-end dev for 25+ years. I have no idea what Backbone is/was. There's no direct lineage there, I think that's a sort of forced reading. Also the whole notion of a "front-end vs back-end" division only covers part of the web's history.
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.
Backbone sat right between the jQuery sprinkle and reactive frameworks era. It popularized a bunch of important concepts that quickly led to the next era:
- 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.
As someone who developed web apps since the DHTML days when DOM was not yet standardized,... :)
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.
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.