5 ms·

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by an

• codingdave 2y ago
  Agreed, and I'd add that "obsolete" is a strong word. You can run an older framework for a long, long time. So long as people exist who know your stack and can be hired to work on it when needed, your stack is not "obsolete". "Dated", maybe. "Legacy" is also sometimes an accurate term. But until the day comes when nobody is left who will work on it, it is not "obsolete".
  • 9dev 2y ago
    You can, but at some point things start breaking down. Your dependencies are all outdated and pile up CVEs (which you probably are contractually obligated to do something against.) The dev-tool extension is no longer maintained, and Sentry stops support too. You want to improve things by migrating to the new version or competing framework, but that requires lots of toil, since a lot of things changed in subtle ways or are done differently now, and that has ripple effects. Before you know it, you’ve spent four months playing the zero-sum game of rewriting your frontend. Finally you’ve made it, and then they release Tailwind 4.
    • jchw 2y ago
      Coincidentally, I just migrated something from Tailwind v3 to v4, even though Tailwind isn't really much my cup of tea. The migration tool that they ship was able to do everything. e.g. I ran it, then my project built and worked with v4 instead of v3. Likewise, there haven't really been any major API changes in React lately either, but if you want it to be automated, they ship react-codemods which will handle a surprising amount of edge cases for you when upgrading.
• mlboss 2y ago
  Are you using the same version of React that you started 10 years ago? More importantly can you use the React version that was 10 years ago ? Can you even build a 10 year project ?
  • koito17 2y ago
    At a previous job, the frontend was a ClojureScript codebase dating back to around 2013, with a React-based UI. The codebase survived a decade of major upgrades to ClojureScript and React, and many chunks of code in git blame dated back to 2013 - 2014. For reference, ClojureScript's first public release was in 2011, and the React wrapper the codebase used dates back to December 2013. I think the strong focus on backwards compatibility is what helped ClojureScript (and CLJS libraries we used) stay largely unchanged, but we had plenty of "React code" that wasn't changed at all between 2013 and 2022 since it met business requirements and "just worked". Unfortunately, I don't work there anymore, but I don't see why it'd be impossible to build the early version of that frontend today. Recently, I've been using TypeScript for frontend, and the codebase is still surviving major upgrades to React, TypeScript, and the various libraries we use. However, I will admit that the pace at which libraries release is extremely fast compared to other ecosystems I'm familiar with (Clojure, Java, Rust, etc.).
  • jchw 2y ago
    Well, that's just moving the goal posts. I never said you wouldn't have to do any maintenance at all, just that the floor doesn't just fall from under everyone every 5 years. Even outside of frontend, most ecosystems move fast enough that projects from 10 years ago would be in pretty bad shape. That's long enough that even many C/C++ projects will not compile, if nothing else, as a result of improvements to compilers. As far as a React program from 2015, the maintenance required to get it working in modern React probably wouldn't be all that bad. The biggest transition in React's existence was the move from createClass to ECMAScript 2015 classes. React predates the existence of ECMAScript 2015 classes, having been released in 2013, but once they were available React 13 (2015) they were pretty quickly adopted for reasons obvious. So I'd expect a project from 10 years ago to probably still be using ECMAScript 2015 classes. If not, that transition is mostly mechanical. Definitely a few other potential compatibility breaks over the years, but they're all documented. None of them are going to require a full application rewrite. Can you build a project from 10 years ago, using 10 year old React? Well, yeah, if you want to. You'll need to use an old version of Node.js most likely, but npm still has all of the old packages.
• endemic 2y ago
  It's not just React, but all the other rando packages that your co-workers installed.
  • jchw 2y ago
    Yes, exactly. Please stop doing that! It's not only bad for maintenance to install random packages that get maintained for a couple years (or sometimes barely any time at all,) it's also bad for your bundle sizes. It is annoying having to do a lot more stuff by hand, but it's really not that bad. If you're going to choose third party packages for something, at least vet that they have good support, are backed by a developer or entity that has been around for a while, and that the library itself is sufficiently mature.
• jilles 2y ago
  I've been doing React for about 10 years. Just started playing with Svelte 5 a few days ago. It's so simple to work with. Built a simple stock allocation app and what surprised me most was the bundle size... 9kb (gzip). That's better than any other framework I am aware of. That's even smaller than htmx which is somewhat "anti-js"
  • sickblastoise 2y ago
    I think svelte 5 is an actual innovation, it does not behave or feel like a “framework” to me. It feels like a natural extension of building an front end with raw html, css, js, solving the headaches you eventually hit when you do so.
