6 ms·

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

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?

Raed667 2y ago
Because web apps you see today were not feasible even 10 years ago (and I'm not talking about simple static websites)
- yakshaving_jgt 2y ago
  Like what? I think the web looked more or less the same in 2015 as it does today.
  - Raed667 2y ago
    Wasm, WebGPU, a bunch of PWA features etc...
    - yakshaving_jgt 2y ago
      I mean, we had asm.js in 2013, which ran Unreal Engine 4 in the browser. WebGPU is new, but WebGL came out in 2011.
aredox 2y ago
[flagged]
Eric_WVGG 2y ago
I think it’s because, on a fundamental level, we have been trying to wedge an app platform into a document reader. 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.
- aaronbaugher 2y ago
  Absolutely. It took me a while to realize that I hated web development and why: because of all the layers of stuff you have to deal with on top of that document fetching platform. Something as simple as maintaining a login session is a complicated problem, even before you get into validating users, single sign-on, etc. You can put a lot of that out-of-sight/out-of-mind by letting a framework deal with it, but it's still there, lurking, waiting to bite you. And that's just one small aspect of building a web app. 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.
  - skydhash 2y ago
    But most web apps are actually web sites and they do fit the document model. If we consider the web as a UI layer, it's capabilities are more than just sufficient. The issue is when you want to bring business logic into it, or fighting the document model to bring in your own abstractions.
    - deleted 2y ago
      [deleted]
- ForTheKidz 2y ago
  I'm going to go out on a limb and also suggest that there's a lower barrier to entry with HTML. You get a lot "for free" and this means there's more to choose from. (But yes, I think this is a good assessment, and it matches my experience.)
Kerrick 2y ago
Hmm... 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.
- megous 2y ago
  You left out other 150 major web frameworks.
  - Kerrick 2y ago
    I also left out Qt, Swing, etc. on the desktop. I'm comparing a direct lineage of replacements, not showing diversity of choice.
    - megous 2y ago
      There's no direct lineage.
    - Eric_WVGG 2y ago
      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.
zero_shift 2y ago
It doesn't. It's just a meme. React has been around for eleven years now, and complaints about frontend churn started with the Angular 2 announcement (in late 2015)
- hajile 2y ago
  Churn complaints are older than Angular 2. We'd gone through an entire cycle of churn around templating engines (mustache, handlebars, ejs, jade/pug, nunchucks, underscore, lodash). 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.
  - metalforever 2y ago
    Gen 1 wasn't Gen1. Gen1 for dynamic websites was a lamp stack with yolo javascript in the php header. Then people really started using jQuery because targeting a bunch of browsers at the time was a huge incompatible mess, along with other tools like modernize.js . Then your gen 1 started in earnest, if I remember correctly. 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).
ilrwbwrkhv 2y ago
Noobs. Almost all typescript devs and React devs and especially NextJs devs are terrible programmers and absolute beginners. So that creates churn.
mardifoufs 2y ago
Are you using QT 1.0? I don't think any (updated) desktop GUI from 30 years ago has stayed backwards compatible. So yes frameworks like QT are from 30 years ago but they are entirely different from what they used to be back then. Except for maybe some winforms stuff?

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?

Raed667 2y ago

Because web apps you see today were not feasible even 10 years ago (and I'm not talking about simple static websites)

yakshaving_jgt 2y ago
Like what? I think the web looked more or less the same in 2015 as it does today.
- Raed667 2y ago
  Wasm, WebGPU, a bunch of PWA features etc...
  - yakshaving_jgt 2y ago
    I mean, we had asm.js in 2013, which ran Unreal Engine 4 in the browser. WebGPU is new, but WebGL came out in 2011.

aredox 2y ago

[flagged]

Eric_WVGG 2y ago

I think it’s because, on a fundamental level, we have been trying to wedge an app platform into a document reader. 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.

aaronbaugher 2y ago
Absolutely. It took me a while to realize that I hated web development and why: because of all the layers of stuff you have to deal with on top of that document fetching platform. Something as simple as maintaining a login session is a complicated problem, even before you get into validating users, single sign-on, etc. You can put a lot of that out-of-sight/out-of-mind by letting a framework deal with it, but it's still there, lurking, waiting to bite you. And that's just one small aspect of building a web app. 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.
- skydhash 2y ago
  But most web apps are actually web sites and they do fit the document model. If we consider the web as a UI layer, it's capabilities are more than just sufficient. The issue is when you want to bring business logic into it, or fighting the document model to bring in your own abstractions.
  - deleted 2y ago
    [deleted]
ForTheKidz 2y ago
I'm going to go out on a limb and also suggest that there's a lower barrier to entry with HTML. You get a lot "for free" and this means there's more to choose from. (But yes, I think this is a good assessment, and it matches my experience.)

Kerrick 2y ago

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

megous 2y ago
You left out other 150 major web frameworks.
- Kerrick 2y ago
  I also left out Qt, Swing, etc. on the desktop. I'm comparing a direct lineage of replacements, not showing diversity of choice.
  - megous 2y ago
    There's no direct lineage.
  - Eric_WVGG 2y ago
    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.

zero_shift 2y ago

It doesn't. It's just a meme. React has been around for eleven years now, and complaints about frontend churn started with the Angular 2 announcement (in late 2015)

hajile 2y ago
Churn complaints are older than Angular 2. We'd gone through an entire cycle of churn around templating engines (mustache, handlebars, ejs, jade/pug, nunchucks, underscore, lodash). 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.
- metalforever 2y ago
  Gen 1 wasn't Gen1. Gen1 for dynamic websites was a lamp stack with yolo javascript in the php header. Then people really started using jQuery because targeting a bunch of browsers at the time was a huge incompatible mess, along with other tools like modernize.js . Then your gen 1 started in earnest, if I remember correctly. 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).

ilrwbwrkhv 2y ago

Noobs. Almost all typescript devs and React devs and especially NextJs devs are terrible programmers and absolute beginners. So that creates churn.

mardifoufs 2y ago

Are you using QT 1.0? I don't think any (updated) desktop GUI from 30 years ago has stayed backwards compatible. So yes frameworks like QT are from 30 years ago but they are entirely different from what they used to be back then. Except for maybe some winforms stuff?