React は好きだが、Svelte に乗り換えた
筆者は React が好きです。
元々 jQuery をちょっとかじった程度の JS 知識だったのですが、本格的にフロントを書くことになった際 React に触れ、その分かりやすさ・書きやすさに感動し好きになりました。
React は好きですが、App Router (React Server Component) あたりから書く上で考えることが非常に多くなり、辛さが出てきました。
そんなとき試した Svelte の開発体験がとてもよく、気に入りました。今の React(NextJS) で消耗している人にはぜひおすすめしていきたい[1]ので、私の感じている良いところ悪いところを React 好き視点でまとめてみます。
文法が超簡単
React, Vue など最近のフロントエンドライブラリをある程度触った経験があれば、本当に数時間で習得できます。筆者はある日の夕方にチュートリアルを通しただけで完全に理解できました。[2]
発展形の機能は都度ドキュメント見ながらやっていますが、基本文法は極めてシンプルで一度見ればだいたい理解し書き始められます。
一切 Svelte を触ったことがなければ、とりあえずこの公式チュートリアルをざっと通してみるのがおすすめです。
デプロイが簡単
初期設定は adapter-auto になっており、何もせずそのまま設置もできます。最近のデプロイ環境なら最適化用の公式アダプターが提供されています。ビルド職人にならなくていい！
css で迷わない
.svelte ファイル内に書く場所があるので、迷いません。vue と同じ方式ではありますね。
未使用 css の検知などは拾ってくれますので、css用の追加セットアップはせずとも快適に書けます。
TypeScript サポートがしっかりしている
any になっちゃってる、という場面はありません。型ガードの効いた環境で、快適に svelte を書けます。
筆者が React 好きな理由の中で「typescript でガチガチに固められるから」は割合としてかなり大きいのですが、書き方に癖はあるものの svelte でもしっかり書けるので不満はありません。
<script lang="ts"> と毎回 ts 指定するのは面倒なのですが、これは技術的理由で毎回指定するしかないようです。[3]
あとは……SSR 周りで、何も書いてないのに魔法みたいに型定義が生えてくる箇所があり、なんだこれはと感じたことはありました。存在しないファイルである ./$types に対して import を書くと、サーバー側 load の型が取得できる挙動です。
これはめちゃくちゃ便利なので結局のところ慣れです。慣れは全てを解決する。
let とどう向き合うか
let hoge = "リアクティブな値"
私が Svelte のコードを初めて見たときにまず感じたのは、let の気持ち悪さでした。
上記コードで React の useState 相当ですから、初見はぎょっとするでしょう。
JavaScript (TypeScript) に限らず、極力イミュータブルにしておくのはプログラミングのベストプラクティスとして知られています。
一方 Svelte は React でいう useState 相当の、つまりはトップレベルの変数のほとんどを let で宣言するような構文を採用しています。
これは全てに const を徹底しているプログラマからすれば非常に抵抗感、不安感があるでしょう。
私も最初は大きな抵抗感があり、最初に svelte を見たとき敬遠する理由になりました。
今は慣れて、むしろメリットを感じています。
const [hoge, setHoge] = useState("リアクティブな値")
と書くより圧倒的に早く、頭を使わずに済むからです。
- シンプルにタイピング数が少ない
- setter の名前を考えなくていい、覚えなくていい
どちらも地味ながら効いてきます。頭に set を付けるだけなので機械的に名称を付けられるものではありますが、それでも多少なりとも時間と脳を使っていたんだなと実感しました。
とはいえ "let" です。できれば書きたくないので、たくさん書くと嫌な気持ちになります。実際 svelte を書きながらどう向き合っているかですが
- 丁寧にプログラミングしていれば、普段 const を徹底することになるが、おかげで let を書く場面はリアクティブな値しかない。宣言や再代入を見ただけで「useState」として認識できる
- 丁寧にプログラミングしていれば、 let 変数は一か所に固めて定義するので、どれが let だか把握しきれず保守爆弾を抱えるような事態は起きない
- 丁寧にプログラミングしていれば、コンポーネントは適切なサイズに切り分けされており、また let のスコープはファイル内に閉じているので、把握しきれないほどの巨大なコンポーネントになるケースは少ない
であることに気づき、あまり意識することはありませんでした。
太字にしてみましたが、これは svelte 以外でも一般的に好ましいとされているプログラミングスタイルです。それを徹底していれば、相当大規模な開発にならない限り問題にならないのではないでしょうか。
むしろ let に対して危機感を持てるようなプログラマであればあるほど特に問題なく管理でき、そのレベルで書けるプログラマは実装が早いのでタイプ数と考えることが少なくなる恩恵を受けられる、という実感です。
また、執筆時点ではまだベータ版ですが、Svelte 5 では rune が導入されます。これならもう少し受け入れやすくなるのではないでしょうか。
let count = $state(0);
let は変わらないんですけどね！
筆者は Svelte の微妙な文法が大幅に緩和されていて好きなので、Svelte5 を積極的に使ってます。
良くないところ: コミュニティが小さい
大規模で複雑な動作が求められる「webアプリケーション」については、やはり多くのライブラリから必要なものを組み合わせられる React 等を選定するのが無難です。
とはいうものの、svelte(kit) は本体機能側でユーティティを提供しているケースが多く、そもそも外部ライブラリに依存する必要性は React ほど高くはありません。
今のところ必要性を感じているのは
- 仮想リスト系 (tanstack-virtual)
- データフェッチ系 (tanstack-query)
- フォームバリデーション系 (まだ良さげなのを見つけられていない, valibot 手書き中)※→記事コメント参照
あたりです。
tanstack 推しみたいになっちゃってますが、開発コミュニティが大きめだと安心ですからね…。
UIライブラリの貧弱さ
一方で、UI ライブラリの少なさはどうしてもカバーしきれない弱点です。
React なら MUI, Chakra, Mantine 等有名なライブラリから好きなものを選べますが、現状 svelte にそこまで強力な選択肢は存在していません。
一応、最近可能性を感じているものに material design の web component 実装がありますが…。
web component だと svelte として扱いやすい形にはなっていないので、現状で一番有力なのは tailwind 系の資産を持ってくる形になります。
良さそうに見える svelte のUIライブラリは大抵 headless + tailwind 系です。
筆者はいい機会だと思いモダン css を勉強し直しながら全て手書きしていますが[4]、とにかくすぐにいい感じのUIを組みたいんだ！！という要望が最優先事項であれば、今の svelte はまだ向いていない可能性があります。
まとめ
色々書くつもりだったんですが、いざ書き始めてみたら「let が気になる」ぐらいしかありませんでした。
筆者は Vue があまり合わず React をずっと使っていましたが、Svelte はしっくり来ています。Svelteの文法はVueと似ていますが、よりシンプルです。
とにかく「書きやすい」のがいいところなので、React に疲れを感じることがあればぜひ触ってみてはいかがでしょうか！[5]
その他読み物
Svelte for Sites, React for Apps https://www.swyx.io/svelte-sites-react-apps
Discussion
初めまして！フォームについて、個人的にはSuperformsがおすすめです！
手前味噌ですが、SuperformsとValibotを組み合わせて使ってみる例を記事にしているのでよろしければ
ご紹介ありがとうございます。記事も拝見させていただきました、なかなかよさげですね！
細部まで考え出すと自前実装に限界を感じてきていたところですので、さっそく試してみようと思います！
コメント失礼します。
UIライブラリーは以下のものが現状有名かと思います。
デザインシステムになってしまいますが、IBMのcarbom UIもsvelteのUIライブラリーを出していますので、ご参加までに。