Webの地図 - Speaker Deck

Webの地図

by Yosuke Furukawa

Embed

Start on current slide

Slide 1

Slide 1 text

Webの地図 yosuke_furukawa 2026/09/12 @ FEC Fukuoka

Slide 2

Slide 2 text

X: @yosuke_furukawa GitHub: yosuke-furukawa

Slide 3

Slide 3 text

今回の講演の背景とある年末の忘年会での一コマ • なんで fetch って ECMAScript に入ってないのかなって思ったんですよね • たしかに・・・？ • 「fetch は JavaScript という言語の枠の中というよりもWebブラウザというプラットフォーム側の機能であり、仕様を管轄している場所が違うから」というのが答えだが、そもそもそこから曖昧な場合はなんでだろう？ってなる

Slide 4

Slide 4 text

今回の講演の背景とある年末の忘年会での一コマ • fetch は WHATWG が仕様作成元 • Date / Math といったライブラリはECMAScriptの内部で規定、つまりECMA が仕様作成元 • ネットワーク経由のライブラリだけなぜこっちなんだという問いをちゃんと答えたいが、Webの「地形」がわかっていないと理解が難しそうだと思った

Slide 5

Slide 5 text

今回の講演の背景そもそも Web アプリケーションを１つ作る場合複数の仕様にまたがる • HTML => WHATWG • CSS => W3C • JavaScript => ECMAScript • HTTP => IETF • URL => IETF • 他の言語とかサーバサイドだと１つの仕様でまとまっていることが多い

Slide 6

Slide 6 text

Webの地形 • Web開発自身は地形がどうなってるかなんて意識しなくても開発ができる • これ自体がWebの大きな特徴、別に仕様がどこで定義されて、どうなってるとかは特段意識しなくてもいい。 • 既に色んな目印や看板が立ってるのでやりたいことをすぐできる。MDNなんかは街中にある地図が書かれた看板のようなイメージ • しかも今はAIという自動運転で連れてってくれる仕組みまである • 全体の地図なんて知ってても役に立つシーンは少ないが、 fetch が ECMAScript に存在しない理由はわかる

Slide 7

Slide 7 text

というわけで、Webという大きな概念を１つの世界地図のようなものと見立ててみようと思う HTML CSS WHATWG W3C JavaScript HTTP / URL ECMA IETF powered by AI

Slide 8

Slide 8 text

大陸が移動しながら今の地球が形作られたように、今のWebがどうして形作られたのかを語る回にします

Slide 9

Slide 9 text

Before Web

Slide 10

Slide 10 text

Before Web • 論文や資料には参考となる資料（リファレンス）があり、各々のフォーマットでファイルとして保存され、各々の方法で共有されていた • それぞれの通信方式で通信し、それぞれのビューワーで閲覧し、、、となると大変なので何らかの方法で共通の通信方式で共通のビューワーで見れないかという考えがあった • これ自身は誰にでも思いつくが、決定打となるものはなかった • インターネット上に共通の通信方式で共通のビューワーが求められていた

Slide 11

Slide 11 text

Before Web • 1990年、最初のWebブラウザが Tim Berners Lee 氏によって誕生する • いわゆるこれが World Wide Web プロジェクトの始まり

Slide 12

Slide 12 text

Before Web • 最初のブラウザが搭載していたのは • 共通のファイルフォーマット => HTML • 共通の通信方式 => HTTP • 共通のアクセス先の表現 => URL • 特に仕様団体という枠組みもなく、大陸で言うと1つしかない。 • というより、まだ仕様化されてない

Slide 13

Slide 13 text

1990年代のWebブラウザ

Slide 14

Slide 14 text

1990年代のWebブラウザ • 最初の World Wide Web プロジェクト発足から大学などの研究機関を中心にブラウザの開発が行われる • さらに 1993年頃、NCSA Mosaic Browser がイリノイ大学で開発される • この頃に時を同じくして企業が参入し始める

Slide 15

Slide 15 text

1990年代のWebブラウザ • Mosaic ブラウザが画像とテキストを同じビューワーで見れるようにした

Slide 16

Slide 16 text

1990年代のWebブラウザ • このあたりから企業がどんどん参画してくる、商用のブラウザで Netscape Navigator, IBM Web Explorer, Mosaicのライセンスを企業が買うなどで商用化の道ができていく • Microsoft が Internet Explorer を開発し始めるのもこの頃 • 商用化による競争は発展でもあるが、独占は産業そのものの衰退でもある

Slide 17

Slide 17 text

