[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.