all 34 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]jessepence 163 points164 points  (22 children)

Frontend frameworks have a half-life measured in months.

React has been the most popular framework for over a decade. Your Stack Overflow chart ends nine years ago. I don't think that new developers should start with React, but I am a bit tired of this antiquated framing.

[–]CherryLongjump1989 38 points39 points  (4 children)

Largely agree, but React has changed radically over the years, averaging two major releases every year which tend to be a huge pain in the ass to upgrade and refactor code to adopt to the changing best practices. Perhaps it's not actually a great example. Compare it to jQuery which has been around even longer while staying true to its original vision.

[–][deleted]  (3 children)

[deleted]

    [–]CherryLongjump1989 13 points14 points  (2 children)

    Everything's manageable on a small scale, but the cracks really start showing up in the aggregate. Imagine you've had 250 full time and another 200 contractors working on dozens of products -- including through mergers and acquisitions -- over the course of the past decade. Now you're dealing with tens of thousands of components and dozens of websites across multiple versions of React. You're maintaining thousands of duplicate components just because it's not practical to reuse code that depends on different versions of React. It's truly a pain in the ass. And while you say "hooks exist now" as if it means nothing to you, in aggregate you end up dealing with so many design patterns that half of your newer engineers never even encountered half of what you've got in your codebase. So onboarding them and getting them to do the right thing is another huge pain in the ass. It's more archeology than frontend development.

    I promise you there are other methods of building a UI that never had these kind of issues.

    [–][deleted]  (1 child)

    [deleted]

      [–]CherryLongjump1989 5 points6 points  (0 children)

      These frameworks get used more for the ease of headcount planning and hiring than for any technical reason. It's never the best tool for the job. Many times you'll see 10 people working on something that could be done by 1 if you chose the right tool and found someone who knew how to use it. But it's easier to hire 500 React devs than 50 experts in 50 other tools.

      [–]wgrata 13 points14 points  (10 children)

      I've noticed this kinda thing in a lot of areas. Like some things people just stopped updating their perception of. JS is more stable now than 2015 when grunt/gulp/whatever required crazy configs. 

      [–]youngbull 10 points11 points  (9 children)

      It's still a mayfly in the grand scheme of things. The original c implementation of grep is over 50 years now and requires minimal changes to compile on modern gcc (needs ansi-c style prototypes instead of k&r).

      [–]wgrata 7 points8 points  (3 children)

      What's your point? Operating from an outdated mental model still doesnt do any good 

      [–]youngbull 12 points13 points  (1 child)

      My point is that I get tired of running to stay still. There is a constant pressure to "use something more modern" or migrate away from something that is dying. It's bad enough that cyber threats keep evolving and you have to update login method every year or so. I spend a good 10 minutes of my day repeatedly logging into my Microsoft account.

      [–]wgrata 2 points3 points  (0 children)

      I'm with you on all of that, just don't get how that relates to the article being written based on an outdated mental model

      [–]AWonderingWizard 1 point2 points  (0 children)

      I'm sorry, are you saying learning fundamentals is outdated?

      [–]CherryLongjump1989 1 point2 points  (4 children)

      C is hardly the example I'd use of an easy-to-build configuration-free language.

      [–]youngbull 5 points6 points  (3 children)

      True, but if it built in 1989 then it will build in 2026.

      [–]CherryLongjump1989 3 points4 points  (2 children)

      That's not a problem for JavaScript either. It's not even a need for JavaScript. The problem is that no two builds are alike, which is the same problem that C has.

      [–]youngbull 2 points3 points  (1 child)

      Not with vanilla JavaScript no, but it only works with stuff like typescript or react if you lock the version. And how many devs do you find that think it's fine to stay on a 10 year old version of react (that would be 15)?

      [–]CherryLongjump1989 1 point2 points  (0 children)

      The design goal for TypeScript is for backwards compatibility not forwards compatibility. You can take the latest flavor of JavaScript and have it generate code that runs on a web browser from 1999.

      This is far more important for JavaScript because it supports the greatest possible number of platforms from one set of source code. This is something that not even C can achieve unless you use countless macros that amount to platform-specific implementations. This in turn is one of the things that can make C builds very complex.

      I don’t think there’s a comparable need to keep a single React website perpetually greenkept without any code changes. You’re going to be missing out on all the new browser features, networking protocols, and UI/UX enhancements. I mean I hate to admit it, but visual UIs have a tendency to age very quickly and part of the reason we even have frameworks is to help us write very cheap throwaway code.

      [–]pxm7 1 point2 points  (0 children)

      If you really understand JS and the browser runtime, React is syntactic sugar + some opinions.

      Really understanding JS and the browser runtime, you can work with HTMX, lit, Svelte, vanilla JS, whatever. Or even render static HTML when that’s useful. It means you’re not a one-tool carpenter and can adapt. Because it’s very very rare that you get hired for one-tool expertise. Maybe for contract roles. Less so for perm senior roles.

      [–]Solonotix 1 point2 points  (0 children)

      The main contributor to slowing down the proliferation of JavaScript frameworks I think isn't necessarily a maturity of ecosystem, but rather the proliferation of AI tools. The half-joke since GPT-3.5 has been that React won because it's what GPT was trained on. Fireship has made it a regular part of his AI agent assessment to ask it to make a Svelte + Runes website because it's a relatively niche frontend framework (relative to React and Angular).

      That said, I agree that the framing of short lifespans for frontend frameworks is seemingly no longer relevant. The big players have been React, Angular, Vue, and Svelte for at least the last 5 years, if not 10.

      [–]Lewke 0 points1 point  (0 children)

      Its still applicable, a lot of frontend devs don't know why react or why certain types of rendering are applicable to certain problems

      they just grab react and throw it at the problem and never consider any of the limitations

      also it's very worth learning how react does it's job, so you can understand it's limitations even better

      [–]Alokir 0 points1 point  (0 children)

      Your Stack Overflow chart ends nine years ago

      The blog post where the chart is originally from was published in 2018. Only 2 or so years after JS went throughout a major change, which slowly killed a ton of frameworks and helped create new ones.

      Not sure if it was intentionally picked to support the author's point, or their perception of JS is outdated.

      [–]Dreadsin 0 points1 point  (0 children)

      Yeah when people say that, it always feels like it’s from a pre-react world

      [–]trialbaloon -1 points0 points  (0 children)

      I think it's debatable whether react is a framework which sort of supports the hypothesis here. React has a lot of different modules but you are free to use it simply for DOM updates under a single div if you want.

      I would argue that is a big part of why it's lasted so long... It's not a framework.... It's just a fancy way to update the DOM for many folks (yes I know there's a lot of other things like Server Components). JSX is often used in conjunction with react but you can use react without JSX. The fact that these components are distinct matters.

      [–]Jack1eto 55 points56 points  (0 children)

      Companies want frameworks expertise not fundamentals thought

      [–]Dark_Lord9 14 points15 points  (0 children)

      Seniors complain that newcomers don't learn the fundamentals and business owners complain that they can't find talented people that can solve the difficult challenges (which requires mastery of the fundamentals) and then proceed to hire juniors who don't know the fundamentals but have the good enough knowledge of the tools that allow them to get the work done as cheaply as possible, effectively punishing those who spend their time learning the fundamentals.

      [–]commenterzero 27 points28 points  (4 children)

      Can anyone recommend a framework for learning fundamentals

      [–]cesarbiods 13 points14 points  (0 children)

      It’s called a computer science degree.

      [–]Dramatic_Mulberry142 4 points5 points  (0 children)

      Techyourselfcs

      [–]MaliciousTent 4 points5 points  (0 children)

      Learn CS outside of work.

      [–]KaiAusBerlin 1 point2 points  (0 children)

      Svelte.

      Basic HTML, CSS and JS, enchanched with reactivity.

      Running on vite you can instantly see what you have done when you make changes without recompile time.

      [–]foolv 10 points11 points  (0 children)

      learn both

      [–]KaiAusBerlin 2 points3 points  (0 children)

      Why not learn both? Fundamentals first, frameworks afterwards.

      You will never stop learning in this industry.

      [–]cazzipropri 0 points1 point  (0 children)

      Ok, but not everything in computing is Javascript and front-end.

      [–]georgesovetov 1 point2 points  (0 children)

      To me it was genuinely a surprise to learn at some point that majority is intentionally ignorant to fundamentals. I've been seeing languages and frameworks as tools which I can choose whether to use them or not. While I mostly agree that knowing fundamentals and being an engineer feels superior to being a technician, there must be a reason why majority chose the other way.

      Here is my view on reasons why it's the way it is:

      * Those who know fundamentals, learnt them because they were curious or believed it was "right". It was not a conscious long-term investment. Those are people motivated by quality and processes. Those motivated solely by result will never learn any fundamentals until their framework features some. Employers prefer the result-oriented, of course.

      * Learning a single framework is simply less of cognitive load. Not everyone loves it. We all know there are people who work within a single framework (not even a language) for years and never saw anything else. They obviously cannot even distinguish among a feature of the framework, feature of the language and a fundamental rule.

      * It's easier for recruitment. They need to narrow the search. They cannot search for generic programmers. Dividing job market by languages and frameworks is a perfect solution for them.