ノービルド宣言：バンドラーなしで本番に出す

以下は、ビルドツールを捨てるべきだという主張ではありません。捨てたときに何が起こるかの計測結果です。

blakecrosley.comはFastAPI + Jinja2 + HTMX + Alpine.js + プレーンCSSで動いています。webpackなし。Viteなし。Rollupなし。TypeScriptコンパイラなし。Babelなし。PostCSSなし。Tailwindなし。package.jsonなし。node_modules/なし。このサイトは33本のブログ記事、14のインタラクティブなJavaScriptコンポーネント、20のガイド、9言語の翻訳を配信し、Lighthouseスコアは100/100/100/100です。

TL;DR

HTMXコミュニティには多くの支持者がいます。不足しているのはエビデンスです。ここに示す数値は、大量のコンテンツ、インタラクティブ機能、多言語対応を備えた本番サイトから得たもので、ビルドツールは一切使っていません。トレードオフは正直に示しており、結論は限定的です。コンテンツ中心のサイトをソロ開発者や少人数チームで運営する場合、ビルドツールは存在しない問題を解決し、存在する問題を生み出します。共有コンポーネントライブラリやデザインシステムパッケージを持つ大規模チームでは、ビルドツールはその複雑さに見合う価値があります。境界線は、議論が示唆するよりもはるかに明確です。

スタック構成

Backend:    FastAPI + Jinja2 (server-rendered HTML)
Frontend:   HTMX + Alpine.js + Bootstrap 5 (CDN)
Styles:     Plain CSS with custom properties
JavaScript: Vanilla JS, IIFE-scoped per component
Deployment: Railway (git push → live)
CDN:        Cloudflare (caching, Workers, D1)

トランスパイルなし。ツリーシェイキングなし。ホットモジュールリプレースメントなし。ソースマップなし。書いたJavaScriptがそのまま配信されるJavaScriptです。

実際の数値

推定値ではなく、実測値を示します。

18個のPythonパッケージにはFastAPI、Jinja2、Pydantic、SQLAlchemy、その他14個が含まれます。ビルドツールはゼロ。コンパイラもゼロ。バンドラーもゼロです。²

失うもの

正直であるためには、実際のコストを列挙する必要があります。それは確かに存在します。

TypeScriptがない。 このプロジェクトのすべての.jsファイルはバニラJavaScriptです。型エラーはコンパイラではなく、テストとClaude Codeの解析で捕捉します。ソロ開発者には有効なアプローチです。10人のチームがモジュール間でコンポーネントインターフェースを共有するなら、このやり方は通用しません。

ホットモジュールリプレースメントがない。 CSSファイルを変更したとき、ブラウザは手動でリフレッシュします。HTMXのhx-boostでナビゲーションが十分速いため、フルリフレッシュでも許容範囲です。30秒ごとにビジュアルの細部を調整するプロジェクトでは、HMRがあれば意味のある時間短縮になるでしょう。

ツリーシェイキングがない。 書いたJavaScriptはすべてブラウザに配信されます。ユーティリティライブラリから1つの関数だけをインポートすることはできません。ファイル全体が配信されます。この制約が規律を強います。大きなユーティリティモジュールではなく、小さく焦点を絞ったファイルを書くことになります。14個のインタラクティブコンポーネントは、自己完結している必要があるため、平均300〜700行です。³

npmのコンポーネントライブラリが使えない。 Radixもshadcn/uiもHeadless UIもありません。すべてのインタラクティブ要素（ボイドシミュレーション、ハミングコードビジュアライザー、合意形成シミュレーター）は手作りです。このアプローチが成立するのは、インタラクティブコンポーネントが汎用的なUIパターンではなく、特定の教育目的に特化しているからです。

npmのデザインシステムトークンが使えない。 私のデザインシステムはすべてCSSカスタムプロパティで構築されています。他のプロジェクトにパッケージとしてインポートすることはできません。単一サイトのシステムとしては許容範囲です。複数プロダクトを展開する組織では、許容できません。

この5つのトレードオフは、1人の開発者が運営するコンテンツ中心のサイトでは許容範囲です。15人のエンジニアリングチームが開発するSaaSプロダクトでは許容できないでしょう。

得られるもの

