Rick Byers
rbyers.net
Rick Byers
@rbyers.net
Web Platform engineer at Google on the Chrome team, helping the open web to thrive.
Opinions are my own, not my employer's.
We never thought Chrome would get so popular. Of course I don't personally think we "went wrong", but it sure is more fun and celebrated to be in the back racing to catch up. It feels like some of that again now with all the AI competition and it's invigorating!
November 28, 2025 at 1:56 AM
Yeah I appreciate that. "We supported it, then changed our minds" also isn't totally wrong. It's just that we supported experimentation behind a flag (like always) and when it came time to make the key one-way-door decision of shipping it, we thought the cost/benefit tradeoff didn't look good.
November 28, 2025 at 1:52 AM
Now, if two engines have shipped a feature for an extended period and the third is still holding out, that's something to be suspicious of! We are always keeping an eye on the data to try to ensure Chromium isn't holding back interoperability. webstatus.dev/stats
November 27, 2025 at 9:08 PM
I think it's fair to criticize the Chromium project for apparently getting the initial cost/benefit prediction wrong on JPEG XL. But the fact that JPEG XL is moving forward anyway is a success to be celebrated in the consensus-forming process of the web platform! groups.google.com/a/chromium.o...
November 27, 2025 at 9:04 PM
When we first reviewed JPEG XL, as far as we could see no other browser engine wanted it. Our judgement was the benefit wasn't worth the cost. Then Safari decided otherwise and shipped it. Once Mozilla expressed their openness to shipping, it was inevitable that Chromium would too.
November 27, 2025 at 9:04 PM
It's good and healthy for different browser engines to have different opinions on the cost/benefit tradeoffs of features. This is what we want from "engine diversity" after all, right? But then we each watch the public signals of the others when deciding what to ship.
November 27, 2025 at 9:04 PM
I bought the cited book so I could trace the reference and found it cited a newspaper interview with our site lead from 2016. Now I remember that interview and error. IIRC we tried to get them to issue a correction but failed.
November 21, 2025 at 12:25 AM
Hah, yeah. I actually wasn't sure exactly his role. Were you there in 2008? By 2010 I saw him driving ChromeOS. I assume it was Linus and Brian driving Chrome in the 2008 timeframe?
November 20, 2025 at 11:58 PM
Hah, wow. Not gonna bother going that far. The edit has stuck for now.

At least now I know why random visitors sometimes say "Chrome was developed here, right?"
November 19, 2025 at 1:16 PM
Most Chrome engineering was happening in Mountain View, not "Kitchener" (where the Google Waterloo office moved to in 2010). I would see most of the Chrome engineering leaders (Sundar, Darin, Ben, etc.) when I visited Mountain View.
en.wikipedia.org/w/index.php?...
November 18, 2025 at 9:55 PM
I just watched it this evening too and agree! I mean hopefully we'd get luckier, but seems plausible. Some details from their technical advisor: www.netflix.com/tudum/articl...
Could A HOUSE OF DYNAMITE Really Happen? An Expert Weighs In
Technical advisor Dan Karbler discusses the facts behind the fiction. Plus, check out a glossary of key terms.
www.netflix.com
October 26, 2025 at 3:14 AM
Yes DMA does require it and we've built a prototype that we can see has some real wins over our WebKit based version. But there are still several reasons why we can't ship a serious blink-based browser in the EU, mostly covered here: open-web-advocacy.org/blog/apples-...
Apple's Browser Engine Ban Persists, Even Under the DMA - Open Web Advocacy
open-web-advocacy.org
October 4, 2025 at 1:21 PM
IMHO they are free to do so as long as users can choose to use a better browser. It's how Netscape took over from IE when Microsoft stopped investing in it.

But on iOS, users have no choice! This then reduces the pressure on Apple to invest in making Safari better on iOS.
October 4, 2025 at 1:03 PM
And then we would have done a postmortem to reflect on what we learned from the incident and how to prevent similar ones in the future. docs.google.com/presentation...

Instead we just accepted 2 months to even get a 'have a repo?' response on the bug, and 3 months of high crashes for our users.
Regression prevention & mitigation - BlinkOn 19
Rick Byers / Google Video, discussion and discussion notes Regression prevention & Mitigation BlinkOn 19
docs.google.com
October 4, 2025 at 12:56 PM
Here's another example of a WebKit crash that really hurt Chrome iOS product quality bugs.webkit.org/show_bug.cgi....

As I said on the bug, if this had been blink/Android we would have immediately been doing emergency reverts of any possibly related CL to try to bring the rate down.
282945 – REGRESSION(iOS 18.2 beta): Crash in RemoteScrollingCoordinatorProxyIOS::establishLayerTreeScrollingRelations
bugs.webkit.org
October 4, 2025 at 12:54 PM
Hmm... Worked OK for me an hour later from the corp network where it failed before.
October 4, 2025 at 4:00 AM
I believe it's fundamentally impossible to ship Chrome on iOS meeting the same high quality bar we have on other platforms when we are forced to rely on WKWebView and very slow and unreliable issue handling.
October 3, 2025 at 11:44 PM
If this study is right, it means telling pregnant mothers with a fever to "tough it out" will likely significantly increase the occurrence of ASD! Guess we're going to do the experiment. 😕
September 27, 2025 at 1:07 PM