Why What You’re Reading About Blink Is Probably Wrong

By now you’ve seen the news about Blink on HN or Techmeme or wherever. At this moment, every pundit and sage is attempting to write their angle into the annoucement and tell you “what it means”. The worst of these will try to link-bait some “hot” business or tech phrase into the title. True hacks will weave a Google X and Glass reference into it, or pawn off some “GOOGLE WEB OF DART AND NACL AND EVIL” paranoia as prescience (sans evidence, of course). The more clueful of the ink-stained clan will constrain themselves to objective reality and instead pen screeds for/against diversity despite it being a well-studied topic to which they’re not adding much.

May the deities we’ve invented forgive us for the tripe we’re about to sell each other as “news”.

What’s bound to be missing in most of this coverage is what’s plainly said, if not in so many words, in the official blog post: going faster matters.

Not (just) code execution, but cycle times: how long does it take you to build a thing you can try out, poke at, improve, or demolish? We mere humans do better when we have directness of action. This is what Bret Victor points us towards — the inevitable constraints of our ape-derived brains. Directness of action matters, and when you’re swimming through build files for dozens of platforms you don’t work on, that’s a step away from directness. When you’re working to fix or prevent regressions you can’t test against, that’s a step away. When compiles and checkouts take too long, that’s a step away. When landing a patch in both WebKit and Chromium stretches into a multi-day dance of flags, stub implementations, and dep-rolls, that’s many steps away. And each step hurts by a more-than-constant factor.

This hit home for me when I got my first workstation refresh. I’d been working on Chrome on Windows for nearly a year in preparation for the Chrome Frame release, and all the while I’d been hesitant to ask for one of the shiny new boxes that the systems people were peddling like good-for-you-crack — who the hell was I to ask for new hardware? They just gave me this shiny many-core thing a year ago, after all. And I had a linux box besides. And a 30″ monitor. What sort of unthankful bastard asks for more? Besides, as the junior member of the team, surely somebody else should get the allocation first.

Months later they gave me one anyway. Not ungrateful, I viewed the new system with trepidation: it’d take a while to set up and I was in the middle of a marathon weekend debugging session over a crazy-tastic re-entracy bug in a GCF interaction with urlmon.dll that was blocking the GCF launch. If there was a wrong time to change horses, surely this was it. At some point it dawned that 5-10 minute link times provided enough time to start staging/configuring at the shiny i7 box.

A couple of hours later the old box was still force-heating the eerily dark, silent, 80-degree floor of the SF office — it wasn’t until a couple of weeks later that I mastered the after-hours A/C — when my new, even hotter workstation had an OS, a checkout, compiler, and WinDBG + cargo-culted symserver config. One build on the new box and I was hooked.

5-10 minute links went to 1-2…and less in many cases because I could now enable incremental linking! And HT really worked on the i7’s, cutting build times further. Hot damn! In what felt like no-time at all, my drudgery turned to sleuthing/debugging bliss (if there is such a thing). I could make code changes, compile them, and be working with the results in less time than it took to make coffee. Being able to make changes and then feel them near-instantly turned the tide, keeping me in the loop longer, letting me explore faster, and making me less afraid to change things for fear of the time it would take to roll back to a previous state. It wasn’t the webdev nirvana of ctrl-r, but it was so liberating that it nearly felt that way. What had been a week-long investigation was wrapped up in a day. The launch was un-blocked (at least by that bug) and the world seemed new.

The difference was directness.

The same story repeats itself over and over again throughout the history of Chrome: shared-library builds, ever-faster workstations, trybots and then faster trybots, gyp (instead of Scons), many different forms of distributed builds, make builds for gyp (courtesy of Evan Martin), clang, and of course ninja (also Evan…dude’s a frickin hero). Did I mention faster workstations? They’ve made all the same sort of liberating difference. Truly and honestly, in ways I cannot describe to someone who has not felt the difference between ctrl-r development and the traditional Visual Studio build of a massive project, these are the things that change your life for the better when you’re lashed to the mast of a massive C++ behemoth.

