Technically, yes it's non-blocking, that's not the problem. For something like, for example, a store front, I agree, these framework renderers are great because/when:
- You have little data that needs to be pre-loaded (e.g. item name, price, description, thumbnail, etc).
- If you do have a lot of data, then your website is of the type that users revisit a lot (e.g. a documentation site).
- The data is modular (it's not one chunk of data) and can benefit from using a framework to organize it.
- Very little content changes from page to page (in a store front, the majority of the layout is re-used).
- There's a lot of DOM manipulation you want to do (e.g. checkout, cart, etc)
This is not true of content heavy blogs:
- It's a lot of data which must at a minimum be duplicated twice.
- The data is not modular. In one markdown file you have to process the text, images, videos, embeds, etc., all at once. So, for example, you can't take advantage of your framework to generate image tags.
- There's almost zero DOM manipulation needed (at most I might have a portfolio page which needs some js, a lazy-load script, and some share buttons).
- A lot of content changes from page to page (it overshadows any content they might have in common).
- The content is not exactly of the type users would revisit often.
With Nuxt (again don't know with Gatsby, and I think they're working in Nuxt to fix this), you also have to jump through hoops to pre-convert your markdown to html because otherwise you're converting on the client side. Found this out when I looked at the bundles and there were a bunch of emojis in it, turns out it was my markdown converter getting imported into the bundle.
Now, let's suppose this wasn't that difficult, there was some function were you could pre-convert this data and it wasn't including the libraries to do it in the bundle.
Except this is THE pain point of SSGs for blogs. The majority of the problems are here and you would essentially end up writing a static generator inside this function (when I realized this I gave up on Nuxt and similar framework renderers). I would have gained very little for that headache, and how big I would be willing to have the bundle size is a LOT smaller.
And while, yes, bundle sizes are usually small and don't matter for the cases I outlined in the beginning, this is not true, like I said, of a content heavy blog. I don't have a nice a proper benchmark, but I do have some notes from when I tried nuxt. These are the sizes of a single test index page (plain text + a couple lines of css for basic styling) and the full loading times with unthrottled and fully throttled (though this is a bit deceiving* ):
Nuxt w/o Content ~170kb - 250ms - 7.8s
Nuxt w/ 10 Blog Posts ~500kb - 70ms - 14s
Nuxt w/ 10 Blog Posts w/ All Scripts Removed ~110kb - 8ms - 4.3s
You can see how my text is about ~100kb, framework is ~170kb, but the script it produces is 500kb because, I actually forgot, it's reproducing my content 3 times (did not bother to investigate why, just twice is bad enough imo)!
* Now, yes technically the throttled load times don't matter because the static html is loaded (they all paint, even throttled at around the same time), so there's no waiting for the page to load, but who knows what the rest of the background loading does to interactivity (on a proper site, with images, buttons, etc, this was just text) on slow phones with slow internet. Why would I do this to my users? It's not like it's even pre-loading anything useful (this test was with a single page, no other existing pages), imagine if it were.
> Using JS to render a new page is going to be faster than loading the entire static page.
Yes, the lack of a refresh is nice, I'll give you that and it's true that subsequent navigations are faster, but in my case I don't think it's worth the overhead. Plus, so much content changes per page, I could always just fetch the next page and replace the body manually without the overhead of a framework.
Don't get me wrong though, I would probably use a framework based SSG for say, a code blog, where it has more pros than cons. So I can see where most developers are coming from when they use them / design them.