少し前まで、 FFConfカンファレンスでプレゼンテーションを行う機会がありました。 「<目的のライブラリ/フレームワークを作成する>これを使用するのがベストです！」 そして、これにより、モバイルデバイス上の最新のフレームワークの「コスト」に関する専門的な環境での幅広い議論が引き起こされることを期待して、出版物に主要なアイデアを提示することにしました。

私のスピーチのオリジナルを参照したい人のために、ここにビデオがあります：



およびプレゼンテーションのスライド： speakerdeck.com/paullewis/framework-here-its-the-bestestest

フレームワークの利点

年の初めに、 Reactフレームワークのパフォーマンスが、操作するツリーのサイズの増加に依存していることについて書きました（TL; DR：大きいほど、より多くの計算能力が使用されます）。 私はこの出版物について、評価的で建設的なものから非常に否定的なものまで、非常に幅広い範囲で多くのフィードバックを受け取りました。 このフィードバックのおかげで、追加情報を収集しましたが、これは多かれ少なかれすべてのフレームワークに起因するものです。

• フレームワークは素晴らしく、使いやすいです。 私は、より困難で退屈な方法を探している開発者を一人も知りません。 はい、人間工学と快適さが明らかに重要です。
• フレームワークを使用すると、MVPをより迅速に作成できます。 これは、小規模で経験の浅い企業や組織にとって特に重要です。 クイックスタートは、製品の成功に決定的な役割を果たすことができます。
• フレームワークは、機能とプラットフォームのバグを回避するのに役立ちます。 最近では、ブラウザーが標準にはるかに一致するようになったため、これはあまり意味がありません。 しかし、IE5と6、およびFirefox、Safari、Chromeの以前のバージョンで苦労したことを思い出してください。
• [フレームワークの名前を挿入]を知っている場合、彼らは私にこれを支払うでしょう。 新製品と最高のフレームワークを持っていることが、仕事を見つける上で大きな役割を果たすことができます。

さらに、使いやすさが最も重要な要因であることが判明しました-ほとんどの開発者は、明示的または暗黙的にそれを指摘しました。 この集合的な意見は、次のように定式化できます。「自分が生きやすいなら、ユーザーのためにより良いことをすることができます。」 それはいいようです。 しかし、私にはそう思われますが、この立場では多くの重要なポイントが見落とされています。

開発者の快適さとユーザーのニーズ

ユーザーが自分のニーズを持っていることを忘れてはなりません。 特に、次のような：

• サイトとアプリケーションはすばやくロードする必要があります。
• インターフェイスはスムーズに動作するはずです。
• それらは電話にとって「重すぎる」ものであってはなりません。
• 壊れてはいけません。
• 必要な一連の機能が必要です。

問題があります：一方で-開発者の利便性と快適さ-一方でユーザーのニーズ。 また、フレームワークはリソースの使用という点では無料ではないため、これが好きかどうかに関係なく、これらはすべて何らかの形で互いにリンクする必要があります。

余談

ここでは、個々のライブラリを考慮から除外することを提案します。 結局、問題が発生した場合、他の問題に置き換えることができます。 ライブラリが日付形式を設定する方法が気に入らない？ さらにプラグインするだけです。 しかし、フレームワークの変更はそれほど簡単ではありません。 多くの場合、これにはアプリケーション全体の再構築が必要です。 さらに、フレームワークはより多くのスペースを占有し、アプリケーションにはるかに広く深く関わっています。

「コスト」コード

各開発には独自の「価格」があります。 しかし、各フレームワークは全体的な「コスト」に対して独自の貢献をしていると思います。



フレームワークが推奨されていない（受け入れられない）ことを通知する魔法の瞬間。 メッセージはおそらくJavaを生成しました。 変です。

• 研究。 フレームワークの学習に時間を費やす必要があります。フレームワークの「イディオマティック」コードの書き方、さまざまな操作を実行するためのテンプレート、プラクティス、メソッドがここで使用されています。 Webプラットフォーム自体と比較しても違いはありません。 そこでは、単に使用して使用を開始することはできません。次々に問題を解決する必要があります。
• 再び勉強する。 開発中のある日、許容できないもの、古い操作、コードを更新する提案に関する警告がコンソールに表示されます。 このような場合、通常、フレームワークの新しいバージョンについてアクションが好きではなかったものを把握する必要があります。 また、これには、古いバージョンでリリースされたプロジェクトの更新が必要になる場合があります。
• デバッグ 他のソフトウェアと同様に、フレームワークにはバグが含まれています。 独自のバージョンを作成する場合でも、このために準備する必要があります。 また、フレームワークのデバッグの複雑さは、通常「困難」から「不可能」までの範囲に収まります。 問題が見つかった場合は、次のバージョンのフレームワークでバグが公式に修正されるまで、自分でパッチをパッチしてみてください。

