JavaScriptは2つの言語に分割すべきか？

 (devclass.com)
9 ポイント 投稿者 GN⁺ 2024-10-28 | 4件のコメント | WhatsAppで共有
  • Googleのエンジニアが、公式標準化委員会に対してJavaScriptを2つの言語に分割する提案を発表
    • ランタイムエンジンで実装されるコアと、それをコンパイルするツールに依存する、より多くの機能を持つ派生形に分割することを提案
  • 発表は今月初めの Ecma TC39 会議で行われた
    • TC39 は、JavaScript（正式には ECMAScript）仕様を発展させる Ecma International の委員会
  • Google の Shu-yu Guo が発表を行い、Mozilla、Apple、Moddable、Sony の共同著者とともにスライドを作成
    • Shu-yu は JIT、VM、コンパイラ、標準化の専門家
  • 著者らの主張
    • 言語の新機能はほぼ常にセキュリティを悪化させ、性能には中立または悪影響を与える
    • 安定性も時に悪化し、アプリの機能が向上するのは開発者が新機能を使う場合に限られる
    • JavaScript VM（仮想マシン）は速度への圧力によりすでに非常に複雑化しており、これはセキュリティを損なう。さらに新機能が採用されない場合には特に割に合わなく見える
    • セキュリティ欠陥とランタイムの「複雑性コスト」は数十億回の利用に影響する一方で、その恩恵は実際にこの複雑さを活用する開発者やアプリケーションに限られるため、JavaScript の基盤技術はシンプルであるべきだということ
  • 複数の組織が参加しているものの、このイニシアチブはある程度 Google 主導に見える
    • スライドの1枚には「この可能な解決策は Google が好む解決策であり、必ずしも他の実装者の解決策ではない」という免責事項が含まれている
  • 提案された解決策
    • 既存機能を巻き戻すのではなく、今後は大半の新機能をエンジンではなくツールで実装する方向にアプローチを変更すること
    • エンジンで実装される言語を「JS0」、ツールで実装される言語を「JSSugar」と呼ぶ
    • 多くの開発者が実際には TypeScript でコーディングし、Babel、Webpack、TypeScript コンパイラのようなコンパイラに依存しているため、JavaScript に特に適した考え方だとしている
    • 採用された場合、将来の構文機能は JSSugar に入り、API と機能面の機能だけが JS0 に入る
    • 互換エンジンは JS0 のみをサポートすればよい
    • JSSugar をサポートするための負担はツール実装者へ移る
      • 副作用として、ツール実装者が標準プロセスにより深く関与する必要があり、新しい技術グループの結成が必要になる可能性もある
  • この提案はすでに論争を呼んでいる
    • JavaScript ツールに公式な地位を与えるべきではないと求める開発者もおり、多くの JavaScript 開発者はこうしたツールへの依存を減らしたいと考えている
    • セキュリティ、性能、安定性を優先することについては広範な合意があるが、JavaScript を中間ツール依存にするという発想は不人気
    • ある開発者は「RIP Vanilla JS」とも述べている

GN⁺の見解

  • この提案は JavaScript 開発エコシステムに大きな変化をもたらす可能性がある。開発者が新しい構文機能を使うためにコンパイラへさらに依存しなければならない点には懸念がある
  • しかし、ランタイムエンジンの複雑性を減らし、セキュリティと性能を改善しようとする目標自体は前向きだ。長期的には JavaScript の発展に役立つ可能性がある
  • 類似のアプローチを取る他の言語としては Dart がある。Dart は開発者に優しい構文を提供しつつ、JavaScript にコンパイルされてブラウザで実行される
  • この提案を採用する際には、既存コードとの互換性、開発者体験、ツールサポートなど、さまざまな要因を慎重に考慮する必要がある。また、コミュニティの意見を十分に取り入れるプロセスも必要になるだろう
  • JavaScript は Web 開発の基盤となる言語であるだけに、今後も活発な議論と発展が続くと見られる

関連記事

4件のコメント

 
kandk 2024-10-29

レイヤーをもう1つ追加して、そのレイヤーにDXに役立つ内容を加えようとしているようですね。
 
savvykang 2024-10-29

多くのJavaScript開発者は、このようなツールへの依存を減らしたいと考えている
JavaScriptを中間ツールに依存させるという発想は人気がない

今やJSXだけを見ても、トランスパイルが必要になるようにエコシステムが構築されているのに、現実味のない意見だと思います。NodeJSがすべてだと考えているようです。
 
aer0700 2024-10-29

正確に理解できているかは分かりませんが、C++にBOOSTというものがありますよね、それに近い感じですね。Googleの提案が受け入れられて、JSSugarに既存のライブラリ群を統合するとしたら、何が入ることになるのでしょうか？ Babelですか？
 
GN⁺ 2024-10-28
Hacker Newsの意見

  • JavaのHotspot VMは他の言語にも大きな成功をもたらした。JavaScriptも同様にコア言語を目指し、糖衣構文を事前コンパイルするのが理にかなっている

    • JavaScriptは2つの言語に分かれる。インターネットのアセンブリ言語としてのJavaScriptと、フロントエンドWeb開発言語としてのJavaScript
    • 新しい言語機能は、既存ランタイムで十分にサポートされ最適化された部分へトランスパイルするのがよい。トランスパイルは必要だが、これはモダンなビルドツールを使うのと同じこと

  • WebAssemblyに集中するほうがよい。JavaScriptはスクリプティングに使い、他の言語はより大きなアプリケーションに使うべき

  • VanillaJSを好む立場として、強制的に変えられていく言語機能には不満がある。APIの改善に集中し、Webアプリがネイティブアプリと同等になるようにすべき

  • BigIntにユースケースがないという主張には反対。Googleのフロントエンド開発者が使っていなくても、他のJS開発者は使っている。言語の進化に注力すべき

  • JavaScriptとWasmは分離しておくべきだった。代わりにWasmをWeb APIにアクセスできない二級市民にしてしまった

  • 提案された解決策は根本的な問題を解決せず、ツール依存を強めるだけ。JavaScriptは性能と複雑さを減らすため、新しい言語へ移行すべき

  • TC39と開発者コミュニティの分断が原因で問題が生じている。TypeScriptのツールは標準化されておらず、Rustへ移植する計画もない

  • GoogleのV8エンジンの保守問題を理由にJavaScriptの変更が提案されている。セキュリティ問題と複雑性のコストがユーザーに影響している。C++の代わりに別の言語を試すべき