同形JavaScript-Webアプリケーションの未来

Airbnbでは、過去数年間、強力なWebアプリケーションを作成することで多くのことを学びました。 2011年に単一ページアプリケーションの世界に突入し、 モバイルバージョンのサイトを作成しました。それ以来、 ウィッシュリストと新しい検索を開始しました。 これらはすべて優れたJavaScriptアプリケーションです。つまり、大量のコードがブラウザーで実行され、最新のインタラクティブなユーザーエクスペリエンスを提供します。



これは、backbone.js、ember.js、angular.jsなどのライブラリーが開発者が強力なJavaScriptアプリケーションを作成するのに役立つ今日の一般的なアプローチです。 しかし、そのようなアプリケーションにはいくつかの重大な制限があることに気付きました。 それを明確にするために、Webアプリケーションの歴史の短いツアーを見てみましょう。



_{注目を集める記事の画像}

JavaScriptは成長しています

Webの夜明けには、ブラウザとの対話は次のとおりでした。Webブラウザはすべてのページ（たとえばwww.geocities.com ）を要求し、インターネット上のどこかにあるサーバーにHTMLを生成して送り返しました。 当時のブラウザはまだそれほど強力ではなく、HTMLページはほとんど静的で自律的だったため、これは良いアプローチでした。 Webページをより動的にできるように設計されたJavaScriptは、スライドショーや日付の選択よりも複雑なものを許可しませんでした。



数年にわたるコンピューターテクノロジーの後、熱心な開発者はWebを限界を超えて押し進め、進化を余儀なくさせました。 現在、ウェブは非常に開発されているため、アプリケーション用の本格的なプラットフォームになっています。高速JavaScriptとhtml5標準の両方により、開発者は以前は特定のプラットフォームのみで作成できる強力なアプリケーションを作成できます。

シングルページアプリケーション

しばらくして、開発者はJavaScriptと新機能を使用して、ブラウザーでアプリケーション全体を作成し始めました。 Gmail（1ページアプリケーションの典型的な例）などのアプリケーションは、ユーザーのアクションに即座に応答できます。新しいページを表示するためだけに、サーバー上で完全に実行する必要はなくなりました。



Backbone.js、ember.js、angular.jsなどのライブラリは、多くの場合、クライアントMVCまたはMVVMライブラリと呼ばれます。 クラシックMVCクライアントアーキテクチャは次のようになります。







多数のアプリケーションロジック（ビュー、テンプレート、コントローラー、モデル、国際化など）がクライアントに存在し、データには特別なAPIが使用されます。 サーバーは、Ruby、Python、Javaなどの任意の言語で作成できます。 ほとんどの場合、その役割はワイヤーフレームページをレンダリングすることです。 JavaScriptファイルがブラウザに読み込まれるとすぐに実行され、クライアントアプリケーションが初期化され、対応するAPIを介してデータが読み込まれ、残りのHTMLがレンダリングされます。



これはユーザーに適しています。ロードされると、アプリケーションは再起動せずにページ間をすばやく切り替えることができ、すべてが正しく行われていればオフラインでも動作するからです。



理想的な単一ページのアプリケーションでは、クライアントとサーバー間でタスクが明確に分離されているため、開発者にとっても優れています。これにより、優れた開発プロセスが提供され、2つの環境間で多くのロジックを複製する必要がなくなります。

楽園のトラブル

ただし、実際には、このアプローチには致命的な欠陥がいくつかあるため、多くの場合使用できません。

検索エンジン最適化

クライアントでのみ動作するアプリケーションは、検索エンジンと正常に対話できません。つまり、デフォルトではSEOにあまり適合していません。 検索ロボットは、Webサーバーへのクエリを作成して結果を解釈することで機能しますが、サーバーが空白ページのみを返す場合、これはほとんど役に立ちません。 もちろん、回避策はありますが、タンバリンと一緒に踊らない限りではありません。

性能

同じ理由で、サーバーがページ全体を生成せず、代わりにクライアントにJavaScriptがロードされるのを待たなければならない場合、ユーザーは空白ページまたはロードアイコンを数秒間表示します。 遅いサイトがユーザーに、そしてそれに応じて利益に与える影響を調査する多くの研究が行われました。 Amazonは 、100ミリ秒の負荷削減ごとに利益が1％増加すると主張しています。 Twitterは、クライアントではなくサーバー上でページを完全に生成するようにサイトを再設計する40人の開発者の1年の共同努力を費やし、知覚される読み込み時間を5倍改善しました。

サポート

