Webの地図

FEC Fukuoka で発表したWebの地図についての話です

Transcript

1. Webの地図 yosuke_furukawa 2026/09/12 @ FEC Fukuoka
2. X: @yosuke_furukawa GitHub: yosuke-furukawa
3. 今回の講演の背景 とある年末の忘年会での一コマ • なんで fetch って ECMAScript に入ってないのかなって思ったんですよね • たしかに・・・？ • 「fetch は JavaScript という言語の枠の中というよりもWebブラウザという プラットフォーム側の機能であり、仕様を管轄している場所が違うから」と いうのが答えだが、そもそもそこから曖昧な場合はなんでだろう？ってなる
4. 今回の講演の背景 とある年末の忘年会での一コマ • fetch は WHATWG が仕様作成元 • Date / Math といったライブラリはECMAScriptの内部で規定、つまりECMA が仕様作成元 • ネットワーク経由のライブラリだけなぜこっちなんだという問いをちゃんと 答えたいが、Webの「地形」がわかっていないと理解が難しそうだと思った
5. 今回の講演の背景 そもそも Web アプリケーションを１つ作る場合複数の仕様にまたがる • HTML => WHATWG • CSS => W3C • JavaScript => ECMAScript • HTTP => IETF • URL => IETF • 他の言語とかサーバサイドだと１つの仕様でまとまっていることが多い
6. Webの地形 • Web開発自身は地形がどうなってるかなんて意識しなくても開発ができる • これ自体がWebの大きな特徴、別に仕様がどこで定義されて、どうなってるとかは特 段意識しなくてもいい。 • 既に色んな目印や看板が立ってるのでやりたいことをすぐできる。MDNなんかは街中 にある地図が書かれた看板のようなイメージ • しかも今はAIという自動運転で連れてってくれる仕組みまである • 全体の地図なんて知ってても役に立つシーンは少ないが、 fetch が ECMAScript に存 在しない理由はわかる
7. というわけで、Webという大きな概念を １つの世界地図のようなものと見立ててみようと思う HTML CSS WHATWG W3C JavaScript HTTP / URL ECMA IETF powered by AI
8. 大陸が移動しながら今の地球が形作られたように、今 のWebがどうして形作られたのかを語る回にします
9. Before Web
10. Before Web • 論文や資料には参考となる資料（リファレンス）があり、各々のフォーマッ トでファイルとして保存され、各々の方法で共有されていた • それぞれの通信方式で通信し、それぞれのビューワーで閲覧し、、、となる と大変なので何らかの方法で共通の通信方式で共通のビューワーで見れない かという考えがあった • これ自身は誰にでも思いつくが、決定打となるものはなかった • インターネット上に共通の通信方式で共通のビューワーが求められていた
11. Before Web • 1990年、最初のWebブラウザが Tim Berners Lee 氏によって誕生する • いわゆるこれが World Wide Web プロジェクトの始まり
12. Before Web • 最初のブラウザが搭載していたのは • 共通のファイルフォーマット => HTML • 共通の通信方式 => HTTP • 共通のアクセス先の表現 => URL • 特に仕様団体という枠組みもなく、大陸で言うと1つしかない。 • というより、まだ仕様化されてない
13. 1990年代のWebブラウザ
14. 1990年代のWebブラウザ • 最初の World Wide Web プロジェクト発足から大学などの研究機関を中心に ブラウザの開発が行われる • さらに 1993年頃、NCSA Mosaic Browser がイリノイ大学で開発される • この頃に時を同じくして企業が参入し始める
15. 1990年代のWebブラウザ • Mosaic ブラウザが画像とテキストを同じビューワーで見れるようにした
16. 1990年代のWebブラウザ • このあたりから企業がどんどん参画してくる、 商用のブラウザで Netscape Navigator, IBM Web Explorer, Mosaicのライセンスを企業が買うなどで商用 化の道ができていく • Microsoft が Internet Explorer を開発し始めるのもこの頃 • 商用化による競争は発展でもあるが、独占は産業そのものの衰退でもある
17. 1990年代のWebブラウザ • 一社の企業にブラウザが独占されてしまうと産業の発展にならないことは懸 念されていた • 1994年頃を境に仕様化が進み出す • IETF を中心に HTML の仕様ドラフトを発行、後に失効（なんと最初はIETF） • 今も昔も仕様は「独占されないように強者を縛る鎖」みたいなものだった • 今風に言うと「ハーネス」か？（ハンターハンターっぽい）
18. 1990年代のWebブラウザ • World Wide Web プロジェクト発足から5年後、 IETF を中心にHTML, HTTP, URL が仕様化される • HTML 2.0 RFC 1866 1995年 • HTTP 1.0 RFC 1945 1996年 • URL RFC 1738 1994年 HTML / HTTP / URL IETF powered by AI
19. 1990年代のWebブラウザ • Mosaic がマルチメディアに対応してから文書はどんどん装飾表現が出てくる • 画像を埋め込みたい、フォントを変えたい、カラフルにしたい • 文書と装飾表現は分離しようとする動きが起きる • HTMLの中だけで font 要素で表現しようとしても限界がある • そもそも文書の構造と装飾表現は分離されるべきという考え方はHTMLに限ら ない、論文を書くTeXとかも全部そういう概念に基づいている
20. 1990年代のWebブラウザ • ホーコンウィウムリー氏がCHSS (Cascading HTML StyleSheet) というCSS の前身を開発 • 1994年からCSSも仕様策定の流れが起きる • 実際作られたのは 1996年で、この時の仕様化団体がなんと W3C である
21. 1990年代のWebブラウザ W3C • もともとIETFベースで仕様策定されていたが、ウェブの進化を加速させるため にティム・バーナーズ・リーがスピンオフしてWorld Wide Web Consortium (W3C) として団体を発足 • もともと議論が進んでいたものはそのまま IETF として出したが、W3Cという 別な団体で HTML / CSS の協議を進めようとなった。
22. 1990年代のWebブラウザ W3C参入 • CSS 1.0 1996年 W3C • HTML 3.2 1997年 W3C • HTTP/URL 1.0 IETF • ここで大陸が２つに割れる HTML / CSS HTTP / URL W3C IETF powered by AI
23. 1990年代のWebブラウザ JavaScript 参戦！！！！ • Netscape 社は商用ブラウザを作る側だったが、より多くの表現を求めていた • プログラミング言語が動けばよりダイナミックに文書の表現ができる • 当時はやってる Java みたいな言語が動くブラウザってどうかなー？ • 作って同梱させるぞ！！！ • ブレンダン・アイク氏を登用し、 JavaScript を開発（1週間） powered by AI
24. 1990年代のWebブラウザ JavaScript 参戦！！！！ • 差別化と混乱・・・ • 対抗して、 Microsoft は IE に JScript を同梱。 • APIは違うが文法は似てるものができる。 • 圧倒的なシェアを誇っている IE に牛耳らせるわけにはいかない • 当時は既に Windows 95 もあり、 MS は強者の立場 • 「「「強者を縛る鎖（ハーネス）！！！」」」
25. 1990年代のWebブラウザ JavaScript 参戦！！！！ • 仕様を決めることで縛る鎖を発動したい！！！！ • が、、、 W3C におもむいた所、断られる • 「うちら宣言的なフォーマットだから、手続き的なプログラミング言語くん は他のところでやってよ」 • W3Cに断られたことで一同は泣く泣く別団体へ・・・
26. 1990年代のWebブラウザ JavaScript 参戦！！！！ • ECMAという仕様団体に参加 • ECMAで仕様を決めて国際標準として展開 （1997年） • 仕様上の呼称はECMAScript 、 一般呼称は JavaScript として晴れて 標準化の仲間入りを果たす HTML / CSS HTTP/ URL W3C IETF JavaScript ECMA powered by AI
27. 1990年代のWebブラウザ HTTP にも変化が • 余り出番のないHTTPだが、よりパフォーマンス改善によって少しずつ新しく なっていく HTTP/1.1 1997年 ただしベースはIETFのまま • 裏ではHTTPSの仕様策定もあるが、これはこれで長い話なので一旦割愛
28. 2000年代の変化
29. 2000年代の変化 • XHTML をティム・バーナーズ・リーが提唱 2000年 • これ自身は実は一週間前に発表済みなので詳しくはそちらで。 • https://speakerdeck.com/yosuke_furukawa/xhtml-ga-nokoshita-mono
30. 2000年代の変化 • スライド抜粋
31. 2000年代の変化 • XHTML は提唱から仕様策定まで非常に時間がかかった • 委員会をベースに標準化していたため、互換性やニーズの細かい変化に対応しきれな かった • ブラウザベンダー側がしびれを切らして W3C じゃない団体で仕様を決めようという動 きが起きる • WHATWG ができる 2004年 • その後 HTML は HTML5 として仕様になり、今は Living Standard として仕様更新さ れている 2014年
32. 2000年代の変化 • HTMLの仕様はWHATWGに引き継がれた • 大陸は4つになり、分離された HTML CSS WHATWG W3C JavaScript HTTP / URL ECMA IETF
33. 一旦ここまでのまとめ
34. ここまでのまとめ • 最初は文書を共有するための枠組みだった WWW Project • 大学や研究機関が開発に参入 • 企業も参入したことで大きく競争が起きる • 一社に市場を独占させないために仕様策定が行われる • 仕様は強者を縛る鎖として機能している • 最初は１つの仕様としてIETFで定義されていた
35. ここまでのまとめ • しかし、Webの進化対応によりW3Cが誕生 • 新しいユースケースの発見によりECMAが誕生 • 互換性と進化を止めない動きによりW3CとWHATWGが分離 • 今の大陸の状況になる
36. 2000年代の変化（続き）
37. 2000年代の変化（続き） • Webブラウザをただの文書コンテンツを提供するだけではなく、アプリケー ションを提供していく動きが活発になる • いわゆる Web 2.0 とか ajax とかでアプリケーションレイヤがどんどん進化し ていく • Gmail, Google Docs, Google Map, 各種SNS もこの頃
38. 2000年代の変化（続き） • XMLHttpRequestは仕様化されたものではなく、IEの独自実装(XMLHTTP)が 始まり。そこからMozillaがXMLHttpRequestとして互換実装を行う 2000年 • そこから Google Map や Gmail などの衝撃が起きるリロードしなくても更新 される、動的なWebアプリケーションが開発、これに Ajax と命名される 2005年 • 実装から5~6年後、衝撃を与えて、W3Cで仕様化される 2007年
39. 2000年代の変化（続き） • ちなみに同時期 2008年に Google Chrome リリース • 新しい強者が産声を上げる • 検索エンジン、Webアプリケーション基盤作り、ブラウザ開発とほとんどの プラットフォームを押さえた強者 • 仕様があったから混沌としたときよりも参画がしやすくなっていた。仕様は ハーネスであると言ったが、新規参画ハードルを下げるものでもある
40. 2000年代の変化（続き） • XMLHttpRequestはW3C側で策定 • 後にWHATWGが生まれた時にそちら に継承 • ちょうどJavaScriptとHTMLとHTTP HTML/XMLHttpRequest CSS WHATWG W3C JavaScript HTTP / URL ECMA IETF のそれぞれの大陸をつなぐようなもの であったが、出自がW3Cだったので そのまま後継者(WHATWG)に 引き継がれた
41. このまま流れで fetch を〜〜〜〜と思ったけど
42. なんで最初から XMLHttpRequest や DOM に 境界線を引いたのかわからないと思ったので
43. 脱線します
44. ちなみにDOMは？？？
45. ちなみにDOMは？？？ • DOM (Document Object Model) の歴史は深い • Netscape Navigator が JavaScript を導入した時に同時に document オブ ジェクトを導入 • Internet Explorer も同様のオブジェクトを導入 • 相互APIが若干違うため開発者はif文地獄だった • ここでも W3C が介入し、お互いの仕様を共通化、鎖を発動する
46. ちなみにDOMは？？？ • おや・・・・？ • > Netscape Navigator が JavaScript を導入した時に同時に document オブジェ クトを導入 • この時に JavaScript も仕様決めたからそこで document オブジェクトもECMAの 仕様に入れられたような・・・？ • なんでそれをしなかったんだろう・・・？（これがsakuさんの質問にストレート に回答できなかった理由） • 歴史上の経緯であることはわかったけど理由はもっと知りたい
47. ちなみにDOMは？？？ • そもそも JavaScript 設計時に自由に外部からオブジェクトを差し込める拡張性の高い仕様 として設計されていた • Netscape Navigator はブラウザとしては document を導入していたが、同時期に Livewire と呼ばれるサーバ上で動く JavaScript も提供していた • ちなみに Livewire は初のサーバサイドJavaScriptで、Node.jsよりも前に作られていたもの • つまり、 JavaScript は初期の設計から単体のコア機能と実行環境によって必要なオブジェ クトを外から導入できるように設計されていた • ブラウザの一機能というよりも最初からかなり野心的な試みだったことが分かる
48. ちなみにDOMは？？？ • なので、、、 • JavaScript はコア機能と実行環境に分かれて定義できるように設計されていた ため、ECMAScriptで仕様として定義できたのはコア機能だけだった。 • documentがECMAに入らず、入らなかったがゆえに勝手に拡張され続けられた • W3CがDOMをまとめたのもここに起因する • 似たようなものはたくさんある、consoleもsetTimeoutも後々仕様化される が、昔は仕様化されなかった穴として存在していた
49. ちなみにDOMは？？？ • XMLHttpRequest もそういった「仕様の穴」の１つだった • W3C/WHATWGはそういった穴を見つけて埋めていく活動もしてくれていた • 一方であくまでW3C/WHATWGが提供しているもの「ブラウザの仕様」なの で「サーバ側のAPI」の仕様は統一されていない • 最近はそこにWinterCGが仕様化団体として発足しているためブラウザ仕様と の共通化が試みられている
50. というわけで、fetchがなんでECMAじゃな かったのか？？？という問いに対する回答
51. fetchがなぜECMAじゃなかったのか • まず、Webの仕様は複数のプレイヤーが絡むことで複雑である • １つの団体、１つの個人が決めてるものではない • 複数の団体で協議しながら決めている • 仕様は強者を縛るハーネスであり、参画者のハードルを下げる装置である • ECMAScriptはJavaScriptのコア機能だけを定めた仕様 • ECMAScriptの仕様はJavaScriptの設計がコア機能と実行環境を分離するデザ インから来ている
52. fetchがなぜECMAじゃなかったのか • 「実行環境として外側から注入されるオブジェクト」という扱いだったため、fetchは ECMAじゃなかった。 • 前身のXMLHttpRequestがW3Cで仕様として定義されたため、それを引き継ぐ形で WHATWGで仕様が継承 • さらにそれを引き継ぐ形で XMLHttpRequest と同じ団体が fetch を仕様として規定した • 同じく注入されるオブジェクトとして document (DOM) 、 console、 Timer(setTimeout) も同じもの • 結果としてブラウザでの仕様とその外側の実行環境側での仕様は別な定義になる
53. fetchの仕様を眺めてみると...
54. fetchの仕様 • 単なる「HTTPリクエストを送るライブラリ」ではない事がわかる • クロスオリジンだとどうなる？クッキーの扱いは？ヘッダを勝手に操作して 良い？ • ブラウザ独自のセキュリティ面での配慮が随所に盛り込まれてる • fetchそのものをECMAに今更入れるのは大分違和感がある... • ブラウザの仕様を決める団体側（W3C/WHATWG）で持つ方が違和感がない
55. Unicode IEEE ISO FIDO ちなみに大陸4つって言ったけどあくまで便宜上の 話でこの他にもたくさん団体があるし、関わってる IANA/ICANN ISO/IEC MPEG + ITU-T AOMedia
56. まとめます
57. まとめ • 前半 (Webの歴史) • 新しい産業の発展と差別化と仕様化の歴史 • 強者が一人でパワープレーができないのも仕様のおかげ • 色んなプレイヤーが出てこれるのも仕様のおかげ • 一方で色んなユースケースがあるので色んな仕様がある
58. まとめ • 後半 (JavaScriptと周辺のAPI) • JavaScriptは拡張可能なことを前提とした設計であり仕様である • 結果として「色んな拡張仕様」があることで「穴」も存在する • document, fetch, console etc etc • 後から穴は埋められていく結果として fetch はECMAではない所で定義され ている
59. 蛇足
60. みんなに考えてみてほしい • Webの地図として地形図がどう変わっていったかという話をした • 仕様は強者を縛る鎖であるとも話した • 本当に気になるのはこれからどうなるのか、だと思う • 強者が一社独占を作れないようにするための仕様である、一方で強者は強者であり続け られるのか • 新しい強者は生まれるのか • 戦争や隕石衝突などで大陸は変わっていくのか • ぜひ、 Ask the speaker で終わりのない話をしましょう
61. ありがとうございました