Should all Browsers Use WebKit?

Web standards are an ever-evolving entity, with new syntax and functions being added all the time. The buzzwords of the year are HTML5 and CSS3, evolutions of the already-existing languages that most people are familiar with. Unfortunately, getting a function added to the standards is only half the battle; you also need browsers to support the function and the new syntax, or all you’re left with is something that is theoretically awesome.

For a while now, WebKit has been the most standards-compliant browser engine, with Safari and Chrome offering two of the most HTML5 and CSS3 ready browsers. Many other browsers use the WebKit engine, and today I’d like to look at what the benefits might be of a WebKit-dominated Internet.

A Note about Browsers

Browsers are doing a lot of complex work to present the Internet to you in a human-ready form. This review is actually made possible through several different languages, including MySQL, PHP, HTML, CSS, and probably more that I’m not aware of. Each of these languages are essentially a set of instructions for the browser, telling it how to behave and what to display.

Google Chrome, browsing the web.

Google Chrome, browsing the web.

The big browsers–Safari, Chrome, Internet Explorer, Firefox, and (to a lesser extent) Opera–use different engines to read this language. As I said earlier, Safari and Chrome both use WebKit (though, Chrome uses its own forked version), while Firefox has its own Mozilla engine, Opera uses the Opera engine, and Internet Explorer uses the Trident engine.

A full half of the major browsers that are acceptable to use are powered by WebKit

A full half of the major browsers that are acceptable to use are powered by WebKit

Beyond having different names, these browser engines all look for certain lines in the programming language and will process the information in their own way. Each browser, then, is truly unique; it may seem that the interface and name are the only differences between browsers, but in actuality there’s actually a lot under the hood that’s different.

What this Means for Developers

Let’s say that you’re a developer, and you want to use the latest and greatest technique available to you. Say, for example, the newest HTML5 element that you can use is called ‘Christmas Tree’. It’s a really useful element that you want users to be able to experience, so you immediately set out and write it into your website.

You, being the awesome web developer that you are, decide to check it in each and every major browser. Chrome and Safari are able to load the element, and you can hardly believe that this sort of thing is possible through the browser. Then you go to Opera, and for whatever reason it isn’t working; you check, and it’s the same thing with Internet Explorer and Firefox.

What gives? This is a real element, you thought that it was properly coded–stop right there. Your issue lies right there: you thought that it was properly coded instead of knowing it.

Instead of being able to use the amazing ‘Christmas Tree’ element, you’ve suddenly come to the point where you need to either A) Figure out how to make a similar effect work within other browsers, B) See if the element actually does work but requires slightly different coding, and C) Question your choice of career, as you keep muttering ‘stupid Internet Explorer’ under your breath at the dinner table.

Targeting Different Browsers

See, what you’ll need to do is target specific browsers right within your markup. Each browser has a unique identifier; Safari and Chrome both use the – webkit – identifier, while Mozilla uses – moz – and Opera uses – o -. This might not mean anything to you right now, but what it boils down to is that you’re going to have to write a line of code with what is essentially the same syntax, but with the identifier changed.

Does this sound like fun to you? Probably not; none of us are fans of wasting our time. Even if you do write that code properly, you’re stuck with the issue of a browser (probably Internet Explorer) not supporting the element that you wanted to use anyway.

Why not make our lives simpler, and just stick with WebKit?

Benefits to Sticking with WebKit

WebKit is the most standards-compliant engine in use today, and its market share continues to grow. It’s got an exciting history, and continues to be one of the most rapidly developed browser engines today. WebKit is used in everything from Safari and Chrome to app-specific browsers; chances are very high that unless you’re using a Windows Phone, WebKit is powering your mobile browser.

And this is from 2009; the numbers for iOS and Android have both gone up.

And this is from 2009; the numbers for iOS and Android have both gone up.

With near-ubiquity in the mobile space, I think it’s time for WebKit to become king-of-the-hill with the desktop space as well. This would save web developers time writing code, and with so many people contributing to the WebKit open source, it could maintain its position as the most compliant browser.

There’s also the peace of mind with knowing that you can write one line of code instead of three or more; this could help save time, and improve trouble-shooting as developers could focus on one engine instead of trouble-shooting multiple browser types.


Of course, using WebKit as the de facto browser engine has its drawbacks, mainly: competition helps make everything better. We saw this with Internet Explorer a decade ago; it had become (and, unfortunately, remains) the most-used browser, and it got complacent. Say the words Internet Explorer 6 to a web developer and see how quickly he tries to either murder you or breaks down into tears.

Competition might be what is keeping WebKit so bleeding-edge; it sees its ability to read the newest additions to the syntax as an important defining factor, and so long as there’s competition it will continue to evolve. Without competition, it might slow down and grow lazy.

Okay, So?

I think that WebKit should be the main engine. It’s already nigh ubiquitous in the mobile space, and I think that the people who are working on improving WebKit are also the sort of people that would be working to improve it even if there wasn’t any competition from competing browser engines. Not only would it help unify the experience for us, the end user, but it would also save time for web developers and increase the rate of adoption for the shiny new HTML5/CSS3 features.

I don’t really see a downside here. WebKit is the way of the future, and is already on that path. Just think about how much browsing is done via mobile devices powered by WebKit, and then think about how mobile sales are up and desktop/laptop sales are down. WebKit is the future, whether we like it or not, and we may as well embrace it.