これにより、理想的には、明確で明確に分離されたかわいいコードが生成されます;必然的に、アプリケーションロジックまたは表示ロジックの一部がクライアントとサーバー間で複製され、多くの場合異なる言語で記述されます。 標準的な例は、日付または通貨のフォーマット、フォームの検証、およびルーティングロジックです。 これにより、特に複雑なアプリケーションではサポートが悪夢になります。



私を含む一部の開発者は、ここでコーンを埋めます-多くの場合、1ページのアプリケーションを作成するために多くの時間と労力を費やした後にのみ、これらの欠点が明らかになります。

ハイブリッドアプローチ

その結果、新しいアプローチと古いアプローチのハイブリッドが必要になります。生産性とSEOの理由からサーバーから完全に形成されたHTMLを受け取りたいだけでなく、クライアント側アプリケーションの速度と柔軟性も必要です。



これを実現するために、Airbnbでは、クライアントとサーバーの両方で実行できるJavaScriptアプリケーションである「同形JavaScriptアプリケーション」を実験しています。



同型アプリケーションは次のようになります。 「クライアントサーバーMVC」というタイトル：







ここでは、アプリケーションロジックまたは表示の一部をサーバーとクライアントの両方で実行できます。 合理化された実行、より良いサポート、デフォルトのCEO、より制御されたWebアプリケーションなど、多くの機能を提供します。



高速で安定したサーバーサイドJavaScriptであるnode.jsを使用すると、この夢を実現することができます。 必要な抽象化を作成したら、サーバーとクライアントの両方で実行されるようにアプリケーションのロジックを記述できます-これは同形JavaScriptです。

野生の同形JavaScript

アイデアは新しいものではありません-Nodejitsuは2011年に同型JavaScript のアーキテクチャを適切に説明しましたが、適応するのは困難でした。 それ以来、いくつかの同型フレームワークが登場しました。



Mojitoは、最初に知られた同形のオープンソースフレームワークでした。 これはnode.jsに基づく高度なフルスタックフレームワークですが、yuiに依存しており、yahooの癖はJavaScriptコミュニティでの特別な人気に貢献していません。2012年4月に公開された瞬間からです。



流星はおそらく今日最も広く知られている同型プロジェクトです。 流星はリアルタイムアプリケーションをサポートするためにゼロから作成され、彼のチームはバッチシステムと展開ツールを中心にエコシステム全体を作成しました。 Mojitoと同様に、これは大きく、自信過剰なnode.jsフレームワークです。 ただし、JavaScriptコミュニティを引き付けるために多くのことが行われており、最も期待されているリリース1.0はすぐそこにあります（2014年の初めにTrans。 流星は、注目を集めるプロジェクトです-スターチーム、Andreessen Horowitzからの資金で1,120万ドル-は、オープンソース製品のリリースに完全に焦点を当てている企業にとっては前代未聞です。



Facebookが共同設立者Dustin Moskowitzと共同で設立したタスク管理アプリケーションであるAsanaには、興味深い同形のストーリーがあります。 モスコビッツは世界最年少の億万長者としての地位にあるため、資金の問題を経験することなく、Asanaは同型JavaScriptの最も先進的な例の1つである独自のクローズドソースLunaフレームワークの開発に長年の研究を費やしました 元々 v8cgi （node.jsに至るまで）で作成されたLunaは、ユーザーセッションごとにサーバー上のアプリケーションのコピーを実行することを許可していました。 各ユーザーに対して個別のサーバープロセスが起動され、クライアントで実行されていた同じJavaScriptコードが実行されました。 これにより、オフラインの安定性や迅速な応答など、高度な最適化のすべての利点が提供されました。



今年は同型ライブラリも作成しました。 それはRendrと呼ばれます 。 また、backbone.js + handlebars.jsの単一ページアプリケーションを作成し、サーバー上のページを完全に形成することもできます。 Rendrは、 Airbnbのモバイルバージョンを再作成してダウンロード速度を向上させた経験の結果です。これは、データ転送の遅延が大きいモバイルユーザーにとって特に重要です。 Rendrは、いくつかの問題を解決するフレームワークというよりもライブラリーです（MojitoやMeteorと比較した場合）が、変更や拡張は簡単です。

抽象化、抽象化、抽象化

これらのプロジェクトはすべて非常に大きく、フルスタックフレームワークがかなり複雑な問題に直面していることを示唆しています。 クライアントとサーバーはまったく異なる環境であるため、アプリケーションロジックを基本実装から分離する特定の抽象化セットを作成して、アプリケーション開発者向けの単一のAPIを作成できるようにする必要があります。

ルーティング

特定のURIパターンを適切なハンドラーにマップする単一のルートセットが必要です。 これらのハンドラーには、HTTPヘッダー、Cookie、URIからの情報、windows.location（ブラウザー内）およびreqおよびres（node.js内）に直接アクセスせずにリダイレクトする機能へのアクセス権が必要です。

