「速さはDX」
日本語がおかしいですが、ようは「速いことはDeveloper Experienceの向上につながる」という意味です。 それについて書きます。
Bun
「速さはDX」という標語はBunの作者のJarred Sumnerが似た趣旨のことをひたすらXでつぶやいていたのをみて思いつきました。 以下のそのひとつです。
performance is mostly about DX. Waiting for things costs time & focus
— Jarred Sumner (@jarredsumner) September 4, 2023
そう、誰だって「待ちたくない」です。
Bunのv1.0が出る前後にBunを使うユースケースとして「パッケージインストールするのにbun installが速いからCIでそこだけ使う」というものがありました。
Bunの使い道、パッケージインストールするのにbun installが速いからCIでそこだけ使う人がでてきた。
— Yusuke Wada (@yusukebe) September 11, 2023
「や、pnpmだって速い」という議論は置いておいて、「速いことだけ」でも価値になるいい例です。
Cloudflare Workers
Cloudflare Workersの話。 これは僕が中の人だからっていうバイアスがあると思いますが、Cloudflare Workersを使った開発体験はよくて、その理由のひとつに「速さ」があります。
特にデプロイが速い。これはWorkersを始めた人はみんな口を揃えて言います。
以下のアニメーションGIFはWorkers Playgroundで簡単な「ラーメンアプリ」を作ってみて、デプロイする様子です。 全部で28秒の動画ですが、後半、「Deploy」ボタンを押してから15秒くらいで、全世界にデプロイされています。
速い。誰だって自分が作ったものが世の中でどう見られているかを早く確認したいはず。これは開発体験がよいです。
実用的な例だと、@chimame_rtさんがGraphQLのAPIサーバーをGoogle CloudのCloud RunからCloudflare Workersへ移行したという話があります。以下はWorkers Tech Talks #1での資料です。
彼によると移行したメリットのひとつとしてデプロイが「8分前後が1分未満に短縮」したことを上げていました。 Workersでここまで大きなアプリケーションを移行した事例は少なく、また、少々オーバーな例かもしれませんが、Cloudflare Workersの「速さ」がよく分かると思います。
開発サーバー
特に開発環境では速さが求められます。Jarredの言う通り、我々は書いたコードが実行されるまで待つ時間をなるべく短くしたい。
ViteはHMR = Hot Module Replacementを備えています。
幾つかのバンドラは HMR(ホットモジュールリプレースメント)をサポートしています: これにより、ページの変更に関係のない部分には影響を与えることなく、モジュールを「ホットリプレース」することができます。これは開発者体験を大きく改善します。
Vite では、HMR をネイティブ ESM 上で行います。ファイルが編集されたとき、Vite は編集されたモジュールと最も近い HMR バウンダリ間のつながりを正確に無効化することで(大抵はモジュール本体だけです)、HMR による更新はアプリケーションのサイズに関係なく一貫して高速で実行されます。
使ったことがある方は分かると思いますが、これも「速さはDX」のよい例です。
Viteは個人的に、またCloudflare的にも注目しています。
HonoはCloudflare Pagesを開発するのにCloudflareのCLI、Wranglerを使うことを推奨していました。 しかしこれは（Wranglerも十分速いのですが）Viteと比べると遅い。 具体的には内部の開発サーバーで行うバンドルからリロードまでがViteと比べると遅いです（ただ、ViteでもSSRの部分はHMRが現状効きません）。 ではViteを使えばいいじゃないかとなりますが、一概にそうはいかない。というのはCloudflareのKVやR2、D1などのプロダクトへアクセスするためのBindingsが使えなくなるのです。
といってもViteを使いたいので、以下のような工夫をしています。
- Viteのカスタムサーバーを作る。これはNode.jsのAPIで作らなくてはいけない
- Honoで持っているNode.js AdapterはHonoのアプリとNode.jsを繋いでくれるのでそれをカスタムサーバーの中で使う
- Workersの環境をエミュレートするMiniflareにBindingsへアクセスできるAPIがある
- カスタムサーバー内でそのBindingsをプロキシさせてアプリからアクセス可能にする
これでViteを使いつつ、KVやR2、D1などのCloudflareプロダクトへアクセスすることができるようになりました。
以下がそのプラグインのあるリポジトリです。
Viteに限らず、各フレームワークの開発サーバーでBindingsを使えるようにしようとCloudflare社内でも動いています。
その1手としてNext on Pagesのnext devからBindings使えるようになりました。
以下の記事が詳しいです。
next devからCloudflare Bindingsが使えるよ
また、ViteではViteコミュニティからもWorkersやVercelなどのWeb standardsベースなアプリをネイティブで動かす試みが始まろうとしています。
これは素晴らしいことで、少しでも協力できればいいと思っています。
このようにDXをよくしようと開発サーバーを「速く」しようという試みが行われてます。
まとめ
以上、「速さはDX」という題名でBun、Cloudflare Workers、Viteの「速さについて」紹介してきました。 「速いとDXがよい」のは当然のことですが、改めて考えるとああなるほどなと納得したのでまとめてみました。 「速いからDXがよい」例はみなさんの周りにたくさんあると思いますし、また「DXがいいと思ったら速いからだった」という発見もあるかもしれませんね。