異なる環境のためのECMAScript（オペレーティング・プラットフォーム）、非常に異なる設計構造、アイデア、使用。
1、ブラウザ：DOM BOM
2、NodeJS：FSは、HTTP内蔵モジュールと、サードパーティのモジュール、内蔵モジュール
3、デスクトップアプリケーションと他のプラットフォーム：ウィンドウMacと他のオペレーティングシステムプラットフォーム
、CommonJSは、原点を規範
JavaScriptはブラウザでサービスから生まれた言語です。
JS APIのパフォーマンスはホスト環境の能力に依存します
1、web1.0時代：W3Cは、ブラウザのサポートを提供
2、Web2.0の時代は：HTML5の発展に伴い、より標準的なAPIがブラウザに表示されます。しかし、JS規格のバックエンド手つかず
図3は、2009年1月に、とき、ケビンDangoorは、この記事を書いたhttps://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/ ServerJS仕様にノミネートし、。2009年8月には、CommonJSに社名を変更しました。
広いユーティリティを表示するためのAPI
---- =>記事が始まりました----
サーバサイドJavaScriptが何を必要とします
2009年1月29日14:00 * 816 * 4分で単語を読み取ります
サーバサイドJavaScriptの技術が出回っている、非常に長い時間。Netscapeは、サーバーサイドJavaScriptでのサーバソフトウェアで1996早期の提供、および Helma 長年にわたってそこに。しかし、大量のサーバー側の開発は、過去数年間に発生しています。
AptanaのJaxerのは、ライン（クライアントおよびサーバー）の両端にJavaScriptランタイム環境を使用する方法について説明し、革新的なビューを提供します。クライアントと簡単にコードを共有する機能とサーバの間に非常に便利なコミュニケーションは、サーバー上のJavaScriptの大きな利点を実行しています。
JaxerのとHelmaは確かに興味深いプロジェクト、である（そして他の多くのアイテム！）。しかし、私は、サーバー上で見た興味深いプロジェクトの欠如が、有用ではありませんJavaScriptの生態系。Pythonで働く人々は、破片やその他もろもろのWebフレームワークについてお話したいが、JavaScriptの破片と比較して、これは何もありません。
たとえば、JavaScriptがする必要がある標準ライブラリのインタプリタを渡ります。ありがたいことに、（ブラウザ部から継承された）いくつかの標準的なライブラリがあります。だから、正規表現や日付を取得します。しかし、ファイルやディレクトリ、それ？なぜにサイ、SpiderMonkeyの、V8とJSCoreで同じAPIを使用していませんか？
少数の標準インターフェース。データベースに接続し、クエリが十分に理解し、共通の問題である実行します。Rhinoで、あなたは、JDBCを使用することができます。しかし、JavaScriptは本当に、そのようなPythonのよう、独自のクロス通訳規格、持っている必要があり DBAPIを。それはまた、SpiderMonkeyのモジュールWebアプリケーションの背後に、次に通るアパッチの初期展開に用いることができる標準のWebサーバ/ Webアプリケーション・インターフェース桟橋の背後に配置されています。
JavaScriptを必要とされているのである他のモジュールを含めるための標準的な方法、およびこれらのモジュールは、慎重な名前空間として存在することができます。名前空間を行うには非常にシンプルな方法がありますが、モジュールをロードするためのプログラミングの標準的な方法はありません（一度は！）。サーバー側のアプリケーションは、多くのコードを含むことができ、これらの標準インタフェースの一部と混合し、ラインに一致させることができるので、これは、重要です。
私たちはする方法必要な展開のためのコードをパッケージ化して配布し、さらにインストールパッケージを。Linuxの人々は当然、彼らは唯一の「aptの取得」（またはYUM、またはその他）を入力することができますことを指摘し、自分の仕事が行われます。しかし、多くの人が、MacとWindowsの両方を使用して、開発環境を設定するための便利な方法を必要とし、彼らが展開する際に使用し、他の人が書いたコードをパッケージ化があります。
問題の一部は、配布とインストールされたパッケージリポジトリ。私は知りません JSANを答えがあれば、私はインストールパッケージを知っているし、その依存関係のための簡単な方法その用途は非常に異なっている中で、人々の数は、ライブラリを要約することができます。
また、すべてのこれらの利点に加えて、我々はそうでテンプレートエンジン、オブジェクトリレーショナルマッパー、ミドルウェア、パッケージアプリケーションを取得します。実際、その多くはすでに存在しています。しかし、問題は、彼らが共通の基盤を持っていないです。これは、エコシステムの開発を阻止するための理由です。
あなたは、PythonパッケージインデックスWSGI（WebアプリケーションとWebサーバー接続のための標準のPython）を検索する場合は、180のパッケージを見つけるだろう...サーバ、ミドルウェア、アプリケーション全体今日。そして、これらは単にのパッケージ「WSGI」のリストに含まれています。これは生態系の方法です。Rubyは、JavaScriptがものを必要としているJavaは、あります。
原因、共通の標準ライブラリを使用することに、多くのWSGIコンポーネントはCPythonと、JythonのとIronPythonの中で変わらないことができ、ことは注目に値します。JavaScriptは、このようないくつかの契約のようにC及びJavaと.NET実装、のみ特定のインターフェイスで一連を達成しました。図書館はより多くのユーザーを引き付けることができ、これらすべての場所で実行し、より多くの提出者は、ライブラリの開発を支援することを願っています。
私はここで説明する技術的な問題ではありません。これは一緒に人々であると先に行くと大きな、より低温の質問物事の構築を開始することを決定しました。
この目的を達成するために、私は新しい作成ServerJSチームを利害関係者が通信するようにする、とさえ私たちは一緒にいくつかのコードを作る直面し、いくつかのインターフェイスの問題を解決するために直面することができます。JavaScriptコードのコレクションの多くがあった、我々はすべてのコードがより多くの貴重な作ることができるかどうかを見てみましょう。
MozillaのWeb開発ツール群では、我々は、ソフトウェア開発者がオープンなWebを最大限に活用することができ、広いオープン憲章を持っています。コミュニティが成長し、サーバーサイドJavaScriptはもちろん、それの一部にすることができ繁栄を支援するためにあらゆる努力をします。
（誰かが「なぜ、ただのRuby / Pythonの/のJava / C＃のを使わないのでしょうか？」、と言う前に、私はちょうど私がこの記事では、この問題に対処しません、これは全く別の問題であることを言いたいです。）
アップデート：グループが今と呼ばれているCommonJS 。
---- =>記事のエンディング----