There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticate

There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR. Off the top of my head, here are benefits to SPA: - I can just serve a few static files from a CDN. Every user gets the same client. - Most requests made by the application are actually smaller. I'm just loading the data I need, rather than the data, markup and styling. - It's an actual client application talking to a data API. It's the same API the rest of my client applications are talking to, be it a mobile API, native, CLI, etc. - It's a much easier mental model. Interactivity without having to give consideration to whether or not it will disrupt whether it can be rendered. I build my application like a realtime application and just make requests for the data I need when I need it - I don't have to think about exposing backend secrets, or trying to do things I'm mistakenly assuming to necessarily run in one environment or the other - I can be much more explicit about loading and caching data when I would like to Even most of the cons of a SPA can be ameliorated. The biggest con is a larger up front load, but that can be mitigated by code splitting and lazy loading. The fact that it's a handful of static files means that the application is basically cached, too. And SPAs are for applications, not websites. Most people using SPAs want the application experience to be optimal, not necessarily their initial first time load. They want small requests, interactivity, live feedback. This is all possible with SSR, but nowhere near as simple.