Moving on from React, a year later
62 comments
·January 20, 2025sc68cal
I was worried that an application I was building in Django, with a frontend built with Bootstrap and some LIGHT jquery was making me look like an old curmudgeon but the part about testability of the frontend really resonated with me. It was MUCH easier to structure everything as pytest unit tests and completely rely on Django for all the business logic rather than trying to put state in the frontend and deal with synchronizing states between FIVE distinct systems (remote devices, the Django application, the database, an event stream, AND the front end).
I recognize that I'm not hip or with it, because I really fell out of front end development at the peak of jQuery where it was mostly about fixing browser incompatibilities, but it's nice to see that maybe it went too far in the other direction and we're overdue for a bit of a swing back towards server side.
htmxsucks
HN is not real world, just like how Reddit is not real world.
I am a FE with 10 years of experience, and has tried, and tried really really hard and multiple attempts to make HTMX works well.
Doesn’t work. UX is much worse, code discoverability is much worse, slower to code in, everything is messier than just plain React SPA with JSON data. Terrible, terrible DX and UX.
Seriously, there is a reason why despite all the rage in going back to multi page Django/Rails app, very very few people actually take it seriously. You just don’t hear the negativity because most folks just tried it, saw that it is worse, and moved on without writing a blog post.
nchmy
Check out Datastar (https://data-star.dev) . It's similar to htmx, but far more powerful AND simpler.
Epskampie
I'm a freelance webdev with 15 years of experience, and recently I've made some new projects with Symfony Stimulus & Turbo to great success.
A few thoughts:
I tried just htmx too, too limiting. Stimulus/Turbo combination is much better.
Use the right tool for the job. Highly interactive app, like an editor? Use react or similar js framework. Mostly page/document website? A backend framework is much faster and easier to develop, and much simpler to test.
Use what you know yada yada.
kopirgan
If I understood correctly the author of original post is also talking from real world experience, not running university research lab.
cvdub
What kind of stuff have you been building?
henning
your feelings are not facts.
tyre
> Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS.
Everyone's mileage varies, of course, but this is quite the assumption. It feels like a lack of familiarity/comfort with the frontend or poor tooling.
With typescript and a basic UI library like MUI, this really shouldn't be the case for UI changes. If you're using raw JS and manipulating the DOM, maybe?
kellysutton
The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend.
If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following:
- Make the change on the server to support the new functionality. Deploy.
- Make the change on the client to adopt the new functionality. Deploy.
- Remove the old functionality from the server (optional)
Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer.
With server-authored HTML, this separate client + server deploy is not required.
leptons
>With server-authored HTML, this separate client + server deploy is not required.
SSR has been a thing in react for a long time.
runako
If the app has a backend, aren't we still talking about modifying two distinct apps (React + backend app) vs a single one?
Obviously unless the team has committed to React SSR + React backend (is this common?)
null
marcus_holmes
I think the author was talking about React specifically.
I've worked in JS, TS, React, and RoR, and yeah I'd say making a change is probably twice as quick in RoR as in React.
The thing is that Rails is an opinionated framework. If you do things that the framework is designed to do, then it's very very easy. If you go off-piste and have to fight the framework to do the thing you want it to do, it gets very hard very quickly.
React is less opinionated (about most things) so the converse is true; it is slower to write stuff in, but there's less constraint.
ajmurmann
I feel the comparison is really hard. Rails really is a framework that solves anything but the business logic for 80% of your app. React is really a library for rendering components and everything else is your decision to pick or build from scratch. E.g. Rails has opinions on how to build forms while React, a supposed frontend framework, doesn't have anything baked in specific to that. Sure the community has opinions about it but React doesn't like Rails does.
mvdtnz
My experience with very highly paid frontend developers is they like to spend hours and hours (and thousands and thousands of dollars) building out little libraries and components and frameworks that will enable other teams to be faster. Except this never eventuates because things rarely turn out to be reusable along the right axis so a new component or library or framework is developed to solve the problem.
On top of this UI developer propellor-heads love to spend time (and money) pontificating on abstract theories about functional programming and homomorphisms and endofunctors so they can render some text inside a <b> tag. It's how we wound up with utterly ridiculous pieces of code like the "hooks" API in React.
JOnAgain
Can’t get promoted pumping out 10 great pages. But a library that you can claim will enhance the productivity of 100 other engineers? Now that’s IMPACT!!
Except you’re at a company where everyone has figured this out so now you have 4 competing libraries with their own teams which are all 1/2 done making every engineer less productive cause they all have bugs and slightly different priorities.
ctkhn
this is exactly the frontend team from a previous role. we were losing millions a month and had 2 major cuts within 4 months - and instead of cleaning up or simplifying our bloated frontend, the teams responsible for it started building new component libraries for the rest of the org to use on future pages
goosejuice
I also get the feeling that modern frontend is a massive money pit but this seems to be a leadership problem. I wouldn't go so far as to blame the IC. There are developers over-engineering in every ecosystem.
GiorgioG
[flagged]
senti_sentient
The older I get, the more I find myself gravitating toward building with Express.js, using front-end HTML with a touch of Alpine.js—and that covers 99% of my use cases. React is mostly an overkill.
phaedryx
I think the idea of "sprinkling" JavaScript into your server-rendered HTML is a good one. However, I think that Stimulus is terrible.
1. There isn't a good way to test it. There is nothing in the docs about how to test it.
2. Keeping state in the DOM is dangerous
3. Messaging between Stimulus controllers is painful
4. They disconnect parameters from functions. The functions have to scan through the DOM to find what they need which I think is fundamentally weird
5. Reusability is rare
6. It doesn't try to play nice with the larger JavaScript ecosystem.
I personally prefer Vue.
kellysutton
A friend mentioned this made the front page. I'll try to answer any questions on our approach at Scholarly. Thanks for reading!
Swizec
> Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS
I don’t grok this part. Based on my experience with RoR and JS/TS, making changes in TS-land is much easier and quicker than dealing with Ruby.
Is this just a preference/experience thing in the end? For you and your team RoR is faster/easier, so that makes it the better choice. For a different team JS/TS may be faster/easier, so that makes it the better choice?
kellysutton
Haven't written much TS, so can't speak to that.
I should have made the distinction between client-side and server-side JS/TS. Familiarity and expertise will be a main driver of productivity for a team, regardless of language/framework. For us, that's RoR.
Client-side JS however has a multiplying property, where we often need to write more server-side code to accommodate the growth in client-side code. If the client-side code is providing undifferentiated value (e.g. authoring HTML), we now have more pieces in our system to accomplish our goal (author HTML). What's been surprising to me is that you don't need to author HTML client-side to have a reactive experience. With Turbo, Stimulus, and server-rendered HTML, a great experience is possible with fewer layers.
Swizec
Great answer. Thanks!
I think the power of fat clients comes when you have different consumers of the same APIs/logic. Like a browser app or two, maybe backend services, a few task queues, etc. Then having a clean separation between client code and business logic becomes super valuable.
In my experience with SPA we got to a point where my team could go weeks, even months, without having to make changes in server code. Whole new features that were fully supported by our existing APIs because they were written as reusable APIs. If you’re having to write a bunch of Rails to support the growing client code, you probably didn’t need a separate client yet.
But when your codebase gets to that point even Rails is just a frontend really. So it’s mostly about which tradeoffs you prefer. Unfortunately I left Rails right around the time Turbo was becoming a proper thing you could use so I don’t have the best feel for what it’s like.
evanmoran
Thank you for writing this all up. Just curious if you ever considered switching away from Ruby? I think many people are living in parallel stacks (TS, Go, Python, Rust) and it would be interesting to hear how it’s been going more recently in that ecosystem from your perspective.
As to rendering, I’ll be honest and say that my code has moved more towards client-side (using ConnectRPC and my framework ojjs.org—-shameless plug :), but I love that you have had success with a different path. Super interesting, and thanks again!
kellysutton
I don't have a reason for switching away from Ruby at this point in my career. Things can always change down the line. Maintaining multiple languages at the same layer sounds like a personal nightmare to me. I'd rather learn to write PHP and have that be the only language, than to write Ruby+another language on the server-side.
We're building our company on Rails because we think it's the best choice for a young company, since it allows us to respond to customer feedback more quickly. That's what we're optimizing for right now!
oDot
Unfortunately for many of the HTMX/Turbo people, they did right to identify the problem but they have the wrong solution.
The way to alleviate those issues is not to bloat the frontend with things that shouldn't be in it nor is it to fragment the code base with never ending "sprinkle" of JS.
The best solution is something like Gleam's Lustre, where you use the right tool for the job, while keeping a coherent code base:
https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
overstay8930
Watching Meta rewrite Messenger twice without success was enough for me to never touch React for any large project, especially after that botched e2ee chat rollout.
cwalv
You think the major complicating factor of rolling out e2ee was that they used react?
insane_dreamer
> Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to.
PREACH. And many site actions can be handle server-side without degrading the user experience.
elchief
Went all in on the BALL stack (bootstrap, alpine.js, laravel livewire) and couldn't be happier
uncomplexity_
> BALL Stack
Remove the T, it's cleaner.
willsmith72
> p75 at 350ms
Is this really that impressive if you're prefetching? Surely a cached response is <50ms always. What's the prefetch cache hit rate?
If it's anything like remix/react router prefetch caching, it's also useless on mobile. Depending on your target market, that's a huge difference
Server rendered HTML is all well and good until you want to add native apps or a first class API layer. At that point, it makes more sense to have the web be just another client and move as much business logic into the API layer as possible.