JavaScriptはフレームワークについて考え直すときが来ています / Svelteを使ってみた
これはFrameworks without the framework: why didn't we think of this sooner?の日本語訳です。
フレームワークのないフレームワーク
何故我々はこの可能性をもっと早く考えなかったのか
素のJavaScriptでは重要なアプリを書こうとしても必ず壁にぶつかってしまう。
でもコンパイラなら…コンパイラならきっと何とかしてくれる…！！
待って、このFWはランタイムが入ってるのかい？……うん、今回はパスで。
-- 2018年のフロントエンドエンジニア
我々は、あまりに多くの無駄コードをばらまきすぎています。
多くのフロントエンドエンジニア同様、私もその事実を否定していました。
だってたった100kb程度のJavaScriptだぜ、小さなjpg画像一枚分くらいたいして変わりはしないじゃないか！
私は間違っていた。
100kbのJavaScriptは100kbのjpg画像とイコールじゃないんだよ。
アプリが起動するのにかかる時間には、ファイルをダウンロードする時間だけではなく、スクリプトを解析して実行する時間も含まれるのだ。
その間、ブラウザは全く反応しなくなってしまう。
モバイル端末であれば、この無反応時間が急速に増大するのがよくわかるでしょう。
これが問題だと思わないのであれば、Alex Russellをフォローするといいよ。
彼は間違ったことは言っていないはずなのに、最近はフォロアーが増えてません。
彼の主張、AngularやReact、Emberなどといったフレームワークの代わりにPolymerを使おう、というそれは、賛同を集めることができませんでした。
おそらく、我々は全てを考え直す必要があります。
フレームワークが本当に解決しないといけない問題とは？
フレームワークとは、複雑なコードを簡単に書けるようにしようとするものだ、というのが一般的な認識でしょう。
仮想DOMのような技術を使って、実装の細かい部分を抽象化するのです。
しかし、それは真実ではない。
フレームワークは、単にコード部分から、コード以外の部分に複雑さを持って行っているだけなのです。
Reactのようなアイデアがうまく成功した理由は、構想の複雑さをより簡単に管理できるからです。
フレームワークは主に、コードそのものではなく、考え方を構造化するためのツールなのです。
そう考えると、フレームワーク自体を実際にブラウザ上で動かす必要は別にないのでは？
BabelがES2016+をES5に変換するのと同じように、作ったアプリケーションをピュアなJavaScriptに変換すればいいのでは？
フレームワークを初期起動する多大な処理時間を費やす必要もなく、アプリケーションとブラウザ間に抽象化レイヤーも存在しなくなり、アプリケーションは大幅な高速化に成功するでしょう。
ここでSvelteを紹介しよう
Svelteは実際にそれを行うフレームワークです。
あなたはHTML、CSS、および5分で学べるJavaScriptだけでコンポーネントを作成できるよ。
Svelteはビルド時に、それらをただのスタンドアローンなJavaScriptモジュールにコンパイルします。
コンポーネントを静的なコードにすることで、ブラウザがなるだけ何も作業しなくていいようにしちゃいますよ。
サンプルのTodoMVCはzip圧縮後で3.6kbしかないよ。
Reactと比較してみると、ReactとReactDOMのフレームワークだけですでに45kbもあるよ。
ブラウザがReactのフレームワークを解析するだけで、SvelteがインタラクティブなTodoMVCを起動して動き始めるまでの10倍以上の時間がかかることになります。10倍だぞ10倍。
さらに、js-framework-benchmarkによると、Svelteは実際スゴイ・ハヤイ。
これはReactより早い。Vueよりも早い。もちろんAngularやEmberより、RactiveよりPreactよりRiotよりMithrilよりも早い。
おそらく世界で最も早いInfernoといい勝負をしているけど、これはInferno作者のDominic Gannawayがウィザード級ハッカーだから仕方ない。
Svelteは要素の削除が遅くて、我々はその改善に取り組んでるよ。
Svelteは基本的にバニラのJavaScriptと同じくらい早いけど、それはバニラのJavaScriptだからです。
でも貴方はバニラのJavaScriptを書く必要はありません。
でも、それは重要なことではない
いいかい、パフォーマンスはとても重要で大きな問題だよ。
しかしながら、我々の取ったアプローチが真に画期的なのは、それがWeb開発における最も厄介な問題のいくつかを片付けることができるからなんだ。
相互運用性を考えてみよう。
君のアプリケーションでnpm install cool-calendar-widgetしたいとしよう。
以前は、そのヴィジェットが想定していたフレームワークの想定していたバージョンでビルドされていない限り使うことができなかった。
たとえばcool-calendar-widgetがReactで作られていて、君がAngularを使っていた場合、そいつはお生憎様はいさようなら、ということになっていたわけだ。
しかし、もしヴィジェット作者がSvelteを使っていた場合、それを使用する側はなんだって好きなフレームワークを使えるわけだ。
TODO:SvelteコンポーネントをWebコンポーネントに変換する方法
次にコード分割を考えよう。
最初に表示するのに最低限必要なコードだけをまずロードし、それ以外のコードはその後でロードする、これは一見よい考えだ。
だがそこには問題がある。
最初に100のうちの1コンポーネントだけをロードしたかったとしても、結局Reactの本体自体もロードしないといけない、というところだ。
Svelteでは、フレームワークはコンポーネントに埋め込まれているし、コンポーネント自体も小さいから、コード分割が遙かに効率的になる。
最後に、私はOSSのメンテナとして多大な努力をしてきました。
ユーザは常に誰も必要としない機能についても優先順位付けを行いたがり、その作成コストは過小評価したがります。
フレームワーク作者は、プロジェクトの長期的展望と、ユーザのニーズを満たすという二律背反のバランスをうまく取っていかなければなりません。
そしてそれは驚くほど困難です。
フレームワークによって追加された機能がたいして重要ではないということをユーザに伝えるためには、卓越したコミュニケーションスキルが必要です。
しかし、Svelteのアプローチでは、不要なコードはそもそもコンパイラが生成しません。
さあ始めよう
Svelteはできたばかりのフレームワークです。
ビルドツールの統合、サーバサイドレンダラーの追加、Hot Reloading、transition、ドキュメントやサンプルなど、まだまだ多くの作業が残っています。
しかし、既にstableな1.0.0をリリースしたから、豊富なコンポーネントをビルドすることはできます。
ガイドを読んで、REPLを試して、GitHubに向かい、フロントエンド開発の次世代を迎えてください。
感想
スラングとかよくわからん。
many features can be added with absolutely no cost to people who don't use them
「誰も使わない機能ならいくらでも無料で追加できる」ってなんだ？皮肉？
ですます調を意識してるのだが、気がつくとだである調になっている。
で、実際にSvelteを使ってみた記事はこちら。