
WebKit is the jQuery of Browser Engines - jimsteinhart
http://ejohn.org/blog/webkit-is-the-jquery-of-browser-engines/
======
kenjackson
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
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.

~~~
steveklabnik
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.

~~~
ChuckMcM
_"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."_

Yes you could, I was there in the trenches trying to urge them not to go down
that road. I really lost it when we had gotten Sun to release all claim to any
rights to the XDR or RPC code libraries so that IETF could endorse it as an
'independent' standard. There were enough implementations out there, a regular
connectathon which tested interoperability. Paul Leach, who made it his life's
work to prevent any sort of standardization of RPC, successfully rallied
Microsoft to overwhelm the otherwise rational members of the IETF and de-rail
that process. It was so blatant, and so petty. I remember telling Vint Cerf
that I marked that day, and those events, as the death of the IETF as a body
with any integrity. Many working groups soldiered along and did well until
they became 'strategic' to some big player, and then their integrity too was
ripped out of them. Sort of like that movie 'Invasion of the Body Snatchers.'
Very sad.

Over the years I've toyed briefly with starting a new networking working
group.

------
petercooper
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 ;-)

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

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

~~~
MatthewPhillips
There are dozens if not hundreds of kernels in development today. Some
developed as small niche side projects. Some in proprietary embedded products.
Some purely as research experiments. I do not see that type of diversity in
browser engines and I think it is absolutely as important.

~~~
DigitalJack
Diversity for the sake of diversity isn't going to get anywhere. That is
basically gambling that something good will fall out of a different
implementation just because it is different.

Instead, focus on solving problems. If the best way to solve a problem is to
use webkit, then why do otherwise? If the best way is to go back and fork
webkit from 2 years ago, and start your project from there, do that instead.

But don't be different just because you want to be different. Target your
ambition toward something more meaningful.

~~~
zobzu
difference ensure competition and variety of point of views. The problem with
monoculture is that it _enforces_ the lack of difference. So if the guys in
control of the monoculture stop progressing, or progress in a direction that
you do not agree with, you're basically fucked and it takes enormous effort
and time to change it.

It happens so many times and with so many things (not even software related)
that I'm amazed it's not the first thing that comes to mind.

------
azakai
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
"On mobile. Mobile isn't everything." And.. mobile is not nothing. mobile is
huge.

~~~
azakai
Agreed.

------
oinksoft

      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.

~~~
jeresig
I don't think this is particularly controversial opinion to have at this
point: <http://trends.builtwith.com/javascript/jQuery>
<http://trends.builtwith.com/javascript>

~~~
oinksoft
Most websites fall into the former "only need to add a small piece of JS
functionality are using jQuery" category. A whole lot of websites include
jQuery in default frontend templates and don't even use it on the public-
facing website (Drupal, WordPress, other software that has a huge installed
base).

Vague deployment statistics mean very little.

~~~
phpnode
Clearly you have some kind of issue with jQuery but just because you don't
like it doesn't make it any less popular, useful or prevalent. Here's a fun
drinking game - open up the top 1000 websites and do a shot for each one that
uses jQuery. You will be in hospital by about #20 I think.

~~~
oinksoft
None of the top five websites use jQuery.

Of the top 20, I've got one fifth of them using jQuery: Amazon, eBay,
Wikipedia, and MSN. Not in the hospital yet.

~~~
ripter
I just checked Amazon, eBay, and MSN they use jQuery.

The only one you listed that doesn't seem to is Wikipedia. You really should
actually _try_ the websites before you list them.

~~~
oinksoft
You ought to read comments before replying to them. I clearly said that only
those four are using jQuery, and that the remaining sixteen do not. I checked
all of them by hand before stating this, except for Wikipedia because it is
common knowledge that MediaWiki uses jQuery.

Also, your idea below about sniffing for $ is a bit embarrassing. Firefox,
Chrome, etc. have come with $ for many years as an ID or query selector, and
it has nothing to do with jQuery. Prototype and MooTools also provide $, and
probably a dozen or more similar libraries you haven't heard of.

