Waaaaaaa?! #

That’s pretty much what my first sentiment was as well. Well actually it wasn’t. I work on the basis that I’m the least smart guy in the room (which works out to be true more often than I’d like) and my first thought was more like “What am I missing? Why such a big change?”

When it comes to web stuff I am entirely self-taught, like most developers, and for most of my career I cared very little for browser internals. After all, I'm giving browsers a bunch of stuff to deal with (HTML, CSS, JS), why should I start caring how they do it? I don't sit there musing over my car's ability to combust petrol whenever I take a drive.

I don't sit there musing over my car's ability to combust petrol whenever I take a drive.

I was dimly aware of WebKit, Trident and Gecko, but I was happy to consider them some abstract notion, much as I do with my car. Sometimes they were awesome, sometimes they were problematic, but whatever the case I honestly didn't care much for them. They just took my code and made it work. Job done.

Browser Internals #

A while ago I figured that I was going to have to understand things a little better and so I set about trying to get to grips with browser internals. I recall the moment that I realised that there's a ton of stuff outside of the engine that actually makes a browser a browser. In short, I realised that WebKit isn’t the browser and that it’s not the right mental model to consider Chrome and Safari as “pretty much the same thing”. In hindsight I feel a bit silly that I hadn't thought about it in those terms before, but there we go, we all learn somehow.

Anyway, in my case understanding more about the browser internals helped me be a better developer because I was less reliant on the “magic” under the hood and I could code more tactically. I'd say if you have the time and inclination it's well worth your effort to do the same. In the interests of not reinventing the wheel, I'll just suggest that you read Paul Irish’s post about WebKit for Developers if you haven't already. It covers the WebKit internals stuff I wish I'd known a few years ago. Obviously that's only one part of the puzzle, though, because there are a bunch of different engines out there. But it’s a start! Actually, aside from Paul’s excellent summary, the HTML5 Rocks article that explains how browsers work is something of a must-read, too, so give that a whirl as well.

The Browserscape #

Today we have five major browsers: Chrome, Firefox, Safari, Opera and Internet Explorer. Opera is switching to use the Chromium project for their next version, and of the three remaining only one other is a WebKit port: Safari. It's worth keeping in mind, then, that as developers if we do assume a certain amount of consistency between WebKit ports, there are still Firefox and Internet Explorer out there with a large market share that are not WebKit-based. But you know all this, so why do I mention it?

Well if two of the major browser vendors are not WebKit-based then we still have a situation where several completely different implementations need to interoperate and behave consistently. It's actually far more important that we have standards around which compliant implementations can be built than it is that we have some “common base”. That way we can have a clearly documented set of APIs and behaviours that we can reference, no matter which browser we're discussing. We need to be able to ask the question "Is this thing acting the way we all agreed it should?"

It's actually far more important that we have standards around which compliant implementations can be built than it is that we have some “common base”.

A pretty solid example of this in action is V8 and SpiderMonkey. V8 was a break from WebKit's default JavaScript parsing and execution engine (JSC), and it fast became the leader for JavaScript performance. Today Mozilla ship SpiderMonkey in Firefox, which is also blazingly fast. The teams behind V8 and SpiderMonkey (or any other JavaScript engine, I’m just picking these two) ensure your JavaScript is executed according to ECMA standards, but when was the last time you sat there pondering how much code is shared between JavaScript engines, or if there should be some combined effort? Before writing that sentence my own honest answer was "umm, never" and I've got a hunch yours might be similar. So adhering to the standards, to me at least, makes more sense than any shared code.

It turns out that “big change” I didn’t understand initially is about improving the platform, much like V8 did for JavaScript. Blink is a new engine, yes, but it’s being built to conform to open web standards, which is what we need as developers, much more than we need any given engine. My hope is that we’re also going to see innovation across the platform as a whole in terms of performance and stability, and if that means we can all build better apps, then I’m excited.

OK, a new engine. Now what? #

Well there's a pretty fine Blink FAQ document that will hopefully answer the majority of your questions, but from my perspective there are a few final thoughts I have on all this.

We are building sites and apps for our users, and their expectations of what can be done in the browser grows year on year. Many of us are also building for businesses that choose between web and native as their primary delivery platform. I for one am really grateful when any browser vendor takes that need seriously, whether that's Google or anyone else. I believe we are going to need an engine that will allow us to build the next generation of web apps. I think Blink is the start of that, and that’s something I'm really excited about.

Secondly there's a new Chrome Status page, which gives way more insight into Chrome's implementation of standards, as well as the known position of other vendors on a per-spec basis. It's great to be able to get insight into the current status of whichever upcoming features your apps rely on, so that you can plan accordingly.

Finally there are now very clearly defined policies around how Chrome changes going forward. That means it should be clearer what we can expect from Blink and Chromium as a whole.

Conclusion #

There's no doubt in my mind that Blink is going to be a huge change for a web, but I also think it's a very positive one. I desperately want the web to be the best delivery platform for our apps and sites. I am hopeful that in the same way we saw V8 change our expectations of JavaScript performance, that we will now see the broader browser landscape challenged as well.