--- title: "Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク【Fresh 2対応・2026年版】" url: "https://www.issoh.co.jp/tech/details/3619/" published: 2024-09-19 updated: 2026-10-13 categories: ["フレームワーク"] publisher: "株式会社一創" --- # Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク【Fresh 2対応・2026年版】 Fresh（フレッシュ）は、DenoチームがつくったWebフレームワークです。ビュー層にPreactを使い、既定ではブラウザにJavaScriptをほとんど送らない「アイランドアーキテクチャ」で高速なページを返します。2025年9月にはFresh 2.0がベータへ到達し、内部APIとビルドまわりが大きく変わりました。この記事は「Freshとは何か」から、Preactを選ぶ理由、SSRとの関係、Fresh 2.0での変更点、Next.js・Astro・HonoXとの使い分けまでを、実際によく検索される論点に沿って整理します。 ## まとめ：Freshは「Deno＋Preact＋アイランド」で配信JSを最小化するWebフレームワーク Freshは、Denoランタイム上で動くフルスタックWebフレームワークです。特徴は3つに集約できます。(1)サーバーでHTMLを生成するSSRを標準とし、(2)対話が必要な部分だけを「島（island）」としてクライアントでhydrateするため既定の配信JSがゼロに近く、(3)ビューにReact互換で約3KBのPreactを採用してバンドルを小さく保ちます。デプロイ先はグローバルエッジのDeno Deployを前提に設計されています。2025年9月にベータへ入ったFresh 2.0では、`app.use()`／`app.get()`というExpress・Hono風の新APIや任意のVite統合が加わり、起動速度も大きく改善しました。各論点を順に整理します。 ## Deno Freshとは：Deno公式のフルスタックWebフレームワーク このフレームワークは、TypeScript/JavaScriptランタイムであるDenoの開発チームが公式に提供しています。ルーティング・サーバーサイドレンダリング・データ取得・フォーム処理をひととおり備え、Denoの標準機能（TypeScriptの直接実行、URLインポート、パーミッションモデル）をそのまま活かせます。Node.jsやnpmのビルドチェーンを別途組む必要がなく、Denoさえ入れれば開発を始められる点が、React系のメタフレームワークとの一番の違いです。導入手順そのものは[DenoとFreshの開発環境セットアップ](/tech/details/4646/)で具体的に追えます。 ## アイランドアーキテクチャの仕組み：既定はJSゼロ、必要な島だけ動かす Freshの中核がアイランドアーキテクチャです。ページ全体はサーバーでHTMLに描画して返し、クライアント側のJavaScriptは既定で送りません。ボタンやフォームのように操作が必要な部分だけを`islands/`ディレクトリのコンポーネントとして分離し、その「島」に限ってブラウザでhydrate（イベントを結びつけて動かすこと）します。結果として、静的な見出しや本文はJSを一切ダウンロードせず表示され、初期表示と通信量が軽くなります。ページ全体を丸ごとhydrateするReactの一般的なSPAと発想が逆で、「動かす箇所を足していく」モデルです。 ### SSRとCSRの違いから見たFreshの立ち位置 サーバーサイドレンダリング（SSR）は表示に必要なHTMLをサーバーで組み立てて返す方式、クライアントサイドレンダリング（CSR）は最小限のHTMLを返してJavaScriptで画面を組み立てる方式です。Freshは前者を既定にしつつ、動的な島だけを部分的にCSR化する折衷型といえます。両方式の判断軸は[CSRとSSRの違いと使い分け](/tech/details/5895/)で詳しく比較しています。SEOや初期表示を重視し、かつ全ページをSPA化するほどの対話性は不要、という要件でFreshは効きます。 ## PreactとJSXでUIを書く：ReactではなくPreactを選ぶ理由 Freshのビューは、React風のJSXをそのまま書けるPreactで構築します。コンポーネントの書き方はReactとほぼ同じで、`props`やフックの感覚も共通しています。状態管理には`preact/signals`が使え、細粒度の再描画を軽量に実現できます。 ### ReactとPreactの違い（互換性とバンドルサイズ） PreactはReactと同じAPI設計をなぞりつつ、本体が約3KB（gzip）と小さいのが最大の差です。ReactとReactDOMを合わせた数十KB規模に比べ、配信するランタイムが桁違いに軽く、アイランドアーキテクチャの「送るJSを減らす」方針と噛み合います。React向けライブラリを使いたい場合は互換レイヤーの`preact/compat`でエイリアスを張れますが、内部実装に依存するライブラリは完全互換ではない点に注意が必要です。「Reactの巨大なエコシステムを丸ごと使いたい」ならReactメタフレームワーク、「軽さを最優先し、必要な互換だけ取り込みたい」ならPreactという判断になります。Preact単体の定義や10.29系の現在地、preact/compatでReact資産を移す手順は[Preactとは？Reactとの違いと採用判断](https://www.issoh.co.jp/tech/details/16011/)で整理しています。 ## ファイルベースルーティングとプロジェクト構成 Freshのルーティングはファイル配置で決まります。`routes/`ディレクトリに置いたファイルのパスがそのままURLに対応し、`routes/about.tsx`なら`/about`、角括弧を使った`[id].tsx`なら動的セグメントになります。対話が必要なコンポーネントは`islands/`、静的アセットは`static/`に置く、という役割分担が決まっているため、設定ファイルを書かずに構成が把握できます。ルートファイルはリクエスト処理（handler）と描画（component）を1ファイルにまとめて書け、サーバー処理とUIの距離が近いのが特徴です。 ## ビルド不要の開発フローとFresh 2のViteオプション Fresh 1.xの売りは「ビルドステップが要らない」ことでした。DenoがTypeScriptとJSXをそのまま実行するため、事前コンパイルなしに開発サーバーが立ち上がります。Fresh 2.0ではこれを保ちつつ、任意でViteプラグインとして動かせるようになりました。Viteを有効にするとホットモジュールリロード（HMR）や豊富なViteプラグインエコシステムを利用でき、本番向けにサーバーコードもバンドルされます。Viteを使わない従来のノービルド構成も引き続き選べるため、「手軽さ」と「本格的なツールチェーン」を要件で選び分けられます。 ## Deno Deployによるグローバルエッジ配信 Freshは、Deno公式のホスティングであるDeno Deployへの配信を前提に設計されています。Deno Deployは世界各地のエッジロケーションでコードを実行するため、ユーザーに近い拠点でSSRが走り、応答が短くなります。GitHub連携でプッシュごとにデプロイでき、サーバー管理やコンテナ構築を伴わないのが利点です。SSRを標準とするFreshと、エッジで関数を動かすDeno Deployの組み合わせが、Freshの高速さを支える土台になっています。ただしDeno Deployは、2026年10月9日の発表で約6か月後の終了が決まりました。Fresh 2のアプリをCloudflare Workersへ移す設定とDeno KVのデータの移し方は[Deno Deploy終了と移行手順：Cloudflare WorkersへのコードとKV・cronの移し方](https://www.issoh.co.jp/tech/details/18318/)で解説しています。 ## Fresh 2.0の主な変更点（1.xからの移行で押さえること） Fresh 2.0は63回のアルファ版を経て、2025年9月2日にベータ（リリース候補相当）へ到達しました。Fresh 1.1のプラグインシステムを前提にした古い解説は通用しない部分があるため、移行時は次の変更を押さえてください。 | 観点 | Fresh 1.x | Fresh 2.0 | | -------- | ------------------------ | ------------------------------- | | アプリ定義 | manifest中心（fresh.gen.ts） | new App() ＋ app.use()/app.get() | | ミドルウェア署名 | (req, ctx) | (ctx) に簡素化 | | コンポーネント | 同期中心 | 非同期コンポーネント対応 | | 拡張 | 1.1のプラグイン | ミドルウェア共有の新プラグイン | | ビルド | ノービルド | ノービルド＋任意Vite（HMR） | APIがExpress・Honoに近づき、ルーティングとミドルウェアの記述が直感的になりました。``コンポーネントが復活し、DenoのprecompileなJSX変換を標準で使うことで描画も速くなっています。起動時間はFresh公式サイトで86ms→8ms、プロジェクト全体では9〜12倍の高速化が報告されました。新規プロジェクトは`deno run -Ar jsr:@fresh/init`で作成できます。1.x向けの構成は自動では移り変わらないため、App定義とミドルウェア署名の書き換えが移行作業の中心になります。ベータ到達後も更新が続いているため、最新の安定版はJSRの`@fresh/core`と公式ドキュメントで確認してください。 ## FreshとNext.js・Astro・HonoXの使い分け 同じ「軽量・高速」を掲げるフレームワークは複数あり、要件で選び分けが必要です。Freshが向くのは、Denoを前提にでき、エッジSSRで初期表示を軽くしたい中小〜中規模のWebアプリです。逆に採用を避けたほうがよい場面もはっきりしています。Node.jsやnpm資産（特定のReact専用ライブラリやビルドプラグイン）に強く依存するプロジェクトでは、Preact互換の壁とDeno前提が足かせになります。数千ページ規模のコンテンツを完全な静的サイトとして量産したいなら、コンテンツ主体に最適化されたAstroのほうが素直です。比較の詳細は[AstroとReactの違いと使い分け](/tech/details/2697/)が参考になります。APIサーバー寄りで軽量ルーターを軸に組みたい場合は、Hono／[HonoX](/tech/details/3614/)のようなアイランド対応のメタフレームワークが候補になります。「Denoで、SSRとエッジ配信を軽く回したい」という条件に当てはまるほどFreshの利点が生きます。 ## よくある質問 ### Fresh 2.0は正式リリースされていますか？ 2025年9月2日に63回のアルファ版を経てベータ（リリース候補相当）へ到達し、Fresh公式サイトやDeno Deployの本番でも使われています。アーキテクチャは安定済みですが、安定版の正確なバージョン番号は更新が速いため、JSRの`@fresh/core`と公式ドキュメントで最新を確認してください。 ### Fresh 1系のプロジェクトはそのまま2.0へ移行できますか？ 自動では移行しません。`new App()`とルーティングの新API、`(ctx)`へ簡素化されたミドルウェア署名、1.1プラグインから新プラグインへの置き換えが必要です。App定義とミドルウェアの書き換えが移行作業の中心になります。 ### Freshはビルドが必要ですか？ 既定ではビルド不要で、DenoがTypeScriptとJSXを直接実行します。Fresh 2.0では任意でViteプラグインを有効にでき、その場合はHMRや本番向けバンドルが使えます。手軽さを取るならノービルド、ツールチェーンを取るならVite、と選べます。 ### PreactとReactのコードは互換性がありますか？ JSXやフックなどAPI設計はほぼ共通で、React向けライブラリは`preact/compat`でエイリアスを張れば多くが動きます。ただしReactの内部実装に依存するライブラリは完全互換ではないため、重要な依存は事前に動作確認が必要です。 ### FreshとNext.jsはどちらを選ぶべきですか？ Denoを前提にでき、配信JSを最小化してエッジSSRを軽く回したいならFreshが有利です。Reactの巨大なエコシステムや既存のNode.js資産を丸ごと使いたい、大規模で機能豊富な構成を組みたいならNext.jsが無難です。 ## 関連記事 - [DenoとFreshの開発環境セットアップ](/tech/details/4646/) - [CSRとSSRの違いと使い分け｜レンダリング方式を比較して実装で選ぶ](/tech/details/5895/) - [AstroとReactの違いと使い分け｜AstroでReactを使う方法【2026年版】](/tech/details/2697/) - [HonoXとは何か？メタフレームワークの定義とその目的](/tech/details/3614/) --- 出典: [Deno Freshとは｜Preactとアイランドアーキテクチャの軽量Webフレームワーク【Fresh 2対応・2026年版】]()（株式会社一創）