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.

Issues

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.


  • Sebastiaan

    I’d love to see all major browsers use the Webkit engine. However even if you got every browser to use Webkit, you still be stuck with a HUGE chunk of users using outdated versions of their preferred browser. Hell i still come across people who refuse to get rid of Windows XP and Internet Explorer 6.

    • Nathaniel Mott

      I must admit that most of my family is still using an older version of Windows, whether it’s XP or Vista. A lot of it comes down to financial issues, but they also haven’t found much use for upgrading.

      Luckily, through sheer force of will and dumb luck, I have gotten most of my (and my girlfriend’s) family and friends to switch over to Chrome. It’s easily the best browser on Windows, and I feel good knowing that I’m helping IE fade into the background.

  • http://www.brunobernardino.com Bruno Bernardino

    Obviously there are other things to consider. For example, most current Firefox users won’t switch to Chrome because of the power of its extensions, which is possible only because of its own engine, Gecko.

    WebKit, by not allowing its extensions to do as much as Gecko does, has less powerful (or less customizing) extensions, which is a big drawback for its users.

    As a Web Developer and Google Chrome lover (former Firefox lover, like most Google Chrome users, I guess), I would love to see WebKit be the most used engine, but realistically, I just want Internet Explorer dead and I can cope with Firefox (rarely needs that much attention anyway, and they’re trying really hard to catch up with Chrome).

    Sebastian also has a point.

    • Nathaniel Mott

      Write, I was unsure whether Firefox’s extensibility was a product of the Gecko engine or whether it had to do with the rest of the browser. That’s certainly something to consider, though Chrome is catching up in the extensions department.

      So far it seems that the consensus is ‘kill Internet Explorer’, and I couldn’t agree more.

  • http://chrisdpratt.com Chris Pratt

    I’ve been thinking along the same lines for quite a while. It hardly makes sense to develop your own custom rendering engine when a really good open-source engine already exists. If Microsoft and Mozilla would drop their own efforts in this space and instead contribute their time and energy to WebKit, we could not only have a single unified platform to build on, but also an even better one at that. Then, you could pretty much hitch WebKit to the W3C and have near perfect parity from spec to implementation.

    Particularly in the case of Internet Explorer, continuing development on Trident is a huge waste of time. Trident is the absolute worst engine and will continue to be, because improvements are merely built onto the same shoddy foundation.

  • http://www.tecnomente.com/ gabriele

    The problem is that also IE6 was the best and nearly ubiquitous, and that leads to angry developers because MS made IE works differently from other browsers to force everybody to follow the “IE way”.

    What you are suggesting it’s no different, and that is bad not because MS did it, but because it will actually make things worse again; WebKit will not go forward, but simply in a different direction from everybody else, just like IE did.

  • http://dkuntz2.com DKuntz2

    Mozilla’s rendering engine is called Gecko, not the Mozilla engine.

    Sorry, that’s my INTP showing.

    • Nathaniel Mott

      Hmm. I knew that, I must have missed the mistake while I was proofing the article.

      No problems there, I’d rather people know what the engine’s called than continue to refer to it incorrectly, as I did.

  • http://dkuntz2.com DKuntz2

    Also, PHP and MySQL never talk to the browser. The HTML generated by them does, but not the “pure” PHP and MySQL.

    Actually, Apache, or whatever server you’re using, is what reads the PHP (which reads the MySQL). If you browsed to a php file on you computer without using apache or another server you would be given the plain text version of the file, not the rendered version.

    It’s like how Rails renders your Ruby application to the browser, or Django renders your Python. The browser itself doesn’t know what to do with that stuff, but the frameworks know how to present it to your browser.

    • John Smith

      This is mostly correct, although if you think PHP interprets MySQL commands you’ve seriously misunderstood something. MySQL reads MySQL commands and passes the results back to PHP.

  • http://twitter.com/mmorri Mike Morris

    No. Competition fuels innovation, while monopoly breeds complacency. You cited the negative example of IE stagnation and standards ignorance, but failed to highlight positive aspects of browser competition. Great current example is the HTML5 localStorage proposal. Most current browsers supported DOM-based storage (dating back to IE8 I believe). The WebKit team implemented sqlite storage as a more robust solution. However, Mozilla/Firefox implemented the key-value NoSQL solution indexedDB, which seems to be favored at the moment as a faster alternative, built on a different data storage architecture. Even IF all browsers used the WebKit engine, I would expect to see forks like Chromium and resulting browser differences.

  • Tim

    I just want Mozilla to stop this incredibly stupid rapid release program they’ve got going on. They just released 8 and the 9 beta is out. How ridiculous. Their updates don’t even warrant a full number update.
    Chill out, Mozilla! Your browser is still good. You don’t have to play catchup to Chrome just because you think you do. If anything, these rapid releases have made the browser worse because they don’t take time to test everything.

  • Will

    It’d be awesome to see Webkit as the only engine, but really, as a developer I’d be happy to just see IE (more so pre version 9) continue to fall. My company doesn’t have the most web savvy customers, but IE share on our main web product has dropped down to 32% and is continually dropping which is a great feeling for my team :)

    • Nathaniel Mott

      That’s definitely something to be happy about! Hopefully as people are forced to upgrade their computers or their family members push them towards other browsers IE will either be forced to conform or finally bite the dust.

      It amazes me that it still exists as a product; I’m not sure that it brings that much money in for Microsoft, it’s got to be a hassle to make, and it’s universally hated. I don’t think I’ve ever heard a single person say ‘hey, I really like Internet Explorer’. Usually it’s a lot of swearing at toolbars and angry pop-ups.

      • Tim

        I used to like IE 5 for the Mac many years ago. It was a good product. Then, well…you know…

      • Sebastiaan

        The one problem why IE won’t just die is very simple. Internet Explorer and the regular Explorer (the application that makes filebrowsing possible at all on Windows systems) are one and the same. You can never strip IE out of a windows system completely.

        Even though these days MS is forced to offer a bunch of alternative browsers after the initial setup, you can still turn any regular filebrowser window into a native internet explorer window.

  • http://dkuntz2.com Don Kuntz

    I think it would be a really poor decision if all browsers started using Webkit as their rendering engine.

    I think that it would be like saying all new cars have to arbitrarily be made by Chevy.

    I think a part of technology is that you have choices. I can choose to run Arch Linux, you can choose to run OS X, person x can choose to run Windows, and that’s great. I may not like your operating system, but that doesn’t matter, because YOU like it. It’s the same with a rendering engine.

    Would your life be easier if all browsers used the same rendering engine? Possibly. But if so, I personally think it would only be marginally better. Ohh, I can’t use [element x] yet because [rendering engine y] doesn’t support it. Who cares? Just use it and tell people that they might need a different rendering engine to have full support. In general, most websites don’t really need [element x]. I don’t particularly use anything “html5-y” on any regular basis.

  • Joe

    The biggest Fallacy of the definition of “Standards”.

    Only suckers open forth the future. They’re always open to a con promise.
    And they’re trying to kill Flash. IGNORANTS.

  • Xananax

    This post is a nice thought experiment/brainstorming, but frankly, I don’t see the point (no offense meant). It’s not as if some sort of authority could come and decide which engine should be used from now on.
    Webkit is becoming the de facto engine…For the moment. As long as people can code, other engines will evolve, new engines will be created, and eventually something will appear for users as a better option. By users, I mean coders that implement webkit (Actual end-users have little to say in this, if everything works well).
    Remember, a few years ago, flash was the de-facto technology for displaying dynamic (moving) content in a cross-platform, cross-browser way. A few articles at the time described how Flash and Air would conquer the world of web and desktop alike.
    As I spend most of my time working with HTML, for the web or for apps, I would love to have to support webkit only, but the time where supporting other platforms will be irrelevant is probably never. Furthermore, as you point out yourself, there are slight differences between webkit implementations that will make your code behave differently on different platforms anyway. Although the iphone, safari mac, safari windows, chrome, android browser all implement webkit, they all read and react differently. And don’t get me started on javascript events, it’s even worse.

  • George

    Opera doesn’t use the “Opera engine” it uses Presto

    • Nathaniel Mott

      My apologies. I thought that it was called the Opera engine because I’ve never heard otherwise and its identifier in code is ‘-o-’.

  • Andy F.

    In a effort to reduce the “complacency scenario” … why not make webkit extendable? Programming languages have long used this to create custom functionality that is based off internal classes. An unrecognized benefit of this is if a really great class is written, the company responsible eventually works it into their own code. RoR has been doing this for years.

    I’d have to do some research into the technical feasibility, but why not allow web developers the ability to extend webkit classes in their own code? If they want to do something slightly different, they can in a one-off manner. It would be far easier on developers with specific use-cases, rather than entice them to write “yet another” rendering engine. It would also essentially crowd-source development much like RoR, which is what has made that language popular.

    Point being, if we have to live with the need for differences, why not do so while keeping a standard “base” engine? In the event everyone can agree with a change, at least merging it into the standard wouldn’t take re-writing the whole engine.

    Just a thought ….

  • http://www.massagista.org Massagista

    i Agree in The WebKit team implemented sqlite storage as a more robust solution. However, Mozilla/Firefox implemented the key-value NoSQL solution indexedDB…good work!

  • Orrin

    This is very shortsighted idea and in the end would be the end of the web as we know it today. The plain and simple fact is that browser engine is a core component of the browser itself and if all vendors standardized on 1 browser engine we’d pretty much have 1999 all over again (I may be a little off on the date, I have not committed the pinnacle of IE usage to memory). Does anyone here still remember that? It was terrible.

    If you have one browser engine why not have 1 browser? Why not have phone laptop maker? Why not have one smartphone maker? The world would be much simpler and all the human effort could be used to put forth the best of everything.

    As others have pointed out Firefox is simply the best and always will be when it comes to a user customized experience. It was built from the ground up to be 100% customizable from UI to functionality, etc. I can’t cite this source but I can find it if someone wants it but Google looked at using Gecko and went with Webkit simply for speed. If anyone here remembers when Chrome showed up on the scene they will remember that the biggest selling feature of Chrome was speed. I’m glad Chrome showed up and challenged the rivals on that feature and today we have much faster browsers all around (Firefox, IE, and Opera are all faster because of Chrome).

    In conclusion please consider this idea. Competition is good. Competition is what makes great minds at Google, Mozilla, Apple, Opera and Microsoft get out of bed in the morning and strive to create a better project.

  • Sanjay

    Hey how can i embedd webkit in my browser??Any suggestions????Help pls..

    • http://techinch.com/ Matthew Guay

      If you’re using Internet Explorer, you can get Chrome’s webkit based rendering in your browser with Chrome Frame (http://code.google.com/chrome/chromeframe/). If you’re using Safari or Chrome, you’re already using Webkit.

  • http://greenwap.tk Muhammad Shahmi

    I don’t really like webkit actually though I still use it in my CSS file. You say what? Opera and Mozilla didn’t support such an element (described in this post)? Nah.. I use any HTML5 without considering compatibility! Opera and Mozilla has been already supporting HTML5 and CSS3!!!! I use the webkit prefix only intending to make smartphone support it. Though some special CSS properties, like the linear gradient then I use all available prefixes like -o-linear-gradient ..

  • Erwinus

    Webkit, hmmm. It is true that it got some great features but….. There are some different implementations around and i think google chrome has the best one. Safari webkit on iOS is the most worst one.

    The fact that Apple does not allow third-party implementations on the iOS platform is scary. On the iPad3 (iOS 5.1.1) the webkit engine is awful and safari crashes many times (cause: some HTML5 features as gradient and javascript driven websites/webapps). Installing another browser doesn’t make sense because Apple requires that the browser use the crappy ‘Apple webkit’ engine.

    It is bad that there is no other choice on the iOS platform, when it crashes there is no second opinion possible except for Opera that use a proxy to render pages (but does not work on all sites). Also when Safari crashes, no message, no explanation, no nothing. User friendly. duh!

    Apple likes that you are using everything from Apple but i think that it is limited freedom. It is like the time with the IE dominance, but with one major difference. When an user install another browser it is still safari webkit but with another enclosure. Evil. No other options, still nothing to choose.

  • Pingback: Pourquoi Flex reviendra « Blog d’Ippon Technologies

  • Rishabh Shah

    I am facing some problem that i developed website and it’s logo in chrome isn’t looking perfect means logo in chrome is small or compress and other browser like in mozilla firfox, internet explorer looking big and proper. so i want some help to solve this problem..

    for any information please visit site http://www.shadesofweb.in/iim
    this site visit in both browser chrome and mozilla tan please suggest me that how to solved this problem.

    I want immediate rply…:)

    Regards:
    Rishabh shah

theatre-aglow
theatre-aglow
theatre-aglow
theatre-aglow