I'm Ian Kilpatrick, an engineering lead on the Blink layout team, along with Koji Ishii. Before working on the Blink team, I was a front-end engineer (before Google had the role of "front-end engineer"), building features within Google Docs, Drive, and Gmail. After around five years in that role I took a large gamble switching to the Blink team, effectively learning C++ on the job, and attempting to ramp up on the massively complex Blink codebase. Even today, I only understand a relatively small portion of it. I'm grateful for the time given to me during this period. I was comforted by the fact a lot of "recovering front-end engineers" made the transition to being a "browser engineer" before me.
My prior experience has guided me personally while on the Blink team. As a front-end engineer I constantly ran into browser inconsistencies, performance issues, rendering bugs, and missing features. LayoutNG was an opportunity for me to help systematically fix these issues within Blink's layout system, and represents the sum of many engineers' efforts over the years.
In this post, I'll explain how a large architecture change like this can reduce and mitigate various types of bugs and performance issues.
A 30,000 foot view of layout engine architectures
Previously, Blink's layout tree was what I'll refer to as a "mutable tree".