JavaScriptは中年期に入ったのか? 高速化の裏で進む「見えないブラックボックス化」

The JavaScript Midlife Crisis

JavaScriptは中年期に入ったのか? 高速化の裏で進む「見えないブラックボックス化」

JavaScriptのツールチェーンはRustやGoなどによる書き換えで高速化が進む一方、その内部はブラックボックス化し、メンテナンスできる開発者の層が狭まっている。JavaScriptはどこでも動く万能言語として成功したが、その成功ゆえに自らのエコシステムから締め出されつつある。この変化は単なる速度向上ではなく、トレードオフであると著者は指摘する。

JavaScriptで書かれたツールがJavaScriptのツールとして当然の選択というより、負け戦のように見え始める。
  1. Klonoar

    > バンドラーをRustで書き直せば、速くなるだけじゃない。メンテナンスできるJavaScript開発者のプールも縮小する。新しいツールは見た目も鳴き声もアヒルのままだが、中身はまったく別の獣だ。その内部は、ごく一部の人しか鍵を持たないブラックボックスへと退避する。ソースはオープンのままだろうが、コントリビューションへの扉は閉じつつある。

    別の見方をすれば、そもそも重要なインフラをメンテナンスすべきではないJS開発者のプールだっている。

    それはブラックボックスじゃない。そういうコードベースはたいていオープンで、あなたや誰かを妨げている唯一のものは、JavaScriptという小さな池の外にある何かを学ぶことだけだ。

    ブラウザ以外のものは高速な言語で書け。複雑な概念ではない——何かがあなたのために書かれる時代においては、なおさらだ。

  2. agentultra

    遅くて大量の余分なメモリを使うプログラムを待つこともできるよ、もちろん。

    あるいは、メモリを効率的に使う高速なプログラムを持つこともできる。

    ただ、JavaScriptではそれができないだけだ。注意深いエンジニアリングをすればJavaScriptでもかなりのパフォーマンスは出せる……が、JITコンパイルやトレーシングGCをすべて使っても、収穫逓減の大きな壁がある。

    同じJS開発者たちがZigやRustその他を学ぶことを妨げるものは何もない。JavaScriptの暗黙の型変換ルールをすべて暗記するより、むしろ学ぶのは簡単かもしれない。

    でも、それが高望みすぎるなら、JSの世界に留まって、ツールを書いてくれるJS開発者がいることを確実にしておけ!

  3. cisc

    > 与えられた貴重なミリ秒をいったい何に使えばいいのか、と考え始めてしまう

    速度は重要だ。WebAssemblyがJavaScriptから仕事を奪っているのは、まさに速いからだ。

    Google Sheetsの計算エンジンは、WebAssemblyへの移行で2倍速くなった:https://web.dev/case-studies/google-sheets-wasmgc

    Amazon Prime Videoアプリは、WebAssemblyに切り替えたとき、パフォーマンスのばらつきも少なくなり、2倍速くなった:https://www.amazon.science/blog/how-prime-video-updates-its-...

    WebAssemblyにコンパイルすることで、あらゆる言語がブラウザで動くようになる。GoogleはJavaを、AmazonはRustを使った。

  4. msteffen

    異端の議論:JavaScriptがこれほど成功した大きな理由の一つは、インタプリタ言語が実際には極めて高速になり得るからだ——コンパイル言語と競合し、多くの場合それより速いことさえある。V8はおそらく現存する最速のインタプリタだ。

    LuaJITの作者Mike Pallによるこの投稿を見てほしい(LuaJITは基本的に一人の開発者によるプロジェクトでありながら、パフォーマンス的にはV8に匹敵するかそれ以上だ)。そこでは理由が説明されている:https://web.archive.org/web/20180603053407/http://article.gm.... 要するに、JITインタプリタに高品質なランタイムトレース対応の再コンパイルを追加する方がずっと簡単で、トレース対応でないコンパイル言語はしばしばそれを打ち負かせないのだ。

  5. nzoschke

    > Rust、Go、ZigがJavaScriptツールチェーンのますます大きな部分を占めつつある……

    JavaScriptアプリケーションの領域でも同じだ。

    言語の一貫性、人間工学、標準ライブラリ、パフォーマンスは重要で、JSにはここに大きな欠点がある。これらの言語がJSのように30年以上経ったとき、ソフトウェアの風景がこれほどJSに支配されていることはないだろう。

    最近では、すべてのプロジェクトを意図的にできるだけJSを少なく始め、代わりにGoとHTMXを選んでいる。JSの一貫性のなさとビルドツールの層を取り除くことで、自分と自分のエージェントの生活が良くなる。

    JSを使わないスタックについてのさらなる考えはこちら:https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

この日のほかの記事

2026-09-22