これらの単語は明確に定義されていないため、言うのは少し難しいです。一般的には、Node.jsをフレームワークと呼ぶのは少し非定型だと思いますが、なぜそうではないのかについて議論するのは難しいでしょう。
これはすべて危険であり、言語の非常に貧弱な使用を頻繁に見るので、私は明確にして下から始めます
JavaScriptはコンピューター言語です。つまり、狭い意味で、一連のテキストを実行セマンティクスを持つものとして読み取り、解釈できるようにする一連の規則です。インタープリター、コンパイラー、トランスパイラー、リンター、蛍光ペンなどと呼ばれるプログラムのクラスはすべて、テキストを取り込んで、コードを実行する方法のこの従来の理解で何かをしようとします。
- 通訳者は、実際にはいくつかのマシン(通常はコンピューター)を操作して実行セマンティクスを実行します。JavaScriptプログラムで書かれた指示に基づいて、「この文字を印刷」のようなスイッチをひっくり返す、コンピューター内部の小さな男と考えることができます。
- コンパイラは、JavaScriptテキストを別の言語の実行セマンティクスを持つ新しいテキストセットに変換しようとします。これは、おそらくコンピューターが直接実行できる特別なプロパティを持つものです。
- トランスパイラーは、JavaScriptテキストを受け取って他の言語のテキストを出力するという点で、コンパイラーの一般化された形式です。したがって、違いは少し主観的ですが、通常、コンパイラは非常に低レベルのコードを出力し、トランスパイラーは高レベルのコードを出力すると考えています。
- リンター、蛍光ペン、型チェッカー、等を実行セマンティクスの影響を受け、それを実際に代表されていないJavaScriptのテキストおよび出力の分析、製品のいくつかの種類のすべてのテイク、ハイライトされたテキストなど、。
それでは、実行セマンティクスについて少し掘り下げてみましょう。一般に、実行セマンティクスには、言語テキストを読み取り、抽象的なマシンの記述または観測可能な副作用の記述に到達するプロセスが含まれます。私が提案したいのは、これらの両方が、マシンを操作するか、観察可能な効果を実行するために、何らかの「低レベルAPI」が必要であると想定していることです。これらは通常、ランタイム環境の一部と見なされます
- ランタイム環境やランタイムは、言語規則を動作させるために存在することが必要であることを前提とプリミティブのセットです。言語に関する限り、それらの振る舞いについていくつかの仮定があるかもしれませんが、それらは観察できません。上記のインタープリターの画像では、「内部の男」はランタイムのスイッチをフリックするだけです。彼は自分が何をしているかを個人的に調べることはできません。
ランタイムという言葉は通常、想定されるプリミティブ自体のセットと実際のインスタンス化の両方を意味するために乱用されます。
だから、今、私たちは毛深いものに到達します。言語は、実行セマンティクスに意味を提供するためにランタイムの存在を前提とする一連の規則です。それらが範囲外であるため、「それらにプローブ」することはありません。
実際に言語を使用するには、ランタイム実装と一緒にコンパイラまたはインタープリタのようなものが必要です。コンパイラ/インタープリターとこのランタイムは、実際にコードを実行する際に密接に関連しています。
- エンジンと呼ばれることも多いChromeのV8は、ECMA標準JavaScript規則で要求されるランタイムインターフェースと互換性のあるインタープリター、コンパイラー、ランタイム実装を含むパッケージ取引です。
では、Node.jsはどこに収まるのでしょうか?
パーツに分割する必要があります。
- Node.js は、 ECMAの標準の範囲外のランタイム環境プリミティブのより大きなセットを提供することにより、JavaScript言語を拡張します。これらには、ファイルI / Oなどが含まれます。これは、Node.js が言語を変更し、ある意味では新しい言語である「Node.js JavaScript」であることを意味します
- Node.jsには、パッケージとして、インタープリターとコンパイラーが含まれています。V8からこれらを盗むだけです。
- Node.jsは、「Node.js JavaScript」を実行できるNode.jsランタイム環境の実装を提供します。
- Node.jsは、「Node.js JavaScript」のエンドユーザーがアクセスしやすくする新しいプリミティブの上に構築された一連の標準ライブラリを提供します。
だからNode.jsはたくさんのものです!
しかし、それはフレームワークですか?
ここで用語が完全にばらばらになります。フレームワークが実際に何であるかについて、良い、一貫した、意味のある定義を誰も持っていません。
「フレームワーク対ライブラリとは何か」という怒りの論争があり、「ライブラリはあなたが呼ぶものであり、フレームワークはあなたを呼ぶもの」のような不満足なもので終わります。そんな悲しい説明を1日の明かりにしたくはありません。しかし、JavaScript、特にNode.js JavaScriptは、コールバックを渡す手法全体が常に呼び出しを切り替えることを意味するため、この定義に大きな打撃を与えますと呼ばれています。
私個人の意見では、ここにはかなりの何かがあります。私は明るい線を描きたくありませんが、だから私は単に言います
- コードのセットは、分割可能でアセンブリ用に作成されたレゴのセットのように機能する場合、ライブラリに似ています。ライブラリの使用方法にはいくつかの例がありますが、一般的に、ユーザーのニーズに合わせてライブラリをアセンブルするのはユーザー自身です。
- コードのセットは分割できない場合はフレームワークに似ており、規則を意味します*:コードの一部を引き離すと多くの仮定が失敗する可能性があるため、フレームワークを適切に使用するには従来の使用法を理解する必要があります。
これは確かに手で揺れる行ですが、フレームワークについて本当に興味深い点を引き出したいと思います。
フレームワークは、コードの解釈方法に関する一連の規則を意味します。したがって、それらはそれ自体が言語です。
これは人々も議論したいことかもしれませんが、言語が単なるテキストのブロックに命を吹き込む一連の規則であるという以前の定義を購入した場合、新しい規則のレイヤーを作成するたびにveは新しい言語を作成しました。おそらくフレームワークでは、原材料は生のテキストファイルではなく、ホスト言語のセマンティックな解釈ですが、考え方は同じです!
以上のことを踏まえて、Node.jsをフレームワークと呼ぶのは、それが標準に少し反するとしても、私はまったく満足です!Node.jsは、言語を拡張する方法で生のJavaScriptに機能を追加します。これにより、この拡張言語で作業するための新しい仮定とツールがもたらされます。機能的には、これらのアイデアはRuby on Railsのような他の広く受け入れられているフレームワークのアイデアと同じです。
この時点で少し気分が悪くなり、Ruby on RailsとNode.jsがこのように大きく隔てられていると主張したいのであれば、もちろんあなたと一緒にいると主張します。2人が住んでいる概念的な世界の種類は劇的に異なります。単に同じ種類のものであると言いたいだけです。特定のドメイン内でベース言語の能力を拡張するための一連の規則です。
また、Node.jsのドメインは小さくタイトであるため、それが追加する規則は推論するのが簡単で、修正するのは比較的簡単であることをお勧めします。OTOH、Ruby on Railsは、複雑で不十分に定義された「ビジネスWebアプリケーション」の領域に住んでいます。つまり、その慣習は曖昧で壊れています。
しかし、これらのことはすべて長い言い方です。ええ、リクルーターは、それを言ったとき、彼らが何を意味するのかおそらくわからないでしょう。「フレームワーク」は、「ランタイム」や「エンジン」よりも、より良い、よりグロッカブルな言葉のように聞こえると思います。