Who told you to do all those changes? Maybe change who you're listening to, or even better: don't blindly follow what others say/talk about, but listen and think about it thoughtfully instead. Stay on whatever framework/library/platform you want and feel works best for you and your use cases. No one is forcing you to chase the latest trends.
It helps to pick "boring tech", and hope that what has worked will continue to work. But it's still unpleasant to hear about the X killer every week, when X is your bread and butter.
i think the ideas of hypermedia are fairly stable and relevant, particularly the concept of a uniform interface, even if htmx is just one implementation of them
That said htmx is the only remotely intriguing development I've seen in frontend dev in a decade.
I feel like the backend is just an inherently simpler problem to solve, request in, response out. Largely stateless. Of course there are harder things to do like stateful 2-way connections, but the solutions are mostly concentrated on a couple of technologies. Like yeah we have stuff like graphql, but at the end of the day the principle is the same.
The problem is thinking that all of these things are different domains when they really aren't. The web browser is just a program; its job is to fetch resources and render HTML. If you know how HTTP and HTML/CSS work, you can absolutely make great web applications.
But this requires knowledge and expertise, and also maybe not shoehorning an entire application framework into what was designed to be a collection of hyperlinked documents. I suspect this has more to do with money than anything else... the web is dead, long live the web.
The backend and systems programmers are still writing code in a programming language.
So much of FE dev now is stringing together other people's declarative frameworks. When programming is done it's mostly glue. So if you exist in this paradigm you're going to have very strong opinions about whatever framework/tech you are using because it's so hard to operate outside of it. You also gain a vested interest in the survival of whatever you've chosen.
This is why I've been slowly trying to make the transition out of web dev, at least FE. I don't want to deal with this crap anymore!
Interestingly, I think this problem exists in areas of back-end work. I know people who mostly do systems integration, where they're customizing some enterprise behemoth. But since that world is anchored both by the big vendors and by your company's choices of them, it seems saner to me. People may identify as a SAP developer or whatever, but they don't have to advocate for it or have a quasi-religious belief in it.
I don't know FE development enough to speak on it but I agree with your sentiment in general. When I see "declarative," I think "learn by memorization and trial and error rather than reason and intuition."
Thankfully, they don't take over your application code, though they eat a considerable amount of brainspace, especially in the collective discourse.
Discretion and focus remain key skills in tech these days.
I gave up on webdev when this started to set in. Honestly, it felt like a bunch of kids chasing thoughtful engineering out by simply making more noise. Everyone wanted a magic library that relieved them of thinking, but the only way to make decent software is to think deeply about what data flows where, and how it gets there.
I've since rekindled an interest in it after finding some tech that did click with me: Quarkus + Renarde, htmx, Svelte. All of these are off the beaten path and have users that choose to use them, versus those that have to do, and I really think it makes a difference.
> This is why I've been slowly trying to make the transition out of web dev, at least FE.
Systems/backend dev is a lot more friendly to thoughtful engineering IMO. Check out Java, Golang, and Rust and see what libraries/users you click best with.
And honestly, using Rails or other server-side frameworks, you can get very far with way less effort than those expensive front-end teams by simply using Hotwire:
Sending down rendered HTML using Hotwire Turbo requires far less time, and HTML over the wire is in reality no heavier than sending down JSON. If you absolutely need a bit more interactivity on the front-end while avoiding a server roundtrip, it's easy to drop in little Stimulus JS controllers as-needed. From my journeys to and fro in the real world, I've seen most projects do not need more than that, and are arguably wasting budget trying to use heavier tools than that! For most sizeable projects, you can do more in Rails & Hotwire with fewer developers than a 6-person team using their favorite server side language and React. I'm not saying you have to use Ruby on Rails. I'm saying I wish the dev world would embrace this paradigm in whatever their favorite language/frameworks are.
Frontend, you largely have to pick a team. Trying to run multiple frontends in the same page has a number of problems, if nothing other than each of them gets so large that even just one can impact performance, but they will also fight over events, and you can't cross the streams, etc. The whole structure is more winner-take-all, by its nature.
Don't get me wrong, the front-end certainly seems like a mess to me too. Although I think it's actually not quite as bad as it used to be, maybe over the hump one can hope.
Also, and it seems like this has to be pointed out in every one of these threads, the complexity of interfaces we're building on the web now is far greater than what we were building 10 years ago.
I have Python + Tkinter code that’s close to two decades old and still runs great (doesn’t look great tho but it didn’t look great at the time either).
I have some vanilla JS websites that are about as old and still work great.
As other commenters have noted, boring stable choices are there. Ignoring them for the fancy novel brittle stuff is entirely on the programmer.
All of those are good in theory but don't stand against the demands of modern consumers.
If as a technologist you can’t imagine companies making money selling software to happy customers without relying on the brittle trendy framework du jour, my only advice would be to spend less time making silly bets with strangers on internet discussion boards and more time looking at boring profitable companies.
They don't care about React or htmx. They just want something that fixes the problem.
This is actually very freeing: meet a real need and you don't have to believe that software development consists on running on a treadmill of constant changes for their own sake. Just do the job competently.
Most of the time it is dictated by the whims of corporate(by making frameworks/tools as part of a job requirement) or by the mob(teams need to collective decide what technology to use).
You sincerely believe that devs will just add complexity to their work just because?
Meanwhile when I go out in the world I see all manner of front-ends being actively used. It's almost like different users want different things idk.
Backend (and frontend!) can be use stable technology choices if you want to. There are also plenty of bleeding edge libraries/frameworks/languages that come out every week.
As an example, how do you want to deploy your backend? VPS, severless, Kubernetes? What database? Which language? Which libraries?
There are boring stable answers to the above for backend, just like there are boring stable answers to frontend.
Really, I think you’ve just found those boring stable options for the backend and you haven’t done that for the frontend yet.
React has been out for more than a decade and it’s the dominant way of building UIs. And there are pros and cons to this with 1000 solutions, but, really, plain React will work for most things you want to do.
Alternatives are Webpack (stable, boring), Vite (starting to overtake Webpack since it's significantly simpler), and 1000 other libraries.
Again, there is some movement here, but Webpack has been in a dominant position for nearly a decade and there's no reason you can't continue to use it today if you value stability. It's the equivalent of choosing to host your backend on a VPS instead of trying out serverless.
Needing a build step is part of the complexity of frontend. I think frontend is getting much simpler with build tools like Vite and the addition of ES modules. But, even with these new things coming out, you can stick to your boring stable choices on the frontend just like you can on the backend.
This is insane for beginners.
> You need at least a router
You only need a router if you want to build a SPA with different routes, not all web applications are that! Tons of practical React apps are just a single screen, or even embedded component.
> some way to manage state
You do not need an external library for complex state management, the React docs have some great guides on how to achieve this with plain React:
https://react.dev/learn/scaling-up-with-reducer-and-context
> some way to manage style
Plain CSS and the JSX style property are entirely enough for most apps. If you are using a build tool like Vite, you can also do CSS modules for scoping styles to your React components for more complex applications. I do agree that styling is not a strong point of React, but I don't think pulling in a dependency is necessary.
I just wanna vomit reading that article (which is in official docs!!!). There is a much cleaner way of managing state with just a single `useState` per component instead of bringing over some Redux dogma for some inexplicable reason:
```
const [state, dispatch] = useState()
// ...
dispatch(doThis)
dispatch(doThat)
```
https://react.dev/learn/managing-state
I was linking this later section about extracting state logic into a reducer, because you suggested that you would need an external dependency for state management, I assumed you were talking about something like redux.
But of course you can get pretty far with a single useState and prop drilling as well. Not sure how it supports your point that 'plain react is useless', it sounds like you are arguing against yourself with that comment?
The Redux "pattern" you speak of, does nothing to manage state better than useState(). So I'm not sure why that API even exists, or why you think that is a good response to "need something to manage states".
Let's go back to that, managing state would be for example error and pending state for every async action. In react, that basic, repetitive task is a whole celebration if you just do plain. Try do do form with per-field back-end validation feedback and see how much boilerplate you need for that.
I 100% agree that React is super boilerplate heavy, a lot of things are indeed 'a whole celebration', I personally choose something like Svelte over React if I have the choice, because I don't enjoy that either. All I'm saying is that plain React is not useless! It's completely fine. I don't mind working with it, it makes a tradeoff of being more ceremony but perhaps less magic and I think the tradeoff is okay.
If you want an actual website with proper routing and possibly SSR and want to use “plain” React with no additional libraries you’ll have to waste a lot of time reinventing the wheel.
Joking aside, you really do need to solve the problems jsx solves, but also webpack, next.js, react-router and depending on your application, something like mantine or tailwind. These are the minimum I think.
If you have a smallish project you can get by hand-rolling your own solutions, but it doesn't make the problems themselves go away.
In fact, it is exactly the claim in this thread that there are a lot of beaten paths in backend languages with relative stability over time, whereas in frontend it is 1) not clear what the beaten path is (there isn't one) and 2) when there appears to be favored solution, it often changes radically or disappears after just a couple of years.
For example, create-react-app used to be the default way to start a react app, it is now deprecated. But for python, Django has been a stable beaten path for many, many years. Same for Rails. C# also tends to change every couple of years, but there is always just one single Microsoft recommended way to do things.
Sure there are many experimental libraries and contenders in these languages as well, but there isn't really anything with the same maturity and stability in frontend.
<script src="react.js">
<script src="react-dom.js">
<script>
const recognition = undefined
var foo = document.querySelector("#foo")
let bar = ReactDOM.createRoot(foo)
foo.innerHTML = bar.render("<b>eyond<a>ll{recognition}");
</script>It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app.
It is true that for backend it is more or less the same, however it is a matter of degree. If frontend is all you do, it may be managable, but for full-stack devs who also need to manage infra it can sometimes be overwhelming.
You really don't need any of this though, you can get super far with React alone, and the new docs on react.dev are great at explaining this and pushing this idea in my opinion.
You don't need any of this (aside from a bundler). That's my whole point. You can use these libraries and be on the cutting edge, or go with something simpler.
You'll have the exact same problem on the backend if you want to use a library for everything.
I've maintained a sizeable react app for 8 years, and this has not been my experience at all. Maybe 10 years ago things would break monthly but nowadays things are quite stable, with very reasonable deprecation schedules and upgrade paths. I have lots of code running that I haven't touched in 5+ years and it is not causing any problems even when I'm keeping the main parts of the appliaction up to date with modern practices.
There are a lot of green screen terminal apps that still work today, and haven't been touched in more than 5 years. As long as you leave the same code on the same machine once it's working, and keep the moths off the vacuum tubes and the power flow steady, there shouldn't be a problem.
But try to change that CP/M parts terminal so it can interface with your new EPR and see how well it "just works".
My point is just that the React ecosystem has become surprisingly stable. Of course if you are going to continuously rewrite things into the current flavour of the month framework, you are going to spend a lot of time doing that, but keeping up with upstream changes in dependencies is not something I have found particularly burdensome.
To take the project I mentioned above as an example, currently it’s running on React 18.x, most dependencies are on the latest major version et.c. Still, much of the code is as it was written 8+ years ago, because the core APIs of React have been stable.
Maybe in 2025. I've learned Svelte 5 and think it is pretty good for the tradeoffs it makes though. And I think MPA is the right default for 95% of sites.
What you wrote is probably true (and the one "see how far you can get in react only" comment is probably a decent path, but the landscape is overwhelming.
E.g., I might think to ask, "Which tool creates the output with the lesser overhead on the client, Webpack or Vite?" But I can't find anything solid about that, since everyone's too busy hyping up the dev experience or whatever.
It's a shame that you have to swim against the tide so heavily, if you value simplicity over immediate kitchen-sink levels of functionality. Personally, I've landed on pure client-side React (with any bundler, or with Babel alone if you're feeling adventurous) since it doesn't try to have any purpose other than updating components according to state. Many of its competitors have too much poorly-documented magic for my taste.
Its only a circus if you're constantly chasing the new shiny thing. Many of us have been productively building apps in react for nearly a decade without significant changes in tooling.
So qualify "building apps in react" with whatever bespoke build system, router, state management, etc combination you are actually using.
Just because you found yourself a tent inside the circus doesn't mean it's not a circus.
Frontend is a mishmash of random components and packages, unless you are 100% sure in advance what are you going to use and and do chances are that you’ll run into with issues with the latest version of package X not working with build system Y due to cryptic incomprehensible reasons unless you make sure to stick with the latest “mainstream” trends (which seem to change ever 1-2 years).
You could say the same about developing in Clojure, or Rust or Golang, but somehow you typically only see this same tired rhetoric applied to JavaScript.
The rhetoric applied to JS is fully valid and justified.
Things also change in all language ecosystems. Does anyone use lein these days? Not really.
This is utterly jaw-dropping. There is simply no way to respond to this, since the Everest mountain representing the JS reality directly contradicts this. Its like saying one does not experience Newton's laws of motion. I think you should definitely hold a poll with the community. You would be the super, ultra minority who would hold this position. The only you would have avoided breaking stuff is if you stuck to plain old JS, avoided use of all frameworks, maintained all libraries yourself and did not use any build infrastructure. There is utterly no other possible way you have gone a decade without stuff breaking. React has changed so much - its tooling, libs, best-practices and idioms in the last decade alone.
Comparing the JS versus Go ecosystem is like comparing a mad-max kraken with ten-thousand tentacles surfing the waves and wild on steroids vs a boring container freight-ship placidly making its way across the ocean.
But yes, it can be fun to surf on the kraken.
React router for routing, since.. as long as I can remember.
This notion that the ground is constantly shifting beneath you just hasn't been true for over a decade.
Use CRA + webpack, now use Vite instead, you know what? Screw CRA you should just immediately jump to Next.js instead (which seemed like a huge overkill initially, but actually seems kind of nice).
Unless you’re working on a single project or continuously following what’s new it just seems confusing and overwhelming. If I got comfortable with CRA and came back after a year or two should I still use it for a new project even if it’s bo longer the default? Will new packages/etc. still work with it? Maybe… who knows. I just know that I now have to waste time figuring that out.
When React "is just a library" but the installation instructions tell you to install some large, VC-backed framework immediately - it just doesn't sit right with me.
But also as someone who does fullstack in a pretty much even 50/50 split, this is such a tired meme by this point seemingly from people who just refuse to actually sit down and think about the FE ecosystem for longer than 3 seconds and end up parroting this same talking point.
You could make a similarly dramatic post about the backend world. There you're even fighting which programming language you want to pick. PHP, Ruby, Go, Elixir/Erlang, C#? What about the recent mess with ElasticSearch and Redis? Where and how do you host your backend? Which DB do you use and why? Mongo, anyone?
At this point in the FE framework world, you've got 3 very stable players that have been there for a decade. Angular, React and Vue. And sure, they've each gone through some sort of reworks in the past, but nobody's forcing you to pin your dependencies `@latest`, you can pretty much always keep trucking along with whatever version you were on. We've got a huge app still running along on Vue 2 (not even 2.7 which backports the very nice Composition API) and we see no reason to bump versions to 3. I've even had some nightmare scenarios trying to update Rails and Laravel in the past that dwarf any problems I ever encountered in the frontend world.
Also, vanilla JS, HTML and CSS still exist and work just fine if you're building some small toy thing, but you'll quickly realize why these frameworks exist in the first place (or you'll do the dumb thing of building your own as some do) if you're doing anything more complex than a brochure website.
And the tooling has only gotten simpler if anything with Vite. Want to start a new frontend project? It's literally just `npm create vite@latest`, and you get a nice TUI with which you get to fully customize what you want and don't want. The README even comes with a nice little list of commands for you to run, and hosting can be done literally anywhere where you can deploy the `dist/` folder to, just like the "good" old days.
For people who always claim superiority for being the genius backenders they are, they sure seem to be having a lot of trouble with something that they will themselves say any coding monkey coming out of a bootcamp can do with relatively few problems.
There's a joke I've told many times in interviews if they ask me to define what a full-stack engineer is, to which I joke "It means I do whatever the senior engineer doesn't want to do, which 99% of the time is front-end". The people I tell it to laugh, because it's funny but also because it's true.
On the front-end you're dealing with more customer/users and it's inherently more of a servile role, while it's much easier to be stubborn, eccentric, 'powerful' in the tech-facing backend.
I'd also wager there's a certain "tech purity" angle too, given the inherent reverence foisted upon lower level languages and programming fields that is seemingly rife.
To play devil's advocate on myself, perhaps it's more that the higher end technical complexity challenges for Front-End aren't commonplace enough. I've had the fortune to work in a field where the level of necessary technical complexity on the front-end part of my job is very high, so ymmv
In the Java world alone: Spring vs EE vs Play vs Quarkas vs Micronaut vs Helidon... Tomcat vs Jetty vs Netty... Jar vs War vs Ear ... Maven vs Gradle vs Ant...
Just don't chase fads. Stick to things that you know are working fine.
I do believe everyone involved means well and aims for technically strong outputs but my good the end result is still fuckin chaos.
Backend and systems programming has people with strongly held opinions and flame wars too but somehow it feels more like a war between gentlemen and less The Purge chaos.