I no longer have the patience to read through the praises of another frontend framework.
I started web development just 2 years ago using React and at the time I didn't know any of the traditional frameworks like Rails, Django or Laravel. I learned Rails recently and have been using it for my side projects since. I'm having a great experience!
When I see the headlines praising a frontend framework that's been around for < 5 years, I roll my eyes. I imagine it's been written by someone like me 2 years ago, who hasn't used traditional frameworks.
I started webdev some years back from the other direction; I had read of the countless JS web frameworks and their countless dependencies, and I had read the arguments against using "uncessary" JS (talking about genuine bloat) on websites. So, I thought I'd just explore options like those based on Go; fast, compiles to a single binary, no need to touch JS. Then I wrote my first totally website with Hugo and and a custom theme for it, had fun doing it too. Tried to write a couple selfhosted web apps with Go frameworks too but never got that far.
Then I moved to doing all my projects with Astro/Svelte and webapps with SvelteKit. I was surprised at how good and fun it was. The templating languages less esoteric, more integrated. Reactivity was something I never even dreamed of with a hard line on JS. All the while, the websites got better. I could finish them more quickly and there was still no or a miniscule amount of JS shipped by default. I could also, when making a content-driven website with Astro, easily reach for Svelte for a small bit of interactivity / reactivity. I could've just as easily used Alpine or whatever else someone might recommend.
That's to say, I've found a comfortable DX in current-gen JS frameworks, while finding the server-side giants a bit too sturdy for my use. Reading about new frameworks is fun to me, because I can easily switch from Svelte to something else on my Astro sites, if I find something that fits my tastes even better.
I prefer traditional server side frameworks precisely because they have a rigid pattern of doing something. And also because they have been around for a while.
I don't get excited about learning a new frontend framework because I'm fairly certain it won't allow me to do something new. It may be more convenient in terms of syntax or have fewer client side code being shipped, but it doesn't enable me to do something in terms of functionality I couldn't already do.
I would prefer pick one framework and get better at it, rather than learn the templating language of 5 frontend frameworks.
Interesting that you went from React to Rails, usually people go the other direction. It's neat seeing the good 'ol server side frameworks being "rediscovered".
I'm not sure that's true. Time has went that direction, for sure, but I don't think historical backend web devs have migrated to react. Mostly front-end devs expanding their horizons and younger devs starting there.
> but I don't think historical backend web devs have migrated to react.
Really? Back in the day, myself and my peers weren't "backend web devs" we were just web devs. Stuff started shifting to the frontend and we all learned Backbone, Angular, React, etc because that's the way the industry went. I think a LOT of us migrated to React, maybe not completely, but who can call themselves a web developer these days without at least some experience with FE frameworks?
Guess it depends on your role yeah. I'm familiar with React etc but I only use it when required, it's all so clumsy, constantly changing, and their best new ideas have existed in the ruby/python/php communities for decades.
I still really limit my JS to just improving the client-side UI/UX.
I've been doing web development for about 20 years, and have the opposite reaction. I started web development with Flash (dark times), jQuery, and/or Django.
I love that people are pushing back on the SPA architecture everywhere (though SPAs are still the right choice for some apps). Some people are pushing back like you (returning to backend renderering), and others are pushing back like the implementer/poster by trying to extend the original intent of REST architecture (not JSON apis the term has come to mean).
I think the htmx architecture is brilliant, though it's not something I would use for the majority of my projects (it doesn't fit the use case).
I think what folks who have come to web dev recently don't understand the historical tradeoffs that led to SPAs or the current web dev ecosystem. It was terrible to build websites, but it was worse to build cross-platform applications using the existing tools and delivery systems. The browser solved a lot of that, and SPAs were an attempt to upgrade web architecture to support that need. People forget the positives because of how ubiquitous they've become and only look at the negatives.
I'm glad we're moving away from the SPA-only world, but every web framework that we use nowadays has been influenced by the advent of node+SPAs
I've worked with countless younger junior engineers who know React reasonably well, and largely think Rails is old "legacy" crap they don't want to deal with. And to be fair, using Rails as a dumb JSON api does disrupt much of the convenience of using Rails. But I never understood how people could so under-appreciate the tooling and structure that Rails provides.
I started web development just 2 years ago using React and at the time I didn't know any of the traditional frameworks like Rails, Django or Laravel. I learned Rails recently and have been using it for my side projects since. I'm having a great experience!
When I see the headlines praising a frontend framework that's been around for < 5 years, I roll my eyes. I imagine it's been written by someone like me 2 years ago, who hasn't used traditional frameworks.