Thoughts On A Job Done

Most of the time, when a bit of software you work on floats out of your life and into the collective past, there’s a sense of mourning. But that’s not how I feel about Chrome Frame.

The anodyne official blog post noting the retirement six months hence isn’t the end of something good, it’s the acknowledgement that we’re where we wanted to be. Maybe not all of us, but enough to credibly say that the tide has turned. The trend lines are more than hopeful, and in 6 months any lingering controversy over this looks like it’ll be moot. Windows XP is dying, IE 6 & 7 are echoes of their former menace, and IE 8 is finally going the same way. Most of the world’s users are now at the front of the pack where new browser releases are being delivered without friction thanks to auto-update. The evergreen bit of the web is expanding, and the whole platform is now improving as a result. This is the world we hoped to enable when Chrome Frame was first taking form.

I joined Google in December ’08 expressly because it’s the sort of company that could do something like Chrome Frame and not screw it up by making it an attention hogging nuisance of a toolbar or a trojan-horse for some other, more “on brand” product. GCF has never been that, not because that instinct is somehow missing from people that make it through the hiring process; no, GCF has always been a loss-maker and a poor brand ambassador because management accepted that what is good for the web is good for Google. Acting in that long-term interest is just the next logical step.

Truth be told, we weren’t even the right folks for the job. We were just the only ones both willing and able to do it. MSFT has the freaking source code for IE and Windows. There was always grim joking on the team that they could have put GCF together in a weekend, whereas it took us more than a year and change to make it truly stable. Honestly, if I thought MSFT was the sort of place that would have done something purely good for the web like GCF, I probably would have applied there instead. But in ’08, the odds of that looked slim.

Having run the idea for something like Chrome Frame past one of the core IE team engineers at MIX that year, the response I got was “oh, you’re some kind of a dreamer…a visionary”. I automatically associate the word “visionary” with “time-wasting wanker”, so that was 0 for 2 on the positive adjective front. And discussions with others were roughly on par. Worse, when the IE team did want to enable a cleaner break with legacy via the X-UA-Compatible flag, the web standards community flipped out in a bout of mind-blowing shortsightedness…and MSFT capitulated. Score 1 for standards, -1 for progress.

For me, personally, this has never been about browsers and vendors and all the politics wrapped up in those words: it has been about making the web platform better. To do that means reckoning with the problem from the web-developer perspective: any single vendor only ships a part of the platform that webdevs perceive.

Web developers don’t view a single browser, or a single version of a browser that’s on hundreds of millions of devices as a platform. Compared to the limited reach of “native” platforms, it seems head-scratching at first, but the promise of the web has always been universal access to content, and web developers view the full set of browsers that make up the majority of use as their platform. That virtue that both makes the web the survivable, accessible, universal platform that can’t be replaced as well as the frustrating, slow, uneven development experience that so many complain about.

The only way to ensure that web developers see the platform improving is to make sure that the trailing edge is moving forward as fast as the leading edge. The oldest cars and power plants are exponentially worse polluters than the most modern ones; if you want to do the most for the world, get the clunkers off the road and put scrubbers on those power plants. Getting clunkers off the road is what upgrade campaigns are, and GCF has been a scrubber.

All power plants, no matter how well scrubbed, must eventually be retired. The trend is now clear: the job coming to a close. Most of the world’s desktop users are now on evergreen browsers, and with the final death of WindowsXP in sight, the rest are on the way out. Webdevs no longer face a single continuous slope of pain. We can consider legacy browsers as the sort of thing we should be building fallback experiences for, not first-class experiences. The goal of making content universally accessible doesn’t require serving the exact same experience to everyone. That’s what has always made the web great, and now’s the time for non-evergreen browsers to take their place in the fallback bucket, no longer looming large as our biggest collective worry.

