- 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.

You mentioned TTI (time to interactive) as a concern but that is a metric the Gatsby team seems to really be aware of from the beginning and I think they've done a pretty good job of dealing with it so far, see: https://www.gatsbyjs.org/blog/2017-09-13-why-is-gatsby-so-fa... In general though I've found client-side hydration to work pretty seamlessly in both React and Vue. I'll be shipping my first (non-trivial) Vue Server-Side Rendered app to production soon.

I think Gatsby would do a pretty good job even for content-heavy sites. It's built to try to only render the critical-path items. If you have a content-heavy site, you most likely have implemented some sort of summary list and pagination and only the first set of links on each static page are going to be prefetched by the browser. So it's not like you have to load all the data up front (and you probably shouldn't for UX reasons), you just have to organize the data appropriately like you would for any other kind of site. I've found that Gatsby's graphql interface makes doing these things a breeze compared to my previous React experience where I've had to mess around with state management libraries like Redux.

I'm confused by what you meant by "you can't take advantage of your framework to generate image tags". Is this in the context of Nuxt processing markdown on the client? Like I mentioned previously, this shouldn't be an issue with Gatsby and there are some cool plugins that, for example, allow you to process images in markdown during the build so that they are lazy loaded and initially show a low-res geometric representation of the image.

I can understand your hesitation to want to work with React though. I was hesitant at first. I would get annoyed at writing JSX, but once I got used to it, I found it tolerable and on rare cases I actually prefer it now.

> I'm confused by what you meant by "you can't take advantage of your framework to generate image tags".

I mean that the framework needs to be handed the final html. It has no knowledge about the formatting inside a post. You have to rely on plugins, often third-party, which don't play well with each other.

I know I've gone on about bundle size (that was just the straw that broke the camel's back) but my main problem is that these frameworks don't help in going from the markdown to the final html which is 90% of the work. I'm not saying they should or can, just they don't, so they don't add enough value imo to be worth the overhead. This is true of all SSGs I've tried though. Yeah they always have a markdown plugin and, for example, that image loading plugin does sound really cool, but can I trust them to work nicely with other plugins? Do the plugins I need even exist? Will they be maintained? I can just feel I will end up fighting them and I've wrestled with too many SSGs already. I'd rather just try to roll my own at this point.