I Support the WebKit Monoculture | Hacker News Reader

I Support the WebKit Monoculture

jeremyckahn.github.com

72 pointsglenjamin95 comments

I work for Mozilla, but I speak for me.

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.

I'd prefer multiple vendor collaboration on a 1 spec > reference impl, than 1 spec > multiple incompatible impls. Innovation and experimentation could happen in "feature branches" of a master repo, and accepted once a majority of vendors are satisfied.

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.

I can understand where your argument comes from but in my experience with the web developing for webkit+gecko+(whatever powers opera) is pretty painless. It's only adding IE in the mix where things get hairy. I generally just build solely in chrome, and things end up fine when i test in firefox/opera. In the rare case where something is different, the dev tools help narrow down the issue quickly. Contrast this with IE which often breaks and has horrible tools. If we could get rid of IE, I really would not mind having to support the remaining browsers.

Agreed. My current project is focused on mobile, so I do the development using Chrome and Safari.

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.

The irony being that 10 years ago you'd be saying the exact opposite. Most shops supported IE only.

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.

Yes, it is a PITA. But if we didn't, we'd end up with a massive amount of code that was relying not on spec, but on quirks of implementation of that single implementation. This is the real benefit of multiple independent implementations. One implementation does not just lock in users, but it also locks that implementation into a far more rigid situation, where far smaller changer can break massive amount of code.

Exactly. I understand where the article is coming from, but I couldn't disagree more. Competition is both inevitable and a force for innovation.

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.

[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.

WebSQL[0] 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.

Some history:

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[1] itself be used in the WebSQL standard, along with a WebSQL API for querying the actual SQLite version (e.g. "SQLite 3.7.15.2"), 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.

[0] http://www.w3.org/TR/webdatabase/

[1] http://sqlite.org/

WebSQL as implemented was a terrible idea. Simply exposing SQLite's dialect of SQL to the web was always a non-starter in terms of web standards. You will quickly find (as you always do on the web) that pages would depend on bugs and other quirks in a particular version of SQLite, so trying to update the version you ship would be painful. You could ship multiple versions, or some sort of IE-like compatibility hell, or you could expose the version number and force web developers to test for ever possible version of SQLite so they can handle quirks themselves (protip: they won't).

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.

Your opinion is no more than empty rhetoric.

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) [...]

Ian Hickson has been an employee of Google, not Mozilla, for as long as I can remember. What are you trying to imply here?

At least Gecko is open source, but he's got a point about IE being closed source. I mean it's still good in the sense that it provides "competition", but for the Internet it's still very bad that it's closed source. The more open source stuff the Internet relies on, the better it will be, and the faster the progress. Closed source and patent encumbered technologies are just slowing it down.

I agree with this, but have a (maybe related) comment/question.

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.

Completely agree. First it is bad for the field in general to have only one approach. Currently rendering HTML5 and its transformations is a complex subject, without competition we don't know if there are better ways to accomplish this task.

>urrently rendering HTML5 and its transformations is a complex subject, without competition we don't know if there are better ways to accomplish this task.

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.

I think completely different. I want more approaches on web rendering like I want more operating systems, even if they are attacking niche applications or playing "fantasy" games. I don't care.

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).

Do you remember anyone talking about hard javascript engine optimization until Google Chrome "attacked" with their implementation and anybody tried to catch up.

>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

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).

>Do you remember anyone talking about hard javascript engine optimization until Google Chrome "attacked" with their implementation and anybody tried to catch up.

Yes. In fact SquirrelFish was the first new gen Javascript engine, started long before Google Chrome came out. Plus "two weeks after Chrome's launch, the WebKit team announced a new JavaScript engine, SquirrelFish Extreme, citing a 36% speed improvement over Chrome's V8 engine."

Metric system

The metric system is equivalent to web standards, which (almost) everyone agrees is good. His argument is like saying "we should only have one set of weighing scales or one type of tape-measure to measure metric things".

Web standards are like the metric system. Rendering engines are like measuring tools.

Other measurement systems definitely have their uses though. Many older measurements still exist due to them being easier to estimate with; e.g. an acre being the amount of land you could plow in a day.

And you'll never have the British drinking from litre glasses, I'm afraid. It's pints or nothing.

"an acre being the amount of land you could plow in a day" isn't that an extremely subjective way to measure something? And to almost everyone even modern farmer is that actually a good basis considering a modern farmer can most likely plow much more than an acre in a day with machinery?

Oh absolutely, if they updated it to be based on modern farming then everyone would have significantly less acreage :D

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).

Sure, not from litre ones, there's too much binge drinking already :) But the half-a-litre glasses, common in metric countries, are a very close replacement to pints in terms of volume.

But not quite! ;) Somehow that extra 68.3ml makes all the difference.

Laws of Physics.

>Supporting a monoculture is trading future potential in the name of short-term convenience.

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?

If one implementation becomes the de facto standard, it only means that the standard is written nowhere. Quirks, peculiarities or even bugs become reference points that web developers need to build upon. The pace of innovation may be greater this way (as it is evident now in Chrome especially) but the long term risk is making the whole notion of independent standard irrelevant.

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.

