[thembones]

Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router, global state, or a 200 kB hydration bundle—they just need partial HTML swaps.

The real driver is complexity cost. Every line of client JS brings build tooling, npm audit noise, and another supply chain risk. Cutting that payload often makes performance and security better at the same time. Of course, Figma‑ or Gmail‑class apps still benefit from heavy client logic, so the emerging pattern is “HTML by default, JS only where it buys you something.” Think islands, not full SPAs.

So yes, the pendulum is swinging back toward the server, but it’s not nostalgia for 2004 PHP. It’s about right‑sizing JavaScript and letting HTML do the boring 90 % of the job it was always good at.

[qudat]

Having a server provide an island or rendering framework for your site can be more complex than an SPA with static assets and nginx.

You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE.

And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features.

So honestly I would argue for SPA over a server framework as it can dramatically reduce complexity. I think this is especially true when you must have an API because of multiple clients.

I think the DX is significantly better as well with fast reload where I don’t have to reload the page to see my changes.

People are jumping into nextjs because react is pushing it hard even tho it’s a worse product and questionable motives.

[0cf8612b2e1e]

  I think the DX is significantly better as well with fast reload…

As a user, the typical SPA offers a worse experience. Frequent empty pages with progress bars spinning before some small amount of text is rendered.

[dmix]

The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things.

Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.

[whatnow37373]

> dramatically reduce complexity

If you ever worked seriously on anything non-SPA you would never, ever claim SPAs “dramatically reduce complexity”. The mountain of shit you have pull in to do anything is astronomical even by PHPs standards and I hate PHP. Those days were clean compared to what I have to endure with React and friends.

The API argument never sat well with me either. Having an API is orthogonal: you can have one or do not have one, you can have one and have a SSR app. In the AI age an API is the easy part anyway.

[stavros]

I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.

[freeone3000]

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.

[throwaway7783]

I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice.

For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there.

React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s

[switz]

So here's the kicker: React Server Components don't need a server. They are completely compatible with a static bundle and still provide major benefits should you choose to adopt them (dead code elimination, build-time execution). This is effectively the design of Astro Islands, natively in React Server Components. Letting you write static and client-side dynamic code in a single paradigm through componentization and composition.

If you are curious, my most recent blog post is all about this concept[0] which I wrote because people seem to be misinformed on what RSCs really are. But that post didn't gain any traction here on HN.

Is it more complex? Sure–but it is also more powerful & flexible. It's just a new paradigm, so people are put off by it.

[0] Server Components Give You Optionality https://saewitz.com/server-components-give-you-optionality

[t-writescode]

You can accomplish the "don't have to reload the page to see my changes" with htmx and it's still "server-side rendering" (or mostly server-side rendering). Legendarily, the fastest website on the internet uses partial page caching to achieve its speed

[__abc]

If you truly need for MVC to manage all things state, component communications, and complex IxD in the front-end, sure, but not every app has that level of front-end complexity to warrant a SPA, in my opinion.

[_1tem]

With an SPA you're writing two apps that talk to each other instead of one. That is, by definition, more complex.

> You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE.

Now you're dealing with 2 sets of tooling instead of 1.

> And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features.

There is no app which would not care about first paint. It's literally the first part of any user experience.

> So honestly I would argue for SPA over a server framework as it can dramatically reduce complexity. I think this is especially true when you must have an API because of multiple clients.

So SEO and first paint are not necessary features, but an API for multiple clients is? Most apps I've worked with for over 15 years of web dev never needed to have an API.

> I think the DX is significantly better as well with fast reload where I don’t have to reload the page to see my changes.

With backend apps the reload IS fast. SPA's have to invent tooling like fast reload and optimistic updates to solve problems they created. With server apps, you just don't have these problems in the first place.

[cjonas]

> You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE

This. From a security perspective, server side dependencies are way more dangerous than client side.

[princevegeta89]

As somebody with an expert level knowledge with MVC frameworks like Ruby on Rails and Phoenix Framework, etc., and an experience building large-scale enterprise-grade apps using simpler technologies like jQuery, StimulusJS and plain old JavaScript on the front end with a little bit of React thrown in here and there, I found Development cycles to be much faster with these simpler stacks overall. The complexity of the code base never ended up turning to be a liability that it creates significant overhead and bottlenecks for new engineers joining the team to jump in and understand the end-to-end workflows of things.

Fast forward to what I am doing today in my new job. We have a pretty complex setup using Redwoodjs along with several layers of abstraction with Graphql (which I approve of) and a ton of packages and modules tied together on the front end with react, storybook, etc. and some things I am not even sure why they are there. I see new engineers joining our team and banging their heads to make even the smallest of changes and to implement new features and having to make code changes at multiple different places. I find myself doing similar things as well from time to time - and I always can't help but think about the complexity that I used to deal with when working with these MVC frameworks and how ridiculously easy it was to just throw logic in a controller and a service layer and and the view templates for the UI stuff. It all fit in so easily and shipping features was super simple and quick.