I’m proud to be a small part of the team that made Chrome Frame happen, and I’m grateful to Google for having given me the chance to do something truly good for the web.


  1. Posted June 13, 2013 at 12:08 pm | Permalink

    Why not set the end date to April 2014, the end of support date for XP?

  2. Posted June 13, 2013 at 12:51 pm | Permalink

    Clearly you’ve never done work for federal, state, or local government.

  3. Posted June 13, 2013 at 1:25 pm | Permalink

    My wife is front-end lead for I’m intimately familiar with the constraints the slowest users place on the ecosystem. If I wasn’t, I’d never have poured years of my life into GCF. But the left-behind eventually need to own their situation. I’ve done my bit, and while I feel for those trapped in situations beyond their means to effect change, I hope this will be one more signal that the time to move into the mid ’00s is now.

  4. Bark
    Posted June 13, 2013 at 5:31 pm | Permalink

    Agree with comment above… You’d be amazed and dismayed at the number of Fortune 500 companies still running IE8, with indefinite plans for upgrading. The billion dollar company I work for and develop software for made GCF a part of our strategy for addressing these companies and providing them with the best web apps we could.
    Now, with Google retiring GCF, we are in quite the quandary. It’s a little shocking, given Google’s endeavors in the business space, how unaware they seem to be of the state of IT in the country’s largest companies.

  5. venkat
    Posted June 13, 2013 at 6:29 pm | Permalink

    Alex, great work on GCF, thanks to your hard work, GCF has given us developers much needed relief when client corporate standard browser put us years behind the mainstream, now I know there are sacrifices involved and can never thank you guys enough

  6. Posted June 14, 2013 at 1:32 am | Permalink

    Hey Bark,

    Honestly, having worked on GCF for years, nothing would shock me about organizational upgrade resistance. I’ve seen or heard it all, from scared users to cash-strapped libraries to IT systems that have fallen out of contract and can’t be touched for fear of breakage. And GCF has been my way of doing something to help them out.

    But time moves on.

    For the end-users who can’t move, luckily we’re seeing very broad upgrade campaigns. I show the sorts of things users on legacy browsers experience now in a recent talk:

    The end of that talk was a call to arms: it’s time for webdevs to start treating legacy browsers like the polluters they are and ask those users, very bluntly, to upgrade. Not force, not require in order to get access to content, but as a friction point to continuing to use outdated software. That’s the sort of thing that can be effective at scale with end-users who have some ability to choose; e.g., aren’t in locked-down enterprise scenarios.

    But back to this billion-dollar org: we’ve provided the Legacy Browser Support extension:

    And for years we’ve helped these orgs ride their investment in legacy software down the depreciation curve. But there comes a time when our interests part; what’s good for those orgs may no longer be good for the overall ecosystem. That GCF is riding into the sunset is yet another signal that they are far, far out of the mainstream and will need to pay increasingly high costs to stay there. And that, taken as a whole, is a good thing. Web developers SHOULD be able to charge (quite a lot) more to build experiences for legacy browsers, and those orgs should be hearing from their vendors that running old, less-secure engines is asking for trouble. For organizations with IT staff, this really is the end of the road and they really do have to choose. I know it’s painful to hear, and I’ve done my level best to ensure that these sorts of organizations can’t punish the rest of the world by driving clunkers, but now the water has receeded and we can see legacy browsers for what they are. Time to act. And the good news is that these are people with money, so they can buy options, even if they can’t buy any more time.

  7. Bark
    Posted June 14, 2013 at 4:16 pm | Permalink

    Alex — thanks for taking the time for a clearly well-thought response. I agree with your intent, but not necessarily with the justification or approach.

    With the latter, the idea that these companies are “people with money” is far too simplistic a view. First, you have IT organizations that are cash-strapped. These are seen as cost centers in corporate America, not revenue-generating think tanks like you might see at the halls of Google and Silicon Valley. Many of them, in the largest companies, are seeing their budgets slashed, their personnel outsourced, and their ability to move forward from a technology perspective is eliminated. They’re going to spend money buying their way out of performance and storage concerns, not improving architectural elements of their application deployment strategy.

    At one of our largest customers, a company with 61 billion — billion — in revenue and a market cap of over 230 billion, their head of IT who I met with to discuss mobile strategy said, without a smile, “at our company, we have yesterday’s technology tomorrow.” Again, no smile.

    The money is not there for IT. This is endemic.

    The actual business customers at these clients that I service are just as budget strapped — the insights we provide come at a hefty price, and it is well worth it when our assets are leveraged. However, to now have to say, after selling in the idea of deploying GCF, that they have to abandon these plans and shift to another browser installation and another set of policies, as well as (believe it or not!) another set of trainings on the new browser… Lets just say that I’m not relishing these discussions, and I generally like a good fight.

    Finally, as a technologist, I can understand and appreciate the holistic intent — ditch the crutch, and users will be forced to make the move. However, if you are really going to be true to your ethic, that you want the best of the web available to everyone, I would advise that you are doing it too soon; that the corporate world is not yet ready, with their legions of IE7 and IE8 installs; and that GCF is still the vector that development companies, such as mine, who have and continue to invest heavily in the vision of deploying the best web solutions possible using the most contemporary technologies, hung our hats on.

    And now, regardless of your grand intent (I say that with zero sarcasm), these customers will not get the best of the web. And while it may be premature of me to say so, and while I’m confident that I could win the argument, the issue will be raised at our next strategic discovery sessions, and I will find myself defending my position to boost HTML5 in lieu of our Silverlight and Flash strategy which was entrenched for so long.

    Imagine if I lose that battle!

  8. Posted June 19, 2013 at 4:06 am | Permalink

    Hi Bark,

    Thanks for the thoughtful response.

    I’ve worked in organizations running yesterday’s technology tomorrow. My first “real” web job was at a place that staffed a full floor at their global HQ with COBOL and JCL programmers. But that was a business choice. As is the situation you’re describing.

    That the costs of doing nothing inside these organizations is rising is a long-delayed mirror of the costs they’ve been able to externalize until now. For the first copule of years of IE 6/7/8 ownership, these organizations were in the mainstream, not costing anyone anything, and their costs of ownership were low. As time passed, their collective market pull distorted the cost curve: the entire platform was held back by the drag they created, apps suffered, and they continued to not pay any marginal price for that distortion.

    What’s happening now is that these chickens are coming home to roost for real. After nearly a decade of making life harder and more expensive for everyone else, the rest of the web has finally left them well and truly behind. GCF was a land-bridge to help them navigate their way to a better world. That they haven’t is still a deliberate choice, and one they’ll now have to do something about. That’s not optimal for them, but we’re at the marginal limit of my sympathy: I only care about the choices those organizations made to the extent that they held the larger web back. They have agency, no matter how much they want to talk themselves out of it via budgeting exercises. I have poured years of my life into helping them out, and Google has thrown huge amounts of money into the effort; all of which is justified only on the hope of a better web. Let me be blunt: it doesn’t matter the cause of the web evolving what these organizations choose to do now. They can join the modern, evolving web and once again have low ongoing ownership costs or they can ride a legacy platform and pay full-freight. Either way, developers and consumers of apps built today are no longer caught in the crossfire.

    Another point: the upgrade cycle you’re implicitly positing here is broken. The old-skool model of “lets adopt something and not update it and patch it only occasionally” doesn’t match either today’s malware threat landscape or the way the rest of the web is moving. Organizations with that mindset helped lock developers into the idea of a stable software target (vs. a stable core set of compatible APIs) and that has ALSO cost us large in the collective sense. We’re finally breaking free of that, and even MSFT is hopefully going to move that way with WIndows Blue. The web is one of the platforms that’s evolving in a compatible way that ensures that apps built today work tomorrow, regardless of vendor.

    If you lose that battle about Silverlight/Flash, you’re just going to be betting on legacy. They’re both dead-platforms-walking. The alternative to that is to bite off a truly modern model; one where software compatibility is the question, not version number. Updates MUST happen, else you’re just asking to have malware-riddled boxes. In today’s environment, it’s reasonable to talk about alternative vendors for a comodity platform, but weighing versions against each other is nonsensical. There’s only “up-to-date” and “pwn’d”. Even MSFT and Adobe will tell you that about Siverlight and Flash, respectively.

    Lastly, GCF will still be deployable. It just won’t be updated, although I anticipate that folks will be making updated open-source installers available. There’s some movement on the mailing list about that. But that will get increasingly hard as the patchset gets larger. We’ve provided a 6 month extrication timeframe to help ease the burden, and I suppose we could talk on the list about alternative timeframes that you think are more reasonable. Any evidence you can provide would be helpful in those discussions.

    Lastly, if someone wants to pay one of the GCF hackers huge piles of cash to quit Google and maintain open-source GCF patches against Chromium…well…can’t hurt to offer, right?