If there is wisdom in the Chrome team, it is that these projects are not only recognized as important, but the very best engineers volunteer to take them on. They seem thankless, but Chrome is an environment that rewards this sort of group-adaptive behavior: the highest good you can do as an engineer is to make your fellow engineers more productive.

And that’s what you’re missing from everything else you’re reading about this announcement today. To make a better platform faster, you must be able to iterate faster. Steps away from that are steps away from a better platform. Today’s WebKit defeats that imperative in ways large and small. It’s not anybody’s fault, but it does need to change. And changing it will allow us to iterate faster, working through the annealing process that takes a good idea from drawing board to API to refined feature. We’ve always enjoyed this freedom in the Chromey bits of Chrome, and unleashing Chrome’s Web Platform team will deliver the same sorts of benefits to the web platform that faster iteration and cycle times have enabled at the application level in Chrome.

Why couldn’t those cycle-time-improving changes happen inside WebKit? After all, much work has happened in the past 4 years (often by Googlers) to improve the directness of WebKit work: EWS bots, better code review flow, improved scripts and tools for managing checkins, the commit queue itself. The results have been impressive and have enabled huge growth and adoption by porters. WebKit now supports multiple multi-process architecture designs, something like a half-dozen network stack plug-ins, and similar diversity at every point where the engine calls back to outside systems for low-level implementation (GPU, network, storage, databases, fonts…you name it). The community is now committed to enabling porters, and due to WebKit’s low-ish level of abstraction each new port raises the tax paid by every other port. As James Robinson has observed, this diversity creates an ongoing drag when the dependencies are intertwined with core APIs in such a way that they can bite you every time you go to make a change. The Content API boundary is Blink’s higher-level “embedding” layer and encapsulates all of those concerns, enabling much cleaner lines of sight through the codebase and the removal of abstractions that seek only to triangulate between opaque constraints of other ports. Blink gives developers much more assurance that when they change something, it’s only affecting the things they think it’s affecting. Moving without fear is the secret of all good programming. Putting your team in a position to move with more surety and less fear is hugely enabling.

Yes, there are losses. Separating ourselves from a community of hugely talented people who have worked with us for years to build a web engine is not easy. The decision was wrenching. We’ll miss their insight, intelligence, and experience. In all honesty, we may have paid too high a price for too long because of this desire to stay close to WebKit. But whatever the “right” timing may have been, the good that will come from this outweighs the ill in my mind.

