Web Browser Engineering（2021）

 (browser.engineering)
2 ポイント 投稿者 GN⁺ 2024-10-16 | 1件のコメント | WhatsAppで共有
  • Web Browser Engineering は、ネットワーキングから JavaScript までを扱い、Python で数千行規模の基本的だが完全なウェブブラウザを実際に作ってみる本
  • 学習の流れは、ページの読み込みから文書表示、アプリケーションの実行、現代的なブラウザ機能へと進み、HTTP、HTML、CSS、DOM、セキュリティ、レンダリングパイプラインを順に結び付けていく
  • 前半では、URL と HTTP リクエスト、ウィンドウ生成とキャンバス描画、テキストの折り返しや行間といった ブラウザの基礎実装 に集中する
  • 中盤から後半にかけては、HTML ツリー構築、レイアウト、スタイル適用、フォーム送信、イベント応答、Cookie とログイン、XSS と CSRF までを含む
  • 後半では、コンポジット、イベントループ、GPU アニメーション、アクセシビリティツリー、iframe、無効化と編集の正確性へと進み、現代的なブラウザ実装要素 を幅広く見ていける

実装しながら学ぶブラウザの構造

  • Web Browser Engineering は、ウェブブラウザがどのように動作するかを理解するために、基本的だが完全なブラウザを自分で実装する形で構成されている
  • 実装言語は Python で、全体の実装規模は数千行レベル
  • 範囲はネットワーキングから JavaScript まで及ぶ
  • 紙の書籍は Bookshop、B&N、Amazon で購入できる
  • 翻訳版は、日本語版 O’Reilly、韓国語版 Hanbit がある
  • 更新情報は blog、Mastodon、Twitter で確認でき、GitHub の discussion forum もある

目次の流れ

関連記事