"standardizing on a single rendering engine would go a long way towards unifying the web."

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.

> "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.

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).

WebKit recently became slightly less open

https://lists.webkit.org/pipermail/webkit-dev/2013-January/0...

Ouch. Reading that, they're not just making development less open - developers are now allowed to merge code that breaks the build on non-Apple platforms. Worse, in order to merge any changes to non-Apple platform support code, developers have to have their changes approved by "owners" within Apple who have no incentive to review code promptly and no knowledge of the platform in question.

> developers are now allowed to merge code that breaks the build on non-Apple platforms

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?

It's benefitting them :-)

I think it's a good statement. But I also recognize a dangerous dystopian world with only one render implementation. The competition between Trident/Gecko/Webkit/Presto pushed the web forward, not a single one of them — the whole process has done it.

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?

> But that's what standard stand for.

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.

Without any aggressive intent, how could Backbone improve your cross-environment problems? It's just an MVC pattern implementation, it doesn't abstract you from nothing.

Backbone.Router working on non-pushState browsers is one example.

_touché_

(You shouldn't resort to hash-bang, btw, it's considered a bad pattern)

Oh, I know. The main reason I'm aware of it is from having to work around and disable it!

Absolutely, exactly.

Thats why folks at whatwg.org spent so much time trying to define how html should be parsed. Alas, that still does not fix the problem with different vendors implementing different parts of the same specification.

Every vendor has its own needs and priorities. Would we be happy with a single implementation with incomplete support for a spec feature and no other implementation on the table? It's a possible scenario, in a WebKit only world.

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.

>I think it's a good statement. But I also recognize a dangerous dystopian world with only one render implementation. The competition between Trident/Gecko/Webkit/Presto pushed the web forward, not a single one of them — the whole process has done it.

What competition with Trident? Trident was already stagnant when Gecko started.

And it's not like Gecko added anything significant.

All of them mostly copied Webkit's innovations (canvas, css transformations, a strong push to pass the ACID3 test, JITed javascript engine, etc).

Even if WebKit "wins", there'll still be multiple WebKits http://www.quirksmode.org/blog/archives/2009/10/there_is_no_...

This is an important point. It seems one can never quite escape fragmentation due solely to time moving on, let alone the complexities introduced when targeting multiple pieces of hardware. Reading this article I kept thinking "OpenGL and DirectX". One could argue each has its own monoculture with respect to Windows (or X-Box) and non-Windows OSes, but each monoculture is still fragmented. Windows devs still target DirectX9--initially released over 10 years ago, and the latest DirectX11.1 update will only work with Windows 8. OpenGL is just as bad with the 3.0 flop, issues with the move away from fixed function pipeline concepts, its ES version, and WebGL...

> Gecko is old, buggy and slow - at least in comparison to WebKit

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).

As an end user, based on anecdotal evidence, I can say that:

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.

Hmm, for me, chrome is a much bigger memory hog than FF. Its memory usage is somewhat more controllable because of the process-tab thing (which is probably also responsible for its greater memory usage), but while actually in use, it uses a lot more memory for a given set of tabs open.

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.]

As an end user, i can say that : a) Chrome memory usage is far less than Firefox. try 50+ tab and you'll see. b) Chrome is faster than firefox but it's buggy when you have many tabs c) Mozilla never try to take my personnal data

Actually this is false. Firefox is loads better when it comes to memory. Chrome is slightly faster but not when Firefox has Noscript installed.

Depends on the number of tabs one tends to have open. On Ubuntu your (a) and (b) are far worse for me in Chrome than in Firefox (in fact that much worse that I only use Chrome on my 8GB RAM laptop but not on a 4GB one). I agree with (c).

Have you tried a recent version of firefox? Nicholas Nethercoat and friends have done quite a bit in the last year to reduce memory usage in firefox.

Odd, these days Firefox always uses much less memory than Chrome for me.

Working as a front-end developer I happen to come across tiny bugs and inconsistencies in Chrome more often than in Firefox, rare as that happens.

Developer tools - Firebug all the way, even the error console is more useful.

You're assuming the way Firefox renders if the "correct" implementation. This is like old IE developers complaining about their site "breaking" on Firefox.

Try running some of the Chrome experiments, e.g. 100,000 stars: http://www.chromeexperiments.com/detail/100000-stars

On my pretty high-end machine this runs very smoothly on Chrome and quite jerky on Firefox.

Yes, Firefox is the new IE, literally. In the past years generally everything just works, i develop in Safari and then test in IE, Opera and Chrome. Usually no big quirks. And then comes Firefox, usually something is badly broken. Let's say i have added extra tags into DOM just for FF only, I have FF specific CSS hacks.

The first thing you learn as a web developer with respect to (modern - ignoring IE 7 and even 8) cross browser compatibility is that all browsers have their quirks and all of them suck. Off the top of my head:

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.

The first thing? Well, I have been web developer since 1999. I wrote drag&drop cross-browser JS in 2003. Under my belt is front-end of one Seedcamp winner, webapp that was presumed as native on iOS. What exactly do you wan't to teach me?

