Web 用のコードを記述することは、ファイルに一連の文字を記述し、そのファイルをブラウザーで開き、それが実際に動作するのを観察するという點で、少し魔法のように感じることがあります。しかし、魔法の背後にある技術を理解することは、プログラマーとしての技術をさらに磨くのに役立ちます。

この記事では、ブラウザーを動かしている JavaScript エンジンの複雑さを理解することで、JavaScript を利用した Web スタックやモバイル スタックの舞臺裏で何が起こっているのかを発見します。 JavaScript エンジンの機能、プラットフォームごとに異なるエンジンが使用される理由、それらが長年にわたってどのように進化してきたか、そして開発者としてなぜ気にする必要があるのか??を詳しく見てみましょう。

まず、少し用語について

「JavaScript エンジン」は、仮想マシンの一種と呼ばれることがよくあります。 「仮想マシン」とは、特定のコンピュータ システムのソフトウェア駆動のエミュレーションを指します。仮想マシンには多くの種類があり、実際の物理マシンをどれだけ正確にエミュレートまたは代替できるかによって分類されます。

たとえば、「システム仮想マシン」は、オペレーティング システムを?qū)g行できるプラットフォームの完全なエミュレーションを提供します。 Mac ユーザーは、Mac 上で Windows を?qū)g行できるシステム仮想マシンである Parallels に精通しているかもしれません。

一方、「プロセス仮想マシン」は完全に機能するわけではなく、1 つのプログラムまたはプロセスを?qū)g行できます。 Wine は、Linux マシン上で Windows アプリケーションを?qū)g行できるようにするプロセス仮想マシンですが、Linux ボックス上で Windows OS 全體を提供するわけではありません。

JavaScript エンジンは、JavaScript コードを解釈して実行するために特別に設計された一種のプロセス仮想マシンです。

注: Web ページをレイアウトすることでブラウザーに電力を供給するエンジンと、コードを解釈して実行する下位レベルの JavaScript エンジンを區(qū)別することが重要です。ブラウザの仕組みについては、この記事に詳しい説明があります。

では、JavaScript エンジンとは正確には何ですか?また、何をするのでしょうか?
JavaScript エンジンの基本的な仕事は、結(jié)局のところ、開発者が作成した JavaScript コードを取得し、ブラウザーで解釈したり、アプリケーションに埋め込んだりできる高速で最適化されたコードに変換することです。実際、JavaScriptCore は自らを「最適化仮想マシン」と呼んでいます。

より正確には、各 JavaScript エンジンは ECMAScript のバージョンを?qū)g裝しており、JavaScript はその方言です。 ECMAScript が進化するにつれて、JavaScript エンジンも進化します。これほど多くの異なるエンジンがある理由は、それぞれが異なる Web ブラウザー、ヘッドレス ブラウザー、または Node.js などのランタイムで動作するように設計されているためです。

Web ブラウザーについてはよくご存知だと思いますが、ヘッドレス ブラウザーとは何ですか?グラフィック ユーザー インターフェイスのない Web ブラウザーです。これらは、Web 製品に対して自動テストを?qū)g行するのに役立ちます。 Chrome のバージョン 59 と Firefox のバージョン 56 以降、通常のブラウザをこの方法で、特にテストに使用できるようになりました。 Node.js はこれのどこに當てはまるのでしょうか? Node.js は、サーバー側(cè)で JavaScript を使用できるようにする非同期のイベント駆動型フレームワークです。これらは JavaScript 駆動のツールであるため、JavaScript エンジンを利用しています。

上記の仮想マシンの定義を考慮すると、JavaScript エンジンの唯一の目的は JavaScript コードを読み取ってコンパイルすることであるため、JavaScript エンジンをプロセス仮想マシンと呼ぶのは理にかなっています。だからといって単純なエンジンというわけではありません。たとえば、JavaScriptCore には、JavaScript コードを分析、解釈、最適化、ガベージ コレクションする 6 つの「ビルディング ブロック」があります。

これはどのように作動しますか？

これはエンジンによって異なります。 WebKit の JavaScriptCore と Google の V8 エンジンという 2 つの重要なエンジンについて考えてみましょう。これら 2 つのエンジンはコード処理を異なる方法で処理します。

JavaScriptCore は、スクリプトを解釈して最適化するための一連の手順を?qū)g行します。

字句解析を?qū)g行し、ソースを一連のトークン、または特定された意味を持つ文字列に分解します。

その後、トークンはパーサーによって構(gòu)文が分析され、構(gòu)文ツリーに組み込まれます。

その後、4 つの JIT (ジャスト イン タイム) プロセスが開始され、パーサーによって生成されたバイトコードが分析および実行されます。

簡単に言うと、この JavaScript エンジンはソース コードを取得し、それを文字列に分割し (別名、字句解析)、それらの文字列を取得してコンパイラが理解できるバイトコードに変換して、実行します。

C で書かれた Google の V8 エンジンは、JavaScript ソース コードをコンパイルして実行し、メモリ割り當てを処理し、殘り物をガベージ コレクションします。その設計は、ソース コードをマシン コードに直接コンパイルするコンパイラ パイプラインで構(gòu)成されています。

• Ignition、バイトコードを生成するインタープリタ

• TurboFan、バイトコードをマシンコードにコンパイルする最適化コンパイラー

• SparkPlug、TurboFan を補完するコンパイラ

歴史に興味がある方は、この新しいパイプラインが、V8 で以前に使用されていた古いフル コード生成とクランクシャフト ダブル コンパイラーの設計を置き換えました。

