DEV Community

Cover image for I got tired of heavyweight Markdown editors, so I built one in Rust + Tauri that doesn't ship a browser
Shinya Saita
Shinya Saita

Posted on

I got tired of heavyweight Markdown editors, so I built one in Rust + Tauri that doesn't ship a browser

TL;DR: I wanted a Markdown editor that just opens instantly and gets out of the way. Nothing quite fit, so I built Bokuchi with Tauri v2 + Rust + React. Instead of bundling a whole Chromium instance, it renders through the OS's native WebView — so it's light enough to leave open all day and opens before you finish reaching for your coffee. It's open source: github.com/Bokuchi-Editor/bokuchi

The itch

Here's a situation you probably know too well.

You want to jot down a quick note. Maybe a release checklist, maybe a snippet of Markdown for a PR description. So you open your editor of choice — and your laptop fan spins up like it's about to take off. A "note-taking" app just claimed a serious chunk of your RAM before you typed a single character.

I love VS Code. I've used Atom (RIP). I respect Obsidian. But for the specific job of "open a window, write some Markdown, close it", they all felt like renting a moving truck to carry a sandwich.

I had three requirements, and only three:

  1. Simplicity — Markdown editing. That's it. No plugin marketplace, no account, no sync daemon.
  2. A design I won't get tired of — minimal, calm, something I'd happily stare at all day.
  3. Speed above all else — this was non-negotiable. It has to feel instant.

I looked around. I couldn't find the thing that hit all three. So I did what every engineer eventually does when they should probably know better:

I decided to build it myself.

Why "build your own" is the developer's disease

Building your own tool is a trap and a joy at the same time.

It's a trap because "how hard can a text box be?" is one of the great lies we tell ourselves. It's a joy because the moment your own tool does exactly the thing you wanted, in exactly the way you wanted, there's nothing else like it.

The real question wasn't "should I build it" (my ego had already decided). It was "what do I build it with?"

If I reached for Electron, I'd be right back where I started: shipping a whole Chromium instance to render a text area. That defeats requirement #3 before I write a line of code.

Enter Tauri.

What is Tauri, for the uninitiated?

If you haven't touched it yet:

Tauri lets you build desktop apps with a web frontend and a Rust backend. The key difference from Electron is that Tauri doesn't bundle a browser. Instead it uses the operating system's native WebView (WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux).

That one design choice cascades into everything I cared about:

  • Tiny footprint — no bundled Chromium means dramatically smaller binaries and lower memory.
  • Rust backend — safe, fast, and genuinely pleasant for file I/O and heavier logic.
  • Security by default — the app can only touch the OS capabilities you explicitly grant it (more on this below).
  • Cross-platform — one codebase for Windows, macOS, and Linux.

For a "must feel instant" Markdown editor, this was the right foundation.

Meet Bokuchi

So I built Bokuchi — a lightweight, cross-platform Markdown editor.

Stack:

Layer Choice
Framework Tauri v2
Backend Rust
Frontend React + TypeScript
Build Vite
Platforms Windows / macOS / Linux

Light enough to forget it's running

I originally wanted to open this section with a big, satisfying RAM number. I'm not going to — because honestly measuring memory for a WebView-based app is murkier than it looks. Do you count the OS's WebView helper processes? Shared frameworks already resident because the system uses them anyway? Depending on where you draw the line, you can make the number look heroic or ordinary, and I'd rather skip the benchmark theater.

So here's the claim I can stand behind: Bokuchi doesn't bundle a browser. There's no Chromium instance spinning up just to render a text area — the UI runs in the WebView your OS already ships. In practice that means it opens instantly, idles quietly, and never gives you a reason to close it.

That's not a spec-sheet flex — it's the entire reason the app exists. When opening the editor costs you nothing, you actually use it for the two-line notes instead of reaching for a sticky note.

What's actually in it