~~~
ripter
you ought to read comments before replying to them.

I clearly said you can _not_ just check for `$`.

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

~~~
jeresig
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
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.

~~~
Turing_Machine
According to Statcounter.com's current numbers, Chrome is 36.9%, Safari is
8.57%, and Opera is 1.2% = 46.67%, leaving 53.3% for everything else. That's
not "roughly two thirds".

Also, Safari and Chrome are both trending upwards, everything else is trending
downwards.

<http://gs.statcounter.com/#browser-ww-monthly-200807-201302>

~~~
eterm
When it comes to mobile, "everything else" is the android default which is
also webkit.

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

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

~~~
RaphiePS
Correct me if I'm wrong (and I very well may be), but isn't the JS runtime
separate from the rendering engine?

I was under the impression that Chrome uses WebKit for rendering and V8 for
JS.

So, even if Opera switches over to WebKit, that shouldn't affect JS.

~~~
AdamTReineke
You're right. The point he is making is that there is no need to maintain a
rendering engine if it is no longer a point of differentiation when you can
focus your efforts on improving the features that make your browser stand out.

~~~
RaphiePS
Ahh, looks like I misunderstood, thanks.

But will developers/users really flock to Opera just because it has a fast
JIT? For me, Opera is just something to check for compliance.

~~~
acdha
> But will developers/users really flock to Opera just because it has a fast
> JIT? For me, Opera is just something to check for compliance.

I think it's the reverse: users will like Opera if it has UI features they
like. It's highly unlikely that Opera would be able to beat Chrome / Safari on
speed but there's plenty of room for innovation in other areas now that the
web is becoming fast enough for most users.

Not having to support a modern browser engine just be able to start those
features is the major win for Opera because they can focus on things users
actually care about rather than obscure feature compatibility or baseline
competitive performance.

------
snarfy
"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
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
Not to derail the topic, but did anyone else read that headline as a negative,
only to find that it wasn't (necessarily)?

~~~
gcp
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
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.

~~~
oinksoft

      I think that's an easy argument simply by looking at the
      numbers
    

Popular does not imply "better."

~~~
breck
Popularity is highly correlated with quality.

Given that A is 10-100x more popular than B, what are the odds that B is
"better" than A? Slim.

Now, popularity does not imply that something is the best. Often times there
is something better that isn't as popular. But generally the popular thing is
better than most alternatives.

~~~
dvhh
Popularity is no correlated with quality, more with "good enough for the
price".

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

~~~
mmatants
The cool part about jQuery is that I _don't have to use it_. Same with
Bootstrap. So it's not a needless tyranny.

With browser engines things get a little more political - mono-culture is not
a good thing. But at least Firefox holds enough of a market share, and of
course IE is now a much better player in this space - so WebKit can't get away
with too much silliness.

~~~
dasil003
Theoretically yes, mono-culture is not a good thing. Having more from-scratch
rendering engines would be good for the robustness of web standards. However
web standards are hugely complex at this point and it becomes increasingly
infeasible to implement from scratch. With WebKit at least you have an open-
source pluggable engine, so you're not talking about branded product
monopolies where one or two bad actors can foul things up for everyone. An
IE6-like scenario is completely impossible with WebKit.

~~~
stormbrew
This has always struck me as a really poor argument. For one thing, because
webkit itself is by far the youngest rendering engine around and also among
the most complete. You can't reasonably argue both for a webkit monoculture
_and_ an unreasonably high barrier to entry.

Gecko was an open source ostensibly pluggable engine (even MSIE is pluggable,
in fact), so why did we need webkit to bring about the monoculture? Would
advocates of it have been satisfied if it had come about then? Probably not,
and rightly so, because Gecko has stagnated, as most large codebases managed
by people with specific interests do.

And we are talking about branded product monopolies here. Should Google and/or
Apple fall behind who's going to take up the cause of moving things forward
again? People don't use webkit, they use Chrome and Safari.

~~~
dasil003
What do you think exactly is my argument? I'm just talking about the way
things are, not some ideal that I'm holding up. Also, your commentary has
major holes in it:

