はじめに

個人開発しているプロジェクト管理SaaS「Nornai」で、フロントエンドにSvelte（およびそのフレームワークであるSvelteKit）を採用しました。

これまでの個人開発では、Reactベースの定番フレームワークであるNext.jsを一貫して使ってきたため、私にとって今回が初めてのSvelte経験になります。

この記事では、Svelteを実際に使い始める前後で調べたことや、自分の手を動かす中で体験したことを整理しながら、

「そもそもSvelteとは何なのか」「なぜ数ある選択肢の中からあえてSvelteを選んだのか」を解説します。

実務での具体的な実装や「ハマりどころ」については、Part1・Part2に分けて別記事にする予定ですので、この記事は前提知識を整理するための「基本編」としてお読みください。

1. Svelteとは何か

Svelte（スヴェルト）は、Rich Harris氏によって開発されたフロントエンドフレームワーク（Webサイトの画面や動きを効率よく作るためのツール）です。

他の主要なフレームワーク（ReactやVue）と決定的に違うのは、Svelteの本質が「コンパイラ（翻訳機）」であるという点です。

ReactやVueは、ユーザーのブラウザ上でフレームワークの「エンジン」を常に動かし、仮想DOM（Virtual DOM）という仕組みを使って画面を更新します。

仮想DOMとは、実際の画面を書き換える前に、メモリ上に「シミュレーション用の偽物の画面」を作って変化の差分を計算し、変わった部分だけを本物の画面に反映する技術です。

一方、Svelteのアプローチは真逆です。

Svelteは、開発者が書いたコードを本番環境へ公開する前の「ビルド時（コンパイル時）」にすべて解析します。

そして、「どのデータが変わったら、どのHTML要素をピンポイントで書き換えればいいか」という最適化された純粋なJavaScriptコードをあらかじめ先回りして生成してしまいます。

つまり、ブラウザ上で動く「仮想DOM」という仕組みそのものが存在しません。

Svelteの生みの親であるRich Harris氏は、かつて "Virtual DOM is pure overhead"（仮想DOMは純粋なオーバーヘッド＝無駄な処理である） という論考を発表し、大きな話題を呼びました。

「画面の変化をチェックするためだけに、毎回メモリ上で偽物の画面を比較する計算コストを払うくらいなら、翻訳（コンパイル）の段階で答えを出しておけばいい」

という逆転の発想が、Svelteの設計思想の核になっています。

Svelteの仕組み

graph TD
    B1[1. ソースコード] --> B2["2. 事前にコンパイル<br/>（ビルド時の処理）"]
    B2 --> B3["3. 差分箇所を直接操作する<br/>純粋なJSに変換"]
    B3 --> B4[4. ブラウザへ配信]
    B4 --> B5["5. 実際のDOMを直接更新<br/>（仮想DOMなし）"]

    style B2 fill:#E8F5E9,stroke:#A5D6A7,stroke-width:2px
    style B3 fill:#E8F5E9,stroke:#A5D6A7,stroke-width:2px

Reactの仕組み

graph TD
    A1[1. ソースコード] --> A2[2. ブラウザへ配信]
    A2 --> A3["3. 実行時に仮想DOMを作成"]
    A3 --> A4["4. データ変更時に差分を計算<br/>（実行時のオーバーヘッド）"]
    A4 --> A5[5. 実際のDOMへ反映]

    style A3 fill:#FFE5EC,stroke:#FFB3C6,stroke-width:2px
    style A4 fill:#FFE5EC,stroke:#FFB3C6,stroke-width:2px

2. 開発の背景と歴史

Svelteがなぜこのような尖った思想で作られたのかは、その出自を知ると深く納得できます。

Svelteは元々、Harris氏がイギリスの有力紙『The Guardian』や『The New York Times』で働いていた際、「ニュースメディア向けの高速で動くインタラクティブな特設ページ」を作る必要性から生まれたプロジェクトです。

ニュースサイトは、スペックの低い古いスマホを使っている人や、電波の悪い地下鉄の中にいる人など、あらゆる環境のユーザーがアクセスします。