Others will cover better than I can how this won’t affect your day-to-day experience of WebKit-derived browser testing, or how it won’t change the feature-set of Chrome over-night, or how the new feature governance process is more open and transparent. But the most important thing is that we’ll all be going faster, either directly via Blink-embedding browsers or via benchmarks and standards conformance shaming. You won’t feel it overnight, but it’s the sort of change in model that enables concrete changes in architecture and performance and that is something to cheer about — change is the predicate for positive change, after all.


  1. foljs
    Posted April 3, 2013 at 4:27 pm | Permalink

    >*The more clueful of the ink-stained clan will constrain themselves to objective reality and instead pen screeds for/against diversity despite it being a well-studied topic to which they’re not adding much.*

    Some BS obscure papers on a tangent of the matter make the issue “well-studied” and closed?


  2. Jim H
    Posted April 3, 2013 at 9:50 pm | Permalink

    Okay, it’s easier to build. Will it be open? Can other companies use it as you used WebKit?

  3. Engineer
    Posted April 4, 2013 at 12:32 am | Permalink

    Browser rendering engines are what makes the web what it is– standards based. Forking webkit is about marginalizing Apple.

    It is google taking the embrace-and-extend-and-destroy play from Microsoft’s playbook.

    Chrome is a dog slow browser with almost no innovation, and it’s not because of webkit, as Safari is able to run circles around it. Chrome may score well in JS benchmarks, but in use it locks up, pauses for minutes at a time with a few tabs while safari keeps on rocking.

    Here’s a translation from BS to English:


  4. Bob Spryn
    Posted April 4, 2013 at 1:03 am | Permalink

    Funny, at first I thought when you were talking about cycles and directness you were pointing out how even though you may be squeezing more performance out of chrome with this new engine, us developers will have to spend more cycles testing/debugging/solving on more platforms, and have a less ‘direct’ path to creating things we want to create.

    Instead you were thinking from the point of view of your team being able to spend less cycles, and a more direct path to advances your browser/platform.

    Maybe this ends up being a good thing, but I’m still having trouble reconciling how you can immensely speed up innovation and new features, and staying true to web standards (and not breaking the web for the other browsers), which you also see as hugely important.

  5. Chris Campbell
    Posted April 4, 2013 at 1:51 am | Permalink

    Interesting post. Trouble is, development may now be quicker for chrome devs, but the work required by web devs on testing just went up by 33%.

  6. Posted April 4, 2013 at 3:22 am | Permalink

    Hi Bob,

    I very honestly know where you’re coming from. My background is webdev. I led the Dojo team for years and was the “front end guy” at many jobs before joining Google.

    What you may be missing — and it’s easy to, WebKit is a big and mostly uncommented code base — is that Chrome, Safari, and other ports have been diverging for years while still living in the same tent. This has been enabled by pervasive use of build flags that allow ports to agree to disagree about the feature set we respectively ship to the web.

    Consider Chrome for Android and the old-skool Android Browser. What makes them so different? It’s not WebKit revision. Nor even choice of JS engine (they both use V8). Nor even the network or remaster stacks. Indeed, the massive differences in behavior, performance, and feature availability was down to *dozens* of other flags. Just think how much further away safari is than even that.

    What’s happening here isn’t that your testing burden is getting higher. It was already as high yesterday as it will be tomorrow. What *is* happening is that your assumptions are being turned out for frauds.

    I’m sorry it’s happening this way, but it will truly be better for your users if you’re doing the testing you should have been doing all along.


  7. Posted April 4, 2013 at 5:27 am | Permalink

    Perhaps while you’re at changing things you can get Chrome’s version numbers under control? It’s on major version 26 now?! Been around for 26 years has it? 13 years? No? Oh, well I guess that every single *minor* release you guys ship is considered a major version. Great.

    Also, Chrome is now 2.X Gb on my Mac. Is there a reason why it stores so much data?

    I’m sure breaking from webkit will get right on fixing that.

  8. penguat
    Posted April 4, 2013 at 5:57 am | Permalink

    Will this reduce the memory footprint of each chrome tab? They feel pretty memory hungry at the moment.

  9. Justin
    Posted April 4, 2013 at 6:15 am | Permalink

    Personally I’m fine with the concept of testing in a new engine; you’re right, Alex, web devs should already be testing in Chrome separately from other browsers regardless of the engine it uses. Laziness and carelessness don’t help users.

    What troubles me about Blink is that the more I read about it, the more I have a strong sense of, “Well, we don’t like what’s out there right now, so we’re going to do our own thing.” My concerns are largely in line with Bob’s. There is value in being fast, as you say, but there’s also risk.

    That’s underscored by the attitude Blink has towards things like vendor prefixes. I can’t imagine that Chromium will always wait to release a feature until it’s already out on the market; that’s never been how WebKit’s been run in the past, and my gut feeling is that the “Exceptions” mentioned in the new features section may appear not-so-coincidentally with the launch of a highly-publicized Chrome Experiment. We could then end up with competing implementations if another browser decides to do it differently. (Hate on vendor prefixes all you want, but at least there’s no risk of this when you use them.)

    It’s great to be efficient and cut what you don’t need. It’s great to be fast. But please, please, as tempting as it is, don’t try to be so fast that you leave the process of new feature standardization in the mirror in favor of doing something for the sake of being first; I really don’t want to go back to the days of conditional CSS we faced with IE6.

  10. Posted April 4, 2013 at 7:34 am | Permalink

    Hi Justin,

    There are many ways to contain the risk you (rightly) sense. Good project governance is one of them, and we’re committed to it in Blink. You can decide for yourself if our 4+ years in WebKit were evidence of good citizenship, but that’s what the whole web feature dashboard is about and why folks like me are continuing to be paid by Google to go fight the good fight to improve standards. But there is a large aspect of “trust us” to this, and I know how risky that sounds. The good news is that there are real browser and engine alternatives to keep everyone honest.

    But I think your view of the first browser war needs revising: it not only created a platform so capable that it bested the competition even in its decline, it set the stage for today’s performance and UX arms race. I’m with you in wanting to do the best we can to contain the potential damage from experiments, and the Blink process is geared to take that seriously. Don’t kid yourself, though competition is necessary for improvement. Without it there is no spark and no incentive.

    Wishing for progress without a system of incentives that can credibly provide it is asking for perpetual motion.

  11. Bjorne
    Posted April 4, 2013 at 3:24 pm | Permalink

    Given that the primary impetus here is apparently about the ability to cut down the edit-build-run-test cycle for developers (a worthy goal!), and that you admit that the project is “a massive C++ behemoth” (a language not known for its speedy compilation or for being easy on programmers, to say the least), are there any plans for Blink to migrate to a faster, more concise, or otherwise more modern language?

    I’ve seen a ton of work done the past few years to try to make C++ programs build faster, but these ambitious projects only serve to narrow the gap between it and other languages, while increasing complexity.

    With even interpreted languages offering impressive performance today, and with more and more pieces of all web browsers being written in higher-level languages, when are we going to see layout engines written in something other than C++?

  12. Alex Bell
    Posted April 4, 2013 at 9:06 pm | Permalink

    I find the vitriol in these comments odd.

    In my experience, the Chromium team is probably the most thoughtfully responsive team in the field right now. Bugs that I file are routinely fixed within weeks, sometimes days. If you have a good argument, a test file, and it’s backed by data and standards, Chrome listens, and iterates, with incredible speed. It’s extremely gratifying, and fun for a relatively newcomer like me to participate in moving the platform along. I honestly haven’t had the same experience with Safari (crummy private bug tracking system, no helpful discussions) or Mozilla (too often the reply is outright condescension or “hey, go fix it yourself!”, which I personally don’t have the C++ chops for). I’m not a Google fanboy by any measure, but Chrome Dev Tools has won the hearts of developers worldwide because the team *listens*. In itself, this has nothing to do with market share.

    There are large parts of the web that functionally aren’t even “1.0” yet. Look at the Web Animations 1.0 Editor’s Draft, just released today. Someone’s going to be first up the mountain. If Chrome wants to break off to race ahead, so much the better. We’re not there yet, folks.

    I will say that some of the anxiety about Chrome dictating standards is reasonable. I think that’s a legitimate debate to have. But then again firstcomers have always laid the tracks. That’s how the web has always worked. And reality check: if you actually look at the standards formation process around SVG 2.0, for example, which is very much a work in progress at this very moment, you don’t see Chrome people even remotely controlling the process. Everyone’s at the table, hashing it out. Things look very bright in this area.

    Cheers, Alex, for a thoughtful post, and all the work you do.

  13. Posted April 5, 2013 at 1:39 am | Permalink


    C++ contains multitudes. One of the important things that can happen quickly in Blink is that we can move to begin using modern C++. Our primary build toolchains (clang, gcc 4.7, and MSVS 12) all support large sections of C++11 which will pay large dividends. Similarly, we’ll be able to drop many abstractions and ifdef/#define layers that have served mostly to insulate WebKit from what can only be described as archaic build requirements. For a flavor of what can go, go give the aptly-named WTF namespace a gander. At a minimum, we’ll be able to rely on Chromium’s base/ versions of many of these abstractions instead, cutting the # string, number, and vector classes a new Blink engineer needs to learn to be effective in half.

    As for moving to something other than C++…we can all dream, right? My personal hope is that by moving more of DOM to JS (a.k.a. “self-hosting”), we’ll get a lot of those benefits. What happens with core rendering/parsing can largely change behind the scenes, but the imperatives there are all about runtime perf. We have suffered C++ thus far because it’s the only thing that gets us in the ballpark on all of: compat, perf, x-platform support, and “something some people know”.


  14. Posted April 5, 2013 at 1:40 am | Permalink

    Thanks so much for the kind words, Alex.

  15. Posted April 5, 2013 at 4:58 am | Permalink

    This all seems very selfish to me. The main point of your argument is speedup. Got it. But speedup for the dozen or so developers on something which -might- be considered to be commoditized does not scale well up to the massive amounts of wasted energy on the part of your users (web developers and end-users). The world has not craved another fundamentally different operating system for decades. Same ought to be true for browsers. Inside it might be shiny and new, er, wait… it’s written in C++? New? Outside it’s the same old thing- navigation, pages, applications.

  16. Posted April 5, 2013 at 7:36 am | Permalink

    Hi t.:

    First, you vastly underestimate the sizes of the teams involved.

    Next, as I tried to explain above in the comments, this does nothing to functionally change the testing burden webdevs face. WebKit was already fragmented in ways that meant you were screwing users if you weren’t testing on a per product basis instead of assuming that “it’s all good, it’s webkit based”.

    You might also misunderstand what’s going on here: we’re not giving up on the WebKit codebase. Indeed, we’re taking it it as our starting-point for Blink. We just hope to evolve it faster. And you’re wrong on the meta-point: people expect more out of computers year over year. If the web cannot deliver that change, more closed, more proprietary systems will instead fill the gap. Don’t know about you, but that seems like the definition of a regression to me.


  17. Posted April 5, 2013 at 8:14 am | Permalink

    I think your numbers still won’t work to make your case. Even if there are a thousand engineers working on Chrome, it is still dwarfed by the number of web developers. A hundred-to-one or a thousand-to-one ratio isn’t terribly important in this case.

    Re: ‘you are screwing your users if you weren’t testing on a per product basis’. Unless you have money to burn, testing combinatorics is a judgement-based business- one should test a reasonable set of combinations to cover the anticipated usage. Testing too much is a waste of time. Testing too little hurts in varying degrees. It’s a business decision.

    Re: the metapoint of people expecting more from computers. You have the theory right, but the example is wrong. For instance, I know how to design a computer with a better instruction set than X86. But the x86 architecture is good enough for the masses. People, real live, non-geeky, human beings expect speed and [generally] the ‘how it does it (the apps)’ is not only not-important but is downright noisy-blah-blah-blah. Sorry, but after building O/S, middleware, frameworks for too many years– they are now ‘good enough’ and apps are where it’s interesting. Changing the junk underneath the app can and does create problems. Humans can;t track an infinitely tall vertical stack of technology. Commoditizing the lower parts allow us to move up the stack and concentrate a lot of this innovation (not all, but a lot) at the top— near where regular, non-geeky, humans live.

    I don’t want to add another browser to my dev and testing mix. But to your point, given Chrome’s popularity, I will be forced to. This will slow down MY rate of innovation (given a budget that doen’t flex on maintenance). For some longer-than-I-like time, I’ll be carrying the load for two versions of Chrome. And because my customer base spans a number of browsers- I’ll not be doing much to special-case browser shiny features. It’s a tax.

    Like everyone else, I’ll bet my CSS is going to bloat up some for some period of time. Gee– can’t wait.

  18. Posted April 5, 2013 at 8:29 am | Permalink


    I’ve already explained why #’s of devs is a distraction here. Safari and Chrome’s behavior had already drifted in ways that made not testing both untenable. Arguing a moot point well makes it no less moot.


  19. s.booth
    Posted April 5, 2013 at 5:06 pm | Permalink

    You deride others for offering their point of view on what the news of google’s press release means, and then offer your own? What matters to you is not the same as everyone else, no matter how convincingly you delude yourself. Perhaps you should rephrase your statement, “May ME forgive everyone else for existing.”

  20. Posted April 8, 2013 at 4:46 am | Permalink

    Dear Alex,

    This is my response to you as owner of Blink open source SIP project since 2009.

    The thread is here:


    I find this to be confusing for a large amount of users. We developed since 2009 Blink http://icanblink.com which is an open source SIP client for Linux, Windows and Mac. With half a million downloads, Blink is well known project in the open source VoIP community.

    It is unfortunate that no research was done to yield a better name for this webkit fork.

  21. Kundan
    Posted April 8, 2013 at 10:51 am | Permalink

    Blink is a very popular and useful opensource software for internet communications.

    If this was an oversight from Google in picking a name, it should be corrected soon. Just show us that you still care and that you are good at heart.

    If it was a deliberate or “i don’t care” attitude from a giant company, it is a shame – another instance of going from good to evil.

    The one action might soon be forgotten in press, but will remain forever with those who are affected. The choice is yours to make – be good or evil.

  22. matto
    Posted April 8, 2013 at 7:20 pm | Permalink

    Will Blink use the webrtc stack for video/audio? Will this be part of Blink or something seperate that it “plugs” into?

  23. Posted April 11, 2013 at 7:11 am | Permalink

    Hey Matto:

    Blink (the new fork of WebKit) is not a product, it’s a project that other projects (which may be end-user products) depend on. Like WebKit, it implements parts of WebRTC and provides hooks for callbacks to browser-specific implementations of the bits it can’t do itself. But nobody will ever download a “copy of blink and use it for WebRTC”. Instead, they’ll download a product that uses or embeds Blink but which has a different name. For example Chrome, Opera, or some other custom Chromium-based product.

    So the way to think about it is that Chrome implements WebRTC via Blink. Blink itself is not a product, it’s just a name for the source code repository and project.

    Hope that clears it up.

