Princesseuh

Hello, I'm the maintainer of this. Let me know if you people have any questions / comments :)

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.

Love everything you do Steve, consider that I've done it for you

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!

This was actually part of the reason I made the Rust markdown processing, the unified ecosystem is a lot of deps!

I still have some plans in this area that should reduce the overall count further, though.

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.

It depends in what regards you mean, I have some benchmarks here if you'd like to take a look at those: https://github.com/Princesseuh/web-markdown-benchmark

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.

Both good options, though!

This does not affect remote content, only the content written in .astro files. If you have remote content you'd use something like `set:html`: https://docs.astro.build/en/reference/directives-reference/#...

See this example: https://stackblitz.com/edit/github-ug3paw61?file=src%2Fpages...

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!

Zed has semantic highlighting: https://zed.dev/docs/semantic-tokens

It was added a few months ago if I remember correctly.

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.

https://maudit.org https://github.com/bruits/maudit

Thank you! Let me know if you have any questions or encounter any problems, always happy to help.

Ah! Thank you for taking interest.

At this time there's no built-in way to generate RSS feeds, you'd need to use a "Endpoint" route and return a .xml from it: https://maudit.org/docs/routing/#endpoints.

It's pretty straightforward, but it does require some manual work. Crates like `rss_gen` can help making the generation easier, though

Prettier does not support Astro files natively, so it's the Astro plugin's fault in this case.

(I maintain said plugin, so, well, it's my fault)

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