WebKit is the jQuery of Browser Engines

WebKit is the jQuery of Browser Engines(ejohn.org)

252 points by jimsteinhart 13 years ago | 204 comments

kenjackson 13 years ago |

The web is not open and becoming increasingly less so.

People love to talk about how the web is about open standards and such, but it really is rather quite closed.

It's driven less by standards and more by de-facto implementations. Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard".

And I think even worse has been the wholesale discounting of plugins. I still strongly believe that being tied to JavaScript as really the only client side language is a mistake. It's not a great IL and limiting the language for such a pervasive platform is scary. I powerful plugin model would be, IMO, one of the best things to a truly powerful web.

I wish the web was more open. I wish that browsers were a truly extensible runtime that specified lower level abstractions, that allowed more innovation at the top of the stack.

It feels like we're walking into the dark age of the internet.

ChuckMcM 13 years ago | |

This comment captures a lot, perhaps not in the way Ken intended, but I feel compelled to respond.

Lets start with the thesis statement, "The web is not open and becoming increasingly less so."

On its face, this statement is not only false, it is painfully so. Sort of like saying the world is not round and becoming increasingly less so. To pretty much anyone they would say "the world is clearly round, and its impossible to change that." Similarly there is absolutely nothing standing between Ken, or anyone else, preventing them from building an entirely different "web" just like Tim Berners-Lee did back at CERN. So the definition of the word 'open' here clearly is needs some additional verbiage.

The next statement helps a bit, "It's driven less by standards and more by de-facto implementations. Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the 'standard'."

This deliciously captures a debate that has raged for 30 years at least. "Which came first, the standard or the code?"

Back when I was young and impressionable, the debate was something called the "ISO 7 layer networking model" and "TCP/IP". You see the international standards organization had decided that the world needed a global networking standard, and so they got their best standards engineers together to come up with what they gloriously christened the "Open Standards Interconnect" or OSI set of protocols. Meanwhile a scrappy bunch of network engineers and hacker types were in this loose knit organization called the Internet Engineering Task Force who were building networks that spanned countries and they wrote code and brought it to the meetings and debated stuff that worked well and stuff that didn't work well, and then everyone went back and wrote more code, Etc.

The forces of evil ignored the IETF and focused on the ISO working groups, since the latter were making standards and the former were just playing around with code.

As it turned out, working code tended to trump standards, and a process of debating changes to the system using working code vs debate using 'it should/it might' as opposed to 'version A does/ version B doesn't' meant that changes got made to standards based on a convincing argument that had never been tried or experienced in practice. The result was that the OSI standards had a lot of stuff in them to avoid issues that weren't issues, and were missing responses to things that actually were issues.

A number of people found the 'code first, standard later' methodology superior for that reason. Assuming that the code was available and unencumbered by patent or licensing restrictions. The latter of course became a much bigger problem when the focus switched to the IETF and the 'big guns' started their usual games.

My first response is then, "open" means anyone can implement and contribute new stuff. And by that definition the web is very open. However, since the community favors a implementation model over a theoretical standards model the 'cost' to influence change is you have to write code, as opposed to making a good argument. And that disenfranchises people without good coding skills.

The second part of this screed is prefaced with this: "And I think even worse has been the wholesale discounting of plugins." Which speaks to the other side effect of "open" as in "we don't make any boundaries we don't have to."

From a mass adoption point of view, the more variability you have in an experience the harder it is to capture the larger audience. This is why cars and motorcycles are all driven in basically the same way, Televisions have 'channels' and 'volume' and browsers have an address bar and bookmarks.

The unification of the structure allows for mass learning and talking in generalizations that remain true without device specific knowledge. Can you imagine how hard it would be to write a driver's code if every vehicle had its own customizable UI and indicators?

So as a technology matures the variability is removed and the common practices are enshrined into the structure.

What that means in a practical sense is that if you're trying to push the envelope in such a mature technology you will face higher and higher resistance. However, you are always allowed to create an entirely new way of doing things.

This isn't the 'dark age' it's the post renaissance start of the industrial revolution. Except instead of widely accessible books we've now got widely accessible information and a de-facto portal for accessing it.

dinkumthinkum 13 years ago | | |

