top | item 46571980

Show HN: Ferrite – Markdown editor in Rust with native Mermaid diagram rendering

241 points| OlaProis | 2 months ago |github.com

Ferrite: Fast Markdown/Text/Code editor in Rust with native Mermaid diagrams

Built a Markdown editor using Rust + egui. v0.2.1 just dropped with major Mermaid improvements:

→ Native Mermaid diagrams - Flowcharts, sequence, state, ER, git graphs - pure Rust, no JS

→ Split view - Raw + rendered side-by-side with sync scrolling

→ Syntax highlighting - 40+ languages with large file optimization

→ JSON/YAML/TOML tree viewer - Structured editing with expand/collapse

→ Git integration - File tree shows modified/staged/untracked status

Also: minimap, zen mode, auto-save, session restore, code folding indicators.

~15MB binary, instant startup. Windows/Linux/macOS.

GitHub: https://github.com/OlaProeis/Ferrite

v0.2.2 coming soon with performance improvements for large files. Looking for feedback!

190 comments

order
[+] random3|2 months ago|reply
This is cool. I was hoping to see progress coming from Zed (e.g. because Tree-sitter → https://github.com/tree-sitter-grammars/tree-sitter-markdown) but it's exciting to see this. I'm a heavy Obsidian user, and I love it, but I'd love to see real alternatives focused on foundations.

It would be interesting to know more about the end-goal if any.

Best of luck! I'll watch this.

[+] OlaProis|2 months ago|reply
Thanks! The end-goal is a fast, native Markdown editor that "just works" - no Electron, no web tech, instant startup. v0.3.0 will extract Mermaid as a standalone crate and build a custom text editor widget to unlock features egui's TextEdit blocks (proper multi-cursor, code folding). Long-term: potentially extract the editor as a headless Rust library since that's missing in the ecosystem. See ROADMAP.md for details
[+] kirubakaran|2 months ago|reply
Since you're an Obsidian user, can I please get your feedback on https://hyperclast.com/ which I'm building?

(I'm not quite ready to do a Show HN yet, so please don't post it, but I'm ready for some early feedback if you'll indulge me)

[+] echelon|2 months ago|reply
What is Obsidian written in? Electron?
[+] rkagerer|2 months ago|reply
> Platform Note: Ferrite has been primarily developed and tested on Windows. While it should work on Linux and macOS, these platforms have not been extensively tested.

Neat! Lately on Windows I've felt like a 2nd class citizen.

> AI Disclosure: This project is 100% AI-generated code.

Oh.

Well, at least they're up front about it.

[+] dystroy|2 months ago|reply
This disclosure has been added today, after some users here called them out for hiding that they were using AI to build it.
[+] rajatkulk|2 months ago|reply
Shamelessly plugging my app Octarine (https://octarine.app) for users that may want a more WYSIWYG editing experience while storing all notes on device in markdown, which is also written in Rust (Tauri), and NOT vibe coded :)
[+] weakfish|2 months ago|reply
Wow, this looks awesome. Downloading now.
[+] msephton|2 months ago|reply
Will need a magnifying glass to see the text on the screenshots.

I find it makes sense to take screenshots in a window big enough to show what's going on, but no bigger. This means probably not full screen, or maximised, especially if you're running at a very high resolution. If there's a lot of dead/empty space in the window that's a signal it's too big. This way you guarantee the screenshots are readable without zooming in, on smaller displays than your own, for example mobile.

[+] OlaProis|2 months ago|reply
Great feedback, thank you! You're absolutely right — the screenshots are taken at high resolution, which makes them hard to read on smaller displays.

I'll retake them with a more focused window size and less dead space. Appreciate the specific guidance!

[+] deviation|2 months ago|reply
AI generated code, AI generated HN post, AI generated comments…
[+] password4321|2 months ago|reply
I'm trying to figure out why this post didn't get run out of town like several others recently, for starters it hit several favorite discussion topics.
[+] djvdq|2 months ago|reply
I missed this disclaimer about it being 100% AI-generated.

In one second I went from "looks cool" to "I don't want to touch it"

[+] Arubis|2 months ago|reply
I happily paid money for Typora, which does roughly the same thing for just Markdown without support for JSON, Yaml (that I know of). This feels like a ripe space, especially with LLMs eagerly outputting reams of parseable text with embedded diagrams.
[+] gregman1|2 months ago|reply
The $15 price tag for Typora seems a bit steep considering the fundamental features it provides.
[+] OlaProis|2 months ago|reply
Thanks! Typora is great - Ferrite aims for similar polish but with native Mermaid, structured data support (JSON/YAML/TOML tree viewer), and the pipeline feature for shell integration. And it's open source!
[+] vunderba|2 months ago|reply
+1 happy user of Typora. I really like its ability to auto-create a related assets folder for embedded media as it’s dragged into a doc.
[+] huevosabio|2 months ago|reply
Nice to see an egui project that doesn't have super obvious egui aesthetics.

How did you find working with egui?

[+] OlaProis|2 months ago|reply
egui is fantastic for rapid prototyping - immediate mode makes state management simple. Main limitation: TextEdit isn't designed for code editors (no multi-cursor, can't hide folded text). v0.3.0 will replace it with a custom widget. The default styling does scream "egui" - spent time on custom theming to avoid that
[+] koakuma-chan|2 months ago|reply
> How did you find working with egui?

Claude Code would have preferred React.

[+] bananaboy|2 months ago|reply
Nice to see native markdown rendering rather than relying on spawning chromium and taking screenshots like some other libraries do!
[+] quintu5|2 months ago|reply
One major downside of native rendering is the lack of layout consistency if you’re editing natively and then sharing anywhere else where the diagram will be rendered by mermaid.js.
[+] OlaProis|2 months ago|reply
Valid point! Native rendering won't be pixel-perfect with mermaid.js. The trade-off is speed and no JS runtime. For documents staying in Ferrite, it's great. For sharing, we're adding SVG export in v0.3.0 so you can use mermaid.js for final renders if needed.
[+] silcoon|2 months ago|reply
Why did you remove AI agent configurations and instructions from the repo? See .gitignore
[+] OlaProis|2 months ago|reply
Fair point - I should be more transparent. Yes, Claude assisted significantly with development. The .gitignore excludes AI config files because they where not needed in the project and aren't useful to others. I'll add a note to the README about AI-assisted development. The code is reviewed and understood, not blindly accepted.
[+] WD-42|2 months ago|reply
It's vibe coded. The entire project is only 10 commits, a few of them are giant with a bunch of markdown files full of emojis in the docs/ folder.
[+] dcreater|2 months ago|reply
Good catch. For me its a red flag when the dev does not disclose AI usage
[+] _flux|2 months ago|reply
Seems like Mermaid parsing and layout would be a useful crate as by itself. I would enjoy a fast mermaid layout command line tool with svg/pdf/png support, which I think would be quite feasible to implement with such a crate.
[+] OlaProis|2 months ago|reply
This is exactly the plan for v0.3.0! Extracting the ~7000 line Mermaid renderer into a standalone crate with SVG/PNG output and CLI support. Pure Rust, WASM-compatible. Stay tuned!
[+] Bishonen88|2 months ago|reply
Looking at the Screenshots, this would've taken days/weeks e.g. 5 years ago. Now this seems to be vibe coded in 2 sessions. Crazy world we live in.
[+] OlaProis|2 months ago|reply
Ha! I appreciate the compliment (I think?). To be transparent: yes, AI tools were used during development — they're fantastic for boilerplate, documentation, and exploring unfamiliar APIs.

But this wasn't "2 sessions" — Ferrite has been in development for months with ~30,000 lines of Rust across 50+ modules. The Mermaid renderer alone is ~6000 lines of layout algorithms (Sugiyama-style graph layout, sequence diagram activation tracking, nested state machines, etc.).

AI helped ALOT, but there's no "generate full app" prompt that produces working text editors with native diagram rendering, rope-based text buffers, and custom window chrome. Still takes understanding the domain.

That said, you're right that the development velocity is higher than 5 years ago. Exciting times!

[+] risyachka|2 months ago|reply
It can be vibe-coded quickly but can also be done rather quickly without ai - the heavy lifting is UI lib from Zed. That is the real unlock in apps like this.
[+] sean_pedersen|2 months ago|reply
Like the idea but it spawns a terminal on startup on Mac and is not WYSIWYG (like Obsidian). Hope this project develops into usable state soon.
[+] OlaProis|2 months ago|reply
Thanks for reporting! This is a packaging issue - need to create a proper .app bundle. On the roadmap for v0.3.0 (macOS signing & notarization). For now, running from terminal is the workaround.
[+] WillAdams|2 months ago|reply
Made the fan in my Windows 11 laptop spin up.
[+] nurettin|2 months ago|reply
This is why I prefer clunky hardware with heating cpus and a slow disk. You can easily feel that you wrote bad code from audio and tactile feedback.
[+] OlaProis|2 months ago|reply
Which view/file caused this? v0.2.2 (coming soon) has significant performance optimizations for large files - deferred syntax highlighting, galley caching. If you can reproduce, please open an issue with details!
[+] OlaProis|2 months ago|reply
v0.2.2 just released — addressing several issues raised in this thread:

- CJK font support 1 — Korean/Chinese/Japanese characters now render properly

- CLI improvements (#9, #10) — ferrite file.md now works, plus --version and --help flags

- Undo/redo fixes 2 — Fixed scroll reset and focus issues

- Default view mode setting 3 — Can now set split/preview as default

- Configurable log level 4 — Reduce stderr noise

- Ubuntu 22.04 compatibility 5 — .deb now works on 22.04+

Thanks to everyone who reported issues! Download: https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2

[+] cat-whisperer|2 months ago|reply
also, on the markdown front, I saw this cool library https://github.com/Canop/termimad gaining popularity
[+] dystroy|2 months ago|reply
Termimad author here: I’m always a bit afraid, when I see the popularity of this crate, that it might be undue and that people may lose time trying to use it when it’s probably not the tool they need.

Termimad isn’t a full-fledged TUI framework. It can be used to build TUIs (I made broot, bacon, safecloset, etc. with it), but if you want to quickly build a TUI and compose UI components and widgets, you’ll probably find it much easier to choose a real TUI framework (e.g. ratatui).

Termimad isn’t a generic Markdown viewer either. Markdown is mainly used as a language for the developer to describe parts of the interface—especially rich text—inside a TUI. People interested in rendering arbitrary Markdown files will find that it lacks features such as image rendering.

[+] k_bx|2 months ago|reply
We need privacy-focused Obsidian alternative (which doesn't store unencrypted text files on disk), excited to see a potential player written in my tech stack, meaning it should be easy to extend!
[+] OlaProis|2 months ago|reply
Ferrite is privacy-focused in that it's fully offline — no telemetry, no cloud sync, no accounts, no network calls (even Mermaid diagrams render locally in pure Rust).

However, files are stored as plain text, same as Obsidian/VS Code/any text editor. Encryption at rest isn't currently on the roadmap.

For encrypted storage, you might consider: - Using Ferrite with an encrypted volume (VeraCrypt, LUKS, FileVault) - git-crypt for encrypted git repos

That said, if there's strong interest in built-in encryption (vault-style or file-level), I'd love to hear more about the use case. Would you want password-protected vaults? Per-file encryption? Something else?

[+] Levitating|2 months ago|reply
Made with egui, if anyones wondering.

I love the new era of graphical applications in Rust.

[+] mgaunard|2 months ago|reply
The main issue is that Markdown remains a pretty primitive language to write documents in, with dozens of incompatible extensions all over the place.

I don't know if it's the best format to focus on.

[+] OlaProis|2 months ago|reply
Fair point about fragmentation! Ferrite uses Comrak which implements CommonMark + GitHub Flavored Markdown (GFM) — arguably the closest thing to a "standard" we have.

We chose Markdown because: - It's what most developers already use (README files, documentation, wikis) - Plain text files are portable, grep-able, git-friendly, and won't lock you in - GFM covers tables, task lists, strikethrough, and autolinks which handles 90% of use cases

We also support JSON, YAML, and TOML with native tree viewers. Wikilinks ([[links]]) and backlinks are planned for v0.3.0 for folks wanting Obsidian-style knowledge bases.

That said, I'd love to hear what format you'd prefer — always interested in expanding support!

[+] tapirl|2 months ago|reply
This is one reason why I created TapirMD, which offers better specificity.
[+] porjo|2 months ago|reply
I don't want to diminish the effort put into this project, but it's a reminder to me of just how many markdown editors there are out there! And yet I'm still searching for the holy grail:

- wysiwyg editor (not live preview)

- simplicity: single binary that can be pointed at a directory of markdown files

- fast launch time, low latency UI

- cross platform

- comes with basic 'extras' like tables & code block support

I actually really like the Confluence editor experience. If I could get that in an FOSS 'offline' package, my needs would be met.

[+] OlaProis|2 months ago|reply
You've basically described Ferrite's design goals! Let me check the boxes:

Single binary — ~15MB, point it at a directory with ferrite ./notes/ or open workspace via UI

Fast launch, low latency — Native Rust/egui, instant startup, no Electron

Cross platform — Windows/Linux/macOS

Tables & code blocks — GFM tables, syntax-highlighted code blocks (40+ languages)

WYSIWYG — This is where it gets nuanced. Ferrite has three modes:

- Rendered mode — Click-to-edit rendered Markdown (closest to WYSIWYG)

- Split view — Raw editor + live preview side-by-side

- Raw mode — Plain text editing

It's not pure "type and it formats inline" like Typora or Confluence. The Rendered mode lets you click elements to edit them, but it's not seamless WYSIWYG yet.

If you're looking for true inline WYSIWYG, Typora is probably closest. But if split view + rendered mode works for you, give Ferrite a try — it hits the other criteria well.