We’ve enjoyed a relatively long period when we didn’t have to think about which browser to use. Alas, that period is ending: I must now keep Chrome running all the time, much like I needed that PC in the early 2000s.
Wednesday, July 7th, 2021
Monday, July 27th, 2020
John weighs in on the clashing priorities of browser vendors.
Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.
Thursday, July 9th, 2020
Jay quotes from a 1992 email by Tim Berners-Lee when there was real concern about having too many different browsers. But as history played out, the concern shifted to having too few different browsers.
I wrote about this—back when Edge switched to using Chromium—in a post called Unity where I compared it to political parties:
If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!
In the discussion we dive deeper into the naunces of browser engine diversity; how it’s not the numbers that matter, but representation. The danger with one dominant rendering engine is that it would reflect one dominant set of priorities.
I think we’re starting to see this kind of battle between different sets of priorities playing out in the browser rendering engine landscape.
Webkit published a list of APIs they won’t be implementing in their current form because of security concerns around fingerprinting. Mozilla is taking the same stand. Google is much more gung-ho about implementing those APIs.
I think it’s safe to say that every implementor wants to ship powerful APIs and ensure security and privacy. The issue is with which gets priority. Using the language of principles and priorities, you could crudely encapsulate Apple and Mozilla’s position as:
Privacy, even over capability.
That design principle would pass the reversibility test. In fact, Google’s position might be represented as:
Capability, even over privacy.
I’m not saying Apple and Mozilla don’t value powerful APIs. I’m not saying Google doesn’t value privacy. I’m saying that Google’s priorities are different to Apple’s and Mozilla’s.
There is a contingent of browser vendors today who do not wish to expand the web platform to cover adjacent use-cases or meaningfully close the relevance gap that the shift to mobile has opened.
That’s very disappointing. It’s a cheap shot. As cheap as saying that, given Google’s business model, Chrome wouldn’t want to expand the web platform to provide better privacy and security.
Saturday, September 1st, 2018
This is a terrific spot-on piece by Rachel. I firmly believe that healthy competition and diversity in the browser market is vital for the health of the web (which is why I’m always saddened and frustrated to hear web developers wish for a single monocultural rendering engine).
Saturday, April 6th, 2013
A good history lesson in rendering engines: KHTML, WebKit, and now, Blink.
Wednesday, April 9th, 2008
David Recordon shares his first impressions of Google App Engine.
Every Google account can now be an OpenID login thanks to this app built with the Google App Engine.
Tuesday, April 8th, 2008
Infrastructure just got even cheaper. Between this and Amazon's EC2/S3, the barrier to entry to getting an app up and running is getting lower and lower.