[ryanbrunner]

In my experience SPAs bring a lot of headaches that you just don't really need to think about with traditional HTML. Browser navigation, form handling, a lot of accessibility stuff comes out of the box for free, and there's one source of truth about what makes a particular object valid or how business logic works (which is solvable in the SPA world but brings a lot of complexity when you need to share logic between the client and the server, especially when they're in different languages).

Frankly out of all the things that make our architecture simple and efficient, I would say server rendered HTML is by far the biggest one.

[woah]

Probably depends on the requirements. If the product should basically feel like a static web page, and you are OK making design and product decisions that work easily in that paradigm, then a server side framework built to make static web pages is going to be simpler.

If you have product or design requirements that it should feel more dynamic like a native app, then trying to patch that on top of a static webpage might get messy.

[treis]

IMHO the important thing is where your data is. If can all be client side then write a SPA. If it's on the server then the more you do on the server the better.

Returning HTML and doing a simple element replace with the new content is 99.9% indistinguishable from a SPA.

[woah]

Every app will have a bunch of serverside data so IMO that's not really a consideration.

The great thing about SPAs is that your server now just returns a simple JSON API. It greatly simplifies the server side. It also tends to make things a lot easier to unit test on the server side. Also, it cleanly segments your staffing requirements. If your app is in some way non-trivial, you can have domain experts working on the backend, and just dumping json into http responses, and have a frontend engineer who doesn't understand any of the magic work on the frontend.

> Returning HTML and doing a simple element replace with the new content is 99.9% indistinguishable from a SPA.

Once you're doing this, your backend engineers are dealing with html in addition to whatever their real job is. If you want to have something other than your website consume your backend, you're rewriting stuff to output json anyway.

If you have no domain-specific computation happening and your service will only ever be consumed as a more or less static website, serverside web frameworks can be faster. For example, if you are building a blogging site, or maybe a CRM.

[treis]

>Every app will have a bunch of serverside data so IMO that's not really a consideration.

Every app will not have so much data that they can't send it all to the client. 99% of them will which is why 99% of web apps should be server side. That 1% is when you want a heavy client side app.

>Also, it cleanly segments your staffing requirements. If your app is in some way non-trivial, you can have domain experts working on the backend, and just dumping json into http responses, and have a frontend engineer who doesn't understand any of the magic work on the frontend.

You can separate frontend and backend code without introducing a client server call in the middle.

>Once you're doing this, your backend engineers are dealing with html in addition to whatever their real job is.

Why? You can still have front end engineers. They just write server side HTML templates which is hardly any different than writing JS based HTML templates.

[ta988]

And in Rails 7 with hotwire, it is really looking close to a SPA.