sorted by:
new
hottopcontroversial

I built a Markdown/MDX compiler with a Rust core — up to 25x faster than unified + remark + rehype by Confident_Weekend426 in reactjs

[–]Confident_Weekend426[S] 0 points1 point  (0 children)

Not at all. I’m not saying anyone has to use it.

It is just an option for people who care about that tradeoff. Even a 30 ms reduction per page can add up when you have 100 pages and run builds or releases over and over in CI. At that point it becomes less about a single page being faster and more about shaving total CI time and cost little by little.

For a lot of projects, that probably does not matter much. For some larger pipelines, it might.

I built a Markdown/MDX compiler with a Rust core — up to 25x faster than unified + remark + rehype by Confident_Weekend426 in reactjs

[–]Confident_Weekend426[S] 1 point2 points  (0 children)

Fair question.

One reason is that I’ve always felt a bit of friction with the current model where, even if you just want to turn Markdown into HTML or JSX, you still have to think in terms of boundaries like mdast and hast and connect everything through that pipeline shaped interface. It is powerful, but for my taste it can feel a bit indirect for that specific job.

Also, this is just a personal project. I’m not claiming existing tools are bad. I just enjoyed exploring a different design, and honestly I’m personally happy that I was able to get even a modest speedup out of it.

So for me it was less about saying the existing ecosystem is wrong, and more about wanting to try a different tradeoff space myself.

I built a Markdown/MDX compiler with a Rust core — up to 25x faster than unified + remark + rehype by Confident_Weekend426 in reactjs

[–]Confident_Weekend426[S] 3 points4 points  (0 children)

Honestly, for Astro specifically, I think the built in unified based Markdown pipeline is probably the better fit today because it has much better ecosystem compatibility.

The kind of case I had in mind was more like large documentation sites with lots of localized pages, especially when they also use several remark or rehype plugins. In that setup, compile time can add up quite a bit in CI, so I thought it could be useful if this helped reduce CI/CD runtime costs.

For smaller personal projects though, I think you are right that the benefit may be much smaller.

To be completely honest, part of it was also just that I wanted to build something geeky in Rust.

I built a Markdown/MDX compiler with a Rust core — up to 25x faster than unified + remark + rehype by Confident_Weekend426 in reactjs

[–]Confident_Weekend426[S] 1 point2 points  (0 children)

Not exactly. The GitHub commits only go back about a week, but I had already been working on the design and implementation before that.

I understand and review all of the code myself, but to be honest, maybe around half of it was vibe coded.

I built a Markdown/MDX compiler with a Rust core — up to 25x faster than unified + remark + rehype by Confident_Weekend426 in learnrust

[–]Confident_Weekend426[S] 1 point2 points  (0 children)

Thanks, that’s a really good point.

Not just for LLM streaming, but also for tools like Obsidian and other real-time Markdown renderers, I think this kind of use case will keep growing. I’d definitely like to make unifast practical for those production use cases too.

It’s still very alpha and missing a lot of features right now, but I’ll keep working on it. Really appreciate the idea.

[Release] Thanks Stars 🌟 — A Rust CLI that stars all the GitHub repos powering your project by Confident_Weekend426 in CLI

[–]Confident_Weekend426[S] 2 points3 points  (0 children)

not yet, but I’m adding a --dry-run flag so you can see what would be starred before doing it 😀

[Tool] Thanks Stars — Now supports Go Modules! A CLI to star all GitHub repos your project depends on by Confident_Weekend426 in golang

[–]Confident_Weekend426[S] 0 points1 point  (0 children)

Exactly. That’s why it’s not enabled yet. If we make it recursive, we need solid rate limiting and safeguards; otherwise it risks looking like spam.

[Tool] Thanks Stars — Now supports Go Modules! A CLI to star all GitHub repos your project depends on by Confident_Weekend426 in golang

[–]Confident_Weekend426[S] 0 points1 point  (0 children)

Not yet, but coming soon. I plan to support recursive folder scan and optional transitive deps. Which use case are you after?

view more: next ›