How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I made the Rust compiler and the Rust Markdown pipeline (https://satteri.bruits.org) in this, let me know if you have any questions, glad to answer anything!
It was tough to create a plugin API that was both performant and intuitive. Especially since the library people were migrating from (remark/rehype) was very laissez-faire in regard to the data you have access to, visiting patterns, etc.
Crossing data between Rust and JS is inherently kinda slow (relatively), so there's a constant push and pull between flexibility and performance that's not always easy to reason about!
I probably only use 1 % of Astro's features, but I like how it's enabled me to build static sides as back in the days, but with a build pipeline.
So I can use components, reuse stuff, include stuff etc, basically what I would do with PHP back in the days, but now it spits out a compiled page I can host for cheap (often even free). And easy to add in some interactivity when needed. Like I render a list as a component, and very easy to ship some dynamic filtering on the frontend using the same code, but the content is still statically in the html, so served fast and good SEO.
The switch to strict HTML compilation is just not cool, and actively prevents upgrading sites which need to deal with remote content that is not written in strict HTML.
I also wish there could be a general purpose content processing API so I can plug a different format than markdown (such as typst)
Unfortunately, I've also come across .astro files that I'm not allowed to touch and yet have to work with them (some internal corporate dinosaur which has not been updated for a while).
For my personal site, it was a 5 minute work, as usual :)
set:html only handles rendering though, not what you write in the .astro file itself, right? So strict compilation still bites you if the template markup itself has quirks, not just injected content.
The AI Enhancements section was interesting. I've been wondering about the best practices for agents interacting with long-running dev servers, and Astro 7's approach (run in background and have a logs command) seems like a good model.
Astro is a meta-framework that allows you to plug in other web frameworks where you need it (React, Solid, etc). Although it would also be fair to consider Astro a sort of build tool / bundler.
Node is a runtime, not a framework.
So there's really only one framework here (Astro). Using other web frameworks within it is completely optional.
I have been trying to convince my marketing department to replace there archaic wordpress with an Astro build with AstroCMS and markdown for there needs.
I have build several sites using Astro 6, and i am finding the ease of building the sites amazing and exceptional in SEO as well.
No idea. Probably some markdown-to-content wrapper, half these "CMS" products in 2026 are just YAML files with marketing copy. Astro's own content collections do this fine already.
I had tried astro for my personal website when it was released. It was a mess for me. I couldn't keep with so many components. I keep breaking things, one way or the other. I might have to try again to see what things have changed.
We unfortunately released Astro 6 only a few weeks before Vite 8 / Rolldown came out, which is why we did Astro 7 so soon. But there are very few breaking changes compared to Astro 6. That being said, some of these performance improvements (the Sätteri processor) are available in Astro 6 too.
Cloudflare bought Astro recently, and as it states in docs it previously had cache plugins for 2 companies but not Cloudflare so that may have been a motivation along with the Vite update mentioned
It was partially that, but mostly the Vite version with the Rolldown bundling etc. We typically always need to do a major whenever Vite releases one because it tends to impact us a lot compared to other frameworks for various reasons.
I upgraded my website recently and it's exciting! That being said, I admit my builds didn't get faster (they actually on average slowed down a bit). Hopefully that improves, but worth noting.
I like the idea of astro, but never really used it.
My main concern is. Does v7 mean that there have been 7 breaking changes thus far?
So if I started my project on v1, I had to revise it 6 times to date?
If yes, then this instability is a serious concern to me.
If you are using every single feature Astro has, your code somehow goes through every single branch (of every single dependency), etc then yes, but that'd be a pretty far-fetched scenario!
In practice, our users typically comment quite positively on how little (if any) work major updates requires, and we offer pretty extensive upgrade guides, if that helps.
Version numbers as breaking-change counters isn't really how semver works in practice though, plenty of major bumps are mostly deprecations plus a few edge-case API changes, not full rewrites.
We don't intend on removing support for the unified ecosystem, we on purpose made the Markdown processing pipeline pluggable so that it was possible for both to exists!
The vast majority of our users don't use any sort of unified plugins, so a pipeline that's faster (and about 100 deps leaner) felt like a better default.
For me currently nothing beats Astro + Claude Code for building sites, maybe with some image generator sprinkled in. Build time improvements are always welcome, great job!
Are these typical build speeds on static sites these days? It's slower than I expected for a rust re-write. (Or I guess maybe the portion re-written in rust is only a small part of the build pipeline time?)
My understanding is that astro isn't considered particularly slow?
Yeah, the parts rewritten in Rust here as only parts of the bottleneck. A lot of it is still JavaScript (including the user's code!). If Astro was just .md -> HTML, it'd of course be much faster.
Disagree. Every major framework ships breaking changes eventually, that's not exhausting, that's maintenance. If you froze at v1 forever you'd be stuck with worse APIs and no perf gains.
Rust compiler, sure. Ask me in six months when some CI runner's stuck on wrong glibc and the prebuilt binary won't load. Pure JS never had that problem.
