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.
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.
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.
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!
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.
The TL;DR is that `marked` is very light, but a bit on the slower side compared to Sätteri and `markdown-it` (and its forks). I'm not sure how friendly the extensibility is, but Sätteri re-use the same AST format as the unified ecosystem, which might feel more friendly.
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!
Not intending this to be an ad, but a friend of mine has been working on a changesets-based tool that has native polyglot support: https://github.com/bruits/sampo
Hopefully easier than hacking around changesets, but less mature, of course.
(Disclaimer: Him and I are in the same org and I have sent PRs to said tool)
Working on Maudit, a Rust library to make static websites. Emphasis on library instead of framework. I aim that you could integrate Maudit into existing Rust apps, building pages individually, rendering Markdown where you need etc, instead of a black box magic "build website" command.
Wouldn't it be better to show the intended font at first page (using font-display: swap or fallback instead of optional) instead of a potentially uglier fallback font until second page?
With swap (or fallback) the page is visible early using a fallback font but you still end up with your "goal font" without having to reload or visit another page