I kept the core minimal, but "minimal" doesn't mean "bare":

  • Real-time preview with synchronized scrolling
  • Tab management + auto-save + state persistence (close it, reopen it, everything's where you left it)
  • Markdown toolbar — headings, bold, italic, lists, links, tables
  • Search & replace with match highlighting
  • KaTeX for math ($...$ and $$...$$)
  • Mermaid diagrams from fenced code blocks
  • Marp slide presentations with custom themes
  • CJK-aware word count (yes, it counts Japanese/Chinese/Korean characters correctly)
  • 9 themes and a 14-language UI
  • HTML export, plus HTML/TSV/CSV table → Markdown conversion

The feature I'm quietly proud of: a variable system

Here's the part that started as "a small convenience" and turned into my favorite feature.

I write a lot of repetitive documents — release procedures, runbooks — where the structure is identical every time but a few values (a date, a version, a command) change. Copy-pasting last week's doc and hunting for the three things to update is exactly the kind of small, dumb friction that adds up.

So Bokuchi lets you embed variables directly in your Markdown:

<!-- @var version: 2.3.0 -->
<!-- @var deploy_date: 2026-07-01 -->

# Release Procedure {{version}}

Scheduled for **{{deploy_date}}**.

Run:

    git checkout v{{version}}
    ./deploy.sh --version {{version}}
Enter fullscreen mode Exit fullscreen mode

Define once at the top, reference with {{...}} anywhere, and the preview renders the resolved document. Variables can be file-local (like above) or global (set once in Settings, reused across every file). No spreadsheet, no find-and-replace ritual — the template is the document.

Security: you grant, or it can't

One thing I genuinely appreciate about Tauri v2 is that access to the host machine is opt-in. Your app declares a set of capabilities, and anything not on the list simply cannot be called from the frontend.

A capabilities file looks roughly like this:

{
  "identifier": "default",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "dialog:default",
    "fs:allow-read-file",
    "fs:allow-write-file",
    "clipboard-manager:allow-read-text",
    "clipboard-manager:allow-write-text"
  ]
}
Enter fullscreen mode Exit fullscreen mode

The frontend can open a file dialog, read and write files, and touch the clipboard — because I said so, explicitly. It can't spawn a shell or hit the network unless I add those permissions. For a tool people run on their own machines, that "least privilege by construction" model is exactly the guarantee I want to be able to make.

The Tauri v2 developer experience

A few honest takeaways after shipping with it:

  • The web frontend is just the web. React, Vite, hot reload — all the muscle memory transfers. No weird framework-specific rendering layer.
  • Rust is where the calm lives. File I/O, external-change detection, the variable resolver — pushing that into a typed, compiled backend meant a whole class of "undefined is not a function at 2am" bugs never happened.
  • The capability model makes you think about your surface area early, which sounds like a chore and is actually a gift.
  • The lightness is real. Not bundling Chromium shows up exactly where you'd hope: smaller installers, faster startup, and an app you can leave open all day without thinking about it.

Is it all frictionless? No — you'll spend time learning the permission system, and WebView differences across platforms are a real thing you have to test. But for the class of app where "lightweight" is a feature and not an afterthought, Tauri v2 is the most fun I've had building desktop software in years.

Try it / break it / star it

Bokuchi is free and open source.

If you've ever grumbled at a note-taking app for hogging your RAM, I'd love for you to give it a spin. Issues, feedback, and PRs are all genuinely welcome — and if it saves you a little friction, a ⭐ on the repo helps more people find it.

Thanks for reading. Now go write something. Quickly.

Top comments (2)

Collapse
 
pagerroast profile image
pagerroast

Checked out bokuchi.com — the product looks genuinely impressive, but the page undersells it. The headline 'A lightweight Markdown editor that just works' is generic to the point of invisibility; your actual differentiator (no bundled Chromium, ~3x less memory than Electron editors) is buried under a 'Why Bokuchi?' card instead of leading. 'Uses less than a third of the memory' is a great concrete stat — put that number in the hero. Also, the download CTA is macOS-only with Windows/Linux behind an 'Other platforms' link — a big chunk of visitors have to hunt to convert. On the positive side: the 14-language UI switcher is a touch most indie apps never bother with. I do landing page teardowns for a living — kimmy.inkboxwire.com/roasts has free one-line examples from 550+ recent launches if the pattern is useful.

Collapse
 
shinya_saita profile image
Shinya Saita

Thank you very much.
I never expected to receive feedback on the website, so I’m truly grateful.
I’m not an expert when it comes to messaging, so I’ll take your advice and work on improving it. I have a friend who’s a marketer, so I thought I’d ask him for his opinion as well.

Also, thank you for pointing out the good aspects of Bokuchi. Please be sure to give it a try yourself.