Princesseuh

6 ms·

1.
by Princesseuh 2mo ago
Hello, I'm the maintainer of this. Let me know if you people have any questions / comments :)
2.
by Princesseuh 2mo ago
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
3.
by Princesseuh 2mo ago
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
4.
by Princesseuh 2mo ago
Love everything you do Steve, consider that I've done it for you
5.
by Princesseuh 2mo ago
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.
6.
by Princesseuh 2mo ago
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
7.
by Princesseuh 2mo ago
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.
8.
by Princesseuh 2mo ago
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.
9.
by Princesseuh 2mo ago
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
10.
by Princesseuh 2mo ago
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/#.
11.
by Princesseuh 2mo ago
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!
12.
by Princesseuh 4mo ago
Zed has semantic highlighting: https://zed.dev/docs/semantic-tokens It was added a few months ago if I remember correctly.
13.
by Princesseuh 5mo ago
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 le
14.
Show HN: Sätteri, high-performance Markdown pipeline for JavaScript(github.com)
1 points by Princesseuh 5mo ago|0 comments
15.
by Princesseuh 11mo ago
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
16.
by Princesseuh 11mo ago
Thank you! Let me know if you have any questions or encounter any problems, always happy to help.
17.
by Princesseuh 11mo ago
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/#en
18.
Show HN: Maudit, a Rust library to build static websites(maudit.org)
4 points by Princesseuh 1y ago|4 comments
19.
by Princesseuh 3y ago
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)
20.
by Princesseuh 8y ago
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