そのため、以下の2点が極めてシビアに求められました。

バンドルサイズ（アプリ全体のファイル容量）を極限まで小さくすること

画面をスクロールした時のアニメーションなどの実行時パフォーマンスを落とさないこと

この現場の切実な要求が、「ブラウザ側に重たいエンジンを持たせない（ランタイムレス）」というSvelteのDNAになりました。

その後、2019年リリースの「Svelte 3」では、データが変わると画面が自動で連動する「リアクティビティ（反応性）」の仕組みを大幅に強化。

$: という魔法のような記号（マーカー）を書くだけで、複雑な連動処理が数行で書ける宣言的なスタイルを確立し、世界中の開発者を虜にしました。

そして2024年、満を持してリリースされた現行の「Svelte 5」では、この $: 構文が「手軽だけど裏側で何が起きているかブラックボックスになりがちで、バグの特定（デバッグ）が難しい」という反省から、Runes（ルーンズ）と呼ばれる新しいAPI（$state、$derived、$effect など）に刷新されました。

これにより、画面のファイル内だけでなく、外部の純粋なJavaScriptファイル（.svelte.js）でも全く同じルールでデータの状態管理ができるようになり、大規模なアプリ開発にも耐えうる「ユニバーサル・リアクティビティ」を手に入れました。

当プロジェクト「Nornai」で採用しているのも、この最新のSvelte 5系です。

3. Reactとの違い

現在シェアNo.1のReactとSvelteの最大の違いは、「画面を更新するために、開発者がどれだけ最適化を意識しなければならないか」という点です。

Reactはデータ（State）が変わるたびに、コンポーネント（画面のパーツ）を形作る関数が上から下まで丸ごと再実行されます。

そのため、アプリが複雑になってくると、「本当は書き換える必要のない関係ないパーツ」まで一緒に再計算されてしまい、動作が重くなる原因になります。

これを防ぐために、React開発者は useMemo や useCallback といった、「この処理は再計算せずに使い回してね」と指示するおまじないのような最適化用APIをコードの至る所に記述する必要があります。

これが初学者にとっての大きな壁であり、コードの見通しを悪くする要因でもあります。

対するSvelteは、コンパイル時点で「どのデータの変更が、どこに影響するか」という依存関係を完全に把握しているため、これらの手動最適化が一切不要です。

状態が変わった箇所だけをブラウザがピンポイントで狙い撃ちして書き換えるため、開発者はパフォーマンスの低下を恐れることなく、素直にロジックを書くことに集中できます。

また、ブラウザに読み込ませるフレームワーク本体のコードがほぼゼロになるため、最終的なファイル容量（バンドルサイズ）が非常に小さくなり、初期のページ表示速度が圧倒的に速くなりやすいというメリットもあります。

4. Vueとの違い

Vueは、「HTMLに近いテンプレート構文」や「データと画面が自動連動する仕組み」を採用している点で、見た目や書き味はSvelteに一番近いライブラリです。

しかし、その「裏側の仕組み」は大きく異なります。

Vueは、プログラムがブラウザ上で動いている最中（実行時＝ランタイム）に、JavaScriptの Proxy という機能を使ってデータの変化をリアルタイムで監視しています。

画面のパーツを記述するファイル（.vue）の構造はSvelteと酷似していますが、Vueはあくまで「動いている最中に監視するシステム」であり、Svelteは「事前にコードを変換してしまうシステム」という根本的なアーキテクチャの違いがあります。

また、実際の書き味としても、Svelteの方がHTML/JavaScript本来の仕様に近く、フレームワーク特有の「独自ルール（構文）」の境界線がより薄い印象を受けます。

Vueに慣れている人であれば、Svelteのコードは驚くほど直感的に読めるはずです。

5. 比較まとめ

ここまでの3つのフレームワークの特徴を、分かりやすく表にまとめました。

📌 フロントエンドフレームワーク 3社比較まとめ