Competition is great.

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?

> Gecko is slow

You lost me there. Latest Firefox easily rivals Chrome for both startup and initialization time.

I use an AMD 1.6 GHZ powered netbook with 2GB RAM running Arch Linux. Chromium is unbearably slow after opening a few tabs. Firefox chugs along just fine.

I have never seen that on many systems, perhaps Arch has been configured in a strange way.

I have always noted that behavior, Chrome has a better memory management with a few tabs opened, but if you start opening a bunch of them, then Firefox clearly wins the memory battle.

That's probably because it shares memory between tab processes, since each tab is not in its own sandbox like in Chrome. Personally, I prefer the security of tab sandboxes.

Yeah, the latest Firefoxes are plenty fast, in both JS and DOM. And for that matter, so is IE10, though they iterate much slower and tend to fall behind over time on that basis.

"IE attempted to follow in Microsoft’s Embrace, extend, and extinguish strategy, and that is bad for the web."

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?

Yeah. It's interesting to see people who embrace WebKit-only code right now openly criticize MSIE for the damage it did to the web 10 years ago.

WebKit is the new MSIE. And WebKit-only code needs to be shunned the same way we (eventually) shunned MSIE-only code.

In my opinion, they're already trapped in a monoculture. The fact is that Github is not the only place where you can host code, nor is a macbook the only machine you can type on. Webkit is just late to the party.

The fact that Google has been pushing Chrome only features onto the open web for a long time now, coupled with everyone not running Chrome currently getting ads for it pushed into their face all the time, on all Google-owned services, tells me all I need to know about Google's real stance on web-standards.

I think Chrome (in what it has allowed Google to do) has been bad for the web.

I couldn't agree more.

This is a silly argument. You cannot force others to use one product. WebKit is great, but it is still a project, governed by some people, and with certain goals. People want to create browsers who may have other goals, so either they have to convince the WebKit team to follow them, or fork, which ends up causing the same problem of multiple platforms.

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.

the usual ridiculous trope that "if only we had a single $PROJECT all the people working on the current competitors would work on $PROJECT instead and everything would be great" is enough to discount this whole lot of drivel.

Don't get me started on WebKit fragmentation. Between browsers, webviews, and platforms, it seems like everybody's using a different version of WebKit on mobile.

http://www.quirksmode.org/webkit.html

"Now Gecko is old, buggy and slow"

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.

Following that logic, KHTML should have been killed back in the day.

> WebKit is open source

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?

The OP's argument seemed sort of sensible to me until I read this. Ideas need to compete. If it's not Gecko vs Webkit, it'll be Webkit vs other branch of Webkit. Monoculture will only last until "Why don't you accept my pull request, when this is obviously a better way of doing it? Because it's not better. Go fork yourself."

While we are wishing for things: I wish there was a fully-featured modern rendering engine written in something other than C++.

Mozilla has a prototype browser written in Rust called Servo which might be worth keeping an eye on: https://github.com/mozilla/servo

Haha, is it really your opinion to support browser with most rendering bugs in these days? They are rushing to implement new things but they are not willing to repair old bugs even not to fight with regression. I can say that only good part is V8 engine, others are shit.

Nothing but FUD (regarding Gecko). Would prefer to read something more objective.

Isn't the biggest problem that it gives one engine too much power over the web? Like IE in the first browser wars, it could start ignoring the web standards and implementing its own features, which are badly thought out and harmful for the web. For example, with a WebKit monopoly, suppose the WebKit authors introduce `window.badlyThoughtOutFeature()`. It's instantly a de-facto standard, and all future browser makers are obliged to support it for backwards compatibility. With multiple engines, nobody has too much power and can get away with things like that.

Sorry, but there is this illusion of WebKit being a totally opensource project. This is not true. It is mostly controlled by Apple. Any big decisions need to be "approved" by them. See the recent contribution changes they made about WebKit2 with no consideration for other developers. See how they oppose to any "cleanups" and "refactoring" that doesn't come from them.

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.

I support the monoculture. We wouldn't need vendor prefixes if everyone just ran WebKit to render HTML and CSS. It's free and open source. MS can take the engine now and call it IE 12. New HTML and CSS features would be supported more quickly when everyone is working on the same rendering engine.

I'm from China. I support the Communist Party monoculture.

In a world of Pepsi and Coke, how can three rendering engines be too many?

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.

Give Opera time, eventually they will move to WebKit for everything! http://www.favbrowser.com/opera-drops-presto-in-favor-of-web...

I'm intensely relaxed about Opera support. I suspect that the 0.5% people using Opera know what they're doing, and can deal with the odd incompatibility by firing up something else. Opera compatibility is a nice-to-have, but that's 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.

Because you aren't wasting resources (developer time) when picking between pepsi and Coke.

But you are wasting resources when you use features that are not properly standardized.

Not all features that are standardized are implemented properly on all browsers. This is what uses developer time.

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?

This is more like supporting standard than supporting monoculture. monoculture is bad; standard isn't

Will Google open source it's core search engine? That will be good for an open web too :)

Reply on news.ycombinator.com