16 Trackbacks

  1. […] it has shown to be capable of in the past. For more background on the why, I encourage you to read Alex Russell’s great post on the announcement of Blink. Justin also sheds some light on the security implications of this […]

  2. By Michael Tsai - Blog - Blink on April 3, 2013 at 6:53 pm

    […] Alex Russell: […]

  3. […] better this new story I would recommend you to read Alex Russell excellent post on it: http://infrequently.org/2013/04/probably-wrong/ and for the ones the like (even more) details: The Developer FAQ contain […]

  4. By No sólo de webKit va a vivir la web on April 4, 2013 at 12:02 am

    […] el caso de Google, merece la pena leer a uno de sus ingenieros y defender los motivos técnicos (aunque de fondo va a ser inevitable barruntar que no estaban […]

  5. […] commentary about the core mission of Blink and the history leading up to the fork, there’s Alex Russell’s post from Google’s perspective, and Maciej Stachowiak’s comments from Apple’s […]

  6. […] Chrome developer Alex Russell has an excellent read on this for those […]

  7. […] One of Google’s devs wrote… […]

  8. […] http://www.chromium.org/blink/developer-faq (Resmi SSS sayfası) http://ericbidelman.tumblr.com/post/47054222305/blink-chromes-new-rendering-engine http://infrequently.org/2013/04/probably-wrong/ […]

  9. […] http://infrequently.org/2013/04/probably-wrong/ […]

  10. […] As an open source project, WebKit has many chefs in the kitchen, which is not necessarily a bad thing. But it also has different customers on varying platforms, so in order to keep it working for all, it takes a larger amount of effort in coding and testing than if it were used by a single entity. Alex Russell, a Google developer explains: […]

  11. By Articles you should read (April 4) …. on April 4, 2013 at 7:39 am

    […] “Chrome Engineer: ‘Why What You’re Reading About Blink Is Probably Wrong’ ” — “Daring Fireball” (daringfireball.net) […]

  12. […] divulge further into the Blink engine when the kit is made available, until then listen to what an official Chrome developer has to […]

  13. […] Why What You’re Reading About Blink Is Probably Wrong by Google’s Alex Russell […]

  14. […] direction (to the chagrin of everyone else). Or at least that’s one theory. Other developers, like Google’s own Alex Russell, say that the creation of the custom Blink engine will ultimately save developers time. Russell […]

  15. By Thoughts on the Blink/Webkit fork | UX Write on April 6, 2013 at 11:06 am

    […] this could possibly lead to. I understood the situation much better however after reading Alex Russell’s post which explains their rationale, and I feel that all the reasons he gave make sense — that is, […]

  16. […] A good argument in favour of the fork – via Alex Russell […]