1990年代のWebブラウザ • 一社の企業にブラウザが独占されてしまうと産業の発展にならないことは懸念されていた • 1994年頃を境に仕様化が進み出す • IETF を中心に HTML の仕様ドラフトを発行、後に失効（なんと最初はIETF） • 今も昔も仕様は「独占されないように強者を縛る鎖」みたいなものだった • 今風に言うと「ハーネス」か？（ハンターハンターっぽい）

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

1990年代のWebブラウザ • Mosaic がマルチメディアに対応してから文書はどんどん装飾表現が出てくる • 画像を埋め込みたい、フォントを変えたい、カラフルにしたい • 文書と装飾表現は分離しようとする動きが起きる • HTMLの中だけで font 要素で表現しようとしても限界がある • そもそも文書の構造と装飾表現は分離されるべきという考え方はHTMLに限らない、論文を書くTeXとかも全部そういう概念に基づいている

Slide 20

Slide 20 text

1990年代のWebブラウザ • ホーコンウィウムリー氏がCHSS (Cascading HTML StyleSheet) というCSS の前身を開発 • 1994年からCSSも仕様策定の流れが起きる • 実際作られたのは 1996年で、この時の仕様化団体がなんと W3C である

Slide 21

Slide 21 text

1990年代のWebブラウザ W3C • もともとIETFベースで仕様策定されていたが、ウェブの進化を加速させるためにティム・バーナーズ・リーがスピンオフしてWorld Wide Web Consortium (W3C) として団体を発足 • もともと議論が進んでいたものはそのまま IETF として出したが、W3Cという別な団体で HTML / CSS の協議を進めようとなった。

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

1990年代のWebブラウザ JavaScript 参戦！！！！ • Netscape 社は商用ブラウザを作る側だったが、より多くの表現を求めていた • プログラミング言語が動けばよりダイナミックに文書の表現ができる • 当時はやってる Java みたいな言語が動くブラウザってどうかなー？ • 作って同梱させるぞ！！！ • ブレンダン・アイク氏を登用し、 JavaScript を開発（1週間） powered by AI

Slide 24

Slide 24 text

1990年代のWebブラウザ JavaScript 参戦！！！！ • 差別化と混乱・・・ • 対抗して、 Microsoft は IE に JScript を同梱。 • APIは違うが文法は似てるものができる。 • 圧倒的なシェアを誇っている IE に牛耳らせるわけにはいかない • 当時は既に Windows 95 もあり、 MS は強者の立場 • 「「「強者を縛る鎖（ハーネス）！！！」」」

Slide 25

Slide 25 text

1990年代のWebブラウザ JavaScript 参戦！！！！ • 仕様を決めることで縛る鎖を発動したい！！！！ • が、、、 W3C におもむいた所、断られる • 「うちら宣言的なフォーマットだから、手続き的なプログラミング言語くんは他のところでやってよ」 • W3Cに断られたことで一同は泣く泣く別団体へ・・・

Slide 26

Slide 26 text

1990年代のWebブラウザ JavaScript 参戦！！！！ • ECMAという仕様団体に参加 • ECMAで仕様を決めて国際標準として展開（1997年） • 仕様上の呼称はECMAScript 、一般呼称は JavaScript として晴れて標準化の仲間入りを果たす HTML / CSS HTTP/ URL W3C IETF JavaScript ECMA powered by AI

Slide 27

Slide 27 text

1990年代のWebブラウザ HTTP にも変化が • 余り出番のないHTTPだが、よりパフォーマンス改善によって少しずつ新しくなっていく HTTP/1.1 1997年ただしベースはIETFのまま • 裏ではHTTPSの仕様策定もあるが、これはこれで長い話なので一旦割愛

Slide 28

Slide 28 text

2000年代の変化

Slide 29

Slide 29 text

2000年代の変化 • XHTML をティム・バーナーズ・リーが提唱 2000年 • これ自身は実は一週間前に発表済みなので詳しくはそちらで。 • https://speakerdeck.com/yosuke_furukawa/xhtml-ga-nokoshita-mono

Slide 30

Slide 30 text

2000年代の変化 • スライド抜粋

Slide 31

Slide 31 text

2000年代の変化 • XHTML は提唱から仕様策定まで非常に時間がかかった • 委員会をベースに標準化していたため、互換性やニーズの細かい変化に対応しきれなかった • ブラウザベンダー側がしびれを切らして W3C じゃない団体で仕様を決めようという動きが起きる • WHATWG ができる 2004年 • その後 HTML は HTML5 として仕様になり、今は Living Standard として仕様更新されている 2014年

