Per default, Astro generates static pages. So it makes sense to compare it to an approach that doesn't.
Using a framework has upsides over writing static pages manually. Most notably, you can decompose your website into reusable components which makes your implementation more DRY. Also, you can fluently upgrade to a very interaction-heavy website without ever changing tech or architecture. But that's just what I value. I whole-heartedly recommend trying it out.
What about DX in terms of template execution speed? There are many implementations of template fragments on various platforms like Go and Rust [1], which might arguably perform better than their JavaScript counterparts. Wouldn't quicker execution give you a faster feedback loop when developing, and also give you a faster UX?
> Wouldn't quicker execution give you a faster feedback loop when developing, and also give you a faster UX?
Yes, I've used stuff like Templ for Go or Razor Pages for .NET.
Even if the raw HTML rendering performance is significantly better, there are other factors to consider in terms of dx.
1) Most backend languages will not hot reload modules in the client which is what Vite gives you.
Very often the whole backend application needs to be recompiled and restarted. Even with something like the .NET CLI which does have a hot reload feature (and it's absolute garbage btw) the whole page needs to be reloaded.
PHP has an advantage here since every request typically "runs the whole application".
But even with PHP, JS and CSS assets do not have hot reload unless you're also running Vite in parallel (which is what Laravel does).
With Astro you can run a single Vite dev server which takes care of everything with reliable and instant hot reload.
2) With Astro you will get islands which are simply not feasible with any non-JS backend. Islands are so much more powerful than old school progressive enhancement techniques. When we were using eg jQuery 15+ years ago it was a massive pain to coordinate between backend dynamic HTML, frontend JS code, and CSS. Now with islands you can encapsulate all that in a single file.
3) You also get CSS co-location. Meaning you can write an Astro server component with its own CSS scoped to the particular piece of markup. Again, CSS colocation is a huge win for dx. These days I write vanilla CSS with PostCSS but with Astro it's trivial to integrate any other CSS workflow: Tailwind, SCSS, etc.
4) Finally, you have to consider bundling of frontend assets. I don't think it's an exaggeration to say that solutions like Vite are really the best you can get in this space. Internally it uses Go and Rust but it's all abstracted for you.
If you have a use case where you really need exceptional HTML rendering performance in a monolithic application, Astro (or really anything in JS) is definitely a bad fit. But you can easily run an Astro server app on eg Cloudflare Workers which could would work in many of those use cases too and reduce latency and adapt dynamically to load.
That's a really low bar. Why not static pages? Why even use a framework at all if you're thinking of using Astro?