JS/TS とか Web の標準について学んだり
Web 標準と、その限界 by nakasyou
HTML, CSS, JavaScriptの標準の仕様書はどこにあるのか
なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待 | blog.jxck.io
Web 標準 #とは
ウェブ標準モデル - ウェブ開発の学習 | MDN
ウェブ標準は、私たちがウェブサイトを構築するために使用する技術です。これらの標準は、仕様書と呼ばれる長い技術文書として存在し、この技術がどのように動作すべきかを詳細に記述しています。これらの文書は、記述されている技術をどのように使用するかを学ぶにはとても役に立ちません（MDN Web Docs のようなサイトがあるのはこのためです）。その代わりに、ソフトウェア技術者がこれらの技術を（通常はウェブブラウザーで）実装するために使用するよう意図されています。
どのブラウザでも同じ結果が得られるように HTML / CSS / JavaScript をまとめる仕様
HTML -> WHATWG が HTML Living Standard を管理
JavaScript -> Ecma International の傘下の TC39 が ECMAScript(ECMA-262) を管理
CSS -> W3C 傘下の CSS WG が仕様を策定(1 つの仕様ではなく多数のモジュール( c.f. CSS Snapshot))
DOM(!) -> WHATWG が DOM Living Standard を管理
URL -> WHATWG が URL Living Standard を管理
アクセシビリティ -> W3C が WCAG, WAI-ARIA を管理
WebAssembly -> W3C 下の WebAssemby W3C が WebAssemby Spec を管理
WebGL -> The Khronos Group が WebGL Specification を管理
WebGPU -> W3C 傘下の GPU for the Web WG が WebGPU Spec を策定(The Khronos Group の Vulkan 等の影響を受けるが管理元は W3C)
glTF -> The Khronos Group が glTF Specification を管理(3D シーン・モデルのフォーマット)
TypeScript に関しては Microsoft が作っているだけで、仕様書が公開されていたり仕様を管理する団体があったりするわけではない
ややこしいのは Web API の仕様
Fecth -> WHATWG(2021 年に明確に W3C -> WHATWG )
URL -> WHATWG
Streams -> WHATWG
Storage / LocalStorage -> WHATWG
Service Worker -> W3C
Geolocation -> W3C
WebRTC -> W3C (と IETF
WebAuth -> W3C
Web Audio -> W3C
JS の歴史
1995 年に Netscape 社が当時主流だったブラウザ Netscape Navigator のために作られた
「ブラウザ上で簡単な動きをつけられる軽い言語」として作成
ライバルの Microsoft の Internet Explorer の JScript など、JS の方言が生まれる
ユーザー間で「同じコードでもブラウザによって動かない」という混乱が生まれ標準化が望まれるようになる
1997 年に Ecma International が ECMA-262 として標準化
JavaScript という名前が商標の都合で使用できず、ECMAScript という名前になった
以降、TC39 が決めた仕様を各ブラウザが実装していく感じに
2000 年代後半 Gmail, Google Maps のような Web アプリが広がるにつれ、当時のブラウザの JavaScript の遅さが大きな足枷になっていた
そこで Google はブラウザ上のアプリをデスクトップ並みに高速化することを狙って Javascript の実行速度を劇的に改善する独自エンジン V8 を開発
JavaScript エンジンは言語そのものの実行だけを担当(ファイル操作とかネットワークは含まない)
V8 は当時桁違いに高速で、他の環境に組み込みやすい設計になっていた
2009 年に Node.js が生まれる(Ryan Dahl)
(LiveWire, Jscript on ASP, Rhino, ...)
JS エンジンとして V8 を使用
2015 年に ES2015(ES6)
let, const
アロー関数
クラス構文
Promise
...
2017 年に Cloudflare Workers ベータリリース
エッジで動かすために Node.js ではない専用のランタイム(workerd)を開発
2020 年に Deno 1.0 がリリース
https://www.youtube.com/watch?v=M3BM9TB-8yA
Node.js の生みの親である Ryan Dahl が Node.js の設計で反省したことをもとにゼロからJavaScript ランタイムを作ったのが Deno
Deno の設計思想は「Web 標準への準拠」と「セキュリティ」
2022 年くらいに Bun が注目を集め始める
Node.js や Deno が Chrome で使用されている V8 を使用している一方、Bun は Safari で用いられている JavaScriptCore を採用
Bun は何よりも速度を重視(Written in Zig)
Vercel も 2022 年くらいに Edge Functions(Edge Runtime) を提供
(現在は Edge Functions は非推奨で Vercel Functions への移行が推奨されているとのこと)
ランタイムの標準化
Node.js, Deno, Cloudflare Workers, Bun, Vercel Functions, ...
ランタイムごとに例えば fetch() の挙動が異なっていた
W3C とか WHATWG は専ら Web ブラウザのニーズのみ扱っていた
HTML や fetch() の仕様は「ブラウザで動くこと」が前提であり、サーバーとかエッジのことは考えられていなかった
2022 年に Web-interoperable Runtimes Community Group(WinterCG) はブラウザ以外のニーズに応えるために生まれた
独自団体というわけではなく W3C のコミュニティグループとして設立　　　　　
Minimum Common Web Platform API(最小共通 Web プラットフォーム API)
すでに実装されていたランタイムのうち 2 つ以上で実装・サポートされている標準 API をまとめた
WinterCG は新しい標準を乱立させる団体ではなく、WHATWG が定めた既存の標準と競合する新しい API や独自の標準セットを作らないことを強調
「WHATWG, W3C, TC39 が実際の仕様を握り、WinterCG はそこへサーバー側の要望を橋渡しするハブ」
WinterCG が成熟してきたがコミュニティグループのために標準を公布できなかったらしい(？)
目標も 非 Web API の定義まで広がり始め、標準を交付できるようにならないといけなくなってきた
2024 年に WinterTC(TC55) として Ecma International の技術者委員会として結成され、WinterCG が閉じられ WinterTC に移行された(2025 年)
Community Group から Technical Committee へと格が上がった
Web-interoperable Runtimes Technical Committee
Bun と WinterTC
/petamoriken/Bun の非互換な拡張 API
がかなり更新されているっぽいのでこれを見ましょう
？「俺は幼稚園の徒競走みたいに手をつないでゴールをしたくない」
なんかずっと WinterTC(WinterCG 時代からも)声をかけているのにずっと Bun 側が無視しているらしい
@ryoppippi: BunはJSの標準を無視してるからよくないという話を聞くが、足並み揃えるのも大事だけど実験的な機能をガンガンshipして試すcanaryみたいな存在は大事なのでこれからもどんどんやっていただきたい。
逸脱する人がいてこその標準規格の発展
というかnode apiを標準とするのは早計だとずっと思ってる
@petamoriken: 実験的機能を入れるのは良いと思っていて、S3 の機能は面白いと思って見ています。
問題なのは標準と非標準の見分けがつかない形で追加しているところです。例えば Chrome で実験的機能を試す場合 Origin trials をDeno も実行時にフラグを必要とします。Bun にはそれがありません。
@mirror_kt: > node apiを標準とするのは早計
これを解消するためにWinterCGが立ち上がったのに、Bunはそこに参加していないので🧐
好き勝手やった結果をWinterCGにフィードバックしてるわけでもないので、非互換ばかりが進んでしまいそう...
@nwtgck_ja: 非標準な機能をバンバン追加する利己的で無責任な姿勢がある間はbunは広まらないでほしい。
例えば、将来ある名前のメソッドを違う仕様で標準化する時に広まった非標準の影響でその名前が使えないという歴史は何度か起こってるよね。
Bun は WinterTC に参加してない
好き勝手やったり独自の API を実装していたり、パフォーマンスに対する姿勢は評価されている
しかし、標準に対しては無頓着のようでその姿勢がよろしくないらしい