I think this is unfair to the parent. Comparing web standards to the OSI model is really not the same thing, in my view,, at all. Web "standards" are much more specific and prescriptive, as well as detailed than the OSI model.

It's hard to say whether the parent is correct about the dark age but such a thing clearly has been the case in the past with regards to standards. There was a time before in the not-so-distant past that browser vendors, particularly MS, did not care much at all about conforming to any sort of standards and created mess for which things like jQuery were partially created to solve. So I think there is real ground the parent's point. The issue is whether it is really getting worse, still.

One thing I think is different from previous years is that the programming community is less accepting, I think, of totally non-standard, even weird, proprietary implementations.

steveklabnik 13 years ago | | |

You could argue that the IETF has become everything the ISO working groups used to be, and that 'rough consensus and running code' is long gone.

I seem to flip flop back and forth on this, personally. Some days the standards process seems bright and cheery, at other times, I fear Apple/Google/Microsoft are running the show.

Shorel 13 years ago | | |

Sadly a group of backwards people stopped WebDB just because SQLite being fast, fully featured and in public domain was not enough for them.

Me1000 13 years ago | |

Lets step back from the "open" buzzword and look at the empirical facts.

Less than a decade ago you made sure your web sites ran well in Internet Explorer, a closed source browser that was allowed to stagnate. IE took the W3Cs standards as more like "guidelines" and not a specification.

- Today, every major web browser (except IE) uses an open source rendering engine (or the browser itself is open source.

- Every major web framework and library is open source.

- Most of the servers running the web are powered by an open source OS.

- The standards bodies are actually working faster than ever on new version of Ecmascript and HTML.

- IE's marketshare is smaller than ever.

Years ago some guys had a crazy idea to make a browser for KDE. Today it's powering much of the desktop web and almost ALL of the mobile web. Perhaps I just like a good love story, but it seems like this is a pretty great achievement for "open". Now, it seems pretty disingenuous to say "the web is not open" and even more so to say that just because more people are working on the same open source project that it's, "becoming increasingly less [open]."

[edited for formatting]

saurik 13 years ago | | |

... and before IE it was Netscape: people didn't like that either, but you (and most people who talk about browser history) seem to forget or ignore that :(. If you go back and read through the W3C mailing lists people really really hated Netscape (the by-far dominant web browser at the time, for which books on HTML would have sections dedicated to optimizing for and would even go as far as to say being Netscape-only was fine) for seemingly making up HTML as they went along (almost all of the stuff in HTML that is deprecated, including all of the markup that was for style and presentation only, were Netscape-only HTML extensions) and refusing to take up the charge of CSS. Microsoft was even occasionally described as the potential savior that would come in with a second implementation that paid attention to them (and in fact you then find a ton of praise on the list from Microsoft publishing open DTDs from IE).

Despite all of this, Netscape (a company whose business model at the time relied on selling web browsers and getting contracts with ISPs to bundle their software with subscriptions) managed to get Microsoft's hands slapped so hard by the justice department for having the gall to give away a web browser as part of an operating system (something we now all take for granted: no one complains that Apple pushes Safari with OS X, nor do nearly enough people scream loudly about the fact that alternative web browsers on iOS are only possible if you use Apple's rendering engine in a crippled mode, defeating the purpose, despite Apple having near-monopoly status on the mobile web) that Microsoft never quite got back the courage to keep moving forward given the new constraints they were under. Thankfully, in the process, Netscape still died, and from its ashes arose the idea that an open-source web browser would be interesting and viable, leading to the ecosystem we have today.

shmerl 13 years ago | | |

The "almost all of the mobile" part is really bad, and exactly resembles the IE situation on the desktop before. I hope Mozilla will shift the balance there again.

dinkumthinkum 13 years ago | | |

Honestly, in my view "guidelines" is even a strong word for what Microsoft did with the browser and "standards." This is not to hate on MS at all but honestly, even though you could, I suppose, argue IE has gotten much better, I don't really see a reason for it to exist anymore. It's been such a bad boy and has so few redeeming features that I really think the "blue e" on the desktop should be made to be like simply a shortcut to whatever your default browser is, be it Chrome, Firefox, Opera, or whatever (but not IE because it's development, in my view, should stop).

tolmasky 13 years ago | |

Here's another interesting way to think about it: look at the mobile web on iOS. Does it matter that WebKit is open source and forkable? No, since Apple actively prevents "alternative" visions of what the web should be since they just don't allow custom builds of WebKit/JS on there. Any browser you make can only add superficial features, forcing you to use the built in WebKit. You may have a great idea that would instantly make everyone want to use web apps on iOS instead of native apps, but since you 1) can't ship that browser on iOS, and 2) can't convince Apple to commit that change to WebKit proper, you are effectively locked out.