データの読み込みと保存

読み込みメカニズムに関係なく、特定のページまたはコンポーネントをレンダリングするために必要なリソースを何らかの方法で記述する必要があります。 リソースの説明は、特定のJSONを指す単純なURIである必要があります。または、大規模なアプリケーションの場合は、リソースをモデルとコレクションにカプセル化し、何らかの方法でURIに変換されるモデルクラスと主キーを定義すると役立つ場合があります。

ページ生成

DOMを手動で変更するか、HTMLテンプレートエンジンを使用するか、DOMから抽象化するコンポーネントのライブラリを使用するかどうかにかかわらず、マークアップを同形で生成できる必要があります。 アプリケーションのニーズに応じて、サーバーとクライアントの両方で任意の表現を生成できる必要があります。

組み立てと包装

同型のアプリケーションコードを書くことは、話の半分にすぎないことがわかります。 gruntやbrowserifyなどのツールは、アプリケーションの構築と実行のプロセスの不可欠な部分です。 アセンブリの場合、通常、クライアントの依存関係を含むテンプレートのコンパイル、変換の適用、縮小などのいくつかの手順を実行する必要があります。 最も単純なケースでは、すべてのアプリケーションコード、プレゼンテーション、およびテンプレートを単一のパッケージに収集する必要がありますが、大規模なアプリケーションでは、数百キロバイトをクライアントに転送する必要が生じる場合があります。 より高度なアプローチは、動的バンチを作成し、ロードを遅延させる機能を提供することですが、この場合、複雑さが急速に増加します。 Esprimaなどの統計コード分析ツールを使用すると、意欲的な開発者が高度な最適化とメタプログラミングを行って、定型コードの量を減らすことができます。

小さなモジュールから組み立てます

最初の同型フレームワークで市場に参入するということは、これらの問題をすべて解決できたことを意味します。 しかし、その結果、巨大なフロッピーフレームワークとなり、既存のアプリケーションに適応して統合することが困難になります。 これらの問題の解決に関与する開発者が増えるにつれて、同型アプリケーションを作成するために組み合わせることができる多数の小さな再利用可能なモジュールにすぐに遭遇します。



明らかに、ほとんどのJavaScriptモジュールは、わずかな変更の有無にかかわらず同形で使用できます。 たとえば、undrscore、バックボーン、ハンドルバー、モーメント、jqueryなどの一般的なライブラリは、サーバーで既に使用できます。



これをすべて実証するために、GitHubから取得できる同形チュートリアルと呼ばれる小さなアプリケーションを作成しました。 それぞれが同形で使用できる複数のモジュールを組み合わせると、100行のコードで小さな同形アプリケーションを作成するのは非常に簡単です。 ここでは、サーバーとブラウザーのルーティング用のディレクター 、HTTPリクエスト用のスーパーエージェント 、テンプレート用のハンドルバーを使用します。これらはすべて、通常のexpress.jsアプリケーションの上に構築されています。 もちろん、アプリケーションの複雑さが増すにつれて、抽象化のレイヤーを追加する必要がありますが、このアプローチをより多くの開発者が実験するほど、より多くの新しいライブラリと標準が登場することを望みます。

周りを見てみましょう

実稼働環境でnode.jsを起動する組織が増えれば増えるほど、クライアントとサーバー間で共有されるコードがますます増えます。 同形JavaScriptは、狭いタスクと広いタスクの両方でローカルに使用できることに注意することが重要です-テンプレートを分離し、表示サブシステム全体を分離し、アプリケーションのビジネスロジックを完全に分離することから始めることができます。 JavaScriptを環境間で分割する具体的な方法は、アプリケーションの作成方法とその機能に完全に依存します。



Nicholas C. Zakas氏は 、彼の意見では、アプリケーションでUIレイヤーがクライアントからサーバーに切り替わり、パフォーマンスの向上とサポートの向上を実現する方法を完全に説明しました。 同形JavaScriptを使用するために、既存のバックエンドを放棄してnode.jsに置き換えて、子を水で跳ね返す必要はありません。 代わりに、正しいAPIを作成し、RESTfulアプローチを使用することにより、従来のバックエンドはnode.jsの隣に静かに住むことができます。



Airbnbでは、gruntやbrowserifyなどのノードベースのツールを使用してクライアント側を作成するプロセスのやり直しをすでに開始しています。 メインのRailsアプリケーションがnode.jsによって完全に置き換えられることはありませんが、それらを一緒に使用すると、JavaScriptの特定の部分を環境間で共有するのがさらに簡単になります。