ウェブの歴史 (Chrome University 2019)
このページのタイトル、字幕、要約、読書メモは保存済みの AI 翻訳です。誤りが含まれる場合があります。タイムスタンプは原文と同じです。原文の字幕を開き、元の動画と照合できます。
Chris Wilsonは初期のウェブ、Mosaic、ブラウザ戦争をたどり、標準、互換性、そしてプラットフォームを形作ったコミュニティについて振り返る。
文字起こしの出典：YouTubeに作成者がアップロードしたキャプション。AIによる句読点の付加はVidleafによるもので、元の文言とタイムスタンプのアンカーは保持されています。元の文字起こしは以下でご覧いただけます。
AI生成の要約
この講演では、NCSA MosaicのWindows版を共同執筆し後にChromeに携わった、長年のウェブプラットフォーム貢献者であるChris Wilsonが、初期の1990年代の始まりからブラウザ戦争を経て現在に至るまでのウェブの歴史をたどる。彼はイリノイ大学における原始的な初期インターネット、ARPANET時代のアクセスの制約、そしてNCSA Mosaic for Windowsがネットワークスタック、バージョン管理、正式なテストなしにどのように構築されたかを説明する。彼は、ウェブの成長がニッチなコンテンツのロングテールと、誰もが著者になれることによってどのように推進されたかを説明し、blinkタグとmarqueeタグ、IE 4のダイナミックHTML、ActiveDesktop、IE 5-6時代などのエピソードを語る。講演はまた、Avalon/.NET Framework 3.0の取り組み、マッシュアップアプリケーションの台頭、WHATWGの結成、Internet Explorer 7からの教訓、モバイル革命、Web 2.0、Progressive Web Appsについても扱う。彼は結論として、ウェブを完成したものとして扱うのではなく、物事の自然な秩序に適応させ、ユーザー、プラットフォーム、コミュニティを尊重し、部屋の中で最も賢い人ではなく最も優れた聞き手になるべきだと述べる。
文字起こしから生成されました。リンクされた箇所を元の動画と照合して確認してください。
タイムスタンプ付きの章の要約
ウェブの歴史とブラウザ戦争のイントロ
- [0:04] Chris Wilsonの講演は、初期の1990年代の始まりからブラウザ戦争を経て今日に至るまでのウェブの歴史を扱う。
- [0:14] この講演は部分的にはWilson自身のノスタルジーであり、歴史が今日のウェブをどのように形作ったかを検証する。
- [0:24] 彼は、過去を覚えていない者はそれを繰り返す運命にあるというGeorge Santayanaの警告を引用する。
- [0:32] 講演の大部分はInternet Explorerの歴史と、それがウェブを今日の姿にどのように導いたかに焦点を当てている。
- [0:41] メル・ブルックスの映画のように、彼は多くの素材を飛ばさなければなりません。彼の最初の草稿デッキは約一時間半に及んだからです。
Chris Wilsonのウェブプラットフォームの経歴
- [0:55] Chris Wilsonは、長年のウェブプラットフォーム貢献者として自己紹介する。
- [1:00] 彼は26年以上前にウェブプラットフォームの仕事を始めた。
- [1:02] 彼は、Tim Berners Leeの後に続く最初の大衆市場向けブラウザであるNCSA MosaicのWindows版を共同執筆した。
- [1:10] 彼はエンジニア、PM、リードPM、GPM、デベロッパーアドボケイトの役職を務めてきた。
- [1:16] 彼は現在ChromeのTPGMチームに所属している。
- [1:19] 彼は四つの異なるブラウザに携わり、2010年からGoogle社員で、Chromeバージョン6頃から始めました。
- [1:39] 彼は謙虚に、自分は部屋の中で最も賢い人ではないが、しばしば物事が起こった部屋に居合わせてきたと述べる。
- [1:50] 彼は聴衆に、彼がイリノイ大学に進学した1988年を思い返すよう求める。
初期のインターネットと世代の変化
- [2:00] 1988年、インターネットはほとんど存在せず、学界ではまだARPANETとして知られていた。
- [2:24] 彼の入学した学部のクラスにはデフォルトでメールアカウントが与えられず、学生はコンピュータラボで直接申請しなければならなかった。
- [2:42] メインフレームへのアクセスは週七時間に制限されており、彼はよくそれをUltimate Larnのプレイで消費しました。
- [3:00] 工学部の学生は、別のメインフレーム上で制限なしの二つ目のアカウントを受け取りました。
- [3:09] 彼の最初のインターネット端末は、サーマルプリンタを内蔵したお下がりのHP 2622Aだった。
- [3:26] 彼は2,400ボーのモデムでイリノイ大学のシステムに接続した。これは彼の携帯電話のLTEよりおよそ6,000倍遅かった。
- [3:50] 初期のインターネットは主にテキストだった。メール、Usenet、IRC、Gopherであり、FTPは主にソフトウェアの共有に使われた。
- [4:21] 若い頃に存在する技術は普通に感じられ、15歳から35歳の間の発明は新しく、キャリアに値するものに感じられる。
- [4:47] ウェブを完成したものとして退けるのではなく、課題はそれを物事の自然な秩序に適応させ、それが何になり得るかを想像することである。
1991年のNCSAにおけるMarc Andreessen
- [5:12] 1991年、彼は全米スーパーコンピューティング応用センター（NCSA）でアルバイトの仕事を得た。
- [5:21] NCSAは、NSFの五つのオリジナルスーパーコンピューティングセンターの一つです。
- [5:26] NCSAにおける彼のグループの使命は、研究者がデスクトップ上でスーパーコンピュータの能力を使えるようにするソフトウェアツールを構築することだった。
- [5:39] グループはTelnetを構築し、彼は特に端末の作業のために雇われた。
- [5:46] この作業はWindows 95より前のものであり、TCP/IPネットワークスタックはまだ存在しなかった。
- [5:59] PC TelnetはDOSソフトウェアであり、彼らは最終的にWindowsソフトウェアを構築しなければならなかった。
- [6:04] 彼らはまた、可視化、データ読み込み、フォーマットのツールも構築した。
NCSA Mosaic for Windowsの構築
- [6:20] 数人の男たちが、スイスのある人物によって発明されたワールドワイドウェブにアクセスするためのMosaicというX Windowsソフトウェアを作成しました。
- [6:33] ウェブはHTMLと呼ばれるプロトタイプの文書言語を使用していました。
- [6:40] 講演者はMosaicのWindows版を共同執筆し、それが彼の人生の次の26年間となりました。
- [6:42] NCSA Mosaicには三つの全く異なるバージョン（Mac、PC Windows、X Windows）があり、コードを全く共有していませんでした。
- [7:08] Windowsには組み込みのネットワークサポート、ソケット、TCP/IPが欠けていたため、チームは独自のネットワークスタックとネットワークカード用のデバイスドライバを書きました。
- [7:44] 講演者は個人的にTCP/IPフォールバックアルゴリズムをデバッグしました。
- [7:52] 彼らはWindows用のHTML解析とレンダリング機能を構築しました。
- [7:57] NCSAには多くのベータリリースを出荷する伝統があり、しばしばマシン上でビルドしてすぐにリリースを公開しました。
初期のMosaic開発とその課題
- [8:17] Windows Mosaicは最初にFTPサーバーにアップロードされ、一週間で1,000ダウンロードに達しました。
- [8:27] 2011までに、Firefoxは一瞬のうちに1,000ダウンロードを達成し、規模の違いを示しました。
- [8:45] 同じ年にDOOMがリリースされたにもかかわらず、チームは大学生だったためMosaicの開発を続けました。
- [8:55] 教育と研究を可能にするというNCSAの設立趣意書により、チームは自分たちのグループの趣意書の範囲外でウェブブラウザを探求し構築することができました。
- [9:20] Googleの柔軟性はNCSAのそれと似ており、講演者はそれを高く評価しています。
- [9:29] Mosaicチームは知識、サポート、ビジネスプランの不足により愚かな過ちを犯しました。
- [9:46] 講演者のコンピュータサイエンスの学位には、ユーザーエクスペリエンスとソフトウェアテスト理論が欠けていました。
- [9:56] リビジョン管理システムやネットワークドライブがなかったため、二人の開発者はzipディスクを介して手動でコードを共有しました。
初期のウェブと重複タグ
- [10:25] 講演者は、初期のウェブで重複する太字と斜体のタグを機能させたことについて個人的な責任を負っています。
- [10:43] Chromeや他のブラウザは依然として重複タグをサポートしており、文書の品位を損なわない方法で実装されています。
- [11:02] 1993前後の初期のウェブは、膨大な量の情報へのアクセスを提供したため、魅力的でした。
- [11:17] Googleの使命は、世界の情報を整理し、普遍的にアクセス可能で有用なものにすることです。
- [11:30] 当時、世界の情報のほとんどはインターネット上になく、デジタル形式ですらなかったため、図書館に行く必要がありました。
- [11:57] ウェブプラットフォームのLICEという頭字語は認識されていましたが、情報はまだ真にインデックス可能ではありませんでした。
- [12:06] 1993頃に出版された製本された紙の本に、URLとその説明が記載されていました。
- [12:34] NCSAで彼らはウェブの最も素晴らしい点を認識しました。
初期のウェブ共有とロングテール
- [12:41] 目標は誰もが著者になることでしたが、ほとんどのシステムは誰もがサーバーを立ち上げて情報を共有できるようには設計されていませんでした。
- [12:51] Gopherクライアントは簡単にアクセスできましたが、Gopherサーバーソフトウェアは高価だったため、主に大学や民間企業が運用していました。
- [13:08] NCSAでは、1993のグループ注釈機能を含む、情報共有を促進する機能を実装しました。
- [13:32] 彼らはウェブサーバーソフトウェアは無料であるべきで、誰もが自分のマシンでサーバーを運用すべきだと信じていました。
- [13:49] 講演者はNCSAで自分のPC上で世界中からアクセス可能なウェブサーバーを運用し、誰でもFTPで接続できました。
- [14:00] 彼と友人たちはNCSAのPC Telnetコードを使用してネットワーク対応の宇宙ドッグファイトゲームを書き、初期のLANパーティーにつながりました。
- [14:36] ホノルルコミュニティカレッジのKevin Hughesが恐竜博物館の写真をオンラインに公開するなど、たくさんの変わったコンテンツがありました。
- [15:06] ウェブの成長はロングテールによって推進されました。つまり、個々の関心は低いが大量のコンテンツが集まれば、トップコンテンツの人気に匹敵するのです。
ディジュリドゥからウクレレへ：ニッチなオンラインコミュニティ
- [16:04] 1996年に、講演者はディジュリドゥの演奏と製作に関するクラスを受講しました。
- [16:17] 彼は竹製ディジュリドゥの作り方に関するウェブページを作成し、GeoCitiesでホストしました。
- [16:37] 彼はデジタルカメラを持っていなかったため、このページはASCIIアートを使用しました。それはCanon Digital Rebelの七年前のことでした。
- [16:50] 彼はそのページにMicrosoftのメールアドレスを記載し、それはGeoCitiesが2009年に閉鎖されるまで残りました。
- [17:03] 13年間、彼はフィンランドなどで生の竹をどこで入手できるか尋ねる人々から毎月メールを受け取りました。
- [17:18] そのページはまだアクセス可能で、URLは講演者のノートにありますが、彼はそのアートワークを恥ずかしく思っています。
- [17:53] 最近では、彼はウクレレの製作を始め、材料や工具をオンラインで購入し、YouTubeの動画を見て、フォーラムで情報交換をしています。
- [18:19] 彼は、eBayでウクレレ用木材の検索結果が何百件もあるような、オンライン上の情報の豊富さを驚くべきことだと考え、新しい自然の秩序を示していると感じています。
インターネットが人間の相互作用を加速
Mosaicチームの流出とInternet in a Box
- [19:14] 1994年にMosaicのコアチームはほぼ同時にNCSAを去りました。
- [19:23] マーク・アンドリーセンはすでに前年に去っていました。
- [19:26] 講演者は辞職し、別の仕事のためにシアトルに移りました。
- [19:30] マーク・アンドリーセンはジム・クラークと共に戻り、エンジニアリングチームが分散する前に残りのメンバーを採用しました。
- [19:45] 講演者はSPRYに参加し、同社はInternet in a Boxという製品を開発しました。
- [20:01] Internet in a Boxは、インターネットに接続するために必要なすべてをバンドルしていました。
- [20:07] このパッケージには、Usenetブラウザ、電子メールシステム、Gopherクライアント、そしてウェブブラウザが含まれていました。
- [20:15] 当時は、ウェブが他のプロトコルに勝つかどうかはまだ明らかではありませんでした。
SPRY、Spyglass、そしてMicrosoft IEへの参加
- [20:35] 講演者はSPRYについて深く語ることを避けています。なぜなら、その会社は正当な理由で失敗したからです。
- [20:44] SPRYとSpyglassはまったく異なる会社でした。
- [20:49] SPRYを去って一年後、話者はMicrosoftのInternet Explorerチームに加わりました。
- [20:55] NCSAはソフトウェアライセンス事業に関わりたくなかったため、自社のコードをSpyglassにライセンス供与しました。
- [21:06] Spyglassはライセンス供与されたコードを他社に再販し、MicrosoftはそれをSpyglassからライセンス供与されました。
- [21:15] Spyglassはすべてのコードをゼロから書き直したと主張しましたが、講演者はその多くに見覚えがありました。
- [21:29] そのコードは、講演者が書いたコードと特異な点を共有していましたが、必ずしも誇れるものではありませんでした。
- [21:38] 講演者はIE 2.0が出荷される直前にIEチームに加わりました。
Netscape、Windows、そしてブラウザ戦争
blinkタグとブラウザ戦争
- [22:52] blinkタグは、一晩飲酒した後にNetscapeのエンジニアによって作られました。この話はWikipediaに記録されています。
- [23:32] Microsoftはblinkタグを嫌っており、点滅する光に敏感な人々に害を及ぼす可能性があると考えていました。
- [23:47] NetscapeがCSSにtext-decoration: blinkを含めるよう要求したとき、Microsoftはそれを解析して適用することには同意しましたが、実際に点滅させることは拒否しました。
- [24:01] CSS1仕様にはblinkが含まれていましたが、ブラウザが点滅効果を視覚的にレンダリングすることを要求していませんでした。
- [24:07] Microsoftはブラウザ競争でNetscapeを凌ぐためにmarqueeタグを作りました。
marqueeタグとGoogleのイースターエッグ
- [24:14] Googleでmarqueeタグを検索すると、このタグのスクロール動作を再現するイースターエッグが表示されます。
- [24:33] marqueeタグの中心的な機能は、テキストを前後にスクロールさせることでした。
- [24:38] IEチームはまた、marqueeに垂直スクロールと垂直テキスト積み重ねを実装しました。
- [24:54] 垂直marqueeテキストは、当時の韓国語のテキストとフォントの仕組みに合っていたため、韓国で特に人気がありました。
- [25:06] IEチームは、マーキー機能が非常に多用されていたため、それを削除すると多くのコンテンツが壊れるとして、十年以上もの間その機能を削除できませんでした。
- [25:18] Internet Explorer 3は1996に出荷されました。
IE対Netscape：レイアウト、CSS、そしてチェックインベア
- [25:27] IEはウィンドウのリサイズ時にページを動的にレイアウトしました。これは講演者がNCSA Mosaicのために書いたシステムです。
- [25:41] Mosaicのレイアウトはテキストを決して再結合されないランに分割していたため、ウィンドウを縮めるとメモリ使用量が増加しました。
- [26:12] Netscape Navigatorはウィンドウのリサイズ時にネットワークからページを再読み込みし、フォームフィールドのデータを失っていました。
- [26:40] Netscapeは、リサイズ時にフォームデータを失わないようにするために、ページロードをまたぐキャッシュを始めました。
- [26:55] 機能ごとの比較により、NetscapeがIEよりも安価な機能を狙っていることが明らかになりました。
- [27:06] 講演者は、IE 3のためにフレームの代わりにCSSを提案し、ブラウザで最初にCSSを実装しました。
- [28:04] IE 3のリビジョン管理は同時チェックインで失敗したため、チームは物理的なテディベアをセマフォとして使用しました。
IE4 Tridentエンジンとスタイルシート
- [28:40] IE 3を出荷した後、チームはIE 4の計画を始めました。
- [28:51] MicrosoftはIE 4のためにTridentエンジンと呼ばれるまったく新しいエンジンを構築しました。
- [28:57] 講演者は、Forums Cube Teamによる講演に招待されたときに初めて新しいエンジンについて知りました。
- [29:12] 同僚のJeffはその講演に出席し、意気消沈して戻ってきて、「我々は終わった」と言いました。新しいエンジンはライブの動的環境ですべてを実行できたからです。
- [29:34] Jeffは半分正しく、講演者はすでにスタイルシートを実装していました。
- [29:38] 一週間後、話者はTridentチームに自身のスタイルシート作業をデモンストレーションする講演を行いました。
- [29:50] 聴衆の一人が、特定の機能を出荷しないでほしいと頼みました。それらと互換性を持たせなければならなくなるからです。
- [29:57] その要求に応えて、話者は二つではなく三つの機能を含めることにしました。
IE4 ダイナミックHTMLとActiveDesktop
- [30:00] 彼はスタイルシートの作業のためにIE 4チームに加わるよう求められましたが、オブジェクトモデルチームに配属されると告げられました。
- [30:14] この時代の重要な変化は、すべてが動的にプログラミング可能になったことでした。
- [30:21] IE 4以前、IE 3とNetscape Navigatorでは、再プログラミングできたのは画像、ハイパーリンクターゲット、入力フィールドのみで、レイアウトを変更することはできませんでした。
- [30:50] 新しいシステムでは、inner HTMLを変更し、まったく新しいドキュメントを挿入し、ドキュメントオブジェクトモデルを変更することができました。
- [31:02] 彼はhasLayoutについての45分以上の講演を省略し、それは自分のせいではなかったとだけ述べています。
- [31:16] Netscape Navigatorには動的システムがなく、Mozillaとなったその新しいシステムは遅れました。
- [31:29] Netscapeは変更可能なコンテンツのためにCSSポジショニングの代わりに新しいLayerタグを提案しましたが、MicrosoftはCSSポジショニングを行うことに固執しました。
- [31:50] この競争は、Windows 98でActiveDesktopを出荷するに至りました。これにより、ウィンドウ装飾がウェブコンテンツで行われるウェブコンテンツをデスクトップにドロップできるようになりました。
- [32:07] ActiveDesktopは、それを理解した人々にとって恐ろしいものでした。なぜなら、それは非常に重量級のシステムをデスクトップに投入したからです。
IE 5-6時代とマイクロソフトのつまずき
- [32:20] Alex HauptmannのチームはOutlook Web Access用のデータ転送制御を構築し、IE 5時代にMSXMLで出荷しました。
- [32:40] IE 5はOfficeとの整合を図りながら、多くのマイナーリリース（5.0から5.01D）で出荷されました。
- [32:52] IE 5の後、マイクロソフトは主に再設計を行い、IE 5.5でネイティブフレームを導入し、IE 6でIE 5.5が壊したものを修正しました。
- [33:13] ブラウザの採用はこの時期にピークに達し、マイクロソフトはそのピークをうまく処理できませんでした。
- [33:27] IE 6のリリース時、マイクロソフトは最高のブラウザを持っており、Netscape Navigatorよりも優れており、Mac製品はWindows製品よりも優れていました。
- [33:49] 当時のウェブにはリッチなレイアウトが欠けており、スタッキングやグリッドはありませんでしたが、フローテキストとテーブルはうまく処理できました。
- [34:03] マイクロソフトの強硬な互換性哲学により、標準サポートの修正には、古いゲームのヘルプページのような些細なものを壊す場合でも承認が必要でした。
- [34:29] ウェブは開発者をWindowsに呼び戻すことはなく、マイクロソフトはなぜそれにそんなに投資したのか疑問に思うようになりました。
Avalon、マッシュアップ、ブラウザ戦争
- [34:45] Avalonは開発者市場を維持するために作られ、.NET Framework 3.0になりました。
- [34:56] Avalonの取り組みは最終的に失敗し、マイクロソフトはその市場を失い衰退しました。
- [35:08] 複数のコンポーネントとデータソースを組み合わせたマッシュアップアプリがますます重要になりました。
- [35:11] 講演者はマッシュアップに関する内部ホワイトペーパーを書きました。
- [35:22] シカゴの犯罪統計を地図ソフトウェアと動的に組み合わせることは当時印象的でした。
- [35:34] WebKitとFirefoxが勢いを増し始めました。
- [35:39] WHATWGはW3Cが道を見失ったために結成されました。
Internet Explorer 7からの教訓
- [35:50] 2004年、マイクロソフトはブラウザに対して行動する必要があると認識し、講演者が最も個人的に誇りに思うIE 7のリリースにつながりました。
- [36:03] その誇りは出荷されたものからではなく、ゼロからチームを構築したことから来ました。
- [36:10] IE 7のWikipediaに記載された機能には、タブブラウジング、ページズーム、統合検索ボックス、フィードリーダーが含まれていましたが、ウェブ標準のサポートはわずかに改善しただけで、依然として基本的なテストに失敗しました。
- [36:27] チームは悪者扱いに慣れる必要があり、悪魔に扮したブログコメンテーターが講演者に仕事をオファーすることもありました。
- [36:48] 講演者はYouTubeのコメントを読んだり、人々にあまり注意を払いすぎないようにアドバイスしています。
- [36:53] 講演は今、Chromeが始まった時期に達したばかりで、それは代わりにPeterがカバーします。
- [37:05] マイクロソフトはブラウザではなくプラットフォームに最小限の投資を続け、それは彼らにとってうまくいきませんでした。
- [37:18] IEからの重要な教訓：トップに立って慢心してはいけない、そして競争に焦点を当ててはいけない。競争は二人のプレイヤーがいないと成り立たないからです。
- [37:41] チームは風変わりな動作を避けようとし、注意を払い、仕様に従うために多くのテストページを構築しました。
- [37:51] 賢い人々が皆あなたの会社で働いているわけではなく、破壊的要因を無視してはいけません。
モバイル革命とウェブの課題
- [37:58] モバイル革命はブラウザ戦争と同時に起こり、Chromeに課題を生み出しました。
- [38:08] 講演者はMotorola StartacからiPhoneへ12年かけて移行しました。
- [38:24] iPhoneのセンサー、タッチスクリーン、パワーは大きな飛躍をもたらしました。
- [38:32] 35歳以上のユーザーでさえiPhoneに適応し、ギターチューナーのようなデバイスを置き換えることを期待しました。
- [38:55] ウェブはモバイルの準備ができておらず、依然として1024x768解像度用に設計され、ページはハードコードされていました。
- [39:10] ウェブコンテンツをiPhoneに再マッピングするためのAppleのルールは、ページを正しく見せるためにその固定解像度に依存していました。
- [39:23] 当時のウェブはタッチ入力に開かれておらず、しばしばキーボードを必要とし、ネットワークは不安定でした。
Web 2.0とプログレッシブウェブアプリ
ウェブプラットフォームの普遍性とクロスデバイスの課題
ユーザーを尊重し、聞き手になる
[0:03] クリス・ウィルソン：こんにちは。今日はウェブの歴史についてお話しします。1990年代初頭のささやかな始まりから、ブラウザ戦争の浮き沈みを経て今日に至るまでを。そして、この講演の多くは、私個人にとってはノスタルジーです。今日のウェブに歴史がどんな影響を与えたか、たくさん見ていただければと思います。ジョージ・サンタヤーナが言ったように、過去を覚えていない者は、それを繰り返す運命にあるのです。それは絶対に避けましょう。インターネットエクスプローラーの歴史についてもたくさん話します。
[0:34] その理由はすぐにわかります。しかし、私はこの多くが今日の私たちの位置に導いたとまだ信じています。しかし、メル・ブルックスの映画のように、私は多くを飛ばさなければなりません。今日のために最初にまとめたデッキは、一時間半ほどだったと思います。何とか最後まで行き、時間通りに終えられることを願っています。それでは、こんにちは。クリス・ウィルソンです。私は非常に長い間ウェブプラットフォームに携わってきました。26年以上前に始めました。私は、ティム・バーナーズ＝リーのブラウザの後、最初の真のマスマーケット向けブラウザであるNCSA MosaicのWindows版を共同執筆しました。
[1:10] 私はエンジニア、PM、リードPM、GPM、デベロッパーアドボケイトを務めてきました。現在はChromeのTPGMチームに所属しています。私は四つの異なるブラウザに携わったと思いますし、2010年からGoogle社員です。ちなみに、それはChromeバージョン6以降のことです。Chromeバージョン6は私が始めてから一週間後に出荷されました。誤解しないでください。それはすごく印象的に聞こえます。私は部屋の中で一番賢い人間だとは思いませんし、ましてやこの部屋では絶対にそうではありません。
[1:43] ハミルトンの引用をお借りすれば、私は何度も何度もその場に居合わせてきました。長年にわたって、それはかなりクールなことです。しかし――皆さん、しばし心を過去に戻してください。中には生まれる前という方もいるでしょう、1988年へ。1988年は私がイリノイ大学に学部生として入学した年です。当時のインターネットがどんなものだったかを示すのに、このグラフは素晴らしいです。ラベルはほとんど読めませんが、1988がだいたいここにあります。そして、ほとんど存在していないことに気づくでしょう。
[2:16] その時点でインターネットのことを本当に聞いた人は誰もいませんでした。実際、学界ではまだARPANETとして広く知られていました。そして、私の入学した学部のクラスには、デフォルトでメールアカウントが発行されませんでした。実際にコンピュータラボに行き、直接頼まなければなりませんでした。そして実際、私たちはメインフレームにログインしました。つまり、人々は通常接続する能力を持っていませんでした。そして、このメインフレームシステムでは週七時間の時間制限がありました。
[2:47] そして私はよくこれをUltimate Larnのプレイで使い果たしました。なぜなら七時間しかなかったからです。たいてい最初の二日間で使い果たし、それから土曜日の朝までメールをチェックできませんでした。ありがたいことに、工学部の学生は別のメインフレーム上で時間制限のない二つ目のアカウントを得ました。ですから明らかに、私はコンピュータサイエンスの授業に合格しました。これが私の最初のインターネット端末でした。それは夏の間働いていた仕事からお下がりでもらった端末でした。HP 2622A端末でした。
[3:20] 上部に統合サーマルプリンターがありました。最高でした。これを、当時としては驚くほど高速な2,400ボーのモデムを介してイリノイ大学のシステムに接続しました。参考までに、私の携帯電話は全体のLTEで約6,000倍速い接続、自宅のWi-Fiでは60,000倍速い接続が得られると計算しました。あるいは、ここマウンテンビューのホテルのWi-Fiの約二倍の速度です。
[3:50] しかし、これは単なるテキスト端末でした。つまり、インターネットは主にテキストでした。実際、ここで私が指摘した点の一つは、本当に電子メールであり、Usenetであり、IRCであり、Gopherでした。FTPもクールでしたが、率直に言って、ソフトウェアの共有を除けば、はるかに使用頻度は低かったです。さて、心配しないでください。私のプレゼンテーション全体がダグラス・アダムスの引用だけではありません。もういくつかあると思います。しかし、これは本当に――これは常に覚えておくべきことです。
[4:21] あなたが生まれたとき、または非常に若いときに世界にあるものは、ただ普通です。それが世界の仕組みです。私には二人の娘がいます。インターネットは世界の仕組みです。彼女たちはそれについて考えさえしません。モバイルデバイス？もちろんです。あなたが15歳から35歳の間に発明されたものは新しく、エキサイティングで、おそらくそれでキャリアを築くことができます。そして、インターネット、ウェブは、間違いなく私が15歳から35歳の間に発明されました。さて、私はここで「芝生から出て行け、若造ども」と言うために来たわけではありません。
[4:52] ウェブはもう終わった。あなたが思いつくことはすべて、物事の自然な秩序に反している。課題は、本当に、それをどうやって取り入れて、物事の自然な秩序に適応できるようにするかだ。将来それが何になり得るかを考えてみてほしい。そうでなければ、私は Chrome がリリースされる前に 35 になってしまうので、それは問題だろう。1991 年に、私は全米スーパーコンピューティング応用センターでアルバイトを始めた。これを全部綴るのはこれが最後だ。NCSA は NSF の最初の五つのスーパーコンピューティングセンターの一つであり、NCSA 内の私たちのグループの使命は、研究者がデスクトップ上でスーパーコンピュータの力を利用できるようにするソフトウェアツールを構築することだった。
[5:39] そこで私たちはTelnetを作りました。文字通りTelnetを作ったのです。実際、それが私が雇われた理由で、端末に取り組むことでした。念のため言っておくと、これはWindows 95より前でした。Windows 95より前でした。TCP/IPネットワークスタックはありませんでした。PC TelnetはDOSソフトウェアでした。最終的にはWindowsソフトウェアを作らなければなりませんでした。また、可視化ツールなども作りました。データの読み込みや整形のツール、そういったものです。
[6:11] しかし、このプロジェクトが立ち上がったとき、それはぴったりでした。数人の男たちがMosaicというX Windowsソフトウェアを考案し、スイスの誰かがワールドワイドウェブと呼ぶものにアクセスできるようにしたのです。HTMLというプロトタイプの文書言語を使っていました。それはまあ――そう、それが私の人生の次の26年間でした。私はこのWindows版を共同で作りました。
[6:42] ちなみに、NCSA Mosaic には Mac、PC、Windows、X Windows の三つのバージョンがあった。それらは全く異なっていた。コードを全く共有していなかった。お互いのコードは見たが、クロスプラットフォームのソフトウェアは、実際には存在しなかった。私はまた、このせいでモザイクという言葉が完全に台無しになった。モザイクという言葉を聞いても、私は芸術作品を思い浮かべない。しかし覚えておいてほしいのは、繰り返しになるが、当時 Windows にはネットワークサポートがなかったということだ。Windows には組み込みのネットワークドライバがなかった。
[7:15] つまり、ソケットがなかったのです。別途パッケージを購入すれば追加できました。ネットワーク機能を備えたWindows 3.11でさえ、名前を思い出せませんが。Windows for Workgroupsだったと思います。それにもTCP/IPは内蔵されていませんでした。ソケットもありませんでした。ネットワーク機能はありましたが、Novellか何かを通じてでした。ですから私たちはすでに独自のネットワークスタックを持っていました。実際に文字通りネットワークカードのデバイスドライバを書いていたのです。例えば、私はこういったものをデバッグしていました。ある時はTCP/IPのフォールバックアルゴリズムをデバッグしました。
[7:50] そしてそれをWindowsで動作させました。HTMLのパースとレンダリングの仕組みなど、そういったものをすべて構築しました。NCSAには大量のベータ版をリリースするという伝統がありました。つまり、基本的には自分のマシンでビルドして、リリースを公開するという感じです。実際に私はいくつかのデバッグ版リリースを公開したと思います。というのも、ある時バグが見つからなかったのですが、結局それはもちろんポインタの初期化の問題でした。ともあれ、私たちはWindows Mosaicを初めてFTPサーバーに公開しました。
[8:20] そして覚えていますが、一週間後に1,000ダウンロードに達したとき、私たちは非常に興奮しました。さて、私はこの講演を2011年に行ったと思いますが、Firefoxが1,000ダウンロードを達成するのにどれくらいかかったかを計算したところ、それは一瞬の何分の一かで測定されました。ですから、スケールが少し違います。しかし、それでも本当に驚くべきことは、ゲームDOOMが同じ年に発売され、それでも私たちはMosaicの作業を何とか完了できたことです。なぜなら私たちは大学生だったからです。
[8:53] つまり、私たちは学生でした。NCSAには「教育と研究を可能にせよ」という素晴らしい全体的な使命がありました。そして私たちは多くのことを探求することができました。もしそれがなければ、ウェブブラウザを作ることはできなかったでしょう。当時それは私たちのソフトウェアツールグループの使命には含まれていませんでした。私たちは画像可視化ツールやTelnetなどを作る使命を与えられていました。これは私がGoogleと共通点として挙げるものの一つです。なぜならGoogleにはそうした柔軟性がたくさんあるからです。
[9:26] それはここで働く上で私が本当に気に入っている点の一つです。さて、しかし全体として、私たちはMosaicでたくさんの愚かな間違いを犯しました。何をしているのかよく分かっていなかったからです。あまり多くのサポートもありませんでした。ビジネスプランもありませんでした。まあ、多くのドットコム企業もビジネスプランを持っていませんでしたが、私たちには本当に、例えば私のコンピュータサイエンスの学位にはユーザーエクスペリエンスの授業などありませんでした。ソフトウェアテストの理論などもありませんでした。
[9:56] そして、私たちにはリビジョン管理システムさえありませんでした。Windows Mosaicに取り組んでいたのは二人でした。ネットワークドライブはありませんでした。ですから、文字通り、同じコードで作業し、それをZipディスクに保存し、オフィスを横切って歩き、もう一人のドライブに差し込み、正しいファイルをコピーし、うまくいくことを願っていました。ですから、私たちはいくつかの愚かな選択をしました。そして、特に私個人が責任を負うものの一つがこれです。私は、初期のウェブで太字と斜体のタグの重複が機能するようにしたことに個人的に責任があります。
[10:32] なぜか、これはかっこいいと思ったのです。常識やSGML構造化文書の品位のあらゆる違反を甚だしく犯すことになるとは。ちなみに、はい、私たちは今でもChromeやおそらく他のすべてのブラウザでこれをサポートしています。品位あるものすべてを違反しないような興味深い方法でやっています。しかし弁明させてもらえば、当時はかっこいいと思ったのです。しかし初期のウェブ、それも本当に初期のウェブ、というのも覚えておいてください、私は93年頃にいたのですから。
[11:10] それは本当に魅力的でした。そして魅力的だった理由は、これらすべての情報にアクセスできるようになったからです。つまり、Googleの使命は世界の情報を整理し、世界中でアクセス可能で有用なものにすることです。そして先ほどParisaがこの質問をしたときに後ろで話していたのは私です。というのも、それは私のスライドに何度か出てくるからです。そして覚えておかなければならないのは、当時、世界の情報はインターネット上にはなかったということです。インターネットは、私たちはそのランプの低い部分にいたのですよね？
[11:42] その情報の多くはまだデジタル形式にすらなっていませんでした。つまり、情報を得るには図書館に行かなければならなかったのです。やがてもちろん、多くの情報を以前に見て、私たちがウェブプラットフォームをどう捉えがちかを知っている人なら誰でも、ここにあるLICEの頭字語の一部を認識するでしょう。しかしこの時点では、それは実際にはインデックス化できませんでした。あるいはインデックス化はできましたが、それに対するインデックスがなかったのです。実は、持ってくればよかったのですが、私の本棚にこの本があります。製本された紙の本で、文字通りURLのリストとその説明が載っているのです。
[12:18] それは確か93年に出版されたと思います。93年か94年か、どちらだったか覚えていません。そしてそれは、ほら、これはホノルル・コミュニティ・カレッジのウェブサイトで見つけられるものだ、といった内容で埋め尽くされた分厚い本なのです。ですから最も重要なのは、NCSAで私たちはこう認識していたことです――このウェブというものの最も素晴らしい点は、誰もが著者になれるということだと。というのも、当時のほとんどのシステムは、誰もがサーバーを立ち上げて情報を共有できるようには設計されていなかったからです。
[12:51] 特にGopherはそうでした。Gopherのクライアントは簡単に入手できました。Gopherのサーバーソフトウェアは莫大な費用を払わなければなりませんでした。つまり基本的には、ソフトウェアの運用に非常にお金がかかったので、大学か民間企業だけが運用していました。そこで私たちはNCSAで、この情報共有を促進しようと実際にいろいろなものを実装しました。実際に1993年でさえ、グループ注釈機能を実装しました。
[13:21] たとえば、ウェブページに注釈を付けることができ、同じ注釈サーバーを共有しているグループ内の誰もが、同じウェブページを訪れたときにあなたの注釈を見ることができました。また、ウェブサーバーソフトウェアは無料であるべきで、誰もが自分のマシンでサーバーを動かすべきだという考えもありました。これを文脈に置くと、当時は今日の状況から見て、大規模なセキュリティ問題を何世代も経た先の話でした。実際、私はNCSAの自分のオフィスのPCでウェブサーバーを動かしていました。
[13:54] それは世界中からアクセス可能でした。つまり、文字通り誰でも私の個人用マシンにFTPできたのです。実際、私たちはネットワーク対応の宇宙ドッグファイトゲームを書きました。私と大学時代の友人のグループで、そのためにNCSAのPC Telnetコードを借りました。そして、それをプレイした後、起動して動かせるようになりました。それはもう、最高でした。あの初期のLANパーティー。素晴らしかったです。しばらく動かした後、私はPC TelnetコードのFTPサーバーを無効にしていなかったことに気づきました。
[14:26] 案の定、友人がゲームをプレイしている間に彼のマシンにFTPして、大きなダウンロードを始めることができました。彼はあまりそれを好みませんでした。でも素晴らしかったのは、たくさんの奇妙なコンテンツがあったことです。当時これは画期的でした。なぜなら、こうしたコンテンツにはアクセスできなかったからです。ホノルル・コミュニティ・カレッジのKevin Hughesという人物がいて、そのホノルルのコミュニティ・カレッジには本当にクールな恐竜博物館があります。そこで彼は、ああ、これは素晴らしいと思いました。
[14:58] デジタルカメラで写真を撮ってオンラインに載せよう、と。そして彼はそうしました。すると、こうした奇妙なものがただ出てくるのです。そしてこれが、何よりもウェブの成長に貢献したのは、ロングテールという概念だと思います。ロングテールを聞いたことがない人は？ はい、では少数ですね、それは良いことです。ここでは、コンテンツの大部分、つまり全体の母集団がこのテール部分にあります。残念ながら、色がめちゃくちゃになっています。でも、ここにあるものすべては、関心で測ると、最も人気のあるものと同じくらい人気があります。
[15:35] 別の見方をすると、ウェブは素晴らしいのです。なぜなら、人々は珍しい話題に非常に強い関心を持つからです。時にはTaylor Swiftの最新ビデオよりも、そうした関心が勝ることもあります。ちなみにそれは素晴らしいですよ。これは今日では当たり前のことです。これは、うんうんとうなずいて、ええ、まあそうだねと言う類のものの一つです。当時は新しいことでした。なぜなら、90年代初頭には、ロングテールに実際にアクセスすることはできなかったからです。実際、90年代初頭、あるいは90年代半ば、正確には1996年に、私はディジュリドゥの演奏を学ぶクラスを受講しました。
[16:12] クラスの一部は、ディジュリドゥの作り方でした。私は、ああ、これは本当にクールだと思い、竹のディジュリドゥの作り方についてウェブページを公開しました。ちなみに、とても簡単です。多かれ少なかれ、穴を開けるだけです。でも、GeoCitiesを覚えている人はどれくらいいるでしょう？ その通り。ノスタルジー好きの方々、いいですね。私は竹の節からディジュリドゥを作る方法についてGeoCitiesのサイトを公開しました。まだデジタルカメラを持っていなかったので、ASCIIアート付きで。
[16:44] 参考までに、これは Canon が Digital Rebel を発売する七年前のことだった。だから本当にそれほど人気があったわけではなく、私はそこに Microsoft のメールアドレスを載せていた。そして、はい、今日ではそれはクレイジーなことのように思えるが、私はそうした。そしてこのページは 2009 年に GeoCities が閉鎖されるまで残っていた。その間ずっと、13 年間、少なくとも月に一度は、誰かから「こんにちは、これは素晴らしいですね。フィンランドで生の竹をどこで手に入れられるかご存知ですか」というメールが届いた。
[17:18] ちなみに、このページは今でもアクセス可能です。本当に見たい方のために、URLはこのページのスピーカーノートにありますが、今はそこへ行きません。そこのアートワークが少し恥ずかしいからです。でも、この話をするのは、皆さんが竹のディジュリドゥ作りに興味があると思っているからではありません。もちろん、それについて話すのは喜んでしますが。カリフォルニアで生の竹をどこで手に入れるかという細かい詳細に実際に興味がある人はさらに少ないでしょう。私は知っています、ここにしばらく住んでいましたから。
[17:49] でも、皆さんにも同じくらい珍しい趣味があるでしょう。実際、対照的に、ここ数年、私は余暇にウクレレを作り始めました。材料や道具はオンラインで買っています。側面を正しく曲げる方法などの動画をYouTubeで見ています。木材の選択についてフォーラムで情報交換したり、eBayで珍しい木材を閲覧したりしています。これは実際にあることです。私はeBayでukulele woodを検索していました。
[18:24] しかも、それは五ページ程度ではありません。何百もの結果があるのです。そして、私は自分の年齢を露呈しているわけですが、これを素晴らしいと感じています。つまり、これは衝撃的で、皆さんが持つ情報へのアクセスなのです。これは大規模に新しい自然の秩序です。そして、これは私が自分のキャリアについて何十年も言ってきたことにつながります。すなわち、ウェブとインターネットは人間の交流がより速く、より少ないガードレールで、より少ないスピードバンプで行われるのを助けるだけだということです。
[18:54] ちなみに、以前はこれは無条件に良いことだと思っていました。もうそうは思いません。ですからこれはある種の伏線です。人間の交流をどのように可能にするかには注意してください。しかし、それは確かに地理的な障壁と情報の障壁を取り除きます。ともあれ、1994年に、Mosaicのコアチームはほぼ全員がほぼ同時期にNCSAを去りました。Mark Andreessenは前年に去っていました。
[19:26] 私は辞めて、別の仕事に就くためにシアトルへ向かいました。そしてMarkがJim Clarkとともに戻ってきて、残りのエンジニアリングチームを、彼らが去って四方八方に散る前に掻き集めました。なぜなら、私が最初に去ったのを見て、私が最後になるわけではないと分かったからです。しかし私はSPRYという会社に行きました。彼らはInternet in a Boxという製品を作っていました。私は文字通りこれも本棚に持っていました。そうです、インターネット全体が箱に入ったものです。
[19:58] しかし、それはある意味かっこよかったのです。なぜなら、これはインターネットに接続するために必要なものすべてを含むパッケージだったからです。当時、これはかなりかっこいいものでした。Usenetブラウザがありました。メールシステムがありました。そしてGopherクライアントがありました。ウェブブラウザもありました。ちなみに、当時はウェブが勝者であることはまだ明らかではありませんでした。これらすべてを持っていたのです。この講演を準備していたとき、MacでCommandタブを押したら、文字通り実行されているのはブラウザの二つのコピーと電卓だけでした。
[20:31] そしてそれは、アイコンをクリックするだけで電卓にアクセスする方が簡単だったからです。さて、私は特にSPRYについてあまり話したくありません。なぜなら、彼らは正当な理由で消えたからです。ちなみに、これはSpyglassではありません。Spyglassは全く別の会社でした。そして実際、一年後に私はSPRYを去り、MicrosoftのInternet Explorerチームに加わりました。Spyglassは、NCSAがコードをライセンス供与した会社でした。なぜなら、ソフトウェアライセンスのビジネスはNCSAが望むビジネスではないと気づいたからです。
[21:06] そしてSpyglassはそれを他のすべての会社に再販し、Microsoftは実際にSpyglassからライセンスを受けました。Spyglassはコードをすべてゼロから書き直したと言っていました。ただ言っておくと、そのコードの多くは非常によく見覚えがあり、その多くは、アーキテクチャ上の選択も含めて、そう、私が書いたコードと同じような特異な癖を持っていました。必ずしも誇れることではありませんが、同じでした。
[21:38] ちなみに、私はIE 2.0を出荷する直前にIEチームに加わりました。この引用を聞いたことがある方も何人かいるでしょう。Mark Andreessenは「NetscapeはWindowsをデバッグの不十分なデバイスドライバの集合体に貶めるだろう」と述べたと引用されています。ちなみに彼を擁護すると、Markは実際にはBob Metcalfがこれを言ったと述べており、ただそれをリツイートしていただけでした。まあ、引用していたのですが、当時JavaScriptはありませんでしたから。
[22:09] Twitterもありませんでした。これはMicrosoftへの安っぽい皮肉に見えるかもしれません。実際はそうではありません。なぜなら、当時私はそれを信じていなかったからです。私はその後15年間Microsoftで働き続けました。今でも信じていません。なぜなら、それらのデバイスドライバは今では本当によくデバッグされているからです。しかし、この発言が予兆していたこと、つまり世界はやがてウェブプラットフォームとその上に載るソフトウェアになるのであって、Windowsの上に載る大量のソフトウェアではなくなるだろうということを、私たちの誰も予想していなかったと思います。
[22:44] そしてこれが本当にブラウザ戦争の火蓋を切りました。ブラウザ戦争の醜さを表す私のお気に入りの例はblinkタグです。blinkタグがどうやって発明されたかという話を聞いたことがある人は何人いますか？わあ、そうですか。これはなかなか良い話です。私はこの件の当事者ではありませんでした。この出来事が起きた部屋にはいませんでした。blinkタグは、Netscapeのエンジニアたちがとある夜に飲みに出かけたことから生まれました。冗談ではありません。Wikipediaに載っています。調べてみてください。
[23:15] そしてそのうちの一人、あるいは複数人が「ああ、すべてを点滅させるタグを作るべきだ」と言いました。彼らは飲みに出ていたので、一人がオフィスに戻ることにし、翌朝、同僚たちにblinkタグを見せました。さて、Microsoftでは私たちはblinkタグを嫌っていました。「なんてこった、なぜこんなものを作るんだ？なぜこんなことをするんだ？」と思いました。まるで、何というか、点滅する光に敏感な人々を刺激しようとしているかのようです。
[23:46] これはひどい。実際、NetscapeチームがCSSにtext-decoration: blinkを含めるよう要求したとき、私は「いいだろう。パースはする。適用もする。しかし、実際に点滅させることを強制される筋合いはない」と言いました。少なくともCSS1仕様には含まれていました。実際に視覚的に点滅させることは必須ではありませんでした。とはいえ、私たちは彼らを出し抜いて点滅させなければなりませんでした。それがmarqueeタグの目的でした。marqueeタグについては、Google検索で「marquee tag」と検索してみてください。
[24:21] これは実際に素晴らしいです。なぜなら、今ではGoogle検索で私のお気に入りのイースターエッグになっているからです。実際にmarqueeタグを再現しているのです。タグの検索結果が左右にスクロールし始めます。それが基本的にmarqueeがやっていたことです。テキストを左右にスクロールさせていました。実はこの冗談はIEチームの私たち自身に向けられることになりました。なぜなら、私たちは縦方向にもスクロールさせ、テキストを縦に積み重ねることもできるようにしたからです。まるでmarqueeのように、タイムズスクエアを歩いているときのような縦書きのテキストです。
[24:54] そしてどうやら、これは韓国で非常に人気がありました。なぜなら、当時の彼らのテキストとフォントの仕組みに合致し、韓国語のテキスト開発に役立ったからです。そして、私たちは文字通り、その後十年以上、それを削除できませんでした。なぜなら、それが非常に頻繁に使用されていて、多くのコンテンツを壊してしまうからです。さて、1996年にIE 3を出荷したので、これが私たちがいる時代です。
[25:24] そしてこの頃、理解しておくべき重要なこととして、IEは実際にページを動的にレイアウトしていました。ウィンドウのサイズを変更すると、単に再レイアウトしていました。これは実は私がNCSA Mosaicで最初のレンダリングレイアウトシステムを書いた方法でもあります。ちなみに、これが先ほど話した特異な癖でもありました。私はテキストの連続したまとまりを分割していました。ウィンドウを狭めると、異なる位置で分割する必要があり、その連続したまとまりは決して再結合されませんでした。ただ積み重なっていくだけでした。
[25:54] つまり、ウィンドウを目一杯まで縮めると、メモリ使用量がわずかに増え、システム全体の実行回数も増えるということです。彼らも同じ仕組みでした。一方、Netscape Navigator はというと、ウィンドウをリサイズすると、文字通りネットワークからページを再読み込みしていました。ディスクからですらありません。ディスクキャッシュがようやく一般的になるのは、その一、二年後のことでしたから。
[26:25] つまり、文字通りページを再読み込みしていたのです。実際、ページにフォームフィールドがあって、そのうちの一つが見えないことに気づいてウィンドウのサイズを変更すると、ページが再読み込みされてすべてが失われていました。まさにその理由で、彼らはページ読み込みをまたいで物事をキャッシュし始めたのです。しかし私たちは機能ごとの比較のためにこうした機能を作りましたが、彼らが私たちよりも安価な機能を目指していることがより明確になってきました。
[27:00] 私たちはJavaScriptで、テーブルで、フォントタグで、機能ごとの比較を実際に行いました。実は私はブラウザで最初にCSSを実装した人間です。これは上司が私のオフィスに来て、こう言ったからでした。「おい、私たちはIE 3の機能を計画している。フレームを担当してほしい。まだフレームをやっていなかったからね、iframe、フレームセットなどなど」。そして私は「おお、それはかっこいい」と思いました。でも、CSSと呼ばれるものがあるんです。
[27:30] Netscapeはまだこれを検討すらしていません。すごくかっこよくなるでしょう。こうした素敵な視覚的要素を全部できるんです。すると彼は「うーん、考えさせてくれ」と言いました。1/2時間後に戻ってきて「よし、それをやれ」と言いました。こうしてブラウザにCSSが搭載されたのです。先ほどコーディング、コーディングの品質、いわゆるソフトウェアシステムについて話しました。この時点で、少なくともリビジョン管理はありました。ネットワークドライブがありましたから。
[28:01] しかしIE 3の時代、複数の人が同時にチェックインしようとすると、私たちのリビジョン管理システムはあまりうまく機能しませんでした。なぜなら頻繁に多くの異なるファイルをチェックインしていたからです。そして私たちが「チェックインベア」と呼んでいたものがありました。これは文字通り物理的なテディベアです。ホワイトボードの隣の廊下に置かれていました。チェックインする必要があるときは、そのベアを取りに行き、ボードに名前を書き、ベアを持って行き、チェックインしている間ベアを自分の机に座らせておき、それから戻って、もし他の誰かがあなたの下に名前を書いていたら、代わりにその人にベアを渡すのです。
[28:36] ある意味興味深いセマフォでした。しかしIE 3を出荷した後、私たちはIE 4を見据え始めました。そしてマイクロソフトでは、IE 4で、まったく新しいエンジン、Tridentエンジン、後にTridentエンジンとして知られるものを構築しました。私がこれを初めて知ったのは、Forums Cube Teamと呼ばれるグループの講演に招待されたときでした。どこから来た名前なのか見当もつきません。彼らが何かを作っているという噂がありましたが、私は行く機会がありませんでした。
[29:10] 私は何かで忙しかったのです。しかしレンダリングエンジンに携わっていたもう一人の男、友人のジェフが行きました。そして彼が戻ってきます。彼は私のオフィスに来て、本当に本当に落ち込んでいました。「どうだった?」と聞くと、彼は「もう終わりだ。彼らは何でもできる。編集もできる。物事を変えられる。完全にライブの動的環境だ。私たちは職を失う」と言いました。そして彼は半分正しかったのです。なぜなら私はスタイルシートをやっていたからです。そして一週間後くらいに、私はTridentチームに講演を行い、スタイルシートでやったことすべてを披露しました。
[29:44] そして私は、これはどうなんだ、これはどうなんだ、と思っていました。出荷前にこの二つの機能を入れたいと考えていたのです。すると文字通り、聴衆の一人が言いました。「それはやめてもらえませんか。出荷されるものには、すべて互換性を持たなければならないんです」と。そこで、それだけのために、機能は三つになりました。そして彼らは私に、IE 4 チームに移ってスタイルシートに取り組むよう頼んできました。参加を求められたとき、私はオブジェクトモデルチームに入ると言われていました。そして私は「え？JavaScript チーム？スタイルシートをやれって言ったよね？」と思いました。しかし、これこそがこの時代の鍵となる点でした。すべてが動的にプログラム可能になったのです。
[30:21] それ以前は、IE 3、そしてIE 3を通じても、そしてNetscape Navigatorでもまだ、再プログラムできたのは画像だけでした。サイズはダメでした。レイアウトを変えられなかったからです。しかし視覚的なものを差し替えること、特定のハイパーリンクが指す先、入力フィールドはできました。それ以外は何も。文書のレイアウトを変えるものは何も。そして視覚的なものを変える唯一の方法は入力フィールドと画像でした。そして突然、すべてを作り直せるようになったのです。
[30:52] つまり、inner HTMLを変更してまったく新しい文書をそこに入れることができました。文書オブジェクトモデルの中で物事を変えられました。動的に変更できないものがいくつかありました。hasLayoutについての45分以上の講演がここにありますが、それはまったく飛ばします。ただ、本当に私のせいではなかったと言っておきます。時々そう言う人がいます。私のせいではなかったのです。そして、Netscape Navigatorには動的システムがなかったことを理解することが非常に重要でした。彼らはすべてのものを動的に変えられませんでした。彼らの新しいシステム、後にMozillaとなったものは遅れていました。
[31:29] これに対抗するために、オブジェクトモデルを通じてすべてをライブで変える代わりに、彼らは提案しました。「Layerという新しいタグを設けるべきだ。変化するものをレイヤーの中に入れられる」。しかしCSSポジショニングの話全体は、やめておこう、と。私たちは「いや、それはやるつもりだ」と思いました。多くの駆け引きが前後してありました。そしてこれらすべては、私たちがWindows 98でActiveDesktopを出荷したときに頂点に達したと思います。というのも、突然ウェブコンテンツをデスクトップにドロップできるようになり、そこのウィンドウ装飾はすべて実際にウェブコンテンツで行われていたからです。
[32:07] これは、何が起きているかを本当に知っていた私たちにとっては恐ろしいことでした。なぜなら、非常に低レベルのシステムを行うために、非常に重量級のシステムが投入されたからです。しかしこれはAjaxの夜明けでもありました。そう、これは、後にIEで一緒に働くことになるアレックス・ハウプトマンという男が、Outlook Web Accessのためにデータ転送システムを必要としていたのです。そこで彼らはこのコントロールを考案し、MSXMLで出荷しました。そしてこれはIE 5の時期に出荷されました。
[32:38] IE 5 のどのリリースだったかは定かではありません。というのも、文字通り IE 5.0、5.01、5.01A、5.01B、5.01C、5.01D がありましたから。私たちは Office と足並みを揃えて出そうとしていました。何度か試行錯誤が必要でした。その後、私たちは Microsoft でつまずきました。主に再設計をしていただけでした。IE 5.5 のこのネイティブフレームという仕組みへの移行などです。そして IE 6 は、IE 5.5 で壊してしまったものをすべて修正しました。本当に、それだけでした。何をすべきか、よく分かっていなかったのです。
[33:09] そしてその多くはこのグラフのせいです。これはこの期間のブラウザ adoption です。そこに素敵なピークがあるのがわかるでしょう。ほとんどの人はピークでうまくやれません。特にMicrosoftはそうですが、ほとんどの人がピークでうまくやれません。しかしIE 6を出荷したとき、私たちはちょうどここにいました。地球上で最高のブラウザを持っていました。つまり、私の多少偏った意見ではありますが、Netscape Navigatorよりずっと優れていました。
[33:41] 私たちのMac製品は実際、Windows製品より優れていました。Macチームがどこかで拍手していますが、理由もわかっていないでしょう。しかし、ウェブには実際、リッチなレイアウトがありませんでした。フローテキストは得意でした。テーブルも得意でした。しかし当時はスタッキングもグリッドもできず、それはちょっとまずいことでした。互換性は私たちにとって本当の問題になりつつありました。特にMicrosoftには非常に厳格な互換性の哲学があったからです。
[34:12] 標準サポートを修正するために何かを壊すには承認を求めなければならなかったのを覚えています。しかしそれは、三年前に出荷したゲーム、Microsoft Cart Precision Racing のヘルプページの何かを壊すことになるのでした。そして全体として、ウェブは開発者を Windows に呼び戻すことはなく、Microsoft は「開発者が増えないもののために、なぜこんなことをしているのか」と疑問を持ち始めました。すでにユーザーは全員いるのだから、なぜこんなことをする必要があるのか、と。
[34:45] 彼らはただ開発者市場を維持したかっただけでした。そこで私たちはAvalonプロジェクトを作り、それがdotnet framework 3.0になりました。そして、そこには少なくとももう45分の講演があるでしょう。そしてもちろん、これは結局彼らがその市場も失い、そして衰退することになりました。そしてもちろん、同時に世界は進み続けました。マッシュアップアプリのこのパターンはますます重要になりました。私はマッシュアップについて社内でこのホワイトペーパーを書きました。
[35:16] そしてこれは基本的に複数のコンポーネントとデータが一緒になり始めたということです。繰り返しますが、今日ではこれは自然に思えます。しかし、シカゴの犯罪統計とマッピングソフトウェアを持つ同じシステムがあり、それらを動的に連携させることができるという考えは、当時はかなり素晴らしいものでした。そしてもちろん、WebKitが traction を得始めました。Firefoxも traction を得ていました。そしてWHATWGもこのあたりで形成されました。W3Cが道を見失っていたからです。
[35:46] そこには数時間分の講演があります。そして2004年、Microsoftはついに目を覚まし、ああ、ちょっと待て、ここで何かをする必要があると言いました。そしてこれは実際、私が個人的に最も誇りに思ったリリースでした。実際に出荷したもののせいではなく、ほぼゼロからチームを構築しなければならなかったからです。残念な部分は、これを読むと、これはIE 7のWikipediaページからの引用ですが、タブブラウジングやページズーミング、統合検索ボックス、フィードリーダーなどの新機能と書かれています。
[36:22] そしてああ、そう、ウェブ標準のサポートは少し良くなりましたが、基本的なテストには合格しません。そしてその段階で、私たちは非難されることに慣れなければなりませんでした。実際、ブログのコメントでサタンのふりをした人が、その時点で私に仕事をオファーしてきました。いくら稼いでいるのか、仕事が欲しいかと尋ねてきました。そして私はちょっと心配だったので、その投稿を削除しませんでした。何が起こるかわかりませんから。でもYouTubeのコメントは読まないでください。人々にあまり注意を払わないでください。
[36:53] そして指摘しておきたいのは、私たちが今ようやくChromeが始まった時期に入りつつあるということです。ですから、それについては実際には触れません。Peterが私よりずっと上手にやるでしょうから。しかし、Microsoftはプラットフォームに最小限の投資を続けたと言えます。ブラウザではなく、プラットフォームにです。そしてそれは彼らにとってあまりうまくいきませんでした。そしてこの多くが、IEの経験から学んだ教訓につながりました。
[37:23] ただ単にその山の頂上にいるからといって、慢心してはいけません。Chrome は間違いなくそこから学べることがあります。競合に注目しないことは、大きな部分を占めていました。競合が二つだけならそれでうまくいきますが、多くの異なる人々がいて多くのことがある場合には、あまりうまくいきません。私たちは実際、風変わりなことをしないのがかなり得意です。注意を払うようにしています。たくさんのテストページを作り、仕様に従っていることを確認するようにしています。しかし何よりも、賢い人々が皆あなたの会社で働いているわけではないのです。
[37:55] そしてもちろん、ちょうどこの頃にやってきたモバイル革命のような破壊的要因を無視してはいけません。そしてこれはChromeでもいくつかの課題を引き起こしました。しかしこれは大きな出来事でした。私は12年で、このMotorola Startac——出たときは超セクシーだったと約束します。それは最高の電話でした。私はその電話が大好きでした。Lake Washingtonに落とすその瞬間まで。そこからiPhoneを持つようになりました。iPhoneには所有这些センサーがあり、タッチスクリーンは非常に魅力的で、本当に多くのパワーがありました。
[38:32] ちなみに、iPhone が発売されたとき、私は 35 にいました。それでも私は適応することができました。二年後にこう言ったのを覚えています。「そう、ベースラインだ。私の携帯電話は今やギターチューナーの代わりにならなければならない」と。とにかく動かなくてはならないのです。もうギターチューナーを持ち歩くことはありません。オフィスにギターがあり、私は音程に敏感なので、ちゃんと機能してほしかったのです。残念ながら、当時ウェブはモバイルプラットフォームではありませんでした。そうなっていれば素晴らしかったのですが、率直に言って、その段階ではウェブはまだ 1,024 によって 768 のために設計されていました。
[39:07] 文字通り、それはウェブページにハードコードされていました。Appleが自社デバイスへの再マッピングに関するやや風変わりなルールを打ち出したとき、彼らはこれに依存していました。そして、ほとんどのページを正しく見せるという点では、彼らは実際のところ間違っていませんでした。しかし、タッチ入力を行うには本当に開かれていませんでした。時々キーボードが必要でしたし、ネットワークもまだかなり不安定でした。人々はこれを予期していませんでした。そしてこれは非常に重要です。これは実際、ちょうどその頃のものでもあります。
[39:39] Ben Galbraithは、Googleで働くずっと前に、あるカンファレンスでこう言いました。彼は言いました、ウェブ2.0とは一連の技術のことではない。ユーザー体験を大切にすることだ、と。そしてこれが当時の大きな進化でした。人々がブラウザで提供される体験を本当に気にかけ始めたのです。それ以前は、本当にそうではありませんでした。その後、我々は数年前にProgressive Web Appバナーを出す必要があったときに、さらに別のバージョンを経験しました。そこでは、帯域幅が依然として必要であるという事実に本当に焦点を当てなければなりませんでした。
[40:15] つまり、接続があると分かっていなければ、ウェブはうまく機能しませんでした。そして私はそれについて多くの講演をしてきました。しかしこの時点で、皆さんに特に注目してほしいのは、私がウェブプラットフォームが依然としてあの普遍的なプラットフォームだと確信している大きな理由は、それらの機能へのアクセスが追いついてきているということです。我々はセキュリティとプライバシー、そしてユーザー体験に非常に注意しなければなりません。そして何よりも、そのプラットフォームが他のデバイスでどう機能するかです。
[40:46] これは Microsoft が陥った罠の一つでもあります。Microsoft には二つのブラウザチーム、Mac チームと Windows チームがありましたが、Mac チームは片隅に隔離されていました。統合されていませんでした。彼らはそれについて考えていませんでした。そして、私が没入型ウェブワーキンググループの共同議長を務めているように、私たちは Magic Leap の AR ヘッドセットと、そこで WebXR がどう動作するかを考えなければなりません。たとえ Google が、私の知る限り現在は、AR ヘッドセットを開発していなくてもです。ですから、それはある意味重要です。そのためのガイダンスは、本当に、これは Google 101 ですよね？
[41:22] ユーザーを尊重し、プラットフォームを尊重し、コミュニティを尊重する。部屋で一番賢い人にならないこと。標準化の仕事に携わっている皆さんにとっては、最高の聞き手になることです。そのほうがずっと良い取り組み方です。今日Parisaも先ほど言及しましたが、これがChromeチームにおける私たちの使命です。そしてちなみに、全体として、これが私をGoogleに導いたものです。これはGoogleのDNAの強い部分です。ChromeチームのDNAの強い部分です。これこそが私がここに留まっている理由でもあります。
[41:54] それでは、ダグラス・アダムスの最後の二つの引用で締めくくりたいと思います。ありがとうございました。[音楽再生中]
英語の原文字幕を見る
[0:03] CHRIS WILSON: Good afternoon. I'm here to talk about the history of the web, from its humble beginnings in the early 1990s through the high and low points in the browser wars to today. And a lot of this talk, for me personally, is nostalgia. I hope there's a lot of-- see what impact history had on today's web. As George Santayana said, those who cannot remember the past are condemned to repeat it. Let's definitely not do that. I'm going to talk a lot about Internet Explorer's history.
[0:34] You'll find out why in a second. But I still believe a lot of this drove getting us where we are today. But much like Mel Brooks' movie, I have to skip a lot. So the first deck I pulled together for today I think was about an hour and half long. Hopefully I'll make it through and land on time. So hi. I'm Chris Wilson. I've been working on the web platform a super long time. I started over 26 years ago. I co-wrote the Windows version of NCSA Mosaic, the first real mass market browser after Tim Berners Lee's browser.
[1:10] I've been an engineer, a PM, a lead PM, a GPM, developer advocate. I'm currently on the TPGM team in Chrome. I've worked on four different browsers, I think, and I've been a Googler since 2010. By the way, that's since Chrome version 6. Chrome version 6 shipped a week after I started. Don't take this the wrong way. That sounds super impressive. I don't think I'm the smartest person in the room, certainly not in this room.
[1:43] I have been in the room where it happened, to borrow a Hamilton quote for a second, many, many times over the years, which is pretty cool. But-- so I want you to all cast your minds back, for some of you, before you were born, to 1988. 1988 is when I went to the University of Illinois as an undergraduate. And to give you a picture of the internet at the time, this chart is great. You can't really read the labels, but 1988 it is here, basically. And you'll note it almost doesn't exist.
[2:16] No one had really heard of the internet at that point. In fact, it was still commonly known as ARPANET in academic circles. And my incoming undergraduate class was not issued email accounts by default. You actually had to go to the computer lab, ask for one in-person. And, in fact, we logged into our mainframe. Like, people didn't usually have the ability to connect. And you had a time limit of seven hours a week on this mainframe system.
[2:47] And I would usually burn this up playing Ultimate Larn, because you only had seven hours. I'd usually burn it up in the first couple days, and then I couldn't check my email again till Saturday morning. Thankfully, engineering students got a second account that was not time restricted on a different mainframe. So clearly, I did pass my computer science classes. This was my first internet terminal. It was a cast off terminal from a job that I was working at over the summer. It was an HP 2622A terminal.
[3:20] It had an integrated thermal printer in the top. It was awesome. I connected this to the University of Illinois' system via a smoking fast, for the time, 2,400 baud modem. For reference, I calculated my cell phone gets something like 6,000 times faster connection overall LT, and a 60,000 times faster connection when I'm on Wi-Fi at home. Or it's about twice the speed of my hotel Wi-Fi here in Mountain View.
[3:50] But this was just a text terminal. Like, the internet was mostly text. In fact, that's one of the points I made here is, it really was email, it was was Usenet, it was IRC, it was Gopher. FTP was cool too, but frankly, used a lot less, except for sharing software. Now don't worry. My entire presentation is not just Douglas Adams quotes. There are a couple more, I think. But this is really-- this is something to remember all the time.
[4:21] Anything that's in the world when you're born or when you're very young it's just normal. It's the way the world works. I have two daughters. The internet is the way the world works. They don't even think about it. Mobile devices? Absolutely. Anything that's invented between when you're 15 and 35 is new, exciting, and you can probably get a career in it. And the internet, the web, was definitely invented between when I was 15 and 35. Now, I'm not really here to say, get off my lawn you young whippersnappers.
[4:52] The web's been done. Everything you can come up with is against the natural order of things. The challenge is, really, how do you take it and make it so that you can adapt to the natural order of things. Think of what it can become in the future. Because otherwise, I turned 35 before Chrome was released, so that would be a problem. In 1991, I got a part time job working at the National Center for Supercomputing Applications. It's the last time I'm going to spell that out. The NCSA is one of the five original NSF supercomputing centers, and our group's mission inside NCSA was to build software tools to enable researchers to use the power of the supercomputers on their desktop.
[5:39] So we did Telnet. We literally built Telnet. In fact, that's what I was hired to do, work on the terminal. Now keep in mind, this was before Windows 95. This was before Windows 95. There was no TCP/IP network stack. PC Telnet was DOS software. We had to eventually build Windows software. We also did visualization tools and things like that. Data loading and formatting tools, that kind of thing.
[6:11] But this fit right in when we had this project come up, where a couple guys came up with this X Windows software, called Mosaic, that let you access this thing that some guy in Switzerland had come up with called the worldwide web. Used a prototype document language called HTML. That was kind of-- well, that was the next 26 years my life. I co-wrote the Windows version of this.
[6:42] Incidentally, NCSA Mosaic had three versions, Mac, PC, Windows, and X Windows. They were totally different. They did not share code at all. We looked at each other's code, but cross platform software, not really a thing. I also, this utterly ruined the word mosaic for me. If you say the word mosaic, I will not think of a piece of art. But keep in mind, again, we didn't have network support in Windows. Windows didn't have a built in network driver.
[7:15] Like, they didn't have sockets. You could buy a separate package that would add it. Even Windows 3.11, with networking, I can't remember the toll name. Windows for Work Groups, I think. It didn't have ti TCP/IP built in. Didn't have sockets. It had networking, but through Novell or something else. So we already had our own network stack. We actually literally wrote the device drivers for network cards. Like, I would debug this stuff. I debugged the TCP/IP fallback algorithm at one point.
[7:50] And so we got that working in Windows. We built the HTML parsing and rendering stuff, all that kind of thing. And NCSA had this tradition of shipping lots and lots of beta releases. Like, basically, build it on your machine, put up a release. I think I actually put up several debug version releases, because I couldn't find a bug once that turned out to be a pointer initialization, of course. But we put Windows Mosaic up on the FTP server for the first time.
[8:20] And I remember, we got super excited, because a week later, we were at 1,000 downloads. Now, I gave this talk I think in 2011, and I calculated like, how long it took Firefox to get 1,000 downloads, and it was measured in fractions of a second. So a little different scale. But still, what was really surprising was, the game DOOM came out the same year, and we still managed to get work done on Mosaic, because we were college kids.
[8:53] I mean, we were students. NCSA had this great overall charter of hey, go enable education and research. And we got to explore a lot of things. And if we didn't have that there, we wouldn't have gotten to go build a web browser. It wasn't in our software tool group's charter at the time. We were chartered to build image visualization tools, Telnet, et cetera. And this is one of the things, one of the parallels that I draw with Google, because Google has a lot of that flexibility.
[9:26] It's one thing that I really like about working here. Now, but overall, like, we made a bunch of foolish mistakes in Mosaic, because we didn't really know what we were doing. We didn't really have a whole lot of support. We didn't have a business plan. I mean, plenty of dotcoms didn't have business plans too, but we didn't really, like, there was no user experience class in my computer science degree. There was no theory of software testing or anything like that.
[9:56] And we didn't even have revision control systems. Like, there were two of us working on Windows Mosaic. We didn't have network drives. So literally, we would like, work on the same code, we'd save it to a zip disk, walk across the office, stick it in the other guy's drive, copy the right files, hope for the best. So we did make some foolish choices. And one in particular that I personally own is this. I'm personally responsible for overlapping bold and italic tags working in the early web.
[10:32] For some reason, I thought this would be cool. The rampant violation of all common sense and SGML-structured document decency. And by the way, yes, we do still support this in Chrome and every other browser, probably. We do it in an interesting way that doesn't violate everything that's decent. But in my defense, such as it is, I thought it would be cool at the time. But the early web, even the really early web, because remember, I'm in like, '93 ish year.
[11:10] It was really compelling. And the reason it was compelling was that you got access to all this information. I mean, Google's mission is organize the world's information and make it universally accessible and useful. And I was the one chatting in the back when Parisa asked this question earlier, because it's in my deck a couple times. And you have to remember, at this day and age, the world's information wasn't on the internet. The internet was like, we were off at the low part of that ramp, right?
[11:42] A lot of that information wasn't even in digital form yet. Like, you had to go to a library to get information. Now, eventually, of course, like, anybody who's watched a bunch of information before and knows how we tend to think of the web platform, you'll recognize part of this LICE acronym here. But at this point, it wasn't indexable, really. Or it was indexable, but there were no indices to it. In fact, I meant to bring along, on my bookshelf, I have this book. Like, a bound paper book, that is literally lists of URLs and descriptions of them.
[12:18] It was published, I think, in '93. '93 or '94, I can't remember which. And it's just a solid book filled with, hey, this is what you can find on the Honolulu Community College Website or the like. So most critically, at NCSA we had this-- we recognized that the coolest thing about this web thing was that everyone could be an author, because most of the systems out there weren't really designed for anybody to put servers up and share information.
[12:51] Gopher in particular. Like, Gopher clients were easily accessible. Gopher server software you had to pay an arm and a leg for. Like, basically only universities ran it or private enterprises, because it was so expensive to run the software. Now, so we actually implemented a bunch of stuff at NCSA to try to encourage this sharing of information. We actually had, even in 1993, we implemented a group annotation feature.
[13:21] Like, you could annotate web pages, and then anybody in your group who shared the same annotation server, they would see your annotations when they went to the same web pages. We also had this idea that the web server software should be free, and everyone should run a server on their machine. Now, putting this in context, this was several generations of massive security problems away from where we are today. We actually, I ran a web server on my PC in my office at NCSA.
[13:54] It was world accessible. I mean, literally anybody could just FTP into my personal. In fact, we wrote a networked space dogfighting game. Me and a group of my friends at the University, we borrowed the NCSA PC Telnet code to do this. And after we'd been playing it, like, we got it up and running. It was like, awesome. Those early LAN parties. It was great. After we had it up and running for a while, I realized that I never disabled the FTP server in the PC Telnet code.
[14:26] So sure enough, I could like, FTP into my friends' machine while he was playing the game and, you know, start a big download. He didn't really like that. But the cool thing was there was lots of wacky content. Like, this was groundbreaking at the time, because you didn't have access to this content. Like, there was a guy named Kevin Hughes from the Honolulu Community College who, they have a really cool dinosaur museum at this community college in Honolulu. And so he thought, oh, this is awesome.
[14:58] I'll take some pictures of it with my digital camera and put it online. And he did. And there was like, you would just get this weird kind of stuff. And this is, more than anything, I think what contributed to the growth of the web was this concept of the long tail. Who has not heard of the long tail before? Just to-- OK, so there's a few, which is good. This is where the large portion of content out there-- the overall population is in this tail. And unfortunately, the colors are messed up. But like, all of this stuff out here, measured by interest, is just as popular as the most popular things.
[15:35] So another way to look at this is, the web is incredible, because people get super interested in uncommon topics, more so, even, sometimes, then Taylor Swift's latest video. Which is great, by the way. This is taken for granted today. Like, this is one of those things where you're nodding your head and saying, yeah, whatever. This was new back then, because you couldn't really get access to the long tail, not in the early '90s. In fact, in the early '90s, or mid '90s, actually, in 1996, I took a class learning to play the didgeridoo.
[16:12] Part of the class was how to build one. I was like, oh, this is really cool, and I put up a web page, how to build a bamboo didgeridoo. It's pretty easy, by the way. You just poke a hole in it more or less. But how many of you remember GeoCities? Right on. Nostalgia buffs, I love it. I put up a GeoCities site on how to build didgeridoos from pieces of bamboo, complete with ASCII art, because I didn't own a digital camera yet.
[16:44] This was seven years before Canon came out with the Digital Rebel, just for reference. So it really wasn't that popular, and I put my Microsoft email address on it. And yes, that seems like a crazy thing to do today, but I did. And this page stayed up until GeoCities shut down in 2009. And that entire time, for 13 years, at least once a month, I would get an email from somebody saying, hey, this is great. I was wondering if you know where to get raw bamboo here in Finland.
[17:18] By the way, this page is still accessible. If you really want to see it, the URL is in the speaker notes for this page, but I'm not going to go to it now, because I'm a little ashamed of the artwork there. But I tell this story not because I think you're all interested in building bamboo didgeridoos, although I'm happy to talk about that. Even fewer of you are actually interested in the finer grained details of where to get raw bamboo here in California. I do know, because I did live here for a little while.
[17:49] But you probably have some interests that are just as uncommon. In fact, by contrast, for the last few years, I started making ukuleles in my spare time. And I buy my materials and my tools online. I watch videos on YouTube of how to bend the sides right or that thing. I compare notes on forums about different wood choices, et cetera, browse through exotic woods on eBay. This is a thing. Like, I would search ukulele wood on eBay.
[18:24] And it's not like, five pages. There's like, hundreds of results. And I'm showing my age because I find this amazing. Like, this is blowing, the access to information that you have. This is a massively new natural order. And this leads me to something that I've said for decades about my career, is that the web and the internet just helps human interactions happen faster, and fewer guardrails, fewer speed bumps in the way.
[18:54] I used to think, by the way, this was an unreservedly good thing. I don't think that anymore. So this is kind of foreshadowing, be careful about how you enable human interactions. But it does definitely remove geographic barriers and information barriers. So anyhow, back in 1994, the core Mosaic team all pretty much left NCSA nearly at the same time. Mark Andreessen had left the previous year.
[19:26] I quit and headed out to Seattle to take a different job. And then Mark came back with Jim Clark, scooped up the rest of the engineering team, before they could leave and go off to the winds because they saw that I was the first one that left, but I was not going to be the last. But I went to this company called SPRY. They built a product called Internet in a Box. I literally had one of these on my bookshelf too. Yes, the entire internet in a box.
[19:58] But it was kind of cool, because this was the whole package for what you needed to connect to the internet. Which, again, at the time, was pretty cool. It had a Usenet browser. It had an email system. And had a Gopher client. It also had a web browser. And it still wasn't clear that the web was the winner, by the way. It had all these. Like, when I was building this talk, and I like, you know, did the Command tab on my Mac, and it's like, literally the only things running are two copies of the browser and the calculator.
[20:31] And that's just because it was easier to get to the calculator by clicking the icon. Now, I don't want to talk a whole lot about SPRY in particular, because they went away for good reason. Although it's not Spyglass, by the way. Spyglass was a totally different company. And in fact, a year later I left SPRY and I joined Microsoft and the Internet Explorer team. Spyglass was actually this company that NCSA licensed their code to, because they realized that the business of software licensing was not really the business NCSA wanted to be in.
[21:06] And then Spyglass resold it to everyone else, and Microsoft actually licensed it from spyglass. And Spyglass said they rewrote all the code from the ground up. I'm just saying a lot of that code looked really familiar, and a lot of it, the architectural choices-- yeah, it had some of the same idiosyncrasies as code that I had written. Not that I was proud of, necessarily, but was the same.
[21:38] But I joined the IE team right before we shipped IE 2.0, for context. And I'm sure a few of you have probably heard this quote before. Mark Andreessen was quoted as saying, Netscape will reduce Windows to a set of poorly debugged device drivers. Now, in his defense, by the way, Mark actually said that Bob Metcalf said this, and he was just retweeting it. Well, quoting it, because JavaScript wasn't around.
[22:09] Twitter wasn't around. This may seem like a cheap shot against Microsoft. It actually isn't, because I didn't believe it then. I continued to work for Microsoft for 15 years. I don't even believe it now, because those device drivers are really well debugged at this point. But I don't think any of us expected what this statement kind of foreshadows, that the world is just going to become the web platform, and software sitting on top of it, not a whole bunch of software sitting on top of Windows.
[22:44] And this really did kick off the browser wars. And my favorite example of the hideousness of the browser wars was the blink tag. And how many people have heard the tale of how the blink tag was invented? Wow, OK. So this one was pretty good. I was not in the middle of this one. I was not in the room where this one happened. The blink tag was created because some Netscape engineers went out drinking one night. I'm not kidding. It's on Wikipedia. Look it up.
[23:15] And one of them, or more of them, were like, oh man, we should make a tag that makes everything blink. And they were out drinking, so one of them decides to go back to the office, and the next morning, shows their coworkers the blink tag. Now, at Microsoft, we hated the blank tag. We were like, oh my god, why would you make the-- why would you do this? It's like you're going to, I don't know, trigger people who are sensitive to blinking lights or something.
[23:46] This is horrible. In fact, when the Netscape team demanded that CSS include text decoration blink, I said fine. We'll parse it. We'll apply it, but we can't be forced to make it actually blink. It was in the CSS1 spec, at least. You're not actually required to visually make the thing blink. Now, we still had to out blink them though, and that's what the marquee tag was about. In the marquee tag, just search for marquee tag in Google search.
[24:21] It's actually awesome, because it has now my favorite Easter egg in Google search, because it actually replicates a marquee tag. Like, the tag results start scrolling back and forth. And that's basically what marquee did. It scrolled text back and forth. The joke actually ended up being on us on the IE team, because we also made it scroll vertically and stack text vertically. Like a marquee, you know, when you walk down Times Square or something and there's vertical text.
[24:54] And apparently, this was really popular in Korea, because it matched how their text and fonts worked at the time, and it was useful in developing Korean text. And we literally couldn't remove it for like, decade, more than a decade afterward, because it was so heavily in use and we would have broken a lot of content. Now, in 1996 is when we shipped IE 3, so this is kind of the era we're in.
[25:24] And around this time, it's important to understand, IE, actually, would dynamically lay out pages. Like, if you resize the window, it would just re lay it out. That's actually how I wrote the original rendering layout system in NCSA Mosaic. This is also, by the way, the idiosyncrasy I was talking about earlier, was I would break up runs of text. As you narrowed the window, it would have to break it up at different places, and it-- like, the runs would never recombine. They would just stack.
[25:54] So like, if you stretched it-- if you squeezed the window all the way down, it would take up slightly more memory and have more runs in the overall system. They have the same thing. Now, Netscape Navigator, by the other way, on the other hand, when you resize the window, it would literally reload the page from the network. Not even from disk. Like, disk caching was only going to start being a thing in a year or two.
[26:25] So they would literally go reload the page. And in fact, if you had form fields on the page, and maybe you realized that you couldn't see one of them, and you'd resize the window, it would reload the page and lose everything. They started caching things across page loads for exactly that reason. But we did this kind of feature for feature comparison, but it started being more clear that they had-- they were going for cheaper features than we were.
[27:00] We did do a feature for feature in JavaScript, on tables, on font tags. I am actually the person who implemented CSS first in a browser. This was because my boss actually came into my office and said, hey, we're planning out features for IE 3. We want you to work on frames, because we didn't do frames yet, iframes, frame sets, et cetera. And I was like, hey, that would be cool. But there's this thing called CSS.
[27:30] Netscape's not even looking at this yet. It would be super cool. You can do all this neat visual stuff. And he was like, oh, let me think about it. Came back in 1/2 hour and said, yeah, go do that. And that was how we got CSS in a browser. I mentioned earlier about coding, coding quality, let's say, software systems. And at this point, we did at least have revision control. Like, we had network drives.
[28:01] But in the IE 3 days, our revision control system didn't work so well if multiple people tried to check in at the same time, because we frequently were checking in many different files. And we had what we referred to as the check in bear. This is literally a physical Teddy bear. It sat in a hallway next to a whiteboard. And if you needed to check in, and you had to go get the bear, write your name on the board, take the bear, the bear had to sit on your desk while you were checking in, and then you went back, and if someone else had written their name below yours, you went and gave it to them instead.
[28:36] It was an interesting semaphore, I guess. But after we shipped IE 3, we started looking ahead to IE 4. And at Microsoft, with IE 4, we actually built an entirely new engine, the Trident engine, what became known as the Trident engine. And I found out about this the first time when we were invited to a talk by this group called the Forums Cube Team. No idea what that came from. And there were rumors that they were building something, and I didn't have a chance to go.
[29:10] I was busy doing something. But the other guy who worked on the rendering engine, my friend Jeff, he went. And he comes back. He comes into my office and he's really, really down. I'm like, how did it go? And he's like, we're screwed. They can do everything. They can edit. They can change things. Like, it's a completely live dynamic environment. We're out of a job. And he was half right, because I had done style sheets. And I gave a talk to the Trident team like, a week later, where I was showing off all the stuff I'd done on style sheets.
[29:44] And I was like, does this, does this. I'm hoping to get in these two features before we ship. Now literally, someone in the audience said, could you not, because anything you ship, we have to be compatible with. Now, just for that, it's three features. And so they asked me to move over to the IE 4 team, work on style sheets. And when I was asked to join, that I was told I would be in the object model team. And I'm like, what? The JavaScript team? You asked me to do style sheets. But this was kind of the key thing about this era, was everything became dynamically programmable.
[30:21] Before that, in IE 3, up through IE 3, and still in Netscape Navigator, all you could reprogram were images. Not the size, because you couldn't change the layout, but you could swap the visual out, the links that a particular hyperlink would point to, an input fields. Nothing else. Nothing that changed the layout of the document. And the only way you could change visuals was input fields and images. And suddenly, you could redo everything.
[30:52] I mean, you could change inner HTML and put a whole new document in there. You could change things in the document object model. There were a couple things you couldn't change dynamically. There's a whole 45 plus minute talk about hasLayout here that I'm just going to skip right past, other than to say it really wasn't my fault. People do say that sometimes. It wasn't. And it was super important to understand that Netscape Navigator didn't have a dynamic system. They couldn't change all the stuff dynamically, like, their new system, what became Mozilla, was delayed.
[31:29] To combat this, instead of changing everything live through the object model, they proposed, hey, we should have a new tag called Layer. And you can put things that change inside a layer. But that whole CSS positioning thing, let's not do that. We were like, no, I think we're going to do that. There was a lot of jockeying back and forth. And I think this all culminated when we shipped ActiveDesktop in Windows 98. And this was because you can suddenly drop web content onto the desktop, and all of the window decoration there was actually done in web content.
[32:07] This was horrifying to those of us who really knew what was going on, because it was a very heavy weight system being dropped in to do a very low level system. But this was also when the dawn of Ajax happened, right? This was, Alex Hauptmann, a guy I later worked with in IE, they needed a data transfer system for Outlook Web Access. So they came up with this control, shipped it in MSXML, and this shipped in the IE 5 time frame.
[32:38] I'm not sure which of the IE 5 releases, because literally we had IE 5.0, 5.01, 5.01A, 5.01B, 5.01C, and 5.01D. We were trying to shift together with Office. It took a few tries. And after that, we kind of stumbled at Microsoft. We were largely just re-architecting. Like, IE 5.5 to this native frames thing. And IE 6 fixed all the things we broke in IE 5.5. And that was about it. Really. Like, we didn't really know what to do.
[33:09] And a lot of it is because of this chart. And this is browser adoption, during this time period. And you'll notice there's a nice peak up there, and most people don't do well at peaks. Particularly Microsoft doesn't, but most people don't do well in peaks. But as we shipped IE 6, we were right about here. We had the best browser on the planet. I mean, we were much better than Netscape Navigator in my, admittedly, somewhat biased opinion.
[33:41] Our Mac product was actually better than our Windows product. Or Mac team is applauding somewhere and they don't even know why. But the web didn't actually have rich layout. It did great on flow text. It did great on tables. But it didn't do stacking and it didn't do grids at the time, which was kind of bad. Compatibility was becoming a real problem for us, particularly because Microsoft had this really, really hardcore compatibility philosophy.
[34:12] I remember having to ask for approval to break something to fix our standard support, but it would break something in the Help pages for Microsoft Cart Precision Racing, a game that we had shipped like, three years before that. And overall, like, the web didn't lead developers back to Windows, and Microsoft started questioning, why are we doing all this for something that doesn't get us more developers. And we already have all the users, so why do we need to do this.
[34:45] They just wanted to retain the developer market. So we created this Avalon project, which became dotnet framework 3.0. And I'm not-- there's at least another 45 minute talk in there. And of course, this just ended up in them losing that market too, and then declining it. And of course, at the same time, the world just kept going, right? This pattern of mashup apps became more and more important. I wrote this white paper internally about mashups.
[35:16] And this is basically multiple components and data started coming together. Again, this seems natural today. But the idea that you had the same system that had Chicago crime statistics and mapping software, and that you could just get them to work together dynamically, that was pretty awesome at the time. And, of course, WebKit started gaining traction. Firefox was gaining traction. And the WHATWG was formed around here too, because the W3C kind of lost its way.
[35:46] There are several hours worth of talks there. And in 2004, Microsoft finally woke up, said, oh, wait a second. We need to do something here. And this was actually the release that I was most proud of personally. Not because of what we actually shipped, but because we had to build a team from basically ground zero. And the unfortunate part is, you read-- this is out of the Wikipedia page on IE 7, and it kind of says, new features, including, tab browsing and page zooming, integrated search box, a feed reader.
[36:22] And oh, yeah, web standard support got a little better, but it deal doesn't pass the basic tests. And that-- we had to get used to being vilified at this stage. I did actually have someone in blog comments, posing as Satan, offer me a job at that point. Asked how much I made and if I wanted a job. And I was kind of worried, so I didn't delete the post, because you never know. But don't read the YouTube comments. Don't pay too much attention to people.
[36:53] And I'd point out that, only now are we getting into the period of time where Chrome began. So I'm not actually going to cover any of that, because Peter will do a much better job than I would. But I will say, Microsoft continued to kind of invest the minimum into the platform. Not the browser, but the platform. And that didn't work so well for them. And a lot of this led me to the lessons that I learned out of the IE experience.
[37:23] Don't become complacent just because you're at the top of that heap, and Chrome can definitely learn something there. Don't focus on the competition was a huge part of it. That works OK when there's only two of you, not so well when it's a lot of different people and a lot of things. We're actually pretty good at not doing quirky stuff. We try to pay attention. We try to build lots of test pages and make sure that we're following a spec. But more than anything, not all the smart people work at your company.
[37:55] And, of course, don't ignore disruptive factors like the mobile revolution, which came along right about this time too, right? And this caused us some challenges on Chrome as well. But this was a huge deal, right? Like, I went in 12 years from having this Motorola Startac, which I promise you was super sexy when it came out. It was the best phone out there. I loved that phone. Right up until the point it dropped it into Lake Washington, to having an iPhone. Right? And the iPhone, it had all these sensors, and the touch screen was super engaging, and just so much power in it.
[38:32] And, by the way, I was over 35 when the iPhone was released. But I still managed to adapt, because I remember saying two years later, yeah, baseline. My cell phone has to take the place of my guitar tuner now. Like, it just has to work. I'm not carrying a guitar tuner around anymore. I had a guitar in my office, and I'm pitch sensitive enough that I wanted it to work. And unfortunately, the web wasn't just the mobile platform at that point. It would have been great, but frankly, at that stage, the web was still designed for 1,024 by 768.
[39:07] Literally, it was hard coded in web pages. When Apple came up with their somewhat wacky rules about how to remap onto their device, they were depending on this. And they weren't wrong, really, to make most pages look correct. But it wasn't really open to doing touch input. Occasionally you needed a keyboard, and the network was still pretty spotty. Like, people weren't expecting this. And it's super important. This is actually from around that time period too.
[39:39] Ben Galbraith, well before he worked at Google, he said this at a conference. And he said, web 2.0 isn't about a set of technologies. It's about caring about your user experience, and this was the big evolution then, was people started really caring about their experiences offered in a browser. And prior to that, they really weren't. Post that, we actually had yet another version of that when we had to bring out the Progressive Web App banner a couple of years ago, where we really had to focus on the fact that bandwidth was still required.
[40:15] Like, it didn't-- the web didn't work well if you didn't know you had a connection. And I've given many talks about that. But at this point, the things that I want everyone to focus on is, a big reason that I'm convinced the web platform is still that universal platform, is that those access to capabilities is catching up. We just have to be super careful about security and privacy and the user experience. And, more than anything, how that platform works on other devices.
[40:46] This is also one of the traps that Microsoft fell in. Because even when Microsoft had two browser teams, a Mac team and a Windows team, the Mac team was off in a corner by themselves. They weren't integrated. They weren't thinking about it. And, like I co-chair of the immersive web working group. We have to think about Magic Leap's AR Headset and how WebXR works on it, even though Google is, not currently to my knowledge, building an AR headset. So it's kind of important. Guidance for that, really, this is Google 101, right?
[41:22] Respect the user, respect the platform, respect the community. Don't be the smartest person in the room. For any of you working in standard stuff, be the best listener. That's a much better way to take that on. As Parisa mentioned earlier today, this is our mission on the Chrome team. And this, by the way, overall, this is what brought me to Google. Like, this is a strong part of Google's DNA. It's a strong part of the Chrome team's DNA. This is exactly why I stay here as well.
[41:54] And with that, I think I'm going to close with my final two Douglas Adams quotes. Thank you. [MUSIC PLAYING]
Vidleafワークベンチで開く
トランスクリプトを検索し、行を選択し、タイムスタンプ付きの引用をコピーし、翻訳します。
帰属
「ウェブの歴史（Chrome University 2019）」by Chrome for Developers（https://www.youtube.com/@chromedevs）、CC BY 3.0（https://creativecommons.org/licenses/by/3.0/）の下でライセンスされています。ソース動画：https://www.youtube.com/watch?v=kNzoswFIU9M。このページは動画のテキスト文字起こしであり、段落区切りとタイムスタンプが追加されています。制作者はVidleafと提携しておらず、Vidleafを推奨するものでもありません。VidleafはAIによる句読点の付加とAI生成の要約を追加しました。元の文言はこのページで引き続き参照できます。
あなたは制作者または権利者ですか？訂正や削除をリクエストする：copyright@vidleaf.app（これらのページについてを参照）。
最終更新