> Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference).
As a user I don't care about the developer's aesthetic preferences for tooling, only how long it takes to see the information I need. This feeds back to the question of why an SPA matters: for a rich application, there's more benefit to cancel out the runtime overhead.
For static docs, your timing is off by at least one order of magnitude: I have to wait a second or more — a LOT more on a high-latency connection where that initial page load is 15+ seconds worse[1] – and there doesn't seem to be much benefit to compensate for that. I mean, the animation is cool the first time I see it but I see it a lot because there's less information on each page so the novelty wears off pretty quickly.
Again, please note the last part of my comment: there is a place for SPAs but I'm not sure why a site this simple needs 500KB of JavaScript to deliver static documentation slower than Apache did two decades ago. I was expecting to see a selling point such as loading the content so that it was usable offline and search results were instantaneous but e.g. that nice search box (which is the one thing you couldn't have done in 1994) still takes 3+ seconds to load and render the new page on a well-peered gigabit connection.
I'm on a terrible high latency connection in Athens, Greece. The serverless SPA is one of the fastest sites I've ever visited. It's a ton faster than HN for me.
Yes the initial pageload takes time. But afterwards I can click around the site and get immediate feedback. Immediate as in native app speeds. Images and such obviously still take time to load and render but they do not block loading. There's no whitescreen while I wait for new pages to load.
So as someone with shitty internet who often browses documentation, give me hundreds of sites like this. This is significantly faster to browse around than, say, the Python or Django documentation, both of which make very little use of Javascript. I'm sorry you're not getting the same experience, I can't speak to that.
To reiterate: An SPA will bloody obviously not faster on the first pageload. The whole idea behind it is that you load more machinery upfront but you don't load it again afterwards. Depending on how good the app is, you make up for it very, very quickly. And if you have any significant JS usage on your site at all, you make up for that too.
My point, which everyone seems to have completely missed, is that well-built SPAs do exist. They don't have to feel slower to use than other apps.
As a user I don't care about the developer's aesthetic preferences for tooling, only how long it takes to see the information I need. This feeds back to the question of why an SPA matters: for a rich application, there's more benefit to cancel out the runtime overhead.
For static docs, your timing is off by at least one order of magnitude: I have to wait a second or more — a LOT more on a high-latency connection where that initial page load is 15+ seconds worse[1] – and there doesn't seem to be much benefit to compensate for that. I mean, the animation is cool the first time I see it but I see it a lot because there's less information on each page so the novelty wears off pretty quickly.
Again, please note the last part of my comment: there is a place for SPAs but I'm not sure why a site this simple needs 500KB of JavaScript to deliver static documentation slower than Apache did two decades ago. I was expecting to see a selling point such as loading the content so that it was usable offline and search results were instantaneous but e.g. that nice search box (which is the one thing you couldn't have done in 1994) still takes 3+ seconds to load and render the new page on a well-peered gigabit connection.
1. http://www.webpagetest.org/result/180628_CF_db268e65de67002e...