Why use an SPA?

I agree. In fact static rendering has become refreshing given the saturation of SPAs everywhere. Even content websites are SPAs these days. Pointless.

Anyway my next venture will be as JS free as possible. I don't have JS, I love it. But that tribe is going thru an over-engineering cycle. Just like Java in the early 2000s.

It will all settle down, eventually.

Downsides first: It's a time sink. By the time you bootstrap webpack, babel, sass, etc. you're often pushed into building an "app" and instead of a web page. So there's a sunk cost just to do something remotely meaningful with react, in practice. The build outputs are colossal, even with tree shaking and codesplitting. The initial build times on a non-trivial app can be minutes. Minutes.

I made some pretty scathing comments about React / SPA apps on HN before. I was insistent I could build an app with django templates + css + js. But in the end I ended up having to use webpack just to build SASS/JS, even if I spurned using a SPA app. So I never found a way to keep it with just jinja/django templates and css and ship a good experience.

If you're making a website that's differentiated enough to be noticed, most likely it'll end up needing the attention to detail a JS app brings. It's just hard to make UX scale without it: template includes are not composable - ES Modules + React components definitely are.

What changed my mind on SPA:

- TypeScript is really the thing that changed the game, because it shores up a very hard-to-scale, disorganized language ecosystem with an amazing type system.

- Webpack and babel getting somewhat stable in their APIs, as well as their extension/plugins

- React Functional Components / Hooks (cleans up a level of indentation and avoids that class cobwebs that can make maintenance a pain)

- Prettier: Excellent formatting tool

- JSX: Ends up making components very "HTML-like" and the formatting with prettier makes it feel like "blocks" where you can get a gist of the depth/hierarchy.

- GraphQL + Relay: The responses are code-generated into types and it automates retrieving data from the server. You can throw redux out. Which leads me to another thing - I consider redux an antipattern on most cases. Not fun at all to work with at scale.

I wish typescript / react / jsx / sass just worked from the browser itself, without all the webpack and babel, and these configuration files. I think maybe, after thousands of hours, I finally comprehend webpack. But in all likelihood I'm mistaken, and webpack 5.x will end up making me have to start over anyway.

If your team consists of backend engineers who haven’t done full stack in a while and front end engineers who are already good with react/vue then I’ve found it easier to just go SPA instead of everyone trying to remember how Django/Rails works. Also if your server side stuff has to or probably will have to talk to other machines then you’re just saving yourself the trouble of implementing the human only version.

If your team consists of mostly people who’re used to doing rails/Django style webapps then it’s perfectly reasonable to not build an SPA.

Why do we need elaborated backend structures? A bit of SQL in stored procedures on top of a DB is good enough all the time. It's way less overhead. Heck, why don't we just let the users get what they want by giving them access to a SQL prompt. We could eliminate the UI completely.

The web has evolved from a collection of hyperlinked documents in the 90s to a fully featured application platform in 2019. There's still a place for server side rendering. But it's for static content, not applications anymore. Practically everyone on the web now has a client capable of executing complex application code. As a result it has become incredibly simple for developers to build things out on the client that would have been impossible with the old paradigm. Not only does it make development faster, but it allows a much greater separation of concerns across the stack. Backends can now be completely agnostic of the presentation layer, which pays for itself many times over when you realize a given application may be running across native desktop, native mobile, mobile web, desktop web, TV OS's, game consoles, etc. Having to duplicate your business logic for these use cases would be terrible.

A valid use-case is to provide a UI for API products (Stripe, Lob, Twilio, etc). The main product is an API for customers to use but you may also want to be able to login to their website and check the current state of affairs of your account. Since you already have to build an API for your customers and everything you're showing might already be possible with the API, you can create a UI to glue the request calls together. A SPA can use the same API, avoids you having to write new code for your website and you get to dog-food your own API.

Disclaimer: I work for Lob.

Shiny New Thing Syndrome.

For example, one of our web apps regularly sends 'heartbeats' to the server. It's difficult to track this across different pages.

But there's definitely overhead, so I wouldn't do it unless necessary.

In a lot of cases, it is more efficient to save state on the front end so you don't need to retrieve it each time on the back end.

The #1 use for an SPA is called “resume padding”.

If you’re a front end dev who wants to look important, making the entire application reliant on your fragile client side code can give a lot of hutzpah to your resume.