ライブラリが進化し、プログラミングが容易になっているように見えるため、Javaが全盛期に使用されていたであろう多くのことにJSを使用しているようです。
とはいえ、私たちが認識しているJSには多くのパフォーマンスの問題があり、そのうちの1つは、スレッドを使用してランタイムを最適化する機能です。
私はこれを見ました：なぜJavaScriptはマルチスレッドをサポートしないのですか？、しかしそれは3-4年前に答えられました（そして3-4は言うまでもなく、1年で多くの変化があります）。HTML5が急速に成長しているので、これがもっと考慮されているかどうか、私はさらに興味があります。
ECMA TC39、彼らはECMAScriptを所有しています。
しかし、簡単な答えはノーです。「新しいスレッドを生成」したい長時間実行スクリプトがある場合は、 WebWorkersをチェックする必要があります。これらのスクリプトは、独自のコンテキストで、技術的には別のスレッドで実行されます。
時間が経つにつれて、WebWorker ができることと、メインの JavaScript スレッドと通信する方法が拡張されると思います。今日では非常に制限されていますが、メインの JavaScript スレッドをシングル スレッドにすることによる安定性とシンプルさを危険にさらすことなく、より強力にする方法があります。
たとえば、現在、WebWorker で画像を読み込んだり、グラフィックを準備したりすることはできませんが、グラフィックを多用するアプリケーションでは非常に便利です。計算はできますが、制限があります。
たとえば、バックグラウンド プロセスでアニメーションの DOM オブジェクトを操作することはできません。これも非常に便利です - ブラウザエンジンが実装するのはもっと複雑だと思いました。
JS がマルチスレッドをサポートしない (おそらくサポートしない) 理由は、特にブラウザーで JS が行う種類の作業に適していないためです。並行スレッドは、CPU バウンドの作業が多く、ロックなどの代償を気にしない場合に便利です。しかし、ブラウザー JS は、CPU バウンドの作業をまったく行わない、または行うべきではありません。これはイベント駆動型の環境であるため、JS に必要なスレッドは 1 つだけです。作業ブロックごとにブラウザに制御を渡し、次のイベント (タイマー、クリック、onLoad など) を待機します。同時実行性は、すべてのイベント ハンドラーを管理する労力を大幅に増加させますが、パフォーマンスはそれほど向上しません。すべてのスレッドが同じイベントを待機することになり、非常に多くのイベントが発生しない限り、パフォーマンスを維持するのに十分な作業はありません。スレッドがビジーです。
Slace が上で述べたように、WebWorker は、ブラウザー JS で CPU バウンドの作業を実行したいという奇妙なケースに対応することを目的としていますが、真のマルチスレッドではありません。