Yea I think Nuxt must have started out with different priorities/tradeoffs than Gatsby did because Gatsby has the idea of sources which gives it a nice structur

Yea I think Nuxt must have started out with different priorities/tradeoffs than Gatsby did because Gatsby has the idea of sources which gives it a nice structure for specifying what processing/data fetching needs to be done at compile time vs at run time. It's super easy to just add a markdown source plugin (actually markdown support might be built-in) and it will compile it to HTML when your run the build and not on the client. There a ton of source plugins, but if you had to, I think it would be much easier to write one and use the provided abstractions than to write the pre-convert function you are thinking of. 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-fast/ 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.