Compare this to a plugin-driven environment vs a standards-driven environment. Say what you like about Flash, but it was able to guerrilla video onto the web without anyone's permission.

saurik 13 years ago | | |

> ...look at the mobile web on iOS. Does it matter that WebKit is open source and forkable?

The version of WebKit used on iOS is actually not open source and forkable; even WebCore, which is LGPL, Apple works around: rather than releasing code changes for iOS-specific features, they release the binary .o files users can link in.

Hell: Chrome for Android isn't even open source. People tend to totally forget that "WebKit is open source" is meaningless in the general case, as the BSD license allows specific forks to be closed, and all of the mobile ones hold stuff back.

pkulak 13 years ago | |

And that's bad why? So the web only works with one rendering engine. One rendering engine that's open source and can be used and modified by anyone for any purpose.

Standards are great for things like protocols (even languages), but an entire web browser is a tad more complicated than TCP or even C++. No two browsers have ever implemented HTML/JS/CSS perfectly and they never will. If that's the case, then what's the point of a "standard" anyway?

bzbarsky 13 years ago | | |

One rendering engine that has some serious limitations, like not being very parallelizable, because of highly entrenched implementation choices.

Which means that if you want hardware capable of rendering the web it can't be low-power highly-parallel hardware; it has to be high-power-consumption fast-serial-operation hardware. Why is that bad? I guess that's a matter of perspective. I think that would be a terrible outcome, personally.

I should point out that I'm not aware of any compiler that has implemented C++ perfectly, and I doubt any ever will given that it's a moving target. So why bother having multiple compilers or a C++ standard at all? For example, why does the WebKit argument not apply to gcc? And note that in compiler-land not being able to compile some codebases is OK as long as you can compile the codebase your user cares about, while the Web equivalent (only rendering some websites but not others) is a lot more problematic, because the typical compiler user compiles fewer different codebases than they visit websites. And also because using different compilers for different codebases is a lot simpler than using different browsers for different websites.

romaniv 13 years ago | | |

This in an incredibly short-sighted comment. The engine is just a client application. There are millions of websites on the other end of the line. Any changes to web standards also affects them. That's why it's incredibly harmful to treat any single implementation as a de-facto standard.

We need (good) web standards, because we need consistent web architecture where features work together and somebody does long-term planning.

Ygg2 13 years ago | | |

A Monoculture by itself has a very bad property.

It's easy to use and misuse on a large scale. What runs same everywhere is great for app and crackers alike.

Its size make it a valid target of all kinds of dubious organization to target. And not just target exploits existing, but introducing new exploits into the source.

rimantas 13 years ago | |

Web being open has nothing to do with the number of rendering engines for browsers. Even having zero of them would not affect the openness of the web in any way. Firewalls would.

  > It's driven less by standards and more by de-facto implementations.

That was always the case. In fact, one of the goals of WHATWG (fathers of HTML5) was to standardise how the code is rendered even if it is invalid.

vor_ 13 years ago | |

> It feels like we're walking into the dark age of the internet.

The persuasiveness of your argument is harmed by this sort of melodrama.

By the way, the "Dark Ages" are named such because of a lack of written historical records from the Early Middle Ages. The negative connotation attached to the phrase by the general public is considered inaccurate by historians.

firefoxman1 13 years ago | |

> Soon we can get rid of the standards committee and just talk to the implementers of webkit to define the "standard".

Your comment in 1995: Soon we can get rid of the standards committee and just talk to the implementers of Netscape to define the "standard".

And in 2001: Soon we can get rid of the standards committee and just talk to the implementers of IE to define the "standard".

And in 2006: Soon we can get rid of the standards committee and just talk to the implementers of Firefox to define the "standard".

...and for more comparison:

