前の章で述べたように、Svelteは私にとって魅力的です。Svelteのコアコンセプトは、「静的解析とコンパイルによってランタイムでの処理を減らす」というものであり、Virtual DOMによる差分処理の時間とランタイムの負荷を軽減します。

しかし、Svelteはランタイム中にあまり多くの処理を行うことができないという問題に直面する運命にあります。

• 例えば、このissue（コンテンツがない場合にスロットのフォールバックコンテンツをレンダリングする）では、スロット内のコンテンツが空の場合にfallbackをレンダリングする必要があります。しかし、以下のようなコードがあるため、

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

静的解析ではif文があることしか分からず、コンテンツがあると判断されますが、実際にはフォールバックではなく空白がレンダリングされます。

• コンパイルはコンパイルであると言っても、ランタイムは存在します。依存関係の追跡や更新をサポートするメカニズムが内部にあります。リアクティビティがブラウザに実装されない限り、フレームワークはこの問題を解決する必要があります。また、現在のコンパイラはプログラムのバンドルを最小限に抑える努力をしていますが、機能が増えるにつれてバンドルサイズが徐々に増加する可能性があります。大規模なプロジェクトでは、その差は明確ではなくなるかもしれません。

• Virtual DOMがないことによるもう一つの問題は、テストです。Virtual DOMは抽象化を提供するため、インターフェースに基づいて実装するのが容易です。Reactのように非常に簡単にテストできるわけではありません。もちろん、これは開発者のエクスペリエンスとユーザーエクスペリエンスに関わる問題です。

また、コードを書く際に「XXXフレームワークは最高で、他はゴミ」といった考え方は好ましくありません。これは自身のキャリアや技術において停滞を意味するだけでなく、良くありません。

もちろん、世界が完全に同じで、みんなが素晴らしいわけではありません。どれが良いか、フレームワーク/言語を選ぶことは、あなたのセンスを表すものでもあります。

「乒乓」というアニメには、私が好きなセリフがあります：

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

もちろん、気味が悪いとまでは言いませんが、特定のフレームワークに固執する必要はありません。あなたの能力はフレームワークを制御する能力に依存するべきであり、フレームワークによって制御されるべきではありません。

まとめると、このフレームワークを会社内に導入するには、しばらく観察する必要があるかもしれませんが、小規模（または中規模）のプロジェクトを素早く開発するために使用するのに非常に便利だと個人的には思います。そして、開発にすぐに入ることができます。とにかく、私にとってワクワクするフレームワークであり、今後の発展に期待しています。