Svelte ノート（1）- 銀の弾丸はない

前の章でも触れたように、Svelte は僕にとって手放せない存在になっている。Svelte のコアコンセプトは、「静的解析＋コンパイルによって runtime が行う処理を減らす」ことで、Virtual DOM による diff の時間や肥大化した runtime を削減することにある。

しかし、Svelte が歩む道には必然的にいくつかの問題も待ち受けている。その最たるものは、Svelte が runtime であまり多くのことを肩代わりできないという点だ。

• 例えばこの issue（Render slot fallback content when there’s no content）にあるように、Svelte は slot の中身が空のときに fallback をレンダリングすべきなのだが、中身に以下のようなコードがあると問題が起きる：

<Box>
	{#if foo}
		something
	{/if}
</Box>

静的解析の時点では中に if statement があることしか分からないため、「コンテンツが存在する」と判定されてしまう。その結果、実際には fallback が使われず、空白がレンダリングされてしまう。

• コンパイルするとはいえ、runtime が完全にゼロというわけではない。裏側には dependency を追跡して更新するための更新メカニズムが依然として存在する。ブラウザが reactivity をネイティブ実装しない限り、フレームワークがこの処理を引き受けるのは不可避だ。また、現在の compiler はバンドルされるコードを極力減らすよう努めているものの、機能を使えば使うほど bundle size は徐々に膨らんで追いついてくる可能性があり、規模の大きなプロジェクトではその差がそこまで目立たなくなるかもしれない。
• Virtual DOM がないことのもうひとつの問題点はテストだ。Virtual DOM のもうひとつのメリットは抽象化を提供してくれる点にあり、インターフェースに基づいた実装を検証しやすい。React のように極めて容易にテストできるわけではないが、もちろんこれは開発者体験（DX）とユーザー体験（UX）のトレードオフに関わってくる話だ。

また、コードを書くときに僕がとても嫌いなのは、「XXXフレームワーク最高！他は全部ゴミ」といった物言いだ。こうした考え方は自身のキャリアや技術的な成長において足踏みを招くだけでなく、かなり避けるべきものだと思う。

もちろん、誰もが仲良く平和でどれも素晴らしい、何でもOKだと言いたいわけではない。フレームワークや言語を選ぶことは、自身のセンスの表れでもある。

「ピンポン」に、僕の大好きなセリフがある：

卓球に人生をかけるなんて気味が悪い

気味が悪いというのは少し大げさかもしれないが、絶対にひとつのフレームワークにしがみつかなければならない理由なんてない。エンジニアの実力はフレームワークを乗りこなす能力によって決まるべきであって、フレームワークに振り回されるべきではないのだ。

まとめると、会社にこのフレームワークを導入するのはもう少し様子見が必要かもしれない。だが、素早く小さな（あるいは中規模の）プロジェクトを作る分には個人的にとても使い勝手が良く、すぐに開発に取り掛かることができる。総じて僕をワクワクさせてくれるフレームワークであり、今後の発展が楽しみだ。