Your comment in the late 70's on computers: Soon we can get rid of the hobbyists and just talk to Apple to define "standard".

And in 1996: Soon we can get rid of Apple and just talk to the creators of the PC to define the "standard".

And in 2010: Soon we can get rid of the PC and just talk to the creators of the iPad to define the "standard".

Just sayin'

mgkimsal 13 years ago | |

I've said for years that a pluggable javascript engine should be something that was fundamental to browsers. Extending it further, plugins that allowed for alternate and complementary lower-level technologies (easily embed a python engine, for example) would lead to more competition and innovation.

We just had a discussion (or, I had a rant) about this at a local web meetup last night. 10 years ago it was "IE only". We're moving in to "webkit only" these days, especially if you're targetting mobile users. In some ways it doesn't feel like we've progressed all that much.

etherealG 13 years ago | |

if the code for the de facto implementation is open source, does it matter? i see the code and the standard as the same thing in different languages personally.

kenjackson 13 years ago | | |

Of course it matters. The "standard" becomes driven by the peculiarities of a specific implementation, rather than the best thing for the base of customers that are served by the standard.

I think it's fine to have a reference implementation, but we need a broad set of implementations (with actual users) so that the standard doesn't get blinders on it due to an implementation decision made on a de-facto standard.

tolmasky 13 years ago | | |

They are different things because its unrealistic to fork WebKit and get any significant market share. So even though you might make a worthwhile change to the engine, realistically you need that change to be accepted by WebKit proper for it to matter.

dinkumthinkum 13 years ago | | |

I don't think you can say the code is the standard. An implementation will have many quirks or things not related to the issue we are interesting "standardizing." Where do you draw the line? That would mean no implementation that was not simply 100% the same would conform to the standard.

You could say "Well standards document is irrelevant because no one follows them anyway" but that's another issue.

mtgx 13 years ago | |

I'd be a lot more worried about implementing proprietary codecs like h.264 and HEVC, and DRM schemes on the web than about having one open source rendering engine as the "standard" for web browsers. At least you can fork webkit, and anyone can collaborate on it anyway.

runn1ng 13 years ago | |

Presto was not open source. WebKit is open source.

So, the internet is becoming more open, not less.

jahewson 13 years ago | |

proprietary binary plugins != open web

petercooper 13 years ago |

I don't disagree but I also see it more as WebKit as the "Linux kernel" of browser engines. Safari and Chrome both use WebKit but are very different in what they offer.. so they're like the Ubuntu and RedHat.

Is it a bad thing that AIX and Solaris fell by the wayside in a rush to Linux? I don't think so. So neither should adopting WebKit as a sort of common kernel in browsers, IMHO. But that's all it is.. MHO ;-)

pcwalton 13 years ago | |

"Is it a bad thing that AIX and Solaris fell by the wayside in a rush to Linux? I don't think so."

Note that Solaris innovated with ZFS, which helped spur Linux to implement btrfs. Competition matters, even in OS kernels.

DigitalJack 13 years ago | | |

I'm a little ignorant of the details here, but was ZFS a part of the Sun kernel?

I know the linux kernel is mostly monolithic, is the Solaris/openIndiana kernel the same?

Even if it is, it seems unlikely to me that the core kernel team had much to do with ZFS.

It's really more about competition between file systems, or so it seems to me. Maybe I'm splitting hairs.

bzbarsky 13 years ago | |

The difference is that we've been actively moving to trying to make things people actually care about (like, say, access to basic information or government services) kernel-agnostic, and we view cases when a specific kernel is required to accomplish some basic computing task as a failure. With browser engines, some people think that way but many don't, as this discussion makes clear.

MatthewPhillips 13 years ago | |

But Linux isn't even close to being the only kernel being worked on. Neither absolutely nor from a marketshare perspective.

maratd 13 years ago | | |

But WebKit isn't even close to being the only engine being worked on. Neither absolutely nor from a marketshare perspective.

Hence, the comparison. Firefox and IE both comprise a major chunk of the market.

snprbob86 13 years ago | | |

What's your point? There's also Trident (IE) and Gecko (FF), just like there's NT and BSD.

tombooth 13 years ago | | |

So Firefox would be Mach, Trident Windows and the assorted other smaller browser engines other 'kernels'?

