I used to write all my static sites using Hugo, until I saw a site that was built using Gatsby. Gatsby has a larger overhead on the initial page load but feels much faster and subsequent page loads have less overhead (or maybe more, if it's prefetching a lot of adjacent pages which you'll never navigate to).
It seems to me that the next logical step is a site that ships the initial page request in vanilla JS, then async loads react and then async fetches the overhead and then runs Gatsby. This would be the ideal if we're optimizing for perceived latency. So the first page load is fast, then as long as you stay on that page for a second or two before clicking elsewhere, everything after that point will be snappy too.
Ofcourse, many other devs are optimizing for network usage, etc, so to each their own.
You can attain Gatsby's SPA feel/speed with Hugo, via Turbolinks[0]. A much smaller overhead on initial page load, and you can hook up a service worker to do any prefetching/caching.
From my experience, it seems like you'd have to jump through a few hoops to get prefetching working with Turbolinks. I just relied on having my service worker do all of the prefetching/caching of the site's important pages + static assets.
> It seems to me that the next logical step is a site that ships the initial page request in vanilla JS, then async loads react and then async fetches the overhead and then runs Gatsby.
I don't know about React and Vue, but that's what Angular universal does, and page load is indeed very fast then
Your next logical step probably won't happen for React (outside of server rendering). React is just JavaScript, so you can't capture and serialize event handlers, etc. Though Prepack (by Sebastian on the core React team) is an attempt at doing something similar.
A more likely path is that React enables aggressive and progressive loading of component code, so the initial bundle is smaller.
Love Nuxt. I use it for all sorts of things. Pair it with something like Vuetify and you can start writing business logic almost immediately. Never had a problem with speed.
It seems to me that the next logical step is a site that ships the initial page request in vanilla JS, then async loads react and then async fetches the overhead and then runs Gatsby. This would be the ideal if we're optimizing for perceived latency. So the first page load is fast, then as long as you stay on that page for a second or two before clicking elsewhere, everything after that point will be snappy too.
Ofcourse, many other devs are optimizing for network usage, etc, so to each their own.