なければ自分で作ればいいのよ！
――――涼宮ハルヒ
かのアニメの主人公はこう言っていました。
はじめに
「もっとサクサク動くMarkdownエディタが欲しい！」
エンジニアなら一度はそう思ったことがあるのではないでしょうか。・・・あれ、ないですか？そうですか。まあ、あることにしておいてください。
世の中にはAtomやObsidianのような多機能エディタが色々あり、それは確かに素晴らしいのですが、ちょっとメモを取るだけなのに、起動するたびにPCに負荷をかけているのはスマートじゃないなと思ったりします。
あと、開発に使うVSCodeと文書を執筆するMarkdownは別扱いで使いたいという欲求もありました。
そんな個人的なニーズやアプリケーションの「重さ」に少し参っており、とはいえ自分が気に入るMarkdownエディターは無い、みたいな状況に自分は半ば諦めていました。
「まあいまあるエディターでなんとか我慢するか」と。
ただそんなとき、冒頭の涼宮パイセンの言葉が頭をよぎったのです。
「なければ自分で作ればいいのでは？」 と。
それが、OSSエディタ「Bokuchi」誕生のきっかけです。
なぜ「自作」という修羅の道を選んだのか？
・・・まあ読んでいるみなさんは普通そう思いますよね。
僕でも思います。
僕がMarkdownのエディタに求めていたのは、以下の3点だけでした。
- 使いやすさ（Markdownエディタ以外の機能はいらない）
- デザインの美しさ（ある程度綺麗で、飽きないミニマルさ）
- 爆速であること（これが最優先。マジで大事。）
VSCodeを使ってみたり、Atomを使ってみたり、Obsidianを始めとした各種Markdownエディターも色々手を出してみたんですが、既存のツールでしっくりくるものがありませんでした。
そのため、いっそのこと自分で理想の道具を作ることに決めました。どうせ作るなら、最新の技術スタックも勉強して、モダンな開発体験を味わいたいな〜という思いも。
そこで選んだのが Tauri v2 です。
「Tauri」ってなんぞ？
同じQiitaの記事に素晴らしい紹介記事が出ているので、詳細はそちらを見てもらったほうが早いです。
一言でいうと、「バックエンドがRustで、フロントエンドがJSで作れるフレームワーク」です。
この時点で技術者的には「なにそれ面白そう！？」と興味を持ったのですが、それだけではなく、他にも良い点はいっぱいありました。
- Rustの安全性とパフォーマンス：バックエンドをRustで書くことになるので、OSネイティブな処理がかける→速い。堅牢な処理も期待できそう。
- フロントエンドの自由度：ReactやVueをそのままUIとして活用できる→Webサイト作れる知識があれば、割とデザインも自由に作れそうだな。
- 軽量性への執念：ほぼこれ。Electronと比較した際のバイナリサイズやメモリ消費の少なさが圧倒的だった。公式でもこれはかなり売りにされてます
最初はGoで頑張る？とか考えていたのですが、Tauriの存在を知ってからは大人しくRust＋Reactで作り始めました。アプリのメモリ使用量は通常時で40MB程度。50MBを超えることはほぼありません。この「常に立ち上げておける軽さ」こそが、markdonwエディタ「Bokuchi」の最大の武器です。
OSS「Bokuchi」のこだわり
Bokuchiは、僕が日常的にガシガシ使うために作ったエディタです。
-
リアルタイムプレビュー
- 書いたそばからプレビューされる、まあこれは当たり前。
-
タブ管理 & セッション保存
- 作業状態を自動保存するため、再起動してもすぐに作業を再開できる。まあこれも当たり前。
- 水平タブと垂直タブを切り替えられるようにしたかった。
-
マルチプラットフォーム
- Tauriの強みを活かし、Windows/macOS/Linuxどれでも動くようにした
-
変数システム
- これもかなり肝
- リリース手順書などのドキュメントは、日付やコマンドなどの微細な違いがあるものの、基本的に構成やフローとしてやることは変わらない
- Excelなどのセル書式でそれを実現してる人も多いと思いますが、これをMarkdown上で実現したかった
- Markdownの中に変数を埋め込める仕組みをRust側で処理しており、柔軟なドキュメント作成が出来るように。
変数システムの例：
Tauri v2での開発体験
Tauri v2を触ってみて感じたのは、完成度が高い部分です。自分がやりたいことはたいてい用意されてる周到さがありました。
セキュリティ構造がかなり堅牢なので、許可したオペレーションじゃないと実施できない。これはインジェクションが第三者によってされないので、意図しない動作を防げる他にもセキュアなアプリが作れます。
ただその分、「ファイル開きたいな」とアクセスしようと思っても弾かれるので、ちゃんと設定ファイルに「ファイル開きますよ」という宣言が必要になります。
実際のBokuchiの設定例
使いたいOS機能（例えば、ファイルを開く/保存する等）があると、ここに記載しないと許可されない
{
"$schema": "../gen/schemas/desktop-schema.json",
"identifier": "default",
"description": "Capability for the main window",
"windows": [
"main"
],
// 必要なことをここに宣言する
"permissions": [
"core:default",
"fs:default",
"dialog:default", // ファイルダイアログ使う
"store:default", // アプリの設定を保存する
"fs:read-files", // ファイル開く
"fs:write-files", // ファイル保存（例えば、「名前をつけて保存」機能はこれだけだとダメで、上記のファイルダイアログの許可もいる）
"fs:read-dirs", // ディレクトリ開く
"fs:write-all",
"clipboard-manager:allow-read-text",
{
"identifier": "fs:scope",
"allow": [
{
"path": "$HOME/**/*"
},
{
"path": "$DESKTOP/**/*"
},
{
"path": "$DOCUMENT/**/*"
},
{
"path": "$DOWNLOAD/**/*"
}
]
},
"window-state:default",
"clipboard-manager:default",
"updater:default",
"process:allow-restart",
"opener:default"
],
"platforms": [
"macOS",
"linux",
"windows"
]
}
そして何より、何よりも・・・・軽い！！！
メモリの使用量が異常に低いんです
これは本当に驚きました。
Rustを使ってる恩恵は、勿論ありますし、OS標準のWebViewを使う構造というのも納得でした。
（対抗するElectronのフレームワーク自体がChromiumブラウザを内包しているのでそもそも重いというのはあります）
最後に
まだまだマイナーなフレームワークTauriですが、実際に開発を始めてみると非常に理にかなっており、大好きになりました。リリースまでをフレームワークが手厚くサポートしているのは大変嬉しかったです。
「自分用の道具」として作り始めましたが、もし同じような「Markdownエディタの重さ」に悩んでいる方がいれば、ぜひ一度触ってみてください。
Markdownエディター「Bokuchi」はまだ成長途中のOSSです。
「こんな機能があったらいいな」「ここ、もっとこうできるよ！」といったフィードバックやプルリクエストは大歓迎です。
軽量で、美しく、そしてあなた（主に僕）に寄り添うエディタ。興味があったら使ってみてください。
昨今のAIツールの台頭もあり、昔と比べて気軽にツールを作れる時代になってるかと思います。みなさんもこの記事をきっかけに「自分でもツールやアプリ作ってみようかな」となってくれれば幸いです。