> multi-page sites seem superior if you're more concerned with things like search engine traffic, maximum compatibility, smallest size, lowest maintenance, inte

> multi-page sites seem superior if you're more concerned with things like search engine traffic, maximum compatibility, smallest size, lowest maintenance, interacting with standard browser functionality (i.e. letting users bookmark pages in your app, browser extensions, etc). Building single-page applications is my bread and butter, and I totally agree with this sentiment. If you're building something that's purely content and doesn't require too much interactivity (which is true for most websites on the web today), SPAs are not worth the hassle. However, it's worth noting that most SPA frameworks support server-side rendering. For one of my clients, I built a server rendered React website that behaved less like a SPA and more like a regular server rendered website, i.e, navigating to a link within the website caused a full page reload. The performance numbers weren't too different from your average Django/Rails/PHP website, and making sure everything worked on Node as well as the browser wasn't as hard as we imagined. The advantage was that we could write the whole thing with React, as opposed to using some kind of templating language to generate HTML and then using JS to inject the interactive bits. It's an interesting strategy that I wouldn't mind exploring again. Why did we do it? Because we had to integrate with a bunch of legacy code and this was the only way we could do it sanely.