A lot of frontend teams are very convinced that rewriting their frontend will lead to the promised land. And I am the bearer of bad tidings.
If you are building a product that you hope has longevity, your frontend framework is the least interesting technical decision for you to make. And all of the time you spend arguing about it is wasted energy.
I will die on this hill.
If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years. That’s just how the frontend community has been operating, and I don’t expect it to change soon. Even the popular frameworks that are still around are completely different. Because change is the name of the game. So they’re gonna rewrite their shit too and just give it a new version number.
Product teams that are smart are getting off the treadmill. Whatever framework you currently have, start investing in getting to know it deeply. Learn the tools until they are not an impediment to your progress. That’s the only option. Replacing it with a shiny new tool is a trap.
I also wanna give a piece of candid advice to engineers who are searching for jobs. If you feel strongly about what framework you want to use, please make that a criteria for your job search. Please stop walking into teams and derailing everything by
73 Comments
mplanchard
I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines.
The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally different configuration and doesn’t support all the same options. Okay, so we just keep the old one and disable the node engine check in pnpm that makes it complain. Want to do a patch upgrade to some dependency? Hope you weren’t relying on any of its type signatures! Pin that as well, with a todo in the codebase hoping someone will update the signatures.
Finally get things running, watch the stream of hundreds of deprecation warnings fly by during the install. Eventually it builds, and I get the hell out of there.
It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’ve been working on a large rust project for nearly four years and in that time there have been a few minor breaking changes in or of third party libraries, but only one major breaking change that required significant changes to our application. Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas.
Okay, rant over.
pwdisswordfishz
> But our current framework layer is working against the grain instead of embracing the platform.
Said the person with this bullshit in their page code, which will not deactivate when JavaScript fails to run:
Guess who just saw it happen.
zwnow
Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too.
Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVueSolidNextNuxt is not the solution but rather trying to patch up some symptoms… The Web needs true change.
ng12
> Whatever framework you choose will be obsolete in 5 years.
I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
rjmill
Great advice, but my case is different because our framework is REALLY hurting us.
/s
It's wild how easy it is to fall into this trap. IMO, if you're considering switching frameworks (especially for perf reasons), your time would be better served by getting parts of your app off framework completely (assuming there's truly no way to get the results you want in your current framework.)
antirez
To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.
havkom
Amen!
krainboltgreene
Giving up on that treadmill after investing 3 insanely intense years consuming everything about it was the best thing I ever did. Now I write elixir (phoenix liveview), sometimes I write javascript (phoenix hooks), sometimes that javascript uses Alpine. Zero pain.
I have never felt more vindicated understanding HTTP, Hypermedia, and HATEOAS than I have in the last three years.
SamuelAdams
Speaking of front end frameworks, whatever happened to Angular(JS)? It seemed to be required on every other job posting, but now things seem to only ask for React or React Native.
ForTheKidz
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?
stackedinserter
> Whatever framework you choose will be obsolete in 5 years.
IDK our product is older than 5 years and React is still not obsolete.
conorbergin
When I made my first website I read things online like "svelte is better than react" and "solid-js will be the next big thing", and I thought this was an important part of web development. Newbies should read MDN and ignore everything else.
MrBuddyCasino
Feels like an article from 2015, where churn was still enormous. Today we have more stability: mostly React, Angular is also still around, some novel approaches like Svelte or HTMX, but mostly its the reactive paradigm packaged in different ways (eg Vue.js). No XHTML, no IE6, heck not even IE. CSS converges on Tailwind.
What is unsolved is the dependency hell: builds break over time, just by NPM rot.
1GZ0
This really strikes cord with me.
I chose early on in my carrier not to use frontend frameworks, precisely because of the added abstraction and inherent complexity they tend to bring to your codebase. Its been tough and limited my prospects significantly as a junior dev. But these days, I'm happy that I chose to steer clear of frameworks. As it really does give you a much more broad understanding of how the web platform works.
Tl;Dr for the juniors out there, learn React if you want a job. Learn javascript if you want a good job.
ThePhysicist
I've seen this so many times already, going from server-rendered web apps to client-side rendered web apps in React, then through multiple generations of state management and component management strategies in React, then back to server-side rendered stuff with Next.js, it is so tiring.
AlexMoffat
The counterpoint is that if you don’t adopt a framework you end up with a “framework” you built yourselves that people outside your team don’t understand, is generally poorly documented and needs constant work to add features existing frameworks already have. There are common features needed on the FE and common problems to solve, why not at least start with something instead of nothing?
hnthrow90348765
We have a jquery/Razor front-end that has a ton of global JS state manipulation and a file called 'common.js' which is a dumping ground for almost any function used in two places regardless of what it does. Many things are reinvented wheels (badly) and the previous team left a ton of XSS vulnerabilities in on top of that. Language differences from the previous offshore team mean things are named strangely to me, but even then, there's sometimes bad names for variables and functions.
Does it still function? Sort of. But most of our bugs are front-end issues because it's difficult to reason about any of the control flow. It isn't just obsolete or an unpopular framework, it's bad code.
There's no way I'm going to stay quiet about rewriting something like that if I want to stay at the company (spoiler: I'm quiet about it) and I don't think anyone else should be quiet about it either. This shit causes stress.
only-one1701
The biggest problem by far with the frontend ecosystem is that it assumes everyone's been writing perfect frontend code which makes deprecation/migration a breeze. Frontend is much more forgiving then backend, which means you can write absolute dogsh*t and have it not be discovered for years. This compounds, unfortunately, and when it comes time for breaking changes in a new library or framework versions, I think the authors of these versions don't understand how bad it is in the average frontend trenches. So more bad code is written to patch over existing bad code, and the cycle continues. Gets worse, in fact.
donbrae
I wonder whether AI being the new and shiny thing will lead to a reduction in ‘innovation’ in front-end frameworks. Front-end dev seems to me to have been a solved problem for years now, yet there are still new ways of doing things for marginal gains. I personally just use vanilla JS (having never built anything Facebook-scale which would necessitate using a tool like React) and would be happy if instead of working on yet more front-end stuff, folk will otherwise build something AI-related, both because that is where the hype is but also because it’s genuinely exciting.
francasso
I think this THE main reason why many people are getting fed up with javascript heavy frontends and switching to technologies like htmx.
Personally I stick to json to feed data to my frontends, but I gave up on "frameworks" a while back and just implemented my own abstractions on top of vanilla js and the dom and have been happily using them for years. If you work in large teams with people that don't care so much tough, that would also have drawbacks.
8s2ngy
I have given this a lot of thought, and I haven't been able to come up with any reasonable long-term solution that avoids major refactors or swapping out libraries and tools. I am leaning toward pairing React with React Router for creating server-side rendered web apps. My thinking is that React has "won" the JavaScript wars, maintaining its popularity consistently over the past decade, and React Router is one of the most downloaded libraries for React. (At this point, I’ve come to terms with the fact that React Router will likely introduce breaking changes in its next major update, as it has done many times in the past.)
PaulHoule
I think of the strange case of react-router which has been through 7 versions, many of which were complete breaking rewrites. It's hard not to come to the conclusion that since they kept rewriting it, they didn't believe in any of them. Lately they made big changes because they want to support SSR but I couldn't give a flying F because we're not using SSR any more than I care about React Native support because we're not using React Native! [1]
I've worked on a lot of code where people tried to use react-router and eventually gave up and have some code where they parse the URL directly and it works just fine. The trouble with react-router is that if you understand it enough to use it, you don't need it that is, you can either write some stupid URL parsing code or you can write some hooks that do 100% of what you want (as opposed to 90% of what you want with their code) with about 25% of the code.
For them it's a tiny amount of code that they understand completely and they have no problem tearing it up and rewriting it all because there is very little to it and it doesn't really do very much. [2] For you you either don't understand it in which case you feel like a hostage to their whims or you do understand it in which case you don't need it.
I am looking at a React 16 app which uses a huge number of third-party components that I badly want to take up to React 17 because of testing. With React 16 the tests can't ever really know that React is done running callbacks which makes them brittle and slow which is a bad enough situation that I don't want to write any more tests. React could have done something about it before because React knows if it has callbacks left to run but they didn't until React 17.
My understanding is that, most likely, all the components I have will work just fine with React 17 or 18 for that matter because the 16 -> 17 and 17 -> 18 transitions caused very little breakage. Their package.json files disagree so I can't just bump to React 17, but rather I have to update all the dependencies to newer version and many of them, like react-router, have a cavalier attitude about compatibility so I'd expect to spend a month at least dealing with all the breaking changes in the dependencies. It's times like this when I wish I could stick an axiom into my package.json that says "Version A of package B is really compatible with React 18" or just fork version A of package B to version A' which has a patched package.json. After all that it is certain that there will be invisible changes in the HTML which will cause us to fail an accessibility audit six months later requiring another month of work to track down.
[1] Sure, somebody else is, but I have enough problems to worry about with the modern web and patching up applications written by interns that I don't need the burden of navigating through the docs over and over and over again having to ignore 80% of the content which is completely irrelevant to me. Never mind that older versions of RR, at the very least, support obsolete methods of navigation which is another thing you don't need filling your headspace.
[2] So little code that it probably takes up more of their headspace to go to a conference and boast about what they did than it did to actually do it!
whatamidoingyo
I had this same mindset when React started gaining popularity. "Vanilla JS all the way". Then I saw the power of React, and fell in love with it. Then I landed a position that uses jQuery and Vanilla JS for everything a few years later… and oh my. It's absolutely awful.
I know, I know, vanilla JS is most likely going to work in 5+ years as opposed to the React codebase, but damn. Wretched.
throwanem
(2024)
rambambram
Good read and I agree fully.
Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack.
CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP.
I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already knew from around 2004, but I feel for all kinds of younger developers who got dragged into the trap.
obiefernandez
Just use Ruby on Rails. Problem solved.
_fat_santa
> Product teams that are smart are getting off the treadmill. Whatever framework you currently have, start investing in getting to know it deeply.
I've been working on a SaaS product for a couple of years and when I first started I picked up MUI as my FE framework. Since then on at least 5 different occasions I looked into replacing it and have always landed back on "no lets keep it".
MUI is far from a perfect FE framework but for me I realized it worked really well because it helped me create pretty professional looking UI's without any designer assistance. And over the years I've learned many of the quirks around the framework and have implemented various tooling to mitigate any shortcomings.
I'm still looking for an eventual replacement though, for a while I thought I was going to jump on Google's official material design spec but then they stopped working on the web version. At this point I'm probably going to gradually adopt TailwindCSS (probably over the course of a year or more) and eventually move my FE to an entirely custom build solution.
But even thinking about this change I still come back to "what's the point?". Customers like my product and use it ever day, MUI has it's shortcomings but it's not something terrible I need to jump ship from. I'm sure I will eventually replace MUI but so far it's been chugging along just fine.
liminal
We're trying to hire an Angular design engineer, so now the recruiter is the person trying to get management to switch to React to make his search easier. The tech doesn't matter too much, but the market forces do.
sherdil2022
If someone new to FE development were to start today, what would the process be?
A) If they are on their own (one-person team), they will do a web search and pick the most popular framework/library etc. Or do some POCs in a few of these frameworks/libraries and pick one.
B) If they are part of a team, they will go with whatever the team has decided
If someone has been doing FE, they either will stick to whatever they are doing or search for what else is out there. Yes. This sounds like a treadmill – but that is part of software development and continuous improvement, right?
Building a website in plain/vanilla JS or no JS is possible.
It all boils down to what is moving the product development forward. And this isn’t always simple or possible with FEs.
There are many choices for BEs and cloud providers as well – and sometimes a combination of those.
In short, there are no right or wrong answers. It is always – “it depends” – on what scenarios you are targeting and what features you want to build
ctrlp
Much of the tech churn in frontend is likely attributable to it being an entry door for beginner coders over other pathways. Most of us got started in web dev and made big messes using frameworks we didn't understand. So e of us got better and changed the framework to make it more x, y, or z. Some decided, I'll build my own that doesn't have those x, y, z problems. And so here we are. TBD if HTML standards can ever replace this cycle.
fitsumbelay
Love a pro-Web Platform post
Really every single point made is well taken, even the if-you-gotta-use-a-JS-framework one(s)
bluGill
As an embedded developer I've long felt the web folks were crazy changing their frameworks all the time. They are not doing anything on the web we haven't done before. Most of the concepts are right out of the mainframe era, and we switched to dumb terminals and PCs for a reason (not always good reasons – there are pros and cons to both approaches)
pandemic_region
If you're in the java world, I feel that Vaadin the "java-only" frontend framework is heavily underused. Yes, http sessions, but no it's not a big deal unless you're scaling beyond 10k+ users and even then so. It's been around for 20+ years, with paying commercial features if needed and they seem to have survived from JSF all the way through the latest version of sveractular.
synergy20
Frontend has always been a pain for me.
Just switched from React to Vue since it's getting harder to stay with React.
then I was thinking maybe just the old bootstrap(alpine.js,htmx) with SSR approach? it's simpler and more importantly, can be maintained a few years down the road without a revamp(due to frontend breaking changes).
In the end, I still stick to Vue.js, as the SSR approach has its own problems, nothing is ideal.
jchw
> 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 any means,) I have been using React for the past… 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. 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. So honestly I think this is out-of-date logic. While frontend dev moves fast, it really isn't that bad. Pick boring choices and you get boring results.
localghost3000
> And if you’re an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies
Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here:
I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical, however, that it will make you more attractive on the job market. It's not that knowing this stuff doesn't matter, it's that folks that make hiring decisions tend to pattern match. The fact is that if you want to maximize your "market value", you still need to be _very_ good at React. This is table stakes. Everything else is great, but if you don't have that foundation, you're limiting your options.
Maybe that is what the author meant and I am just misreading.
breadwinner
> Whatever framework you choose will be obsolete in 5 years.
The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete.
Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie…
It uses two 500-line libraries, hardly a "framework". One for MVC/History and one for TSX.
The notion that you need React/Svelte/Vue/Angular is what is obsolete. All you need is VanillaJS.
upghost
The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.
dewcifer
Front-end dev of 20+ years. Plenty of back-end and full stack work in there too. While I definitely agree with the sentiments in this article, I feel it is a bit more nuanced a conversation than this.
While you can truly swap out the UI and ultimately the front-end doesn't matter if the back-end isn't solid long-term – you can equally swap out/automate/just install a rock solid back-end framework, just like you can a front-end.
Furthermore, the front-end is the single thing that customers/users typically interact with – which makes it drastically more important than is let on in the article. We were recently doing a book study on measuring UX and I am pretty convinced that the way people feel about a thing is more important than how well it functions.
I don't really even call myself front-end or back-end anymore.. to be honest I'm not sure it's as useful of a distinction as it has been in the past. Both aspects of an app need to be solid and also bespoke to a degree imo.
porterehunley
As a developer just starting to get into frontend, I'm wondering how learning core-web technologies has helped frontend developers vs just going all-in on on something like React.
adamtaylor_13
I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there.
And other than that? Pure HTML.
It’s downright lovely. And it’ll still work fine 20 years from now.
TacticalCoder
[dead]
pc86
> If you feel strongly about what framework you want to use, please make that a criteria for your job search. Please stop walking into teams and derailing everything by trying to convince them to switch from framework X to your framework of choice. It’s really annoying and tremendously costly.
We try to screen for this mentality pretty thoroughly in interviews.
Few things are more tiresome than having a product that has been around for years, and that has lots of users, tech debt, edge cases, and business considerations baked into it and having to explain to someone who's been with the company for 2 months that no we probably shouldn't throw out the entire React app and rewrite it in Svelte. An few things are more aggravating than someone who has that idea shot down multiple times and keeps. bringing. it. up.
Any indication in our interview process that you are a language or framework zealot will make it a lot harder for you to move to the next round.
curtisblaine
React 16.8 (the one with hooks) has been stable for almost 6 years and newer React versions are mostly backwards compatible. The real problem are bundler / build tools. Using something like esbuild + tsc goes a really long way and will never get deprecated. If you know the craft enough, you can ignore everything else (save eslint, probably).
czk
I don't disagree with the point being made but it should also be noted that React and Vue are both 11 years old.
Hell, even Meteor.js (anyone remember this one?) is still around and being updated.
Aldipower
Out of curiosity I've just fired up an old dynamic Perl website of mine. Works! 20 years later. On my modern machine!
dekhn
I've proposed an idea several times that I think might resolve this situation, but it's never received any real uptake and I can see some serious issues with the approach.
Instead of building a "inner system" (https://en.wikipedia.org/wiki/Inner-platform_effect) where the browser uses HTML, CSS, and Javascript to create interactive applications, or attempting to make a sandboxed and highly limited execution environment (WebAssembly), browser tabs should be Virtual Machines- in the sense that VMWare, KVM, and HyperV are VMs, not in the sense that some language runtimes are VMs.
Think about it: every tab on your machine could be its own little machine running a full stack and rendering the output to a framebuffer (the tab window content). It provides precisely the sandboxing and virtual IO that existing VMs have already implemented and optimized.
But of course, if you do this, you don't actually need a browser window with tabs: you just render the application to a standalone window. But then really what value does the browser provide, other than giving you some convenient runtime for accessible web resources? So just put the browser runtime in the operating system and host applications within virtual machines. Nothing stops you from building applications using web frameworks- you can still use javascript, HTML, and CSS if you want, within or seperate from existing high quality graphics application frameworks (like Qt, GTK, etc).
Those reading carefully will note this is exactly what (some) operating systems have been capable of doing for longer than the WWW has existed, and all major operating systems now support this natively (KVM, HyperV, Apple Hypervisor) and they also all embed full browser capability in native libraries. The main issue I see is that there are now 2 or 3 hardware architetures (x86, arm, risc-v) and a VM does not directly resolve performance issues of cross-arch translation, so devs would still need to produce binary packages for 2-3 archectures to reach the level of cross-OS compatibility that browsers currently support.
I work frequently with Qt and it's amazing how much better it is for building powerful, complex applications that have long term support.
iamleppert
Make no mistake, the engineers who come in and want to immediately change to another framework, that is purely by design and an organizational play. The goal is to have the team switch to an unfamiliar framework, but one you know well, so you can divide and conquer the team's productivity. It's a great promotion strategy when you're a newcomer with high productivity while the rest of the team is struggling.
ysabelbristol
[dead]
toddwprice
I also miss the web. When HTTP form posts were a thing. React and friends are desktop apps, delivered over HTTP, where the browser is the runtime. You know why we got so obsessed with JavaScript? Cause screen refreshes look janky. "Just use XMLHttpRequest to send the data ONLY over the wire! And get data ONLY as a response!" That's how we got into this mess. I'm not saying you don't need JavaScript, or there aren't reasons to use React. I'm saying there are easier solutions to jank. If good engineering is the ability to design the least complicated solution to a problem, we are far from good engineering.
guybedo
LLMs are a huge win in that regard.
I delegate most of my frontend tasks to Claude Code, no need anymore to waste hours understanding why the latest version of framework xyz isn't compatible anymore with library abc.
Also, it feels like there's way more boilerplate code, repetitive tasks in frontend land, once again my buddy Claude Code can generate UI components html and typescript code 100x faster that i can
guybedo
fwiw i've added a structured summary of the discussion here: https://extraakt.com/extraakts/frontend-development-churn
lo_fye
I once read an article that promoted putting all of your business logic in the database, in the form of stored procedures, functions, etc. I thought the author was completely insane, until I kept reading. "You can change frontends any time you want, or you can run multiple frontends simultaneously. Everything important, including validation, is handled by the database." Have I done it? No… but that opened my mind to a new way of thinking.
timewizard
> If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years.
Frontend guys crack me up. The browser is an extremely advanced environment and ES6 is an extremely powerful language. You don't need a framework. You haven't for 10 years now, which is probably why they're so easy to replace, they're wrappers of very thin technology and very thick opinions.
The only reason to use one is if you want to share code between the web and a native app, otherwise, it's a complete and total waste of your engineering efforts.
proc0
I think there's a big part of the picture being missed here. Frontend is bad because of how the industry treats frontend engineering, and web engineering overall. Companies will make engineers do way more than just focus on the code and build things properly and correctly. This is why they all gravitate towards the new, shiny library and over time the ecosystem is a huge mess of dozens upon dozens of libraries just to build something simple. They want engineers to be more like a technical entrepreneur, thinking about how to add value to the business, and this comes at the expense of building things properly and correctly.
> On a more personal note, this is frustrating to me because I think it’s a big part of why we’re seeing the web stagnate so much. I still run into lots of devs who are creative and enthusiastic about building cool things. They just can’t.
Yes, because they're not allowed to just code. It's no longer enough for the role, and the expectations include everything from talking to stakeholders, to crafting the requirements, to testing, releasing, and doing the telemetry and analyticis. Obviously nobody will have the focus or time to build anything properly this way, and they will always choose to use external libraries instead of making something from scratch that will fit the domain space and will allow full control to build something with no bugs.
It's amazing how the industry has accepted that bugs are normal, and part of building frontends, when good engineering should mean that you are able to build and ship something with almost zero bugs. The industry has changed the role and steered it away from what engineering is supposed to be, which is building things properly, and now people are scratching their heads as to why we have such bad software and everything is so complicated on the frontend.
Illniyar
I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem.
I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3
For backend instead of "let's use this new framework", I get the "let's use this new LANGUAGE" – the newest hottness is to rewrite something in Rust. It was Go before that, haskell, scala, F# (yes I got that too).
You think migrating your frontend code from react to svelte or whatever is troublesome, trying rewriting that VB 6 app :) (Or god forbid something like RPC where your data is in the code)
Not saying that the unstableness of engineering practices aren't a problem. It's a huge problem. Just that it's not a frontend problem.
dcchambers
I was once hopeful that WASM would bring some sanity to browser but…I don't know any more. That was also when I thought (assumed) WASM would get the ability to manipulate the DOM directly but it seems like that's not what the browser overlords want to happen. Having a dependency on javascript doesn't change much IMO.
brainzap
express.js and vue.js with axios/bulma css, has not changed that much in 10 years
pier25
It's not a frontend problem but a JS-ecosystem problem. Happens in the backend too.
The JS landscape is an absolute mess where dependencies have dozens if not hundreds of other dependencies. As an example, this is the dependency graph of Platformatic (a Node framework based on Fastify):
https://npmgraph.js.org/?q=platformatic#zoom=h
Each of those dependencies could be abandoned at any moment. Even huge dependencies like Axios or Express seemed to have been abandoned at one point.
And then each dependency is ruled by whatever their maintainers think is right. Just the other day a dependency I use in prod with aprox 25M downloads per week (React is aprox 26M) and used by 10M Github repos decided it was ok to drop support for Safari versions from about 3 years ago. It's just insane considering Safari has +50% mobile market share in the US.
allenu
I wonder how much of this has been driven by ZIRP, making companies a little bit more lax on what they were spending energy on. Teams are large and devs are decoupled from the end user and end result (PMs, designers, leads, managers have more say on the product being created). That, coupled with devs traditionally, IMO, being enamored by system design and wanting to create even more efficient systems for building things, and given that is the one thing they have direct control over (not the end user experience and product), they would naturally want to focus their efforts on improving their systems for building things, at the sake of missing out on the bigger picture, which is that rebuilding systems has a cost that does not directly translate into net user benefit.
When you're closer to improving the bottom line in terms of sales and user joy, I think there's a greater likelihood that you focus less on spending time rebuilding your platform to whatever is currently hot on the scene. (Not to mention internal promotions may be skewed towards clear engineering efforts vs. more qualitative user-perceived improvements.)
ozim
I am quite some time in the biz but I see it as a feature not a bug.
I was waiting until we get rid of IE6.
Nowadays no one will support anything for dozens of year so you would have to take care of some bug ridden monstrosity because it will get decommissioned because it will just stop working and cost of supporting it will be higher.
Your CRUD web app is not a nuclear powered plant to run 50 years.
jweir
We use Elm for any complicated front end. Elm has not been updated in over five years.
mattlondon
Just use Angular and stop worrying. Batteries included, it works and works well.
Yes there was a big change from v1 to v2, but we are at v19 now I think and upgrades are pretty painless IME (I generally don't even really notice them happening, and there is even a tool to help know what changed: https://angular.dev/update-guide) I've been using it at BigCos now for years and it's really just totally fine, and importantly zero drama.
They key thing is you only need angular so you don't need a whole fleet of dependencies that you also need to migrate at the same time.
medhir
Front-end engineering is incredibly driven by the “fashion” of the moment. The only framework that seems to have maybe overcome fashion is React.
Though React is plagued with its own churn around trends. Perhaps this is aging me a bit but I still can’t get my head around why we threw away class-based components with clear lifecycle methods.
I use hooks regularly now but it just feels so much less elegant than the perfectly fine solution that came before it.
nimish
I love using ai tooling to make frontend engineering trivial. Needs only a minor patch or two but that's enough for me as a dumbass backend/data/distributed systems/site reliability engineer
turnsout
Just write vanilla JS, CSS and HTML. Web standards have improved so much over the past 10 years. You don’t need any of the junk people talk about—not even Tailwind. Not even Svelte. Just KISS.
H1Supreme
Considering all the advancements that Vanilla JS and CSS have made in recent years (plus exciting features like animating "display: none" that are almost fully adopted), I think templated HTML on the server + JS where it's needed, makes more sense than ever. And, that's coming from someone who largely makes their living from React.
Like the author, I've been doing frontend in one way or another for 20 years. The ecosystem, churn, and the absolute juggling act of sync'ing state between the frontend and backend is batshit crazy.
I recently started a proof of concept project using Go templates and HTMX. I'm trying to approximate building a UI with "components" like I would with React. There's still a lot of rough edges, but it's promising. I'm still not sure I need HTMX tbh. I've started managing event listeners myself, and I think I prefer it.
Interestingly enough, managing complex UI state that's based on user roles and permissions is so much easier on the server. Just send the HTML that the user is allowed to see. Done.
That said, React, Vue, et. al has sooo much steam. I don't know how a collective shift in thinking would even begin. Especially considering all the developers who have never known anything but frontend frameworks as a way to build a UI.
meshweaver
> New developers are having an extremely hard time learning enough skills to be gainfully employed. They are drowning in this complex garbage and feeling really disheartened.
> We need to relearn what the web is capable of and go back to that.
> And it [the web] has only gotten better over time while retaining an incredible level of backwards compatibility.
I would suggest that "retaining an incredible level of backwards compatibility" might be one of the sources of this "complex garbage" the web world is drowning in.
The fact that so many people feel the need to reach for a framework makes me wonder if the web doesn't do nearly as much as it needs to do.
Maybe the web will always just be too big, too slow to change, and too bad at pruning out all of the bad ideas that accumulated over the years.
"But what about backwards compatibility? Don't we want all the old web apps to continue to work forever?" Yes, so ship the renderer with the app.
Sure, the current web is probably beyond being able to this, but I'm sure we'll eventually find a far better way to distribute software than the web, a way that makes fewer assumptions about the environment our code will run in.
jongjong
It is kind of gaslighting to say that frontend frameworks don't last more than 5 years when React has been around and popular for more than 10 years and the vast majority of FE jobs today are React.
When I read comments suggesting that frameworks keep changing, it sounds like the kinds of articles which were written 7 to 10 years ago. It made sense to say that back then, the top frameworks DID keep changing. Nowadays it just sounds very strange… It's like complaining about something which is no longer a reality… But which actually turned out to have been a good thing all along.
I actually liked that different companies used different frameworks. It mirrored the reality that no framework is inherently superior to every other framework for every use case. I hate the pretense that React is the silver bullet while simultaneously pretending that it's an underdog struggling for relevance in a world of relentless framework-churn…
notnmeyer
all i know is that nextjs is the absolute worst
anymouse123456
I've been writing UX code professionally since the late 90's and for many years, I have led teams that build relatively complex UX software products at companies you've surely heard of.
It took me about about 5 years before I began to realize no one I had met, had any idea how to do this work in a way that wasn't horrible.
I held out hope, and thought maybe those other super-smarty-pants folks over there had it all figured out.
It took another 10 years to figure out that they most definitely did not have anything figured out at all. Functional weanies, OO nerds, Imperative Prima donnas. No one. Has GUI figured out. Not Apple, Not MS, Not Linux. No One.
I've worked professionally in every language, every framework, every paradigm. I've tried it all.
Writing Graphical User Interfaces is HARD.
The problem is that the problem is HARD.
Graphical User Interfaces (for anything reasonably sophisticated) represent broad and deep, hierarchical, tree-like (or graph-like) projections of large amounts of domain information PLUS some amount of administrative debris.
Changing any state of any node in these large and complex data structures can and often should cause some other node in some faraway sub-branch to instantaneously be updated.
Sometimes, that node is on someone else's computer. Almost always, there's a replicated, similar, but different version of that information on a server somewhere that really must be kept in sync.
The problem is made exponentially more complex when we just drop in some little multi-user, real-time update stories.
This thread is a great example of people shitting on the whole field, and yet… Not one person has figured out how to make front-end development not suck.
The problem appears to be deceptively simple on the surface, and like those sirens, it calls out to weary sailors, only to leave them shipwrecked on the shore.
Funny enough, it turns out that Text-based User Interfaces (TUI's) are far more expressive and exponentially easier to author and maintain.
They just have the little, teeny problem of being a sheer cliff face that users must ascend in order to get anything useful at all.
It's my bet, that the world will be saved by some mixture of Text and Graphical UX that is primarily rooted in Text, but enhanced by graphics, rather than the other way around.
This whole LLM thing looks kind of interesting on that front.
I suspect we'll all look back on the last 30 years with contempt and remorse at all the wasted time and energy we've put into this mess that we've created that is called, "Graphical Applications."
Feel free to rant on about how shitty everything is, but just remember that at least one person out here in the ether knows that your solution either doesn't exist (most likely) or is even worse.
SeanAnderson
I think this issue will slow down as LLMs become more prominent. I find myself being naturally dissuaded from the "shiny, new thing" because it means my LLM won't have a deep set of materials to draw from.
Writing in Bevy was really hard because it was a niche language that has breaking changes every three months.
Writing in Svelte has been decent/good, but LLMs constantly prefer using v4's syntax rather than v5's runes — even with Cursor rules and reminders.
At some point I think the tools will become so overwhelmingly part of my workflow that I'll prefer sticking with the old rather than moving to the new and losing access to well-written LLM code code.
FpUser
I sometime hire web developers to do frontend for my clients. 90% of the time when I talk to them all I can hear is – can we use / rewrite with X/Y/Z/etc framework. Needless to say that I tell them to take a hike right away. I usually ask how would you implement this and that workflow using plain JS (using some specific libs is ok).