フレームワークの無いフレームワーク: なぜもっと早く思いつかなかったのか

待って、この新しいフレームワークには ランタイム があるの？ うーん。ありがとう、やめておくよ。 – front end developers in 2018

私たちはあまりに多くのコードをユーザーに配布しています。多くのフロントエンド開発者と同じように私もこの事実を否定し、ページロードの際に 100kb の JavaScript を配布しても問題ないと考えていました。.jpg を1つ減らせば 良いだけだと。そして 本当に 重要なのはアプリケーションがインタラクティブになった後のパフォーマンスだと考えていました。

しかし、私は間違っていました。100kb の .js は 100kb の .jpg と同じではありません。アプリの起動時のパフォーマンスを低下させるのはネットワークの時間だけではありません。script の解析と評価にも時間がかかり、その間ブラウザーは完全に無反応になります。モバイルでは、このミリ秒単位の時間があっという間に積み上がります。

これが問題であることに納得できないなら、Twitter で Alex Russell をフォローしてください。Alex は 最近、フレームワークコミュニティで多くの友人を作ろうとしませんが、彼は間違っていません。しかし、Angular、React、Ember などのフレームワークの代替として提案されている Polymer は、フロントエンドの世界ではまだ普及していませんし、それは決してマーケティングが不足しているからではありません。

おそらく、全てを再考する必要があります。

フレームワークが 本当に 解決すること

フレームワークはコードの複雑さを管理しやすくする、というのが一般的な認識です。フレームワークは仮想DOMの差分検出などの技術によって面倒な実装の詳細を抽象化する、というものです。しかし、実際にはそうではありません。せいぜい、あなたが書かなければならないコードからあなたが書いていないコードに 複雑さを移動させる だけです。

むしろ、React のようなアイデアがこれほど成功した理由は、 コンセプト の複雑さを管理しやすくしているからです。フレームワークはコードではなく思考を構造化するためのツールです。

そう考えると、もしそのフレームワークが 実際にはブラウザーで動かない としたらどうでしょうか？　代わりに、Babel が ES2016+ から ES5 に変換するように、アプリケーションを純粋なJavaScriptに変換するとしたら？　重たいランタイムを配布するための初期コストを支払うことはなく、アプリは本当に高速になります。アプリとブラウザの間の抽象レイヤーがなくなるからです。

Introducing Svelte

Svelte はまさにそれを実現するフレームワークです。HTML、CSS、JavaScript (それと 5分以内に学べる ちょっとしたこと) でコンポーネントを書き、Svelte がそれをビルドプロセスで小さなスタンドアローンの JavaScript モジュールにコンパイルします。コンポーネントのテンプレートを静的に解析することで、ブラウザーの作業を可能な限り少なくなるようにすることができます。

Svelte による TodoMVC の実装 は 3.6kb (zipped) です。比較として、 アプリコードを除いた React と ReactDOM はおよそ 45kb (zipped) です。ブラウザーが React を評価するのにかかる時間は、Svelteがインタラクティブな TodoMVC を起動して実行するのにかかる時間の約10倍です。

そして js-framework-benchmark によれば、アプリが起動して実行されると Svelte はとてもつもなく高速です。React よりも速いです。Vue よりも速いです。Angular、Ember、Ractive、Preact、Riot、Mithrilよりも速いです。今のところ、おそらく世界で最も高速な UI フレームワークである Inferno (Dominic Gannaway は魔法使い(a wizard)なので) に匹敵します。(Svelte は要素の削除が遅いですが、それについては取り組んでいます)

基本的には純粋な JS と同じくらい速いです。実際、それは 純粋な JS なので 当然です。ただ、純粋な JS を書く必要がないというだけです。

本当に重要なことは

ええ、パフォーマンスはとても重要です。しかし、このアプローチの本当にエキサイティングなところは、Web 開発におけるいくつかの厄介な問題をついに解決できることです。

相互運用性について考えてみてください。npm install cool-calendar-widget を実行してアプリで使いたいですか？　これまでは、そのウィジェットがそのフレームワーク向けにデザインされていて、あなたがそのフレームワーク(の正しいバージョン)を使っているときに限りそれが可能でした。もし cool-calendar-widget が React で作られており、あなたが Angular を使っていたら、まあ、残念でしたね。しかし、もしそのウィジェットの作者が Svelte を使用した場合、そのウィジェットを使用するアプリを好きなテクノロジーで構築することができます。(TODOリスト : Svelte コンポーネントを Web Components に変換する方法)

他には、コード分割 があります。これは素晴らしいアイデア (初期表示に必要なコードだけをロードし、残りは後で取得する) ですが、問題があります。100個の React コンポーネントではなく、最初に1個の React コンポーネントを配布するだけでも、 React自体を配布しなければなりません 。Svelteでは、フレームワークはコンポーネントに埋め込まれており、そのコンポーネントは小さいため、コード分割がより効果的です。

最後に、オープンソースのメンテナーとして悪戦苦闘してきたこと。ユーザーは常に自分の機能を優先してほしいし、その機能を必要としていない人に対してその機能のコストを低く見積もります。フレームワークの作者は、プロジェクトの長期的な健全性と、ユーザーのニーズを満たしたいという欲求との間でバランスを常に取り続けなければなりません。これはとてつもなく難しいことです。なぜなら、少しずつ大きくなっていく成果・結果を予測したりすることはできないですし、ましてや明確にすることは不可能です。また、(それまで熱狂的にツールを伝道してきた)人たちに、それらの機能に重要な部分が足りていないと伝えるには本格的なソフトスキルが必要です。しかし Svelte のようなアプローチでは、使用していない機能のコードはコンパイラによって生成されないため、多くの機能を追加しても、その機能を必要としていない人にそのコストを与えることは全くありません。

まだ始まったばかり

Svelteは非常に新しいです。ビルドツールのインテグレーション作成、サーバーサイドレンダラー、ホットリロード、トランジション、ドキュメントやサンプルの追加、スターターキットなど、まだまだやるべきことがたくさんあります。

しかし、すでにリッチなコンポーネントを構築することができます。それが stable な 1.0.0 のリリースに至った理由です。ガイドを読み、REPL で試して、そして GitHub にアクセスして、次世代のフロントエンド開発をスタートしてください。