ユーザーは価格を「支払う」こともできます。

• 時間。 有線で転送されたものをダウンロードするのにどれくらい時間がかかりますか？
• 帯域幅 作業にはどのチャンネル幅が必要ですか？
• CPU（バッテリー）リソース。 プロセッサの使用量はどれくらいですか？ 計算能力とバッテリー寿命は相互に関連していますか？
• フレームレート。 画面はどのくらいの頻度で更新されますか（ ユーザーがインターフェイスのスムーズな操作を好むため）？
• メモリ。 製品はどのくらいのメモリを消費しますか？ メモリから他のアプリケーションをアンロードする必要がありますか？ 恐らく彼らのfall落を犠牲にしても？

テーブルのデータ

上記のすべてを考慮して、これらの値のいくつかの測定について議論することを提案します。 おそらく、共同の努力により、選択したポイントで妥協点を達成するための最善の方法を見つけることができるでしょう。 スマートフォンにフレームワークを最初にロードするところから始めます。 テストには、TodoMVCを選択しました。 私にとってこれはMVP Webアプリケーションであり、ユーザーの観点からは、機能のオプションはすべて同じです。

ブートストラップ

次のパラメーターを測定しました：時間、帯域幅、およびCPU使用率。 テストはNexus 5とiPhone 5Sで実施されました。



各フレームワークにかかる時間を測定することにしました。

• 有用なJavaScriptロードを評価して実行するには、
• プライマリデータセットのモデルでの処理と配置。

スタイル、レイアウト、塗りつぶしなどを適用するコストは無視しました。これは、さまざまなTodoMVC実装ではあまり変わらないはずだからです。 また、データ転送の期間を測定しませんでした。

方法論

WebPagetestを使用してNexus 5にページをロードしました。 実行ごとにタイムラインファイルが作成され、 Big Rigで処理されました。 SafariでのJavaScriptプロファイリングはトレースとタイムラインのエクスポートをサポートしていないようですので、私は自分でiPhoneから結果を取得して処理しました。



Big Rigを使用する

ところで、だからこそBig Rigを作成しました。私たち全員がこの種のデータを簡単に処理できるようにしたかったのです。

テストプレイ

たとえば、Chromeを実行しているデバイスで自分自身をテストする場合は、次のアルゴリズムに従います。

• Big Rig CLIをインストールします：npm install -g bigrig。
• WebPagetestをチェックしてください 。
• 現在地については、「ダレス」を選択します。
• ブラウザの場合は、Nexus 5-Chrome（またはBeta / Dev）を選択します。
• [Chrome設定]タブで、[Capture Dev Tools Timeline]チェックボックスをオンにします。
• テストを実行します。
• 結果の左側にあるタイムラインファイルをダウンロードします。
• bigrig --file /path/to/timeline.json --pretty-printを実行します。

ここに私がそれをする方法の例があります：

結果

私はそのようなデータを受け取りました：

枠組み	大きさ	Nexus 5の起動時間1、3	iPhone 5S 2、3の起動時間
ポリマーv1.1.4	41 Kb 5	409ミリ秒	233ミリ秒
ポリマーv1.2.2	47 Kb 5	155ミリ秒	232ミリ秒
AngularJS v1.4.3	324 kb	518ミリ秒	307ミリ秒
React v0.13.3 [JSXは変換されません]	311 Kb	1,201ミリ秒	1,463ミリ秒
React v0.13.3 [バベルを使用して変換されたJSX] 4	162 Kb	509ミリ秒	282ミリ秒
React v0.13.3 [JSX変換; 生産アセンブリ] 4、6	160 kb	174ミリ秒	118ミリ秒
バックボーンv1.2.2 [jQueryとアンダースコアを含む]	139 Kb	248ミリ秒	168ミリ秒
Ember v1.10.0-beta.3	580 kb	1.992ミリ秒	1,440ミリ秒
バニラ	16 Kb	50ミリ秒	33ミリ秒

注：

1. Chrome 47を実行しているNexus 5で実行されたテスト。
2. Safari 9を実行しているiPhone 5Sで実行されたテスト。
3. ブートストラップには、プライマリタスクリストからのデータの処理が含まれます。
4. JSX Transformerを切り取ります。 JSXファイルはBabelを使用して変換されます。
5. Webコンポーネントポリフィル（12 Kb）を除く。
6. Reactミニファイドプロダクションビルドを使用しました。

私の観点からは、結論は明確です。モバイルデバイスでは、フレームワークの使用は、特に通常のJavaScriptの作成と比較して、負荷の深刻な増加に関連しています。 Polymer 1.2.2は最良の結果を示しましたが、それでもバニラよりも3倍遅いことが判明しました。 Reactの速度はPolymerに匹敵しますが、そのスケーラビリティに関して疑問があります。