> _webkit itself is by far the youngest rendering engine around and also among
> the most complete_

WebKit was formally released by Apple almost 8 years ago after being in
development secretly for at least a couple years before that. That encompasses
the entire era of the modern mobile web. It was based on KHTML which I believe
was released in the late 90s, in an era when CSS was barely off the ground and
not used in any meaningful capacity by web designers of the time. That's the
same era when Gecko was first developed and released as a clean break from the
previous Netscape rendering engine which was deemed a dead-end from an
engineering standpoint. So no, WebKit is not new.

> _Gecko was an open source ostensibly pluggable engine (even MSIE is
> pluggable, in fact), so why did we need webkit to bring about the
> monoculture?_

I don't know, but neither Gecko nor IE was ever meaningfully used as a
pluggable engine in a major consumer product outside of the original
organization's control. I don't know if there were technical reasons why they
were never embraced on a wider basis, but they weren't, therefore they are not
very informative on the question of what happens with an open-source rendering
engine monoculture when multiple large parties and user bases are relying on
it.

> *Should Google and/or Apple fall behind who's going to take up the cause of
> moving things forward again? People don't use webkit, they use Chrome and
> Safari.

This sentence is hard to argue because it's a non-sequitur. First of all,
anyone can take up the torch any time. The only time this hasn't happened in
the history of the web was when Microsoft has a monopoly and their core
interests were being eroded by the web. Unlike IE, WebKit is LGPL, so anyone
is free to start innovating from the current state of the art. As to the
second point that people use Chrome and Safari, that's not entirely true. On
Android for instance the default browser is not Chrome. Also, WebKit is being
embedded in all kinds of devices. But beyond that, does the fact that people
use Chrome and Safari give Google/Apple to the power to hold innovation
hostage? First, they are competitors, but even if they colluded, it would be
very hard for them to hold off the whole market if everyone else's web
browsers were getting better and better. This is not the Windows-monopoly-
plus-unsavvy-consumer market of the early 2000s. Everyone is used to computers
now and in the web era they won't be corralled into an inferior platform by
sheer business inertia.

~~~
stormbrew
I did not say it was brand new, but it is the youngest and that's inarguable.
It's pre-webkit state also was not exactly much to write home about, and I say
that having been a user of Konqueror back in the day.

Google seems to be replacing the AOSP browser in Android with Chrome, btw.

I think you underestimate the non-technical cost of entry of a new browser by
a lot while overestimating the technical. I'm not saying that it's a small
feat to make a compliant browser by any means, but if a non-Google company
were to attempt to market a new browser the way Google did (including ads of
equivalent value to links on Google's front page), it would be absurdly
expensive. There's a reason all the dominant and growing players in this space
are massive corporations: a plucky underdog stands little chance against
Google, Apple, or Microsoft. So who else's browsers would they have to hold
off exactly?

~~~
dasil003
No, it's only 15 years old out of 20 years of the history of the web. Sheesh.

------
watmough
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
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
_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-...](http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-its-
Gecko-layout-engine-to-adopt-WebKit)

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

~~~
mtgx
He means that there are different parts of a browser you can focus on and
innovate there. If the rendering engine was 'out of the way", and didn't have
to worry about that part, they could focus a lot more on other stuff.

Right now Microsoft has to focus on making Trident catch-up with webkit, and
it's _still_ 2 years behind webkit in HTML5 features. Go to html5test.com and
see how far IE10 is. It's more behind than Chrome 10 was when IE9 launched 2
years ago.

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

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

~~~
nicholassmith
I'd still argue that Chrome isn't a better browser _for me_ , irregardless of
JS processing speed.

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

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

------
dubcanada
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
Mobile.

------
mehrzad
<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
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
I know this is OT, but how hard would it be to create a thin layer so that
WebKit run on bare metal?

~~~
kbrosnan
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.

------
podperson
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
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
Right, my mistake, but you can effectively borg it.

------
justindocanto
Great points. Nice read.