コンパイル プロセスによってマシン コードが生成されると、エンジンは ECMA 標準で指定されたすべてのデータ型、演算子、オブジェクト、関數(shù)をブラウザー、またはそれらを使用する必要があるランタイム (Node.js など) に公開します。 Deno、または Electron (Visual Studio Code で使用されます)。

少し寄り道: ランタイム

JavaScript エンジンがバックグラウンドで靜かに実行され、コードを解析して読み取り可能な文字列に分割し、コンパイラーが読み取ってコンパイルできるようにする場合、ランタイムはより注目を集める傾向があります。それはなぜですか?

よく知られたランタイムは JavaScript エンジン上で動作し、その能力を拡張します。最もよく知られているのは Node ですが、Deno と Bun はこの分野の新參者です。 Node と Deno には V8 が埋め込まれ、Bun には JavaScriptCore が埋め込まれます。

Bun は、JavaScriptCore が V8 より高速であるため、Node や Deno よりも高速に動作すると主張しており、1 秒あたり 69,845 の http リクエストを処理しますが、Node では 16,288、Deno では 12,926 です。

Bun のドキュメントに記載されているように、これらのランタイムの目標は、「世界中の JavaScript のほとんどをブラウザの外で実行し、將來のインフラストラクチャにパフォーマンスと複雑さの強化をもたらし、より優(yōu)れたシンプルなツールを通じて開発者の生産性を向上させることです?！箤g際、これらのランタイムは JavaScript エンジンの能力を活用して、JavaScript をブラウザーの外部で実行します。

NativeScript は、JavaScript を使用して構(gòu)築されたクロスプラットフォームのネイティブ モバイル アプリケーション開発専用に構(gòu)築されたランタイムの良い例です。

これらのランタイムは、JavaScript のシングルスレッド アーキテクチャによって生じる固有の問題の一部を解決するためにも構(gòu)築されています。たとえば、ノードはルーチンの非同期、スレッドレス実行を優(yōu)先します。これらすべてのランタイムは、フェッチ、WebSocket、さらには React 開発者に愛されている JSX などの人気の API の組み込みサポートを含め、厳選された開発者エクスペリエンスを提供します。これが開発者の注目を集める傾向にある理由かもしれません。

ランタイムは、全體的に、標準的なブラウザー アーキテクチャとそれを駆動するエンジンのパフォーマンスにおける認識されているギャップに対処します。エンジンが進化するにつれて、これらのランタイムも進化します。

どのような JavaScript エンジンがあるのでしょうか?

クライアント側(cè)コードの分析、解析、実行に使用できる JavaScript エンジンは多種多様です。ブラウザのバージョンがリリースされるたびに、最新の JavaScript コード実行に対応するために JavaScript エンジンが変更または最適化される場合があります。

これらのエンジンに付けられた名前に完全に混亂する前に、これらのエンジンとその基盤となるブラウザには多くのマーケティング活動が行われていることを覚えておくと役立ちます。 JavaScript のコンパイルに関するこの有益な分析の中で、著者は皮肉めいて次のように述べています。「ご存じない方のために言っておきますが、コンパイラの約 37% はマーケティングで構(gòu)成されており、マーケティングの観點から言えば、リブランディングはコンパイラに対してできる數(shù)少ないことの 1 つです。したがって、列車の名前は次のとおりです: SquirrelFish、Nitro、SFX..."

これらのエンジンの名前付けと名前変更に関する栄枯盛衰を念頭に置きながら、JavaScript エンジンの歴史におけるいくつかの主要な出來事に注目すると役に立ちます。便利な表を作成しました:

*JavaScriptCore は SquirrelFish として書き直され、Nitro とも呼ばれる SquirrelFish Extreme としてブランド変更されました。ただし、JavaScriptCore を WebKit 実裝 (Safari など) の基礎となる JavaScript エンジンと呼ぶのは依然として正しいです。

**Edge は當初、Chakra エンジンを使用していましたが、その一部は Microsoft がオープンソースでした。その後、Edge は、Blink および V8 JavaScript エンジンを內(nèi)部に備えた Chromium ブラウザとして再構(gòu)築されました。

なぜ気にする必要があるのでしょうか？

JavaScript エンジンのコード解析および実行プロセスの目標は、可能な限り最短の時間で最も最適化されたコードを生成することです。
要するに、これらのエンジンの進化は、Web 環(huán)境とモバイル環(huán)境を進化させて可能な限りパフォーマンスを向上させるという私たちの探求と並行しています。この進化を追跡するには、arewefastyet.com で作成されたものなどのベンチマーク グラフでさまざまなエンジンのパフォーマンスを確認できます。

Web 開発者は、作成、デバッグ、保守に熱心に取り組んでいるコードを表示するブラウザーに固有の違いを認識する必要があります。特定のスクリプトが、あるブラウザでは動作が遅いのに、別のブラウザではより速く動作するのはなぜですか?

同様に、モバイル開発者、特に Web ビューを使用してコンテンツを表示するハイブリッド モバイル アプリを作成する開発者は、どのエンジンが JavaScript コードを解釈しているかを知りたいと思うでしょう。ユーザー エクスペリエンスを重視するすべての Web 開発者は、小型デバイス上のさまざまなブラウザーに固有の制限と、それによって提供される可能性を理解する必要があります。
の変化を追い続ける JavaScript エンジンは、Web、モバイル、またはアプリの開発者として進化するにつれて、有意義な時間を費やすことになります。

この記事はもともと 2015 年に Telerik Developer Network に掲載され、その後 2022 年以降に向けて改訂および更新されています。元の記事は、Wikipedia の JavaScript Engine エントリで引用されています。
?

以上がJavaScript エンジンとは何ですか?の詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。