Developer Softのソフトウェアエンジニアで、 Netologyコースの教師であるVladislav Vlasovは、ブログ専用のEcmaScript6に関する一連の記事を執筆しました。 前半では 、例ではIroh.jsを使用してEcmaScriptでの動的コード分析を検討し、 後半ではキャンセルされたPromiseの実装に焦点を当てました。 この記事では、ES6モジュールの歴史について説明します。







EcmaScript言語の歴史は、ブラウザーの単純なスクリプト言語から、さまざまなホスト環境で動作する最新の汎用言語にまで及びます。 言語の複雑さとともに、モジュール構造を整理し、ライブラリに配置してコードを再利用する必要性が生じました。 最初のライブラリは、対応するJSファイルをプロバイダーのホストまたはCDNから読み込むことによってインポートされ、相互作用は、原則として、既知の名前を持つ関数とクラスをグローバルスペース（ウィンドウオブジェクト）にエクスポートすることによって実行されました。



このスキームは長い間使用されており、単純なケースでは非常にうまく機能します。

困難は、ライブラリが多すぎてライブラリ間の関係が始まったときに始まります。

まず、グローバルホストオブジェクトが詰まっており、接続されているすべてのライブラリは、競合しない一意の名前をインポートする必要があります。 第二に、ライブラリ間の相互運用性と再利用を保証する明示的な方法はありません。



ネストされた依存関係の問題は、DOMモデルのdynamic <script> injection



を使用して解決でき、グローバルホストオブジェクトの既知の名前でエクスポートすることで再利用できますが、これは普遍的なソリューションではなく、ライブラリ作成者間の暗黙的な合意に基づいて構築され、クライアントスクリプト。 部分的に、 query string



でパラメーターをCDNサーバーに渡し、ロードされたJSライブラリの名前空間を指定することで名前解決を解決しますが、これも普遍的ではありません。



非同期の読み込みとDOMモデルとの相互作用に関連するいくつかの基本的な問題が残っています。 後者が前者に依存している場合、一部のライブラリは他のライブラリより先にロードする必要があります。 動的インポートの場合、これには、ベンダーとブラウザのバージョンに応じて、非同期フラグの正しい設定またはreadystatechanged



イベントの操作が必要です。



もちろん、この一般的な場合には、記事で説明されている解決策があります 。 ただし、まず、ダウンロード可能なすべてのライブラリの依存関係を慎重に監視する必要があります。次に、一部のライブラリがDOMの状態とイベントの追跡を必要とするpolyfills



ある場合、 defer fallfack



の場合、これは機能しません。



上記の問題の普遍的な解決策として、JS用のライブラリモジュールを整理するためのいくつかの標準が開発されました。最も有名なものは、 AMD （非同期モジュール定義）、 UMD （ユニバーサルモジュール定義）、およびCommonJSです。 共通の宣言形式のモジュールに従う著者と共通のファイルローダーの存在により、ほとんどの問題は解決されました。



一方、Node.JSプラットフォームは活発に開発されており、モジュールの依存関係は完全に異なる方法で解決されました-同期require-callによって、モジュールは対応する特定の形式を持ちました。 その後、技術委員会TC-39は、モジュールをインポートする普遍的な手段の開発を開始しました。これは、上記のすべての問題を解決し、同時にサーバーとクライアントで同じように動作し、モジュールロードの同期および非同期のセマンティクスを提供することになっています。 このツールはES6-モジュールになりました。

トランスパイルおよびバンドルビルダーによるES6モジュールのサポート

Ecmascript 262バージョン6仕様とその後のエディションの出現により、多くの新しい構文構造とネイティブ関数が言語に追加されました。 原則として、それらのほとんどは、構文構築のための予備的なトランスパイル、および欠落している機能のためのポリフィルの追加により、古いバージョンのJSエンジンで簡単に起動できます。



ES6-モジュールは、ロードの同期ノンブロッキングセマンティクス、エクスポート/インポートされたエンティティのバインディングバインディング、モジュラースコープ、および通常のトランスパイルで提供するのが容易ではない他の側面を提供しました。



開発者は、現在のEcmascriptダイアレクト6、7、8以降でWebアプリケーションを作成したいと考えていたため、比較的古いブラウザーで動作するために、transpile-inaを実行し、アプリケーションに適切なpolyfills



を自動的に追加する利便性が必要でした問題ありません。



これらの問題に対するtranspilers



解決策は、プラグインtranspilers



とpolyfills



でカスタマイズ可能なbundle builder



polyfills



。 アイデアは、アプリケーションコードが参照ダイアレクトに変換されることです。これは、タスクに応じて、現在のすべてのブラウザー（たとえば、ES3またはES5）でサポートされていると見なされます。 その後、すべてのライブラリモジュールとアプリケーションコードファイルは、1つの大きなファイル、いわゆるバンドルに結合されます。 このファイルはクライアントに送信され、同期または非同期のインポートは必要ありません。必要なコードはすべてbundle



おり、コード番号でアクセスできるためです。



対応するアプローチを実装する有名なソリューション： BrowserifyとWebpack 。後者は現在の事実上の標準です。 事実上のトランスポーターはバベルです。 提案されたスキームには多くの利点があります。



まず、スキームにトランスパイラーが存在するため、ソースプロジェクトは実際に任意の言語で記述できます。 通常、これは最新バージョンのEcmaScriptまたはTypeScriptですが、構文を拡張する可能性はほとんど無限です。 ESの有名な拡張機能の1つは、Reactライブラリとその派生物で使用されるJSXです。



第二に、トランスパイルフェーズでのコード変換の制御により、 ES6プロキシやリフレクション情報などの機能でさえコードのサポートを実装することが可能です 。



コードバンドリングを使用すると、 F＃やOcamlなどでクライアントコードを作成できるという興味深い結果が得られます。



