こんにちは、チーフアーキテクトの私だ。
日夜、数百万行のJavaScriptバンドルと格闘し、フレームワークのリアクティブ・システムに心を奪われている君なら、一度は立ち止まってこう考えたことがあるはずだ。「おい、俺たちが書いたあのクソデカいHTML文字列は、一体どうやってブラウザのメモリ上でピクセルに変わるんだ？」と。
Reactの仮想DOMやVueのテンプレートコンパイラについて語るエンジニアは星の数ほどいる。しかし、その土台であるブラウザの「HTMLパース」、さらにその前段である「トークン化プロセス（Tokenization）」の生々しい内部挙動まで解像度高く語れる人間は、シニアクラスであっても片手で数えるほどしかいない。
今日は、BlinkやWebkitといったモダンブラウザの心臓部で、HTMLという「歴史的経緯のゴミ捨て場」とも言える泥臭い仕様が、どうやってエレガントに、かつ極限のパフォーマンスでメモリ上の構造体に変換されているのか、その深淵を覗いてみよう。
—
バイト列からDOMへ：見えない地獄の始まり
ネットワークのソケットから流れてくるのは、ただの味気ない「バイト列」だ。UTF-8やUTF-16といった文字エンコーディングの判定（Sniffing）を抜け、文字のストリームになった瞬間から、HTMLパーサーの戦いが始まる。
ここで重要なのは、「HTMLのパースは、字句解析（Lexing）と構文解析（Parsing）が完全に独立したコンパイラとは違う」という点だ。C言語やJavaScriptであれば、まずトークンをすべて切り出し（Lexer）、それを抽象構文木（AST）に組み立てる（Parser）という綺麗な二段構えをとる。
だが、HTMLは違う。HTMLは「生きた動的な生き物」だ。
パーサーは、JavaScriptの実行（`
この瞬間、HTMLのトークナイザーとツリー構築器は完全に停止する。なぜなら、JavaScriptの実行が終わるまで、次にどのトークンがDOMツリーにどう影響するか（例えば、`document.write`が呼ばれてDOM構造が根本から覆る可能性を排除できないため）予測できないからだ。
堅牢なフロントエンドを目指すための最適化プラクティス
1. `
コメント