Hacker News Reader

Comment by jackconsidine | Hacker News Reader

For me it's the pre-rendering. I've used Next.js, Nuxt.js, Remix etc and they all server-render great. But for deploying SPAs to file-hosting (S3 + Cloud Front or Firebase Hosting) without a server runtime, you end up with empty HTML on request which is worse for SEO, social previews etc. There are solutions to pre-rendering for these stacks but they're more focused on deploying to Vercel or Netlify functions, or having a post-build script which opens the site in Puppeteer and saves the HTML into your build file! With Astro, all this is out of the box immediately. Try putting together an Astro site and look in your build directory; you'll see even for React components the HTML is already there

View on HN

I can just do a `nuxt generate` and put it on CF+S3 as well, right? how is that any different to what Astro does?

Looks the same to me after a quick read as someone who has never used an SSG BEFORE

Yeah you can, but there's more configuration involved. The default `nuxt generate` output is an HTML page that just has a loading element and a bunch of JavaScript tags*. On my Astro apps all of components that don't explicitly have a "client" attribute are prerendered

* unless something changed since my last Nuxt project

That's what I find confusing in Astro's self-presentation: they talk a lot about MPA vs SPA and how nicely they blend, making it abundantly clear that by MPA, they mean server-rendered. But then there's all the talk about static file hosting and I think the project even started as a static site generator ("dev-machine rendered")? It would be super awesome if they tackled what might be called "three level partial hydration" (build time, server side, client side).

Might even sneak in a fourth level, "server side, but cached until marked dirty". For when you are set up for static rendering, but want to reduce backend load for rarely changing stuff. I'd expect that it would be quite powerful to have that capability inside the engine that handles rendering, on component level if necessary,and not just on some internal microservice boundary (where I think it's quite common?).

Responding to myself: documentation clearly seems to come from two different areas, one when everything was either client side or build time and another after astro introduced server side dynamism.

Apparently there has been quite a watershed moment, with the announcement merely a few months ago: https://astro.build/blog/experimental-server-side-rendering/

Reply on news.ycombinator.com