明らかな利点に加えて、バンドルされたソリューションにはいくつかの明らかな欠点があります。



まず、結果のbundle



、圧縮の可能性を考慮しても、ボリュームがかなり大きく、モバイルトラフィックで顕著になります。 第二に、 bundle



は、ユーザーが必要とするWebアプリケーションの要素を使用しない場合でも、ユーザーのブラウザーでロードおよび解釈されるWebアプリケーションのすべての依存関係が絶対に含まれます。 第三に、 bundle



完全に関連するか、完全な更新が必要なため、ライブラリの依存関係をキャッシュする可能性がなくなります。



負の効果は、アプリケーションの開発とデバッグに現れます。 バンドルはほぼ常にtranspile



に関連付けられているため、特に大規模なプロジェクトの場合、新しいbundle



を取得するプロセスには時間がかかる場合があります。 これは、開発およびデバッグプロセス中に、次の変更を行った後、 bundle



を再構築し、その新しいバージョンをクライアントにダウンロードする必要があることを意味します。 さらに、ソースコードのマシン変換により、ほとんど読めなくなり、ブラウザーでデバッガーを使用するのが困難になります。



もちろん、上記の問題のほとんどには独自の解決策があります。 実稼働モードでアプリケーションコード全体をブラウザにロードしないために、webpackテクノロジーはコードチャンク分割を使用します 。 インポートの動的バージョンを使用することもできます。これは、Promiseを返し、ターゲットモジュールの非同期ロードを提供します。



デバッグ用のソリューションもあります。 元のソースコードを表示し、さらにブラウザーデバッガーでナビゲートすることも、デザインモードのターゲットbundle



に実装されたsource maps



の仕様を通じて実現されます。 完全なリブートbundle



なしの部分的なアップグレードは、Hot Module Reloadを使用して解決されますが、真の増分アップグレードは単純な場合にのみ正しく機能します。

ES6モジュールのネイティブサポート

依存関係のバンドルを使用したスキームは、その時代に関連していましたが、現在、すべての最新のブラウザーはES6モジュールをネイティブにサポートしています。





これには、ブラウザーの不完全さと必要な機能の不足のためにbundle



が必要だったため、最新のWebアプリケーションのアセンブリに関するビューの改訂が必要です。 外観後、ネイティブデザインを使用すると、はるかに優れた結果が得られます。



第一に、構文構造の過度のtranspile



と、コードのエミュレートによる置換は、最適化のtranspile



低下と困難につながります。 これは、非同期およびジェネレーター関数に適用され、 リジェネレータランタイムに置き換えられ、レキシカル変数let



/ const



最適でないvar-declarationに変換されます。



もちろん、これはES6モジュール自体に直接関係するものではありませんが、通常はアセンブリとアプリケーションクライアントへの配信によって決定されます。 この意味で、これらは相互接続されたものです。



第二に、モジュールはパフォーマンスの点で効率的です。 ES6モジュールは、デフォルトで遅延モードでロードおよび実行されます。 つまり、誤ってブロッキングモジュールをWebアプリケーションに追加することは不可能であるため、すぐに使用できるSPOFの問題はありません。



ES6モジュールをサポートしていない古いブラウザーで操作性を維持するために、 bundle



して古いエージェントに提供することができます。 同時に、ES6モジュールのインポートの設計機能により、ブラウザー行のユーザーエージェントまたは機能検出ツールに応じて、提供されたコードの分離で条件付きでwebpackを構成する必要はありません。



区別するには、次のコードで十分です。

 <html> <head> <script src="app/index.js" type="module"></script> <script src="dist/bundle.js" defer nomodule></script> </head> <!-- … --> </html>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ES6モジュールをサポートしないブラウザーは、単にdist / bundle.jsをロードし、古いスキームに従って動作します。 最新のブラウザはapp / index.jsをエントリポイントとして使用し、依存リソースを自動的にロードします。



上記のスキーム、モジュールの非同期および遅延ロード、依存関係キャッシュ、インラインモジュール、およびそれらのCORSポリシーのためにwebpackを効率的に構成する問題については、「 ES6モジュールがブラウザーのランドをサポート：バンドルを再考する時ですか？」 「および」 ブラウザのECMAScriptモジュール 」。

まとめ

EcmaScriptは長い道のりを歩んでおり、今日まで進化を続けています。 多くのソリューションはその時代に関連しており、クライアントエージェントにまだ組み込まれていない機能のプロアクティブなサポートなど、問題の解決を可能にしました。 現在、ブラウザーとNode.jsサーバーはバージョン更新を頻繁にリリースし、最新のEcmaScript機能を追加しています。



その結果、過去に一般的なバージョンのブラウザの新機能のサポートをエミュレートできるソリューションは、旧式のエージェントに適用できます。タスクによっては、個別に保守するか完全に除外するのが理にかなっています。



モジュールの事前認証とリンク、およびその後のバンドルは、最近までほとんどのブラウザーでES6モジュールをサポートする主な方法でしたが、現在ではそれらに悪影響を及ぼし、最適化ツールとキャッシュツールを妨げています。



したがって、Webアプリケーションのアセンブリを設定する際には、構文要素やモジュールのインポート/エクスポートなど、最新のエージェントに最新のEcmaScriptコードを提供することをお勧めします。

編集者から

トピックに関するNetologyコース：

• 職業「 フロントエンド開発者 」。
  
  
• 職業「 ウェブ開発者 」。
  
  
• JavaScriptベーシックコースオンラインプログラム。
  
  
• オンラインプログラム「 Node、AngularJS、MongoDB：本格的なWebアプリケーションの開発 」;
  
  
• オンラインプログラム「 ブラウザのJavaScript：インタラクティブなWebページの作成 」