The contention between these two schools of thought seems to elude to a bigger problem that right now both options kinda suck.
The old old school mode of serving static HTML pages is totally fine. I have basically no issue with it. You can't do very much but if your site is a series of interlinked but self-contained documents then it's the gold standard. Once you start having a lot of dynamic content there's a lot of waste since each page is it's own little application.
The 'classic' model of multi-page web design which boils down to templating HTML pages is awful. Truly ungodly awful. I don't care how many layers of DSL you pile on top of it to make it feel less like you're building an application with C preprocessor macros it doesn't make it any better or less brittle.
The SPA model is "more correct" way to do dynamic content since we're back to serving static pages but still ends up terrible since now every single page has emulate browser semantics poorly and deal with the nightmare that is using the browser as a rendering target.
There's got to be some middle ground. I want the browser to be my application router. Give be a site-global place to stick my JS send me an event with what page I need to render.
> The SPA model is "more correct" way to do dynamic content since we're back to serving static pages
The contention is that we cannot even agree on basic words. An SPA is anything but "static", it's as dynamic as a website can ever be with all the untrusted JavaScript code that my browser has to execute (hence why browsers are as complex as they are today). A server-side application serving static HTML and CSS ("static" as in "no JS") is much easier to trust.
When I say static I mean that your web server distributes a fixed artifact without any server-side templating.
Your usage of 'static' conflicts with the usage of 'static site generator' where fixed payloads are generated that can be uploaded to any web server. Such sites can have no JS, be full blown SPAs, or anywhere in between.
Some people use "static content" for this but often sites serving static content are still enhanced by JS in some form. Just that the main page content doesn't have any interactivity.
One of these "You probably don't need [popular technology x]" articles comes out pretty often now. I understand what the message is (don't use tech just because it's popular, but pick the right tool for the job). But I always wondered why these types of articles are titled to be dismissive ("you probably don't need x") rather than representative of their actual content ("here's when to use x").
1. Psychological goals: it's more interesting to read "You probably don't need X" articles; they tend to have a bit of snark and humour and brevity to them which more straight-faced "Here's when to use X" don't.
Bluntly, I'll read former even when I am nowhere near using X myself, as they may be fun and educational. I will not read the latter unless I'm closely involved with X, because they sound like instruction manual and world is full of those.
2. Target audience is implicitly different in the two titles - they are not interchangeable in my mind.
Assumption is that there is a far larger number of people who ARE using X but SHOULDN'T, and so the title/article "You probably don't need X" is written for them; than people who SHOULD be using X but AREN'T (for whom the latter title is more appropriate).
I thought this one was very balanced actually. Its message was, "you probably don't need [x] (but you may)".
In all honesty, I've seen dozens if not hundreds of solo or small team startups/bootstrappers build a SPA they didn't need to and then fail, in part because they were moving to slowly.
The second one leaves open the possibility that you should use x if there isn't a y that's clearly strictly better. Whereas the first one suggests you should avoid choosing x unless it's strictly better.
You need to ask yourself if you need a website or a web app.
Sometimes your project can be split into both. The homepage, login, billing, privacy policy, and other static pages can be a traditional server-side rendered website. More complex sections, like a file browser or text messenger, can be apps.
Or make the parts of the app(s) with tabular or news feed type data be more of a SPA type. I find SPA tolerable when they are apps users are filtering, posting, or manipulating data. Once you make my back button weird or break URLs I hate SPAs.
> Once you make my back button weird or break URLs I hate SPAs.
The silly thing is, it’s very easy to not do that. It wouldn’t surprise me to learn that a lot of what people hate about SPAs is down to so many people doing a bloody awful job of building them.
Why do you need server-side rendering for static pages? They are static pages - let them be static html and send the file. Pages like that get millions of times more reads than writes.
If you need an "app," then yes, you should probably do a SPA. In the same way that an app on your phone is a chunk of pre-loaded client-side code that accesses a server's API in a minimal way, with mostly metadata being exchanged, I'm of the mind an "app" ought to minimize server load in this way.
If, on the other hand, you need a "site" (which will be relatively static), and you can handle a few extra processor cycles on your webserver, server-side rendering is probably fine. Still, I retain a distaste for it that I can't fully explain.
Does anyone have a good example of something that's made as a single page app that shouldn't be one? The reasons described for choosing a single page app, real time functionality and rich ui interactions etcetera, seem like core parts of just about every new startup's web service offering as all these formerly offline desktop programs become online SAAS subscriptions and so on. What wouldn't need a single page app?
Good luck building my application https://gif.com.ai as a non SPA. This is an app as much as photoshop is an app so this is a good case for a SPA as the author suggests. If over 85 percent of your app logic is on the front end then you might need a SPA.
No, unfortunately you need. If you want to build a Progressive Web App (PWA) and have just one source for your site and your mobile app, you need a SPA. The mobile ecosystem is nowadays more important than the web.
You can of course just use the website on mobile too though, apps aren’t needed and often they’re just annoying marketing ploys designed to keep you in a walled garden. I much prefer accessing the website of services than their apps while using mobile
The old old school mode of serving static HTML pages is totally fine. I have basically no issue with it. You can't do very much but if your site is a series of interlinked but self-contained documents then it's the gold standard. Once you start having a lot of dynamic content there's a lot of waste since each page is it's own little application.
The 'classic' model of multi-page web design which boils down to templating HTML pages is awful. Truly ungodly awful. I don't care how many layers of DSL you pile on top of it to make it feel less like you're building an application with C preprocessor macros it doesn't make it any better or less brittle.
The SPA model is "more correct" way to do dynamic content since we're back to serving static pages but still ends up terrible since now every single page has emulate browser semantics poorly and deal with the nightmare that is using the browser as a rendering target.
There's got to be some middle ground. I want the browser to be my application router. Give be a site-global place to stick my JS send me an event with what page I need to render.