I wouldn't discount react as a framework but I am also starting to some cracks caused by using TypeScript on the backend. This entire Javascript world seems to be a mess you don't want to mess with. This is probably just me with an opinion, but but using Turbo, Stimulus and and sprinkles of LiveView got me really really far very quickly.

[j-krieger]

I never get these comments. I would choose a Next.js / React project to work on 99% of the time compared to the hellish nightmare that is jQuery.

[catlover76]

What would you say the good and bad of GraphQL are? Like, when it is a value-add, and when should it be avoided?

[_mlbt]

People also forget just how far you can get without using client side JavaScript at all today. HTML and CSS have a lot of features built in that used to require JavaScript.

[joshstrange]

New inputs types have been glacially slow to come out and often underwhelming. Every new HTML thing I've seen (modals, datetime inputs, datalist select, etc) had better JS versions out for years before they released. I understand that the HTML spec is setting a baseline of sorts but most of the UI is ugly and sometimes not themeable/styleable.

[timewizard]

The best approach is to use both. Which is why I never understood the pure server side or the pure "reactive" approach. Having to manage rendering in server side code is pure pain, and having to return DOM markup from inside a function is likewise just madness. They both break the separation of concerns.

The first framework I ever got to use was GTK with Glade and QT with designer shortly there after. These, I think, show the correct way to arrange your applications anywhere, but also it works great on the web.

Use HTML and CSS to create the basis of your page. Use the <template> and <slot> mechanisms to make reusable components or created widgets directly in your HTML. Anything that gets rendered should exist here. There should be very few places where you dynamically create and then add elements to your page.

Use javascript to add event handlers, receive them, and just run native functions on the DOM to manage the page. The dataset on all elements is very powerful and WeakMaps exist for when that's not sufficient. You have everything you need right in the standard environment.

If your application is API driven then you're effectively just doing Model-View-Controller in a modern way. It's exceptionally pleasant when approached like this. I have no idea why people torture themselves with weird opinionated wrappers around this functionality, or in the face of an explosion of choices, decide to regress all the way back to server side rendering.

[lmm]

> Every line of client JS brings build tooling, npm audit noise, and another supply chain risk.

IME this is backwards. All that stuff is a one-off fixed cost, it's the same whether you have 10 lines of JS or 10,000. And sooner or later you're going to need those 10 lines of JS, and then you'll be better off if you'd written the whole thing in JS to start with rather than whatever other pieces of technology you're using in addition.

[yawaramin]

It's absolutely not a one-off fixed cost, it's a constant treadmill of new vulnerabilities, upgrade breakages, and ecosystem incompatibilities. Just because you need 10 lines of JS, doesn't mean you 'might as well' have 10,000.

[skydhash]

10 lines of JS fits into a screen and can be reasoned about quite easily. Now do the same for 10000.

[pier25]

I don't know.

Many interactions are simply better delivered from the client. Heck some can only be exclusively delivered from the client (eg: image uploading, drag and drop, etc).

With HTMX, LiveViews, etc there will be challenges integrating server and client code... plus the mess of having multiple strategies handling different parts of the UI.

[jdsleppy]

HTMX has a very nice drag and drop extension I just found, though. And old-school forms can include image files. The little image preview can be a tiny "island of JS" if you have to have it.

[AlchemistCamp]

Hours so? I’ve found that Phoenix LiveView has made integrating the server and client code much simpler. It’s dramatically reduced the need to write JavaScript in general, including for things like image uploads. Or are you speaking of one of its many clones?

[kace91]

This is not my field, but my mental model was that server side mostly died when mobile apps started being mainstream, and treating the web app as another frontend for your common api was considered the best way to handle client diversity.

Was this not the case? And if so, what has fundamentally changed?

[waprin]

It's one of those things that's like "write one HTML file with zero styling, then you can have multiple different CSS files style the same content completely differently! Separation of Concern!" Sounds perfect in theory but just doesn't always work.

Having one API for web and mobile sounds good but in practice often the different apps have different concerns.

And SEO and page speed were always reasons the server never died.

In fact, the trend is the opposite direction - the server sending the mobile apps their UIs. That way you can roll out new updates, features, and experiments without even deploying a new version.

[trenchgun]

> Of course, Figma‑ or Gmail‑class apps still benefit from heavy client logic, so the emerging pattern is “HTML by default, JS only where it buys you something.” Think islands, not full SPAs.

Figma is written in C++ to webasm.

[ivape]

"Right-sizing" is probably the most diplomatic take on all tech churn. It's the right way to look at it. It's not that we're done with it once and for all, it's just it's not the end all be all that conferences/blogs/influencers make things out to be. It's more of an indictment of the zealotry behind tech evangelism.

[WorldMaker]

I recently blogged about [0] how I felt after some experiments with a traditional multi-page application with simple Web Components as "Progressive Enhancement". Taking an "offline first" approach to the "simple CRUD" of the application (saving everything all the time in Local Storage and then doing very simple "3-way merges" with remote data as it catches up) made it feel enough like a SPA that I was thrilled with overall performance. Think I just need to add CSS View Transitions for one last bit of "SPA-like" polish.

