A browser engine is an awfully portable thing. For a consumer, switching between them (e.g. from Firefox to Safari, whatever) is just a question of minor UI skinning. I don't see that it "benefits" any OS in particular. Assuming it's universally better, Android and Tizen would need to port from WebKit and Firefox from Gecko. If it confers a true competitive advantage, they'll all do it. If not, some probably won't.

For myself, I'm skeptical. There's really nothing "wrong enough" with Gecko or WebKit that I can see another option really being that much better. Developers love to rewrite stuff (obviously both Gecko and WebKit are already effectively rewrites of pre-existing technologies), but the market has a long history of not being nearly as enthused. But I'm willing to be proven wrong.

>Developers love to rewrite stuff (obviously both Gecko and WebKit are already effectively rewrites of pre-existing technologies), but the market has a long history of not being nearly as enthused.

Actually your examples nullify your argument.

Mozilla would be dead today without Gecko, ie with the old Netscape code piled.

KHTML would have gone nowhere much if it wasn't for the Webkit rewrite.

So in both cases, it was the rewrites that made those engines break out.

And KHTML itself can be (and was, by many) regarded as a pointless rewrite of Gecko, which seems crazy now we're aware of its impact.

Surely the impact of Webkit has been greater than that of Gecko? Webkit made decent mobile browsing possible, and until recently Gecko wasn't available in mobile browsers.

Gecko did put a dent in desktop browser usage share early on (when Safari was Mac-only, and Safari for Windows has never caught on – for good reasons), but the desktop is quickly becoming the second screen. Nowadays, most sites are built for Webkit first.

You seem to have overlooked the whole "Firefox basically saved the world from an IE monoculture" thing that happened in the mid-2000s.

Safari was released in January of 2003. Soon after, Microsoft ceased developing Internet Explorer for Mac. Almost two years later, Firefox 1.0 was released, and it took quite some time after that for it to become a good browser. In the meanwhile, plenty of us had been using a Gecko based browser for years: Netscape.

It depends on your point of view.

I'd make the argument that without Gecko the web would have become even more entangled with and dependent on IE. That would have smothered WebKit in the cradle, making it impossible for anyone outside of Microsoft to make a decent mobile web browser.

As you're talking about Gecko far before it was used to create Firefox, I can see how its influence has been profound.

Until recently, Servo has been labeled as an experiment, and they've claimed that it isn't intended to replace Gecko. I'm skeptical about this claim, but it does suggests that replacing Gecko isn't its primary objective. If nothing else, the insights gained from developing Servo will provide insight into future development of Gecko.

what apps? :D

The whole idea behind firefox OS is the "open web", all "apps" are standards-compliant javascript. App portability shouldn't be much of a problem.

That's not true, both Firefox OS and Tizen use many not-yet-standard APIs. Luckily they are collaborating on many of these APIs and they will be interoperable.

Right, but they are all in the process of being standardized. The idea behind them is that they WILL be written using standardized APIs

That doesn't help with portability though. Tizen apps and Firefox OS apps have to be constructed in such a way (by abstracting away the not-standard APIs) to make them portable. You don't get that for free.

Throughout its history, HTML has always been a disaster when it comes to cross browser interoperability. Apps have always been desinged for the vogue browser, which has changed from Netscape to IE to webkit now.

The more you abstract, the more functionality you lose and the more generic your mobile apps will look. Facebook learned this lesson the hard way when they tried to make their mobile App in HTML5.

CSS, javascript, and DOM are just kudge piled upon kludge. HTML5 trying to shoehorn poorly thought out technologies created for hyperlinked static text documents into dynamic applications.

Until some disruptive technology completely replaces that massive HTML5 spec you speak of, the natives apps will always rule the mobile space and performance critical spaces.

The point is the goal is to make all of these API's standardised. Of course you will always have portability issues if you use the newest possible API's as someone will always be first out with an implementation. By the time FirefoxOS has any traction, it is likely a lot of these API's will have additional implementations and/or suitable "polyfills". That'd already put it in a better position out of the gate than Android or iOS in terms of portability.

I suspect you get portability to Firefox for Android for (nearly) free. That's a decent start at the very least (and an important proof-of-concept for other Android browsers).