← 戻る

Codex で Web バイナリエディタを試作

Codex を使ってブラウザで動くバイナリエディタを作った。

Hyper Binary Editor
Ultra-fast web binary editor that reads and writes directly to disk via the File System Access API.
https://bin.umigame.app/

対象読者

  • バイナリエディタに興味がある人
  • Codex に興味がある人

概要

特徴は以下。

  • File System ACcess API を使っている（なので Chromium 系でしか動かない）ので、直接ファイルの読み書きができる
  • パフォーマンス上の工夫をしてあるので1GB以上あるファイルでも扱える
    • 既に世の中に数多ある Web バイナリエディタの多くは、巨大なファイルを扱えないようだった

超シンプルな Web アプリなので、まあ大した機能はない。

最初は、様々なファイル形式の仕様が組み込まれていて〇〇部みたいなのを視覚的に表現できるエディタにしようと思っていた。あと、画像ファイルの場合は画像をプレビューできる機能とかを入れようと思っていた。

しかしそういう機能を入れると途端に動作が重くなった。なのでバイナリエディタではそういう機能を入れるべきではないのだなと理解した。

あと、最初は React Router と Tailwind CSS を使っていた。この環境で Codex にコードを書かせるとフレームワークの機能をふんだんに使ったリッチな実装をしてしまう。それらは全てパフォーマンスの阻害要因になるようだった。

バイナリエディタというアプリが必然的に要求する仕様として、大量の DOM 要素をレンダリングする必要がある。ファイルの全てのバイトをいっぺんに画面に表示すると、馬鹿みたいにメモリを食うしブラウザが固まる。この問題を解決するために、他の人が作っているエディタではファイルの推奨サイズを設定していたりページネーションを実装したりしているらしかった。

最終的には、ライブラリに全く依存しない index.html, style.css, main.js の3ファイルで作られた超シンプルな静的サイトになった。（Cloudflare Workers にデプロイしたので devDependencies に wrangler だけ入っている）

パフォーマンス上の工夫は Codex に考えさせたが、コードを読むと、requestAnimationFrame を使ってスクロール位置で表示中の領域のみを画面に描画（DOMを上書き）するという実装になっているもよう。そんなんで上手くいくのだろうか、という実装だが、自分のPCでは今のところそこそこ上手くいっているっぽい。スクロール、リサイズ、ファイルの読み書き、などのイベントをトリガーにして再描画を行っている。

Codex に言ったこと

普通に「バイナリエディタを作りたい」とだけ伝えると、勝手にダークモードに対応させたりカラフルなデザインにしたりと無駄が入り込んでにっちもさっちも行かなくなった。

ゼロからやり直して、「超シンプルなデザインで、あらゆる工夫を総動員して地球上で最速のバイナリエディタを作りたい」と伝えた。

多分もっとチューニングの余地とか改善の余地はあるのだろうけど（Canvasを使うとか）、自分のようなフロントエンドのパフォーマンスチューニングに明るくない人間が自分で苦労するよりは良い解決策を出してくれてそうな雰囲気がある。

わかったこと

  • パフォーマンスが重要な Web アプリでは仕様をめちゃくちゃシンプルにするべき
  • パフォーマンスが重要な Web アプリでは可能な限りライブラリやフレームワークに依存させず vanilla で書くべき
  • 人間が頑張るより Codex に頼んだほうが、短時間で人間より良い解決策を実装してくれそう
  • とは言え将来的にどちらのほうが良いかと言えば、人間が自力で頑張ったほうが知見として身になるのは間違いない。知見がある人間はよりAIの機能を引き出せる
    • brainrot の問題もある

File System Access API でできることをもうちょっと模索していきたい。