比較項目	Svelte (v5)	React	Vue (v3)
画面更新の仕組み	コンパイラ方式	仮想DOM方式	仮想DOM ＋ Proxy監視
実行時の軽さ	極めて軽量	やや重い	中量級
開発時の最適化	完全自動	手動で記述が必要	ほぼ自動
状態管理の書き方	明示的なRunes構文（`$state` など）	Hooks構文（`useState` など）	Composition API（`ref` / `reactive`）
コードの記述量	非常に少ない	多め	標準的

※ Composition API：ref/reactiveでリアクティブな状態を扱う、Vue 3のロジック記述方式。ReactのHooksに近い発想。

5. なぜNornaiでSvelte（SvelteKit）を選んだか

Nornaiは個人開発のSaaSで、機能追加のスピードと、ユーザー数が増えたときのパフォーマンスの両方を意識したかったプロジェクトです。

Next.jsでやってきた分、違うアプローチのフレームワークを選ぶことで自分の設計の幅を広げたい、という動機もありました。

SvelteKitは、Svelteをベースにしたメタフレームワーク（Reactに対するNext.jsのような存在）です。

ページ遷移を自動化するフォルダベースのルーティングはもちろん、特筆すべきは「フォームアクション（Form Actions）」というバックエンド（サーバー側）との通信の仕組みです。

// SvelteKitの強力な「背中合わせ」のファイル構成例
src/routes/tasks/
├── +page.server.ts  <-- 【バックエンド】データベースへの保存処理などを書く
└── +page.svelte     <-- 【フロントエンド】入力フォーム（画面）を書く

通常のWebアプリ開発では、画面側でボタンが押されたら、JavaScriptの fetch 関数を使ってデータをJSON形式にし、サーバーのAPI宛てに通信するコードを手動で書く必要があります。

しかしSvelteKitのフォームアクションを使うと、HTML標準の <form> タグを使ってデータを送信するだけで、裏側の +page.server.ts に書いたサーバー処理へダイレクトにデータが届きます。

さらに、「プログレッシブ・エンハンスメント」という設計思想が最初から組み込まれており、万が一ユーザーのブラウザ側でJavaScriptの読み込みが遅れていたりオフになっていたりしても、Webの標準機能だけで確実にデータの送信や保存が動作する仕組みになっています。

この「手数が少なく、かつ堅牢なシステムが作れる安心感」は、個人開発において非常に強力な味方になります。

6. 使ってみての所感

Reactを使っていると、HTMLのクラス指定を className と書かなければならなかったり、イベントを onClick と大文字小文字を気にしながらJSXという特殊な構文で書く必要があります。

Svelteはそのまま class や on:click（Svelte 5では onclick）と書けるため、Web標準の地続きでマークアップしている感覚があり、脳のスイッチを切り替えるストレスがありません。

一方で、最新のSvelte 5で導入された「Runes」構文については、若干の記述量アップに伴う学習コストを感じるかもしれません。

しかし、Reactの useState や useEffect の概念に慣れ親しんでいる開発者から見れば、「あ、これがReactでいうアレね」と構造を綺麗に対応付けて理解しやすく、むしろコンポーネントの外でも状態を使い回せるメリットの方が遥かに上回っていると感じました。

もちろん、すべてが初手から順風満帆だったわけではなく、認証周りの共通化や状態の永続化など、実務ならではの「ハマりどころ」やNext.jsとの思想ギャップにもいくつか直面しました。

そのあたりのリアルな泥臭い格闘記については、次回のPart1・Part2で詳しく書き残したいと思います。

まとめ

Svelteは、「コンパイラによって実行時の無駄（オーバーヘッド）を徹底的に排除する」という非常に明確でクリーンな思想を持ったフレームワークです。

そしてSvelte 5という大きな節目を迎えたことで、小規模開発だけでなく、SaaSのような本格的なアプリケーション開発にも自信を持って投入できる強固な土台が完成したと実感しています。

Next.js（React）という絶対王者のエコシステムに慣れきった身だからこそ、Svelteの「アプローチの違い」に触れることは、技術的な視野を広げる上で最高に刺激的な体験になっています。

もし「最近のReactの記述量やおまじないの多さに少し疲れてきたかも…」と感じている方がいれば、ぜひ一度Svelteの世界を覗いてみてください。