非ブラウザランタイムとWeb標準 / Non-Browser Runtimes and Web Standards

fukuoka.ts #2
https://fukuoka-ts.connpass.com/event/332933/

Transcript

1. 非ブラウザランタイムと Web 標準 fukuoka.ts #2 pixiv Inc. 森内建太 petamoriken 2014.12.27
2. 2 自己紹介 • Web  エンジニア • Deno コントリビューター • ECMAScript  や  Web 標準 を追うのが好き petamoriken カスタマーオペレーション ＆セーフティ本部 オペレーション開発部
3. 一人アドカレ完走しました 🎉 おすすめ記事 #1 Normative Changes とは #2 Array.prototype.sort 安定化 #3 プリミティブイテラブルを退ける 規約制定 #8 プロパティ列挙順一律化 #14 Math.sqrt 精度の正確さ保証 #24 IsRegExp の挙動変更（リジェクト）
4. 4 様々な標準化団体によって定義される Web のための仕様 HTML, CSS, JS, WAI-ARIA, HTTP など多岐に渡る 近年ではブラウザと同じ JS コードが実行できるように Node.js など非ブラウザランタイムにも取り込まれている 👉 便利になってきたが問題も見えてきた Web 標準
5. 5 • そもそもブラウザ/非ブラウザで求められるものが違う • 非ブラウザにどこまで正確な Web 標準 API が実装され ているのか不明瞭 ◦ やむを得ず独自拡張を入れる場合がある ◦ 特に fetch のギャップが大きい Web 標準を取り入れることによる問題
6. 6 「え? fetch() 入れるの? CORS は? Cookie は? FormData や URLSearchParams は?? WPT (Web Platform Tests) は通す の?」などの、およそ想像通りの反応をみると、そこにあったイ ンピーダンスミスマッチは「Fetch を入れる」と「fetch() を 入れる」の違いととれる。Web に詳しい人は前者だと思い、 Node メンテナが求めていたのは後者だけだった。Node では名 前を変えるという案もあったが、変えたところで誰も得はしな かっただろう。 https://blog.jxck.io/entries/2022-09-30/XMLHttpRequest.html
7. 7 サーバー、エッジといった非ブラウザランタイムで API 相互運用を実現するための W3C コミュニティグループ • minimum common API 策定 • fetch のサーバー用サブセット仕様作成 • 非ブラウザランタイムの知見を Web 標準側へ展開 👉 JS コミュニティ全体での有益化を信念に活動している WinterCG
8. 8 WinterCG 参加者
9. 9 あのランタイムが参加していないような……
10. 10 Bun は JS コミュニティ全体というよりは Bun 自身が便利 であればよいと考えている（ように見える） Web 標準 API を取り入れつつも、基本それらはブラウザの ための API というスタンスで独自拡張を次々に入れている WinterCG 参加の誘いを断っている Bun
11. 11 ブラウザで動かない “Bun 用のコード”
12. 12 ブラウザで動かない “Bun 用のコード”
13. 13 他ランタイムはなるべく独自機能にアクセスする方法を分 けているが Bun は Web 標準 API にそのまま拡張している Bun の独自拡張を標準と勘違いし、他ランタイムに対して 実行できないとバグ報告するユーザーが出始めている 👉 WinterCG と相反する行動を取っている Bun による Web 標準 API 独自拡張問題
14. 14 多くのユーザーに使われるのが正義となる側面もある
15. 15 • 非ブラウザランタイムに Web 標準 API が取り入れられ ることによる問題が見えてきた • WinterCG でサーバー、エッジ用のランタイムの相互 運用性を高めるための活動がされている • シェア争いの結果によって未来が変わりそう （TC39 や WinterCG で標準化を頑張っている Deno がもっと使われて欲しい……） まとめ