Supporting a monoculture is trading future potential in the name of short-term convenience. This doesn't just apply to rendering engines, or even just technology. Wishing you could wave a magic wand and make everyone use the same tools, language, conventions, or coding style is something every engineer wishes from time to time, but the world would be worse off without diversity.
Wishing one rendering engine "wins" over the others is a reasonable thing to say, and WebKit is a very fine engine. But the moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.
IMO supporting and testing against multiple rendering engines is the biggest PITA / productivity loss in web dev today. Being unproductive takes the joy out of developing software and having to support multiple impls is a sunk cost that creates no end-user value. Knowing about quirks of each rendering engine increases the cognitive overhead developers need to know when developing for the web, further stifling productivity and reducing the end-result quality of websites.
I'd rather only have to know and develop against a single implementation in the same way I prefer there is a primary UI SDK/toolkit for each OS.
IE's tools aren't "horrible" either, they're just different and pretty much have the exact same functionality. In fact they were much better than Chrome's tools until about 2 years ago. Chrome's tools still even have some annoying features that are better in IE. Yes, I'm looking at you watch variables. Also much prefer their 'trace styles' over Chrome's massive list of every selector ever.
With all that said, Chrome's my development browser of choice these days. The right click inspect element is the killer feature over IE's dev tools. For some reason I've never got on with Firebug. For a long time I'd actually be using all 3 at once due to needing different logins, but Chrome's multi-profile support has stopped that.
That said, I do test it on Firefox periodically and when something breaks it's usually an easy fix.
I'm not even attempting to make it work on IE.
Even if we were all to rally behind Webkit (unlikely), what happens when a significant portion of the community decide they don't like the direction of the project (and they will, sooner or later) - we'll get a fork, and be back to square one, only with a huge amount of damage done to the open ecosystem we have now.
WebSQL is an example where Mozilla (and their enabler in the HTML 5 standard, Ian Hickson) actively hurt users and developers by supposedly avoiding a monoculture by demanding multiple implementations. WebSQL should have been part of HTML 5, and we, as a community, have failed both users and developers since it's not. We failed because of an ideology that is hurting us in this instance.
The lack of multiple implementations of SQL (the language) is the "reason" the WebSQL standard is in maintenance mode. But here's the deal: all WebSQL implementations today (e.g. WebKit, Google Gears) are based on SQLite, which is public domain software.
Specifying that SQLite itself be used in the WebSQL standard, along with a WebSQL API for querying the actual SQLite version (e.g. "SQLite 184.108.40.206"), would directly solve literally every actual objection someone might have about WebSQL, except the multi-implementation/monoculture objection.
But the "multi-implementation/monoculture" objection should not be an objection at all since we're talking about SQLite: public domain software that every browser vendor can just use directly, and interested parties can check out the code and study if they want to know what is supported, and what, if any, "quirks" are present (the usual reason why codebases are not used as "standards", which is a valid complaint).
SQLite is just pure awesome and WebSQL makes it possible to do some really great things in the browser. Ideology here is just hurting everyone, for no actual benefit: instead of a monoculture, we have no culture at all.
The only way it was ever going to get off the ground was if someone fully spec'ed out a dialect of SQL that browsers could implement without being tied to the specifics of how SQLite works. Nobody stepped up to do that (and browser vendors weren't exactly foaming at the mouth to write their own SQL engine), so it died. You'd be better off writing a JS SQL engine that worked on top of IndexedDB these days, given that that's shipping in all major browsers.
A working implementation is better than nothing.
SQLite is public domain for Asimov sake!
Everyone can step up and fix it if it has problems, much easier than whatever you propose.
In fact, what you propose is a standard in the spirit of XHTML, with lots of text and good intentions and no practical use.
> WebSQL is an example where Mozilla (and their enabler
> in the HTML 5 standard, Ian Hickson) [...]
This may be naive, but having used various WebKit browsers as well as Firefox, one aspect of the discussion that seems to be missing is end user extensibility. I notice that none the WebKit browsers support the customization that is present in Firefox (or other Gecko browsers, for that matter). This has mattered a lot to me for features like those provided by KeySnail (giving Firefox a very Emacs-like set of keybindings), Firebug, Greasemonkey and Stylish.
I suspect, though I haven't confirmed, that WebKit simply doesn't support certain kinds of extensibility along these lines. Regardless, I think advocating a monoculture where such a situation might arise is myopic. In fact, I doubt Chrome would be what it is today without Firefox...it seems that its extension system is clearly based on Greasemonkey and its development tools were inspired by Firebug.
Why, did anyone told you that the various engines differ in how the go about those in any real way that matters?
It's mostly duplicated code and similar approaches.
And even if it wasn't you can have different approaches in the ONE AND SAME codebase easily. Test alternatives out and see what works better. It's even easier when everybody is using the same engine, because you don't have to also implement EVERYTHING else yourself in order to implement one thing differently.
You are talking about how currently HTML5 is implemented, but there is a long road of optimizations, HTML is a new technology and HTML5 is not yet here (try it on your mobile phone).
What exactly makes a "long road of optimizations" incompatible with having one engine? As a matter of fact I don't expect any competing engine to disrupt of surpass Webkit in overall speed for the next 10 years (except maybe by some inconsequential amount in some neglected area).
And you'll never have the British drinking from litre glasses, I'm afraid. It's pints or nothing.
But you'll find that with most imperial measurements; they're based on physical objects or systems of measuring which make less sense today. One of my favourites being the traditional way of counting sheep in the north of England: http://www.fellpony.f9.co.uk/country/wool/count.htm (and here's a great explanation and song by the late Jake Thackeray: http://youtu.be/TiXINuf5nbI).
By supporting lots of rendering engines to do the exact same thing in various degrees of brokeness we haven't seen any "future potential" and we also lost the short-term convenience.
>Wishing you could wave a magic wand and make everyone use the same tools, language, conventions, or coding style is something every engineer wishes from time to time, but the world would be worse off without diversity.
I'm not sure. I see a lot of examples where diversity has fucked things up:
1) Linux fragmentation for example killed it as a platform for proprietary apps,
2) Gnome/KDE/... fragmentation killed the Linux desktop mass adoption,
3) Tons of C++ compilers make cross platform C++ code more difficult (it's a little better nowadays)
I also see many examples where lack of diversity has made things better:
1) Ruby web frameworks? 99% of the people go with Rails, and it gets all the improvements and stuff (compare with Java/PHP web frameworks).
2) Mobile rendering engine? 99% of companies go with Webkit and free lots of their resources up plus contribute to the betterment of the project.
>But the moment we start treating the Web as a zero-sum game and stop collaborating on the vision of a better online experience, nobody wins.
How about solving the "collaborating" problem by working on the same engine?
And if that happens, then whoever has the biggest influence over the leading browsing engine will dictate the shape of the Web. Last time this was a single corporation; at least this time it might be two. I don't necessarily think this is very much better.
I would agree, but I don't think it would be a good thing to do. Sure, if there were only one rendering engine, all of the web would be rendered in the way. That isn't a good thing though. It would commit the web to being Webkit, warts and all, for a very long time. IE is a good example of this, except it is we who brought it upon ourselves as web developers for using IE specific behavior.
"One of the core evils behind Internet Explorer is that it is a closed platform."
Again, agreed. That said, being closed isn't why we dislike it; its because it has a lot of non standard behavior that people have come to rely on. If the IE source code were to be entirely open sourced tomorrow, how much easier would it be for web developers to work around its idiosyncrasies? I posit that it would still be hard.
"Now Gecko is old, buggy and slow - at least in comparison to WebKit."
Even if this is true, its only true today. It will eventually get better, leaving this argument irrelevant.
This article seems to say that the author disagrees with the "program to interfaces, not implementations" advice. The interface (HTML & CSS) should be how we describe web documents, rather than Webkit's particular implementation of the interface. The author's article seems shortsighted - both forward looking and retrospectively.
Even if it is true today, Mozilla is working on Servo (which will hopefully prove to be a success). There isn't a single reason to not develop competing engines.
Competition will drive all sides to improve their engines. And standardizing on WebKit is like standardizing Linux (it's just a kernel not overall browser). Slow and very hard, if not down-right impossible.
I wish Mozilla all the success in the future but I don't want a monoculture of any engine (Servo/WebKit/Presto/Gecko/<insert engine name> included).
So we can picture OpenWebkit available on github in a week or so then?
Seriously: Apple cannot honestly believe this move is going to benefit anyone, can they?
At the same time I do understand from a developer perspective that a single "runtime" would be the Holy Grail at least as much as a single OS. But that's what standard stand for.
In the actual situation a vendor can implement things directly in their project, trying to push things forward for its benefit, in contrast to the competitors. If we lose this appeal, will we lose the traction the web has?
Except that standards still tend to get implemented differently, which is a massive shame. My life long dream is to develop once, deploy everywhere. We're getting there with libraries such as jQuery and Backbone.js however we're still a long way away from that whilst there are multiple browsers to contend with.
(You shouldn't resort to hash-bang, btw, it's considered a bad pattern)
Don't get me wrong, I love WebKit, I love Chrome, but I also love Gecko AND Presto. They're doing a terrific work that must be rewarded.
What competition with Trident? Trident was already stagnant when Gecko started.
And it's not like Gecko added anything significant.
Is this a widely held view?
From an end user perspective Chrome and Firefox feel pretty much neck and nack. Firefox has better memory usage, Chrome JS engine is a little faster.
I use both (Chrome on Ubuntu and Firefox on Android).
a) on both Windows and Linux, Firefox startup is slower than Chrome
b) at least on Windows, Firefox memory usage is far worse than Chrome's
c) perceptually, Chrome feels a lot faster than Firefox
But yeah. Anecdotal.
Speedwise, they seem pretty much neck-and-neck, although chrome is faster at some of the advanced webgl 3d rendering stuff...
[The competition with chrome has been a great thing, as it seems to have lit a fire under the FF devs, and resulted in many, many, improvements in recent versions.]
Developer tools - Firebug all the way, even the error console is more useful.
On my pretty high-end machine this runs very smoothly on Chrome and quite jerky on Firefox.
Until recently, Chrome 'implemented' the HTML5 date input by giving the user a spinner on the side of the input box which, when pressed, will set the date in the input to '00-00-0000'. Worse, this renders the normal feature detection used by libraries such as modernizr.js useless.
Text rendering is badly broken for Chrome on Windows right now. http://i.stack.imgur.com/MsHdy.png - Firefox, Chrome, IE9. Bug report: http://code.google.com/p/chromium/issues/detail?id=137692
There was a bug that caused inset box shadow used to be rendered outside the element. This is fixed in recent desktop versions, but still haunts older versions of Android's default browser - versions as recent as the one included with 3.x Honeycomb are affected.
Browsers, even modern ones, are incredibly quirky. Moving to a monolithic Webkit market will not help with any of the bugs listed above, nor, I suspect, most of the bugs one might encounter today as a web developer.
I remember the days in which a group of individuals managed to create a browser(Opera) that used 1Megabyte of memory instead of 40 of Netscape and 80 of IE.
As other people said, we need standards, and for standards we need multiple implementations. In my experience creating multi platform code, the best way to multi platform is for the code to work in different platforms from the beginning. I had seen code "designed for multi platform" on a single architecture and over time(gradually slipping) become dependent on a single one, and years later we have people realizing that they can't use the new tech without rewriting the entire codebase, expending millions in the process.
The same will happen with a monopoly browser engine, it will gradually slip.
In the future we could need to recreate the browser internals from scratch using parallel computers, or with new text handling internals, or someone like old Opera would proof that is possible to do the same with much less, super faster and no battery consumption. who knows?
You lost me there. Latest Firefox easily rivals Chrome for both startup and initialization time.
Attempted and failed. And that was 10 years ago. Why are these WebKit guys always so stuck in the past? Microsoft is very clearly all about embracing the web.
More importantly, when will they realise that WebKit-specific CSS styles are bad for the web?
WebKit is the new MSIE. And WebKit-only code needs to be shunned the same way we (eventually) shunned MSIE-only code.
I think Chrome (in what it has allowed Google to do) has been bad for the web.
We have open protocols and specifications. The web uses HTML, CSS, etc. Then it's up to the various rendering engines to adhere to those.
Fuck off dude. A monoculture is ideologically bad in itself but at least you could come up with some tech args. Saying that basically nullifies the entire thing.
I think a critical aspect of open source code is that it can be forked. Wouldn't a Webkit monoculture stand in the way of this?
I am very happy there are other engines like IE and mozilla. It would be very hard to keep html5 and related standards in check without these engines.
1. Trident (IE10+)
2. Gecko (Firefox)
3. WebKit (Safari, Chrome)
(Yeah, Opera needs to just.. stop. So sick of all the Opera oddities, combined with their 0.5% market share.)
Proposing that there be only one seems very dangerous to me. But as an argument for Opera (and other tiny-market-share) browsers dropping their proprietary engine and switching to either Gecko or WebKit, I'm all for it.
IE6/7/8 are still a very much bigger problem, because there are still people that for whatever reason (e.g. corporate IT policy, total lack of knowledge) can't upgrade and can't use anything else.
It's not terribly different from the situation that exists in the C++ compiler world. Different compiler vendors implement different featuresets. It took many years after the release of the 1997 standard for any compiler to implement it 100%. Is there a compiler out there that implements the current standard completely?