ビルド失敗がゼロ。 デプロイパイプラインはgit pushだけです。ピア依存関係の競合でnpm installが失敗することはありません。触ってもいないファイルのTypeScriptエラーでnext buildが失敗することもありません。推移的依存関係をDependabotのPRがアップグレードしてビルドが壊れることもありません。⁴

View Sourceでデバッグ。 ブラウザで実行されるJavaScriptは、私が書いたJavaScriptそのものです。ソースマップは不要。コンパイル出力からオリジナルソースへのマッピングも不要。本番環境でバグが発生したとき、デプロイされたファイルをそのまま読めます。

ローカル起動が一瞬。 uvicorn app.main:app --reloadは2秒以内に起動します。ページを表示する前にインストール・コンパイル・バンドルを行うnpm run devはありません。

Dependabotのノイズがゼロ。 package-lock.jsonがないため、semver、ansi-regex、glob-parentなど、直接インポートしたこともないのに依存ツリーの3階層下に存在するパッケージを更新する週次PRが来ることはありません。

将来にわたって動く。 このサイトは10年後も動きます。HTMLはHTML。CSSはCSS。JavaScriptはJavaScript。Webpack 4→5への移行も、Create React Appの非推奨化も、Next.jsのApp Routerへの移行もありません。プラットフォームがそのまま標準です。⁵

アーキテクチャとしてのHTMX

HTMXに関する議論は構文に焦点を当てがちです。hx-get、hx-swap、hx-target。それは間違ったフレームです。アーキテクチャ上の本質的な洞察は、サーバーレンダリングされたHTMLがそのままAPIであるということです。

従来のSPAの場合：

Browser → fetch('/api/users') → JSON → React renders HTML → DOM update

HTMXの場合：

Browser → GET /users (hx-get) → Server renders HTML fragment → DOM swap

サーバーが最終的な表現をそのまま返します。クライアント側の状態管理なし、シリアライズ／デシリアライズなし、ハイドレーションなし。Jinja2テンプレートがそのままコンポーネントです。FastAPIエンドポイントがそのままAPIです。3層ではなく、1層です。⁶

このパターンは複利的エンジニアリングの原則に直接対応しています。インフラの各要素がちょうど1つのことだけを行い、互いに干渉せずに組み合わさります。テンプレートはHTMLをレンダリングし、ルートがそれを返し、HTMXがDOMに挿入します。これらの要素を調整するビルドステップは、調整の必要がないため存在しません。

プレーンCSSで十分

私のデザインシステムは、10個のカラートークン、13段階のタイプスケール、8つのスペーシング値を使用しています。すべてCSSカスタムプロパティです。

:root {
  --color-bg-dark:        #000000;
  --color-text-primary:   #ffffff;
  --color-text-secondary: rgba(255,255,255,0.65);
  --spacing-sm:           1rem;
  --spacing-md:           1.5rem;
  --font-size-lg:         1.25rem;
}

Sassのコンパイルステップなし。ユーティリティを生成するTailwindの設定なし。カスタム構文を変換するPostCSSプラグインなし。ブラウザがこれらの値を直接読み取ります。⁷

このサイトの美とブルータリズムの美学（絶対的な黒の上に白、4段階の不透明度）は、制約から生まれました。カラーパレットに手を伸ばせないとき、タイポグラフィが階層を担います。コンポーネントシャドウに頼れないとき、ホワイトスペースが構造を作ります。制約そのものがデザインなのです。⁸

CLSとの格闘

Lighthouseへの道のりは、ノービルドの本当のコストを1つ浮き彫りにしました。クリティカルCSSの抽出にカスタムPythonスクリプトが必要だったのです。Next.jsプロジェクトでは、フレームワークがこれを自動的に処理します。

具体的なバグ：モバイル用メディアクエリがCSSカスタムプロパティをオーバーライドしていました（--gutter: 48px → --gutter: 24px）。クリティカルCSSにはデスクトップの値が含まれていましたが、モバイルのオーバーライドは含まれていませんでした。モバイルでは、ヒーロー領域が48pxパディングでレンダリングされた後、フルスタイルシートのロード時に24pxに変わり、CLSが0.493になりました。