I am starting to think now is a great time to return to some of the Knockout-era ideals of "Progressive Enhancement". Web Components, the template tag, local storage, CSS view transitions, and a few other subtle modern things seem to be getting close to the point where the DX is as good or better than SPAs and the UX feels similar or better, too.

[0] https://blog.worldmaker.net/2025/04/27/book-club/

[hirvi74]

> they just need partial HTML swaps.

Been a web dev for over a decade, and I still use plain JS. I have somehow managed to avoid learning all the SPAs and hyped JS frameworks. I used HTMX for once project, but I prefer plain JS still.

I was a JQuery fan back in the day, but plain JS is nothing to scoff at these days. You are right though, in my experiences at least, I do not need anything I write to all happen on a single page, and I am typically just updating something a chunk at a time. A couple of event listeners and some async HTTP requests can accomplish more than I think a lot of people realize.

However, if I am being honest, I must admit one downfall. Any moderately complex logic or large project can mud-ball rather quickly -- one must be well organized and diligent.

[quantadev]

I think the confession that "Figma‑ or Gmail‑class apps still benefit from heavy client logic" is a telling one, and the reason I politely disagree with your thinking is that it relies in the app staying small forever. But that's not what happens. Apps grow and grow and grow.

I've heard people say they just want "Pure JS" with no frameworks at all because frameworks are too complex, for their [currently] small app. So they get an app working, and all is good, right until it hits say 5000 lines of code. Then suddenly you have to re-write it all using a framework and TypeScript to do typing. Better to just start with an approach that scales to infinity, so you never run into the brick wall.

[room271]

The problem is that people are frequently using SPA JS frameworks for things that are clearly not gmail of figma -- i.e. news websites and other sites with minimal interactivity or dynamic behaviour. If you are genuinely building an 'app'-like thing, then of course you need some kind of JS SPA framework, but too often people are reaching for these tools for non-app use cases.

[spenczar5]

Yeah, wouldn't want to rewrite the frontend in a new framework. Good thing the SPA frameworks are so stable and solid; when I choose one I will surely be able to use it for a good, oh, 3 to 6 months.

[freeone3000]

The idea that apps can never be done and can never stop adding new features is the key determiner of web bloat. This is the problem.

[CooCooCaCha]

I’ve been saying this for a long time. It takes very little effort to spin up a react app so there’s little point in starting a project without it or whatever front-end framework you prefer.

As I’ve become more senior I’ve realized that software devs have a tendency to fall for software “best practices” that sound good on paper but they don’t seem to question their practical validity. Separation of concerns, microservices, and pick the best tool for the job are all things I’ve ended up pushing back against.

In this particular case I’d say “pick the best tool for the job” is particularly relevant. Even though this advice is hard to argue against, I think it has a tendency to take developers down the path of unnecessary complexity. Pragmatically it’s usually best to pick a single tool that works decently well for 95% of your use cases instead of a bunch of different tools.

[lazypenguin]

That’s absurd, that’s like saying we should only use C++ for backend code because my CRUD business app might one day scale to infinity. Better be safe than sorry and sling pointers and CMake just in case I need that extra juice!

[ksec]

>Figma‑ or Gmail‑class apps.....

Figma is a definite yes. But Gmail is something we say from late 00s and somehow continue till now. I thought it has been proven we dont need SPA for Email Client. Hey is perfectly fine other than a little slow, mostly due to server response time and not Turbo / HTML / HTMX itself.

I still believe we have a long way to go and innovate on partial HTML swaps. We could have push this to the limit so that 98% of the web doesn't need SPA at all.

Really hopes Rails has more in store this year.

[vinnymac]

I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes.

Everything after ready should have been static content.

[noodlesUK]

I completely agree with the sentiment that we don’t need SPAs and similar tech for news sites and dashboards and the myriad crud apps we use on a day to day basis but I think what you’re proposing is throwing the baby out with the bath water. How would a site like google maps, which I’m sure we can all agree is extremely useful, work in a Web 1.0 style world? It needs to dynamically load tiles and various other resources. The web being a place where we can host and instantly distribute complex cross-platform interactive software in a fairly secure sandbox is a modern marvel.

[bartread]

That ship has sailed. The web is nowadays an application delivery platform and there is no going back. Dynamic loading, iframes, and a whole host of other features all have their uses within that context - the issue is really their misuse and overuse.

[pjmlp]

For me it definitely never went away, as I mostly done Java (JSP, JSF, Spring), or ASP.NET (Web Forms, MVC), with sprinkles of JavaScript islands.

And what makes me like Next.js, besides the SaaS SDKs that give me no other framework choice, it is being quite similar to those experiences.

[brightball]

This honestly feels so much closer to the old jQuery approach of using JS for enhancements but ensuring you could gracefully degrade to work without it.

I loved building things that way.

[chipsrafferty]

This is ChatGPT