1件のコメント

 
GN⁺ 2024-10-16
Hacker News の意見

  • この本の良い点のひとつは、「やらなかったこと」を別に取り上げているところ
    レイアウトは本当に難しく、CSS なしでテーブルだけを扱っても難しい。CSS まで入ると、レイアウトはほとんど不可能なほど複雑になる
    CSS 仕様全体と関連する挙動を頭の中にすべて収めておける人がいるのか疑問だ。現在の CSS+HTML+JavaScript は動的なページ記述言語（PDL）に近くなっており、今日最も複雑なソフトウェアのひとつである可能性が高い
    付け加えると、動画デコードはハードウェアにオフロードされるため、昔ほどバッテリーを食うわけではない

    • プロダクション品質の CSS レイアウトを実装するには膨大なコードが必要で、Servo のソースがそれをよく示している
      たとえばこのファイルはブロック/インラインコンテキストだけを実装しているが、Rust のボイラープレートも少しあるとはいえ、大半は仕様のさまざまな部分を扱う実際のロジックだ。こういうファイルがフォルダいっぱいにある: https://github.com/servo/servo/blob/main/components/layout/f...
      それでもレイアウトエンジンの実装は可能だ。CSS は魔法ではなく、丹念にコードへ落とし込める仕様がある。CSS が恣意的に見えていら立つ人たちにこうしたコードを見せると、実行環境にも論理があるのだと理解する助けになる
      もちろんライブラリ実装を眺めるように頻繁にクリックして見るものではないだろうが、その点では React のようなものとも大きくは違わないと思う
    • その通りで、レイアウトは難しい。特に大きな理由は 2 つあるように思う
      第一に、CSS 2 のようなレイアウトの最も中核的な部分がかなり雑に設計されていて、奇妙な機能同士が奇妙に相互作用する。float と clearance、マージンの相殺などだ。この中核部分の一部はすべてのレイアウトモードで普遍的に使われることを意図していたが、他のモードにはうまく合わない。たとえば margin と padding は grid 要素では目的が明確ではない
      第二に、JavaScript API のようにうまくモジュール化されていない。JavaScript API は独立して実装されることが多いが、レイアウトモジュールはさまざまな形で入れ子にできるため、互いにすべて影響し合う。grid のような新しい仕様はより厳密になろうとしているが、実際の 2D 画面という共有リソースを複数のレイアウトモードで分け合わなければならないという根本的な難題がある
    • レイアウトがあまりに難しくて、Common Lisp と ncurses で情熱プロジェクトを作っていたのをやめ、自分がなくすと誓っていた存在である React 開発者になってしまった
      CSS より単純でありながら、過去 20 年の教訓を反映し、単純さと表現力の積を最大化したレイアウト言語を望んでいるのは自分だけではないはずだ。こういうものを真剣に設計しているプロジェクトがあるのか、それともみんな CSS3 を受け入れて LLVM バックエンドを待っているか、単なるプレーンテキストに戻っただけなのか気になる
    • React Native では Facebook のエンジニアたちが結局諦めて、「君たちに与えるのは flexbox レイアウトだけだ」と言ったようなものだが、人々はかなり受け入れていた。もちろん display grid がないと文句を言う人もいる
      https://github.com/facebook/yoga
    • この バベルの塔はいずれ崩れるだろう
      レイアウトがここまで複雑である必要はない。もっと単純なレイアウトシステムを持つ GUI フレームワークは何十もあり、人々が使うアプリケーションにはそれで十分だ

  • すごく良さそう。約 15 年前に ヘッドレスブラウザを作り始め、数年間保守していた
    JavaScript インタプリタには SpiderMonkey を使い、DOM は自前で実装した。当時の最新 JavaScript や AJAX などをすべて実行し、後にはカスタム Flash ランタイムも追加した。画面に描画すること以外はほとんど全部やったプロジェクトで、本当に楽しかった
    この本はぜひ読んでみたい

    • 画面に描画するなら、どんなライブラリを使うつもりなのか気になる

  • ブラウザエンジニアリングが今やトレンドになりつつあるようでうれしい
    エコシステムは実質的に Google、Apple、Mozilla だけが定義している、かなり貧弱な状態だと思う。今後は、もっと多くの独立したブラウザエンジンがある未来を見てみたい

    • HTML 用レンダリングエンジンを新たに書くのは、取り組む価値のあることではないと思う。絶対に終わらない。HTML は今や実質的に Google と Apple が完全に所有している仕様で、ゼロから実装するには複雑すぎる
      興味深い領域は脱 HTML の UI／ドキュメント技術だ。別スレッドの Typst は、より良い LaTeX のようなもので、Markdown も大きな影響を与えた。「HTML だが、より良いもの」を作る余地はたくさんある。必ずしもマークアップ形式である必要もない。Typst と React HTML はコードとデータの境界を曖昧にし、Jetpack Compose は Kotlin の DSL 機能で、UI 記述のように見えるが実際にはコードであるものを作る方法を示している
      もちろん、そのためにはその形式用の「ブラウザ」を配布するか、既存ブラウザで表示する方法を見つける必要がある。それでも JavaScript/HTML/WASM へコンパイルすることは可能だ。JavaFX のような移植可能な GUI ツールキットを使ってもよいし、アクセシビリティも得られる。両方やることもできる
      自分の UI 言語を定義すれば、HTML がうまくできないことをたくさん試せる。代表的なのはコンテンツとスタイルの分離だ。HTML は試みたが結局きちんと達成できず、XSL:T はさらに熱心に試みたが、XML 構文を使う奇妙な純粋関数型言語だった。React は JSON をボックスに変えるのはかなり得意だが、下層のプロトコルが常にその場しのぎで継ぎ足された形なので、その上に有用なツールを作るのが難しい
      もう一つのアイデアとして、基本的にXSS に免疫のある形式もあり得る
    • メモリ使用量の少ないブラウザがあるといい。それ以外については、Capital-G の Google Chrome と Capital-M の Mozilla Firefox のスパイウェア性さえ除けば、エンジン数が少ないこと自体は大きな問題ではないと思う。重複なしに蓄積された何百万時間もの作業なのだから
      ただし HTML の代替は欲しい。自分がブラウザを作るなら、HTML に耐えられないので置き換えることに集中すると思うし、JavaScript もランタイムが重いので変えたい
      例えば、JavaScript ランタイムがほとんどなく、WASM だけを実行するブラウザならかなり笑えると思う
    • まったく新しいプラットフォームやプロトコルが必要なのかもしれない。今のものは複雑さが完全に飽和している
    • Servo、Ladybird、Goanna、NetSurf、Sciter、Flow のような代替ブラウザエンジンを見たことがあるか気になる

  • この本の著者の一人です。うれしい言葉をありがとう。質問があれば答えられます

    • 素晴らしい本を作ってくれてありがとう。Web 開発者、あるいは本の表現どおり Web エンジニアとして、自分が依存している技術的基盤について、ずっともっと学びたいと思っていました
      ブラウザ実装言語として Python を選ぶに至った経緯が気になります。Node 経由の JavaScript のほうが、より関連性のあるプログラミング経験を提供できたようにも思えます

  • 著者がなぜ Python を選んだのかを説明した記事: https://browserbook.substack.com/p/why-python
    一部は Python を JavaScript にコンパイルして、今ではブラウザ内、つまり「本そのものの中」でも実行されているようだ
    https://browserbook.substack.com/p/compiling-python-to-js

    • Python で書かれているという点で、実際にこの本を読みたくなった。Rust や Go だったらたぶん飛ばしていただろうし、C++ は趣味で見るプロジェクトとしては読むのがつらすぎる
      読んだあとに戻ってきて、もっと意味のある話ができるといい

  • こういう資料が作られているのを見ると本当にワクワクする
    ブラウザは神秘的で解読不能なブラックボックスのように見えるし、おそらく Google もそう認識されることを望んでいる可能性が高い。だが Ladybird のようなプロジェクトの努力と成果を見ると、その壁に亀裂が入っている
    いつか自分も飛び込んで、その堀を壊すことに貢献したい。この本は素晴らしい出発点に見える

    • その堀は Chrome ではないブラウザエンジンが不足しているから生じたのではなく、Chrome ではないエンジンを使う人が少なすぎるから生じたものだ
      Firefox はすでに存在している。ただ、ほとんど誰も使っておらず、Firefox で動かないウェブサイトに出会うと、ユーザーはただ Chrome を開くことを学んでしまった
      堀が崩れることを願って Ladybird のようなブラウザエンジンに貢献するのは楽しいだろうが、それだけで堀を崩すことに貢献しているとは言いにくい。何が実際に役立つのか知りたい
    • 本の著者の一人である Chris は、Google で Blink レンダリングチームを率っている人物だ
    • 本の二人の著者のうち一人で、もう一人は Blink Rendering の責任者です。Chrome チームの人たちとも何度も話したことがありますが、ブラウザを神秘的なものに保とうとしている人に見えたことはありません
      むしろ Chrome、Firefox、Safari、Ladybird で働く人たちは皆、ブラウザとその動作について語ることにとてもワクワクしているように見えます。ブラウザ開発の世界は思ったより小さく、エンジニアも会社間をよく行き来するので、何らかの「陰謀」を維持し続けるのは難しそうです
      ただ、教育資料が実際に不足しているという点はその通りです。だからこそこの本を書きましたし、特にレイアウトやラスタライズのような主要ステップにおけるブラウザ内部を議論するための共通語彙も不足しています。Chris と私は、この本でそうした基盤を作りたいと思っていました

  • 始めるのに面白いプロジェクトを探していたところで、すでにこの本を本当に楽しく読んでいます。文章が特に興味深く書かれていて良いです
    Chrome がどのように動作するかを説明したこの漫画も、始めるには良い資料です: https://www.google.com/googlebooks/chrome/med_00.html

  • ブラウザの内部構造を学んでいるところですが、この本は素晴らしいです
    数百万行に及ぶ Chrome のコードに潜らなくても、ブラウザがどのように動作するかについての直感を築く助けになります

  • HN向けのプロモーションコードがあるのか気になる
    以前、Jython [2] と一緒に HTMLUnit [1] を満足して使っていた。今後は、コード生成と検証手法によってブラウザコードの一部を自動生成できる未来に強い関心がある。Playwright/Cypress/Selenium のようなツールは尊重しているが、HTMLUnit ほど快適に感じたことはなかった
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • 本はまだ出版されていないのでプロモーションコードはないが、全文がオンラインで無料公開されている

  • 良い本。第9章を2章に分けることを勧める
    DuktapeでJavaScriptを実行する部分を1章にし、DOMおよびイベントとやり取りする部分は後の別章にするとよさそう

    • 2回に分けて読むのがいちばん良いかもしれない
      後半に進むほど章が長くなり、より高度なトピックを扱うので、本を読み進めながらコードも一緒に追っていくことを勧める