状況を本当に明確にするために、私は注意します：

• Reactの場合、TodoMVCは変換しないため、JSXを自分で変換しました。 代わりに、JSX Transformerライブラリが含まれています。 このライブラリの実行が結果に影響を与えないように、私はそれを見つけ出し、結果の「カスタム」バージョンをテストしました。 残念ながら、この場合、Reactの縮小されていないバージョンを使用したため、3番目のオプションをテストする必要がありました。
• 表に示されている結果には、データ転送の期間は含まれていません。 インターフェイスの最終レンダリングまで、JavaScriptでフレームワークの起動時間のみを測定しました。 TodoMVCのフレームワークの一部は縮小されていないことに注意してください。 ご希望の場合は、フィラメントグループのWebサイトでデータ転送量に関する議論を検討できます。

考えられる異議

おそらく、テストのいくつかの瞬間は異論を引き起こす可能性があり、それに答える必要があります：

• 「TodoMVCは慣用的ではありません 。 」 この声明を確認しました。 私の知る限り、それぞれの実装は慣用的です。 そうでない場合、フレームワークは各ファイルに必要なコンピューティングリソースを分析します。
• 「TodoMVCは私のシナリオを反映していません 。 」 おそらく。 しかし、あなたの場合、「コスト」はTodoMVCのそれよりもさらに高いと思います。 Paul Irishは最近、Redditのモバイルバージョンのパフォーマンスを調査し、とりわけ、モバイルデバイスにReactコンポーネントをダウンロードするのに22秒かかることを発見しました！
• 「ユーザーにはNexus 5 / iPhone 5Sがありません 。 」 これも非常に現実的です。 良いデバイスでテストを行う機会があり、多くのユーザーが高価で強力なスマートフォンを持っていないことを想像できます。 したがって、実際には、ロード時間の状況はさらに悪化します。
• 「次のバージョンでは、<フレームワークの名前を挿入>状況が改善されます。 」 認めます しかし、これは、以前のバージョンのフレームワークで既に製品を使用している人には役に立たないでしょう。

64,000ドルの質問

そして、必然的に疑問が生じます。フレームワークを使用する必要がありますか？ 私はそれに答えることができません。 それは完全にあなた自身の決定でなければなりません。 フレームワークが必死に必要な理由は百万通りあります。 これに関する私自身の考えは次のとおりです。

• フレームワークは、アイデアと概念の実装を促進します。 どのアプローチが機能し、どのアプローチが機能しないかを理解できるのは、彼らのおかげです。 これは、プラットフォームレベルでソフトウェア製品を改善するプロセスを刺激します。 この観点から、フレームワークは、プラットフォームのフレームワーク内で将来のイノベーションを体験できる、ある種のテストサイトのように思えます。 彼らの助けを借りて、モバイルWebが近い将来獲得する機会を理解できます。
• フレームワークは制御の逆です。 上記では、ライブラリは簡単に切り替えることができるため、考慮から除外しました。 フレームワークは、アプリケーションのライフサイクルを制御し、コードを開始するためのエントリポイントを提供します。 はい、あなたはコード自体に責任がありますが、全体の状況を制御するわけではありません。
• モバイルデバイスで使用する場合の道路フレームワーク。 少なくとも基本言語と比較して。 そして、私の観点から-許容できないほど高価です。 しかし、それぞれが許容範囲の限界について独自の考えを持っています。

はい、フレームワークは開発者にかなりの快適さを提供します。 しかし、ウェブプラットフォーム自体のフレームワーク内で自分の知識とスキルに投資する方が良いと考えざるを得ません。 フレームワークは行き来し、それらはインターネットの衰退のようなものであり、アイデアとテンプレートの実装と洗練を支援します。 しかし、ある日、お気に入りのフレームワークが機能しなくなったり、重要なバグが修正されていないことに気付いた場合、プラットフォームデバイスを理解する能力は非常に貴重なサービスになります。

乾燥残留物中

私はかつて、開発者の快適さはユーザーのニーズほど重要ではないと書きました。 私はまだそれを信じています。 私は楽な生活に魅了されていますが、うまく機能しない製品を作りたくありません。 そして、ユーザーに高い「価格」を払わせたくありません。 今、私はモバイルデバイスにフレームワークをロードする速度について心配しています。 しかし、これは最初のステップにすぎません。 他のメトリックがあります：メモリ使用量、長いCPU負荷、フレームレート。 一般に、ユーザーにとってコストのかからないソリューションを探す必要があります。

メモリをほとんど消費せず、大きなフレームレートで動作する高速ロードフレームワークを実装でき、開発の快適ささえ提供できる場合、これは理想的です。 しかし、それまでは、少なくともモバイルセグメントでは、フレームワークなしでdoを使用することを好みます。