azakai 13 years ago |

I disagree with much of this article.

> as a contributor to WebKit you have the complete ability to drive it in a direction you wish (often for the better)

Not really. Follow the internal WebKit politics and you see a lot of conflicts. For example, Google wanted to push multi-VM support (for Dart) and Apple blocked that.

> WebKit is already a de facto standard

On mobile. Mobile isn't everything.

Also, should we have said "ie6 is already a de factor standard and given up"?

> I think one this is clear already: WebKit has completely and unequivocally won mobile at this point. They are nearly the only rendering engine used on the vast majority of mobile browsers, including the soon-to-switch Opera Mini/Mobile browsers too. There is no reason to worry about a slippery slope, the slope has already been slid down. In order for any other browser to remain relevant in the world of mobile (which, you must admit, is quickly becoming the only world we live in) they must keep feature parity with WebKit.

Again, this is utterly defeatist. Even if it were 99% true, should everyone give up?

> At this point it’s honestly a business/engineering decision for Mozilla and Microsoft (as it always has been).

No, Mozilla is a nonprofit and the decision would also regard whether it is good for the web, or not. I'm surprised to see John Resig not realize that - he used to work at Mozilla.

edit: And regarding the main point: jQuery worked in a space that was not standards-based. There were multiple JS libraries, and they fought for market share. No one tried to develop a standard that there would be multiple implementations for. Comparing jQuery to WebKit is odd.

zobzu 13 years ago | |

"On mobile. Mobile isn't everything." And.. mobile is not nothing. mobile is huge.

azakai 13 years ago | | |

Agreed.

oinksoft 13 years ago |

  In the case of JavaScript libraries virtually everyone has
  standardized upon jQuery at this point.

This guy really lives on his own planet. Maybe most websites that only need to add a small piece of JS functionality are using jQuery, but I seriously doubt that "virtually everyone" writing large JS projects is using jQuery. Google Closure Tools, Sencha/ExtJS, and MooTools remain quite popular, and a host of developers are skipping compatibility layers altogether and only supporting IE9+ and other recent browser versions, particularly those targeting mobile devices.

StavrosK 13 years ago |

I like the arguments: "Don't worry about <x bad thing> happening, because it's already happened!"

jeresig 13 years ago | |

Pretty much! People worry that the transition to a WebKit monoculture would result in some terrible things. On the contrary Chrome has shown that a shared rendering engine does not result in stagnation. Stagnation is a separate concern from a shared core.

ZeroGravitas 13 years ago | | |

On desktop the only browsers that use Webkit are Chrome (about 1/3 of the market), Safari (about 1/10) and now Opera (currently unreleased). So roughly two thirds of the market are on non-webkit engines which I think contradicts your argument as there's still competition there.

However, on mobile (a market which Chrome has only just entered) you could say that webkit is dominant and that we can already see problems there. To be honest though, I think that's misleading. Mobile Safari has been ridiculously dominant compared with other webkits, in mind and marketshare, and it's that monoculture causing the problems we currently see.

Serious new contenders like Chrome and Opera entering the mobile market with webkit renderers will, I think, actually help that situation to some degree by actually competing with Mobile Safari and not being half-hearted also-rans.

bzbarsky 13 years ago | | |

Ah, but it does result in stagnation on many axes. Where's the Google or Apple effort to add significant intra-page parallelism to WebKit? It's too hard in that codebase, so it's not happening. If you require that codebase for a web browser, that means no significant parallelism in web browsers.

