スヴェルトノート (1)-特効薬なし

前の章で述べたように、Svelteは私のお気に入りです。Svelteの核心概念は「静的分析とコンパイルを通じてruntimeの負担を減らすこと」であり、Virtual DOMがdiffを行う時間と大量のruntimeを削減します。

しかし、Svelteが進む道にはいくつかの問題も避けられません。主な問題は、Svelteがruntimeの中であまり多くのことを行うことができない点です。

例えば、この issue（コンテンツがない場合にslotのfallbackコンテンツをレンダリングする）では、Svelteはslotの内容が空の場合にfallbackをレンダリングする必要がありますが、以下のようなコードが含まれているため：

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

静的分析の段階ではif statementがあることしか認識できず、内容があると判断されますが、実際のレンダリングではfallbackではなく空白になります。

コンパイルされるとはいえ、全くruntimeがないわけではありません。背後には依存関係を追跡し、更新するためのメカニズムが存在します。ブラウザがreactivityを実装していない限り、フレームワークはこの問題に対処する必要があります。また、現在のコンパイラはパッケージに出力されるコードを減らす努力をしていますが、機能が増えるにつれてbundle sizeが徐々に増加する可能性があり、大規模なプロジェクトではその差があまり目立たないかもしれません。
Virtual DOMがないことによるもう一つの問題はテストです。Virtual DOMのもう一つの利点は、インターフェースに基づいて実装を容易にする抽象を提供することです。Reactのように非常に簡単にテストできるわけではなく、これは開発者エクスペリエンスとユーザーエクスペリエンスに関わる問題です。

プログラミングをしているとき、「XXXフレームワークは最高！他はゴミ」という考え方が好きではありません。このような考え方は、キャリアや技術的な成長を停滞させるだけでなく、非常に好ましくありません。

もちろん、これは世界が皆素晴らしいということではありません。このフレームワークもこの言語も良い、というわけではなく、フレームワークや言語を選ぶことは、あなたのセンスを反映しています。

「ピンポン」の中で好きなセリフがあります：

卓球に人生をかけるなんて気味が悪い（卓球のために人生を賭けるなんて気持ち悪い）

確かに気持ち悪いというのは少し誇張かもしれませんが、特定のフレームワークを固守する必要はありません。あなたの実力はフレームワークを使いこなす能力によって決まるべきであり、フレームワークに支配されるべきではありません。

まとめると、このフレームワークを会社に導入するにはもう少し観察が必要かもしれませんが、個人の小規模なプロジェクト（さらには中規模なもの）には非常に使いやすく、すぐに開発に入ることができます。とにかく、私をワクワクさせるフレームワークであり、今後の発展を楽しみにしています。