Slide 32

Slide 32 text

2000年代の変化 • HTMLの仕様はWHATWGに引き継がれた • 大陸は4つになり、分離された HTML CSS WHATWG W3C JavaScript HTTP / URL ECMA IETF

Slide 33

Slide 33 text

一旦ここまでのまとめ

Slide 34

Slide 34 text

ここまでのまとめ • 最初は文書を共有するための枠組みだった WWW Project • 大学や研究機関が開発に参入 • 企業も参入したことで大きく競争が起きる • 一社に市場を独占させないために仕様策定が行われる • 仕様は強者を縛る鎖として機能している • 最初は１つの仕様としてIETFで定義されていた

Slide 35

Slide 35 text

ここまでのまとめ • しかし、Webの進化対応によりW3Cが誕生 • 新しいユースケースの発見によりECMAが誕生 • 互換性と進化を止めない動きによりW3CとWHATWGが分離 • 今の大陸の状況になる

Slide 36

Slide 36 text

2000年代の変化（続き）

Slide 37

Slide 37 text

2000年代の変化（続き） • Webブラウザをただの文書コンテンツを提供するだけではなく、アプリケーションを提供していく動きが活発になる • いわゆる Web 2.0 とか ajax とかでアプリケーションレイヤがどんどん進化していく • Gmail, Google Docs, Google Map, 各種SNS もこの頃

Slide 38

Slide 38 text

2000年代の変化（続き） • XMLHttpRequestは仕様化されたものではなく、IEの独自実装(XMLHTTP)が始まり。そこからMozillaがXMLHttpRequestとして互換実装を行う 2000年 • そこから Google Map や Gmail などの衝撃が起きるリロードしなくても更新される、動的なWebアプリケーションが開発、これに Ajax と命名される 2005年 • 実装から5~6年後、衝撃を与えて、W3Cで仕様化される 2007年

Slide 39

Slide 39 text

2000年代の変化（続き） • ちなみに同時期 2008年に Google Chrome リリース • 新しい強者が産声を上げる • 検索エンジン、Webアプリケーション基盤作り、ブラウザ開発とほとんどのプラットフォームを押さえた強者 • 仕様があったから混沌としたときよりも参画がしやすくなっていた。仕様はハーネスであると言ったが、新規参画ハードルを下げるものでもある

Slide 40

Slide 40 text

2000年代の変化（続き） • XMLHttpRequestはW3C側で策定 • 後にWHATWGが生まれた時にそちらに継承 • ちょうどJavaScriptとHTMLとHTTP HTML/XMLHttpRequest CSS WHATWG W3C JavaScript HTTP / URL ECMA IETF のそれぞれの大陸をつなぐようなものであったが、出自がW3Cだったのでそのまま後継者(WHATWG)に引き継がれた

Slide 41

Slide 41 text

このまま流れで fetch を〜〜〜〜と思ったけど

Slide 42

Slide 42 text

なんで最初から XMLHttpRequest や DOM に境界線を引いたのかわからないと思ったので

Slide 43

Slide 43 text

脱線します

Slide 44

Slide 44 text

ちなみにDOMは？？？

Slide 45

Slide 45 text

ちなみにDOMは？？？ • DOM (Document Object Model) の歴史は深い • Netscape Navigator が JavaScript を導入した時に同時に document オブジェクトを導入 • Internet Explorer も同様のオブジェクトを導入 • 相互APIが若干違うため開発者はif文地獄だった • ここでも W3C が介入し、お互いの仕様を共通化、鎖を発動する

Slide 46

Slide 46 text

ちなみにDOMは？？？ • おや・・・・？ • > Netscape Navigator が JavaScript を導入した時に同時に document オブジェクトを導入 • この時に JavaScript も仕様決めたからそこで document オブジェクトもECMAの仕様に入れられたような・・・？ • なんでそれをしなかったんだろう・・・？（これがsakuさんの質問にストレートに回答できなかった理由） • 歴史上の経緯であることはわかったけど理由はもっと知りたい

Slide 47

Slide 47 text

ちなみにDOMは？？？ • そもそも JavaScript 設計時に自由に外部からオブジェクトを差し込める拡張性の高い仕様として設計されていた • Netscape Navigator はブラウザとしては document を導入していたが、同時期に Livewire と呼ばれるサーバ上で動く JavaScript も提供していた • ちなみに Livewire は初のサーバサイドJavaScriptで、Node.jsよりも前に作られていたもの • つまり、 JavaScript は初期の設計から単体のコア機能と実行環境によって必要なオブジェクトを外から導入できるように設計されていた • ブラウザの一機能というよりも最初からかなり野心的な試みだったことが分かる