(There's some work being done to parallelize the rendering pipeline, and a bit on painting, but parallel CSS layout seems to be completely off the table in existing browser implementations.)

pcwalton 13 years ago |

Increasingly, jQuery is not just an implementation, but is rather an API. That's why we're seeing the rise of alternatives like zepto.js that match the jQuery API de-facto standard but are implemented better (smaller, dropping IE6 compatibility).

Replace "jQuery API" with "Web API" and this actually argues against John's point. Multiple implementations are better for everyone.

jeresig 13 years ago | |

I'm not sure Zepto could be defined as "better" considering that it only implements a small subset of the jQuery API. In the browser world you can't get away with implementing a small subset of a specification, it'll be consider broken and people won't use it.

I'm not arguing against multiple implementations. If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous! Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine. I am arguing that the writing is on the wall for the common parts of a browser. A browser vendor's time will be used much more efficiently by collaborating with each other on the implementation instead of writing a number of separate implementations.

pcwalton 13 years ago | | |

"If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous!"

Rewriting WebKit's DOM implementation to be 20x faster wouldn't be possible without rewriting WebKit. The DOM implementation is one of the most central parts of any rendering engine. We're working on doing that (Servo), but not by building on top of WebKit for precisely this reason.

"Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine."

They did that by replacing JavaScriptCore wholesale, rather than building on top of it. This was only possible because JavaScript is a standard, not defined by JavaScriptCore's implementation. If JSC had had a monopoly and the Web started relying on JSC's quirks, then V8 might never have happened.

goldfeld 13 years ago | | |

In as much as I consider jQuery a kitchen sink approach, anyone who tries to trim it down to the core (and dropping old browsers which need lots of ifs and elses) may well be better in my opinion.

hemancuso 13 years ago |

In the past there was some amount of competitive advantage in owning the rendering/browser engine. You could add unique features, fix things your competitors wouldn't, whatever.

These days performance is heavily driven by the javascript runtime. While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime. It seems unlikely Opera would have been able to close the gap, much less surpass, with WebKit on that front.

At that point, any competitive advantage they hold in features is being offset in a fairly substantial performance penalty. Good move making the switch. Differentiate elsewhere.

snarfy 13 years ago |

"This page best viewed in Internet Explorer".

Remember those days? This is not a good thing. The HTML spec should be the standard, not WebKit's bugs.

ripter 13 years ago | |

The difference is that WebKit is open source with several large companies contributing to it. If it doesn't follow the HTML spec you (or anyone else) can fix the bug.

IE was closed source and Microsoft disbanded the team that developed it (IE6). If it had a bug, there wasn't anything you could do about it. You just made your site work around the bug, possibly breaking it on other browsers.

fideloper 13 years ago |

Not to derail the topic, but did anyone else read that headline as a negative, only to find that it wasn't (necessarily)?

gcp 13 years ago | |

Maybe it depends on what your view of jQuery is:

In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point.

In other words, as far as he cares things other than jQuery don't have a right of existence. Although it's very popular it's probably even more arguable if there aren't better JavaScript frameworks than jQuery, compared to whether there are better rendering engines than WebKit.

I believe it comes pretty close to illustrating what I believe is so wrong about his arguments.

jeresig 13 years ago | | |

Are there better JavaScript libraries than jQuery at certain things? Absolutely -- look to Backbone, Angular, Meteor, etc. etc. Are they better than jQuery at doing DOM manipulation? I think that's an easy argument simply by looking at the numbers: http://trends.builtwith.com/javascript/jQuery

jQuery or WebKit being dominant platforms doesn't requite that innovation stop, it gives innovation the ability to explode: When you don't have to work about nit-picky cross-platform capabilities or standardization then you get to focus on performance and building sweet frameworks like Backbone and Angular.

sigzero 13 years ago | | |

"In other words, as far as he cares things other than jQuery don't have a right of existence."

I don't think he made that point at all. He is merely reflecting on the fact that jQuery has the most market share and by a long way.

Achshar 13 years ago | | |

I actually don't like jQuery at all and I read the headline in negative, so your theory holds true, atleast to me.

k3n 13 years ago | |

No, given that it's from ejohn.org...

papsosouid 13 years ago | |

Yeah, same here. I assumed this was going to be some article about why webkit is bad for the web somehow. Funny how statements like that can have such dramatically different interpretations.

cs702 13 years ago |

WebKit and jQuery -- and Bootstrap -- are becoming the new 'Win32 API.'

watmough 13 years ago |

I look at the who the author and hesitate to disagree, but I've had better experience in some areas with Firefox on Android (notably webgl) than I have had with Chrome / Chrome Beta.

Personally, aside from a few small wrinkles, I prefer the experience of using Firefox over Chrome on Android.

bobsy 13 years ago |

I think it is obvious that WebKit has won and by a margin when it comes to browser engines.

For Opera it is the best move for them. They can now focus the majority of their development time on making the browser great instead of putting a decent chunk of their development time in effectively replicating what WebKit does. I think in the coming year or so Opera will be become a far better browser for it.

As for Mozilla and IE. You would expect Microsoft have more than enough resources to keep working on Trident/Lynx whatever it is called.

For Mozilla is their OS tied to their own engine? I don't know how committed they are to it. For all the releases of Firefox tabs still aren't sandboxed and phpmyadmin often freezes the entire browser when looking at monster tables... perhaps they would benefit from spending more time improving the browser and less time working on rendering.

I wonder what would have happened if Microsoft, Mozilla or Opera had open sourced their browser engine with WebKit. Perhaps we would have seen a split and more competition in this area.

Now it is who has the $$$ to continue to develop their own propriety engine.

gcp 13 years ago | |

I don't know how committed they are to it.

Extremely, especially in this context. The reason why Opera is switching (web compatibility issues if you're not the dominant implementation) is exactly the reason why Mozilla would fight a switch with tooth and nail - and remember that unlike Opera they cannot care for profit when doing so.

Here's an extensive reply from a Firefox developer: http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-...

I wonder what would have happened if Microsoft, Mozilla or Opera had open sourced their browser engine with WebKit.

I have no idea what you mean.

Yaggo 13 years ago |

"I don’t think anyone can successfully argue that Chome/Chromium isn’t a better browser than Safari [...]"

That sounds like Chrome was somehow superior to Safari. Chrome has some nice features that Safari lacks (and vice versa) but from browser engine perspective they are definitely on par.

nicholassmith 13 years ago | |

That stuck out for me as well, I could argue that Chrome isn't a better browser than Safari for me, but functionally they're both using WebKit so they render sites identically in most cases.

untog 13 years ago | | |

Aside from JS performance, I'd argue that Chome's rapid updates make it a better browser. Safari as at best months old.

jeresig 13 years ago | | |

Except when it comes to the JavaScript engine. Safari's JS engine is the slowest out of Chrome/Firefox/Safari: http://arewefastyet.com/

dinkumthinkum 13 years ago |

I wouldn't say mobile is the only world we live; that's a bit of a stretch for me.

shmerl 13 years ago |

Boring. They can switch to Gecko with IPC embedding for a change: https://wiki.mozilla.org/Embedding/IPCLiteAPI

dubcanada 13 years ago |

I find that funny because even if you add up everything WebKit, Gecko+IE+Opera+Others still have a higher browser share. And most of the "large parts" of the world don't even really use WebKit (I'm looking at China, India, Africa, parts of Europe etc) most of which are IE/Gecko/Opera

gcp 13 years ago | |

Mobile.

mehrzad 13 years ago |

https://html5test.com/results/desktop.html

Why does Firefox do so poorly? ;_; Mozilla is such a good organization (but to be fair can only survive with Google).

khuey 13 years ago | |

Because much of what it tests isn't in HTML5. Some of what it tests isn't even standards track (e.g. WebSQL). The tests are also usually pretty superficial and test things like "does this property exist", not "does this feature work".

malandrew 13 years ago |

I know this is OT, but how hard would it be to create a thin layer so that WebKit run on bare metal?

kbrosnan 13 years ago | |

Mozilla is doing this with Gecko. Google is sort of doing this with Chromebooks (AFIK). There is little to no incentive for Apple or Google to do this on their flagship products of iOS and Android since they already have dev ecosystems using objective c and java respectively.

simias 13 years ago | |

Depends on the metal, which is why it's nice to have an OS as an abstraction layer :)

dvhh 13 years ago | |

wasn't that the goal of webOS ?

podperson 13 years ago |

I'd say the big risk with webkit which no-one is addressing is that it's LGPL not GPL. Someone could get a dominant position and use a closed fork of it. (The fact that Apple open-sourced Webkit is to its credit.)

dpark 13 years ago | |

The LGPL doesn't work that way. You can't fork WebKit and keep your changes closed unless you don't distribute your browser to anyone. Now, you could use webkit along with (for example) a closed Javascript runtime, but that really has nothing to do with WebKit itself.

podperson 13 years ago | | |

Right, my mistake, but you can effectively borg it.

dvhh 13 years ago | |

yeah because creating a closed fork of an open source project is really popular.

justindocanto 13 years ago |

Great points. Nice read.