修正は12行のPython。調査に3時間。ビルドツールがあれば自動的に処理されていたでしょう。

正直な損益計算：ビルドツールは手動でできることを自動化しますが、手動版は壊れたときにデバッグ時間というコストが発生します。問題は、自動化のコスト（複雑さ、依存関係、ビルド失敗、マイグレーションの手間）が手動のコスト（時折発生するデバッグセッション）を上回るかどうかです。

このサイトでは、手動のコストの方が低くなりました。3年間で、CLSバグ1件、デバッグ3時間。代替案（ビルドパイプラインのメンテナンス）の方が、依存関係の更新、破壊的変更、設定のメンテナンスに費やす累計時間は多かったでしょう。

このアプローチが適さないケース

ノービルドのアプローチは以下の場合には不適切です。

大規模チーム。 TypeScriptの価値はチームサイズに比例して高まります。⁹ 10人の開発者がコンポーネントインターフェースを共有するとき、コンパイル時の型チェックはランタイムテストでは遅すぎるタイミングでしか発見できない統合バグを防ぎます。ソロ開発者はシステム全体を頭の中に保持できます。チームにはそれができません。

デザインシステムパッケージ。 複数のプロダクトがデザインシステムを利用する場合、適切なバージョニング、ツリーシェイキング、ビルドパイプラインを備えたnpmパッケージである必要があります。単一スタイルシートのCSSカスタムプロパティは、リポジトリをまたいで組み合わせることができません。

複雑なクライアント状態。 アプリケーションにリッチなクライアント側状態がある場合（ドラッグ＆ドロップインターフェース、リアルタイムコラボレーション、オフラインファーストデータ）、ReactやSvelteのようなフレームワークはその複雑さに見合う価値があります。HTMXはクライアント状態をサーバーとのラウンドトリップに置き換えますが、レイテンシが問題になると破綻します。

npmエコシステムのライブラリ。 Radixプリミティブ、Framer Motion、TanStack Queryが必要なら、ビルドパイプラインが必要です。3つともバンドラーの存在を前提としています。バンドラーなしで使うのは、困難から不可能の範囲です。

境界線は議論が示唆するよりもシンプルです。アプリケーションが主にサーバーでレンダリングされるコンテンツなら、ビルドツールはオーバーヘッドです。アプリケーションが主にクライアントで管理される状態なら、ビルドツールはインフラストラクチャです。

主要な結論

ソロ開発者と小規模チームへ：

• 証明はサイトそのものであり、議論ではない。 blakecrosley.comは33本の記事、14のインタラクティブコンポーネント、20のガイド、9言語の翻訳を、ビルドツールゼロで、Lighthouseスコア満点で配信しています。数値は検証可能です。

• ノービルドの正直なコストは、時折のデバッグ。 CLSバグの修正に3時間かかりました。ビルドツールなら自動処理されていたでしょう。3年間の累計デバッグ時間は、ビルドパイプラインのメンテナンスに必要だったであろう累計時間よりもはるかに少なくなりました。

• 制約がデザインを生む。 色を使わないことで、タイポグラフィが階層を担うようになりました。ビルドツールを使わないことで、シンプルで自己完結したJavaScriptが生まれました。最良の制約とは、必要になる前に自ら選ぶものです。

スタック選定を評価するチームリーダーへ：

• ビルドツールはチーム規模の問題を解決する。 TypeScript、ツリーシェイキング、コンポーネントライブラリは、複数の開発者がインターフェースを共有するときにその複雑さに見合う価値を発揮します。コンテンツ中心のサイトを構築するソロ開発者には、これらの問題は存在しません。

• HTMXの真の貢献はアーキテクチャにある。 サーバーレンダリングされたHTMLをAPIとすることで、クライアント状態管理、シリアライゼーション、ハイドレーションが不要になります。構文は洞察に比べれば二次的な話です。

この記事は、ブログのデザインセクションとエンジニアリングセクションの架け橋となる記事です。デザインに関する考察は美とブルータリズム、スタートアップのためのデザインシステム、タイプスケールに記載されています。エンジニアリングの計測値はLighthouse満点への道と複利的エンジニアリングに記載されています。バイブコーディングの記事では、この哲学がAI支援開発にどう適用されるかを探っています。