Slide 48

Slide 48 text

ちなみにDOMは？？？ • なので、、、 • JavaScript はコア機能と実行環境に分かれて定義できるように設計されていたため、ECMAScriptで仕様として定義できたのはコア機能だけだった。 • documentがECMAに入らず、入らなかったがゆえに勝手に拡張され続けられた • W3CがDOMをまとめたのもここに起因する • 似たようなものはたくさんある、consoleもsetTimeoutも後々仕様化されるが、昔は仕様化されなかった穴として存在していた

Slide 49

Slide 49 text

ちなみにDOMは？？？ • XMLHttpRequest もそういった「仕様の穴」の１つだった • W3C/WHATWGはそういった穴を見つけて埋めていく活動もしてくれていた • 一方であくまでW3C/WHATWGが提供しているもの「ブラウザの仕様」なので「サーバ側のAPI」の仕様は統一されていない • 最近はそこにWinterCGが仕様化団体として発足しているためブラウザ仕様との共通化が試みられている

Slide 50

Slide 50 text

というわけで、fetchがなんでECMAじゃなかったのか？？？という問いに対する回答

Slide 51

Slide 51 text

fetchがなぜECMAじゃなかったのか • まず、Webの仕様は複数のプレイヤーが絡むことで複雑である • １つの団体、１つの個人が決めてるものではない • 複数の団体で協議しながら決めている • 仕様は強者を縛るハーネスであり、参画者のハードルを下げる装置である • ECMAScriptはJavaScriptのコア機能だけを定めた仕様 • ECMAScriptの仕様はJavaScriptの設計がコア機能と実行環境を分離するデザインから来ている

Slide 52

Slide 52 text

fetchがなぜECMAじゃなかったのか • 「実行環境として外側から注入されるオブジェクト」という扱いだったため、fetchは ECMAじゃなかった。 • 前身のXMLHttpRequestがW3Cで仕様として定義されたため、それを引き継ぐ形で WHATWGで仕様が継承 • さらにそれを引き継ぐ形で XMLHttpRequest と同じ団体が fetch を仕様として規定した • 同じく注入されるオブジェクトとして document (DOM) 、 console、 Timer(setTimeout) も同じもの • 結果としてブラウザでの仕様とその外側の実行環境側での仕様は別な定義になる

Slide 53

Slide 53 text

fetchの仕様を眺めてみると...

Slide 54

Slide 54 text

fetchの仕様 • 単なる「HTTPリクエストを送るライブラリ」ではない事がわかる • クロスオリジンだとどうなる？クッキーの扱いは？ヘッダを勝手に操作して良い？ • ブラウザ独自のセキュリティ面での配慮が随所に盛り込まれてる • fetchそのものをECMAに今更入れるのは大分違和感がある... • ブラウザの仕様を決める団体側（W3C/WHATWG）で持つ方が違和感がない

Slide 55

Slide 55 text

Unicode IEEE ISO FIDO ちなみに大陸4つって言ったけどあくまで便宜上の話でこの他にもたくさん団体があるし、関わってる IANA/ICANN ISO/IEC MPEG + ITU-T AOMedia

Slide 56

Slide 56 text

まとめます

Slide 57

Slide 57 text

まとめ • 前半 (Webの歴史) • 新しい産業の発展と差別化と仕様化の歴史 • 強者が一人でパワープレーができないのも仕様のおかげ • 色んなプレイヤーが出てこれるのも仕様のおかげ • 一方で色んなユースケースがあるので色んな仕様がある

Slide 58

Slide 58 text

まとめ • 後半 (JavaScriptと周辺のAPI) • JavaScriptは拡張可能なことを前提とした設計であり仕様である • 結果として「色んな拡張仕様」があることで「穴」も存在する • document, fetch, console etc etc • 後から穴は埋められていく結果として fetch はECMAではない所で定義されている

Slide 59

Slide 59 text

蛇足

Slide 60

Slide 60 text

みんなに考えてみてほしい • Webの地図として地形図がどう変わっていったかという話をした • 仕様は強者を縛る鎖であるとも話した • 本当に気になるのはこれからどうなるのか、だと思う • 強者が一社独占を作れないようにするための仕様である、一方で強者は強者であり続けられるのか • 新しい強者は生まれるのか • 戦争や隕石衝突などで大陸は変わっていくのか • ぜひ、 Ask the speaker で終わりのない話をしましょう

Slide 61

Slide 61 text

ありがとうございました