• moooo99 2y ago
  > And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not as severe as with the shift from v1 to Angular2, but still severely enough that it would require some major re-adjusting. Everything is moving to standalone components, new template syntax, signals, etc. Similar things can be said about React. React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another. And the same thing kind of applies for less specific paradigms. First everything was SSR, then we went full steam into Single Page Apps only to return back to SSR but only partial SSR with Hydration, etc.
  • jchw 2y ago
    I agree with Angular 2 not really being the same as Angular 1. Angular in general was a lot less stable, pushing API breaks inside of release candidates and generally just playing fast and loose with things. That said, there was a migration path to go from Angular 1 to 2 incrementally. It wasn't fantastic, but if you had a large Angular 1 app, it was absolutely better than rewriting the whole damn thing. Angular took a while longer to become more stable. React considered all of its early releases to be 0.x releases, until (I believe) 0.14 -> 15.0, at which point I'd certainly consider React fairly stable. Angular, meanwhile, was kinda unstable until I'd say around v4. Which to be honest, was still a while ago (Google says 2017) but it does bear mentioning. > React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another. The thing is, functional components are not new. They were a part of React 10 years ago, before React was formally considered stable. I do think hooks came a bit later, but it wasn't that much later. I know that many early React clones supported stateless functional components pretty early on. And yes, compatibility is key. You can continue to use class components indefinitely. I don't think they have any plans to deprecate them any time soon.
  • samspot 2y ago
    New Angular versions lose support so fast that they are already highlighted as risks in our TLM tracker on the first day they are released!
• bdlowery 2y ago
  Svelte will never overtake react. It won’t even overtake Vue.
  • jchw 2y ago
    Honestly, I don't even really care that much which frontend library wins, and I've been mostly happy with React as a foundation to build off of. If the future is some Rust-based framework compiled to WASM, that's ultimately fine with me. Just as long as whatever it is is relatively performant and stable and doesn't add 1 megabyte of code to every pageload.
  • andrewchilds 2y ago
    Especially true with the runes update. imo, it traded away the thing that made it unique and truly great in the market: the feeling that you’re just writing vanilla HTML, JS, and CSS.
    • recursive 2y ago
      It was a false feeling. 1) Vue already had runes, under a different name. 2) Svelte's old behavior was only possible with their dependency-tracking compilation step. i.e. not vanilla. 3) runes use proxies, which are vanilla JS, and don't require a build step at all, although svelte may still have them.
• eximius 2y ago
  React today looks very different from React from 10 years ago. Easily as different as being a different framework. So, there is some nuance, but the logic isn't dead quite yet.
  • jchw 2y ago
    I think it's fair enough that libraries and frameworks change in ways that require your project to do some maintenance. I do not get mad when this happens with e.g. Qt. You may argue it happens a lot less frequently with Qt. Fair point, but Qt is very old compared to React. React 10 years ago wasn't even considered stable. If you keep your dependency list short and make boring choices, your app may not still build with modern dependencies after 10 years of neglect. However, it will almost certainly not need to be entirely rewritten, either. I think learning the fundamentals is good and people should learn to acquire less dependencies, but going as far as to say you may as well not use a framework because it will be gone in five years... I think that is hyperbolic.
  • nicoburns 2y ago
    Idiomatic React is different (it now uses hooks and functional components), but the old style of class based components with methods still works, and can be mixed and matched with the newer style so gradual migration is possible. There have been some deprecations over 10 years, but there are automated code migration tools for those.
  • theknarf 2y ago
    React Hooks have been out for 8 years. Idiomatic React code haven't changed much in the last 8 years, mostly it has just been a slow move away from using Redux.
    • joestrouth1 2y ago
      This may be true if you consider React in isolation but nobody uses it that way. 8 years ago create-react-app was new and Next.js v2 was on webpack 3. The former is now obsolete and Next is radically different. And hooks released in 2019
  • 2y ago
• dogcomplex 2y ago
  Yeah but we also got lucky there - like picking the right altcoin. React was just one of many then, and the rest all crumbled. And like OPs said, modern react is quite different than it was 10 years ago
  • michaelsalim 2y ago
    I believe there's an art in choosing the right tools and frameworks. A big one i think is whether it solves a problem that no other tools have solved - rather than just an improvement. React had that which I believe is the reason why they won. There are other "better" iteration after that but they don't inherently solve a big problem.
  • cloverich 2y ago
    > React was just one of many then, and the rest all crumbled. Luck played a role, but if you were well versed in the ecosystem at the time (read: worked professionally in more than one framework), the others all had well known trajectories, limitations, or issues. Angular was just fine; Knockout was eaten by Angular. Ember was way too rigid and magical. jQuery was great but not a framework, more like a lodash. Backbone was really cool but incomplete and didn't help enough. In a way its the best one to compare too, because React was also minimal, but not incomplete - instead the part it did, it did better than you would on your own, then let you do whatever you want with everything else - I think they marked as "The V in MVC" at the time. It was both really powerful, simple, and easy to pick up especially if you were using a lot of jQuery or vanilla js at the time. Its the only one since jQuery that felt like it was simply adding useful stuff, and not taking anything away; I wasn't at all surprised to see it stick as well as jQuery, and for the others to fade. You'd be lucky to outright choose it out of ignorance.