設計哲学

なぜ zfb は意図的に狭いままでいるのか、そしてなぜ AI 時代がそのバランスを「プラグインよりレシピ」へとさらに傾けるのか。

zfb の表面積は意図的に小さく保たれています。その選択にはコストがあり、そしてメリットがあります。 このページは両方を明示し、そのうえで、LLM がループに入った変化がなぜレシピ経路を以前よりさらに 魅力的にするのかを説明します。

意図的に狭く

zfb は esbuild の SSG + SSR 版です。コミットしたことだけを正確に行い、そこで止まる、速くて 焦点を絞ったエンジンです。esbuild があらゆる変換のためのプラグインエコシステムを備えた完全な アプリケーションバンドラになることを意図的に避けているのと同じように、zfb はあらゆるサイト 構築パターンをカバーするために分厚い API 表面を育てることを意図的に避けています。

6 つのエンジンプリミティブ が zfb v1 の公開コントラクトの すべてです。7 つ目のプリミティブを追加することは — たとえそれが有用であっても — 設計し、 ドキュメント化し、メンテナンスし、将来のリリースを通じてバージョン管理すべき新しい API が 増えることを意味します。新しい表面上のエッジケースについて「これは可能か？」という問いに 答えることを意味します。そして、zfb の上に構築するフレームワーク作者が、さらにもう 1 つの軸に ついて考えなければならなくなることを意味します。

狭いままでいることのコスト は本物です。グルーは利用者が抱えます。zfb がサイドバー生成も i18n ルーティングも組み込みの検索フックも出荷しないとき、フレームワーク作者 — または利用者 本人 — がそのコードを書きます。事前生成のエコシステムであれば、それはレシピを探し、読み込み、 プロジェクトの形に適応させることを意味したでしょう。その適応コストは確かに存在しました。

メリット は不確実性税の不在です。表面が狭くて安定していれば、「zfb はこれをサポートして いるか？」という問いには素早く答えが出ます。6 つのプリミティブを見ればいい。機能がそれらに マッピングできれば、動きます。できなければ、それはエンジンの中ではなく、zfb の上に乗る フレームワークに属します。監査すべき分厚い API もなく、次のマイナーバージョンで壊れるかも しれないプラグインポイントもなく、あらゆる下流のユースケースに追従し続けるエンジンチームへの 依存もありません。

Astro と Next.js は異なるトレードを します。幅広いマルチフレームワークサポート、豊富なプラグインエコシステム、多くのパターン向けの ファーストパーティアダプタを提供します。それは、可能な限り広い層を狙う汎用フレームワークに とっては正しい判断です。zfb の賭けは逆です。より狭く、より速いエンジンで、より小さく安定した コントラクトを持つことが、Cloudflare のエッジをターゲットにしたコンテンツ中心の静的生成 サイトという特定のケースにとって、より良い基盤になる、という賭けです。

エンジン昇格テストがその境界を正確に捉えます。"if two frameworks built on zfb would do this differently, it's not engine."（zfb の上に構築された 2 つのフレームワークがこれを 異なるやり方で行うなら、それはエンジンではない）。もし、下流の 2 つのフレームワークが異なる 選択をする正当な理由が少しでもあるなら、その機能は zfb の表面積に属しません。フレームワークに 属します。

AI 時代のプラグインよりレシピ

LLM があらゆるワークフローの一部になる前は、レシピとプラグインの選択には本物の非対称性が ありました。

LLM 以前のレシピのコスト。 レシピを見つけることは、検索、Stack Overflow の回答や ブログ記事のスキャン、そのレシピが現在のプロジェクトのバージョンと構造に合うかどうかの判断、 そして手作業での適応を意味しました。それぞれのステップが時間と注意を要しました。同じ問題を 解決するうまくパッケージ化されたプラグインは、手を伸ばすのが純粋に速かったのです。

LLM がループに入る変化。 LLM が使えると、適応コストは崩れ落ちます。理解して適応するのに 30 分かかっていたレシピが、今やプロンプト 1 つで済みます。さらに重要なのは、レシピが今や 透明 であることです。それは利用者のプロジェクトの中で動き、利用者のインポートを使い、 利用者のコードベースと共に歳を重ね、依存先の内部をのぞき込まずにデバッグできます。対照的に プラグインは、実装をバージョン固定されたパッケージの背後に隠し、プラグイン作者がエンジンに 歩調を合わせ続けることを要求し、LLM が考慮しなければならない間接層を 1 つ増やします。

これはプラグインが時代遅れだという意味ではありません。何かをプラグインに昇格させるための基準が 上がったという意味です。正しい問いはもはや「ここでレシピを見つけて適応させるのは煩わしいか？」 ではありません — それは LLM が処理します。正しい問いは「これは zfb 利用者の 100% が、 逸脱する正当な理由なく、同じやり方で使うものか？」です。

zfb が今日出荷している狭いプラグイン API — Plugins に文書化された 4 つのライフサイクルフック、仮想モジュール、インポートエイリアス、開発専用の注入ルート — は、 まさにその狭い例外です。setup フックの仮想モジュールとエイリアスの登録、preBuild / postBuild のファイル生成フック、そして devMiddleware ハンドラは、ビルドパイプラインと 構造的に切り離せないパターンをカバーします。エンジン自体をフォークしなければ利用者がレシピ として実装できないものたちです。表面はそれ以外では意図的に閉じられています — addRemarkPlugin も addModuleTransform も onModuleLoad もありません — なぜなら、それらのパターンは 安定したエンジン API ではなくレシピに属するからです。

プラグイン昇格テストがその閾値を述べます。"don't extract until the same recipe has been written by hand in three different zfb consumer projects."（同じレシピが 3 つの異なる zfb 利用プロジェクトで手書きされるまで抽出するな）。1 つのプロジェクトの利便性はレシピです。 3 つの独立したプロジェクトが同じ解に収束することは、普遍的なニーズの証拠です。その時点で、 そしてその時点でのみ、プラグイン API への抽出はメンテナンスコストに見合います。

次に行く先

• Engine vs Framework — zfb がコミットする 6 つのプリミティブと、エンジンとフレームワークの関心事の境界線。
• Plugins — 狭い例外: 4 つのライフサイクルフックと、それらがカバーするもの・しないもの。
• Choosing zfb — 「意図的に狭く」というトレードオフがプロジェクトにとって正しい判断になるのはいつか、ならないのはいつか。