[ryanbrunner]

I think especially for small teams starting out, complex architecture can be a huge trap.

Our architecture is extremely simple and boring - it would probably be more-or-less recognizable to someone from 2010 - a single Rails MVC app, 95+% server-rendered HTML, really only a smattering of Javascript (some past devs did some stuff with Redshift for certain data that was a bad call - we're in the process of ripping that out and going back to good old Postgres)

Our users seem to like it though, and talk about how easy it is to get set up. Looking at the site, the interactions aren't all that different from what we would build if we were using a SPA. But we're just 2 developers at the moment, and we can move faster than much larger teams just because there's less stuff to contend with.

[woah]

That doesn't sound like it's really any simpler than a json API server (written in node, python, go, or anything else), and a SPA. Maybe the lesson is "build with what you know if you want to go fast".

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

[theonething]

In my experience, adding SPAness doubles the complexity of your application. Now you're maintaining and synchronizing the same state in two places and adding extra code in a different language (if you're not using JS on the backend).

[ggpsv]

There is some overhead in using SPAs when your application could have been built in the way that the parent comment suggests.

Some front-end frameworks are closing this gap but I wouldn't necessary say they're equally a simple. See https://macwright.com/2020/05/10/spa-fatigue.html

In other words, choose the right tool for the job.