フレームワークのないフレームワーク：なぜもっと早くこう考えなかったのだろう？

ちょっと待って、この新しいフレームワークにはランタイムがあるのか？うーん、パス。– 2018年のフロントエンド開発者

私たちはユーザーにあまりにも多くのコードを送りすぎている。多くのフロントエンド開発者と同様に、私はその事実を否定し、ページ読み込み時に100KBのJavaScriptを提供しても大丈夫だと考えていました。 – .jpgを1つ減らす！ – そして、本当に重要なのはアプリがすでにインタラクティブになってからのパフォーマンスだと考えていました。

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

これが問題だと納得できない場合は、Twitterでアレックス・ラッセルをフォローしてください。アレックスは最近、フレームワークコミュニティで多くの友人を失っていますが、彼は間違っていません。しかし、Angular、React、Emberなどのフレームワークを使用する代わりに提案されている代替案 – Polymer – は、まだフロントエンドの世界で支持を得ていません。そして、それはマーケティング不足のためではありません。

おそらく、私たちは全体を再考する必要があります。

フレームワークは実際にはどのような問題を解決するのでしょうか？

一般的な見解では、フレームワークはコードの複雑さを管理しやすくします。フレームワークは、仮想DOMの差分などの手法を使用して、面倒な実装の詳細をすべて抽象化します。しかし、それは実際には真実ではありません。せいぜい、フレームワークは複雑さを移動させるだけで、あなたが書かなければならなかったコードから、あなたが書かなかったコードへ移動するだけです。

代わりに、Reactのようなアイデアが非常に広く、当然成功している理由は、それらがあなたの概念の複雑さを管理しやすくするためです。フレームワークは、主にコードではなく、思考を構造化するためのツールです。

そうだとすると、フレームワークが実際にブラウザで実行されなかったらどうでしょうか？代わりに、BabelがES2016+をES5に変換するように、アプリケーションを純粋なバニラJavaScriptに変換したらどうでしょうか？ランタイムを大量に送り込むという初期費用はかからず、アプリとブラウザの間に抽象化の層がないため、アプリは非常に高速になります。

Svelteの紹介

Svelteはまさにそれを行う新しいフレームワークです。HTML、CSS、JavaScript（および5分以内に学習できるいくつかの追加のビット）を使用してコンポーネントを作成し、ビルドプロセス中にSvelteはそれらを小さなスタンドアロンJavaScriptモジュールにコンパイルします。コンポーネントテンプレートを静的に分析することで、ブラウザができるだけ少ない作業を行うようにすることができます。

TodoMVCのSvelte実装は、zip圧縮で3.6KBです。比較すると、ReactとReactDOMは、アプリのコードなしでzip圧縮で約45KBです。ブラウザがReactを評価するのにかかる時間は、SvelteがインタラクティブなTodoMVCで稼働するまでの時間の約10倍かかります。

そして、アプリが稼働すると、js-framework-benchmarkによると、Svelteは非常に高速です。Reactよりも高速です。Vueよりも高速です。Angular、Ember、Ractive、Preact、Riot、Mithrilよりも高速です。おそらく世界で最速のUIフレームワークであるInfernoと競合します。今のところ、ドミニク・ギャナウェイは魔法使いだからです。（Svelteは要素の削除が遅いです。私たちは取り組んでいます。）

基本的にはバニラJSと同じくらい高速です。これは、それがバニラJSだから当然です。あなたが書く必要のなかったバニラJSです。

しかし、それは重要なことではありません

まあ、それは重要です。パフォーマンスは非常に重要です。しかし、このアプローチで本当にエキサイティングなのは、Web開発で最も厄介な問題のいくつかを最終的に解決できることです。

相互運用性について考えてみましょう。npm install cool-calendar-widgetを実行して、アプリで使用したいですか？以前は、ウィジェットが設計されたフレームワーク（正しいバージョン）をすでに使用している場合にのみそれを行うことができました。 – cool-calendar-widgetがReactで構築され、あなたがAngularを使用している場合は、うまくいきません。しかし、ウィジェットの作成者がSvelteを使用した場合、それを使用するアプリは、あなたが好きなテクノロジーを使用して構築できます。（TODOリスト：SvelteコンポーネントをWebコンポーネントに変換する方法。）

またはコード分割。それは素晴らしいアイデアです（最初に必要なコードだけをロードし、残りは後で取得します）が、問題があります。 – 100個のReactコンポーネントの代わりに1つのReactコンポーネントだけを最初に提供する場合でも、React自体を提供する必要があります。Svelteを使用すると、フレームワークがコンポーネントに埋め込まれており、コンポーネントが小さいため、コード分割がはるかに効果的になります。

最後に、オープンソースのメンテナとして私が苦労してきたことですが、ユーザーは常に自分の機能が優先されることを望んでおり、それらの機能がそれらを必要としない人々にどれだけのコストがかかるかを過小評価しています。フレームワークの作成者は、プロジェクトの長期的な健全性と、ユーザーのニーズを満たしたいという欲求とのバランスを常に取る必要があります。それは信じられないほど難しいことです。なぜなら、増え続ける肥大化の影響を予測することは、ましてや明確にすることは難しく、ユーザーに（その時点であなたのツールを熱心に広めていた可能性のある人々に）彼らの機能はそれほど重要ではないと伝えるには、真剣なソフトスキルが必要だからです。しかし、Svelteのようなアプローチでは、それらの機能を実装するコードが不要な場合、コンパイラによって生成されないため、それらを使用しない人にまったくコストをかけずに多くの機能を追加できます。

私たちはまだ始めたばかりです

Svelteは非常に新しいものです。ビルドツール統合の作成、サーバーサイドレンダラーの追加、ホットリロード、トランジション、ドキュメントと例の追加、スターターキットなど、まだ多くの作業が残っています。

しかし、すでにそれを使って豊富なコンポーネントを構築できます。それが、安定版1.0.0リリースに直接進んだ理由です。ガイドを読んで、REPLで試して、GitHubにアクセスして、フロントエンド開発の次の時代を始めるのを手伝ってください。