[webkit-gtk] Porting V8 to WebKit

[Xan]

I've taken some time to think about this issue, trying to structure
what I perceive to be the cons and pros of adding support for V8 in
the WebKitGTK+ port. Hopefully this will allow us to move the debate
in some direction.

Speed
---------

The main factor people mention when pushing to add V8 support in
WebKitGTK+ is the good results it gets in a series of JS benchmarks. I
think this is basically undeniable, but I have two comments about it:

* The relative speed of any JS engine is a very contingent topic.
Historically all engines tend to converge toward some common ceiling,
since when a general technique proves to be very successful in one of
them the others more or less try to implement something similar. This
has happened in the past and is still happening today. For instance,
JSC is in the middle of a huge refactoring and it is moving closer to
V8 in some of its basic architecture decisions. A day might come where
most of us think that V8 is unbeatable and the only sane choice is to
switch to it, but I don't think we are there yet by any means.

* Even ignoring that, it is unclear to me how the results in those
benchmarks affect most real world use cases. In the case of our port
my experience is that both gfx and network performance tend to matter
a lot more than JS in the cases where we do poorly, and in general I
ask you to consider one fact: the widely considered to be the best,
most successful and most profitable mobile platform in the planet uses
JSC, not V8. I don't think spending our scarce resources in this
problem when there's much bigger fish to fry is smart.

Maintenance
----------------

This is the most important part, and it's rarely mentioned. Adding
support for a second JS engine to our port adds a series of problems
and significantly increases the maintenance burden. Specifically:

* The JSC API is part of our public API, and it's already used by
applications. This means most people won't be able to stop shipping
it, and if they gain V8-flavored users they'll need to ship both
variants indefinitely. It also means people will have to decide at
compile time which one of them they want to use. My feeling is that
we'll not only add more work for ourselves, but also for the distro
people.

* Adding another moving piece to our puzzle will add more bugs,
obscure interactions, compilation issues and complexity to our port.
Also, none of the major contributors to the WebKit core does anything
like this, so they won't take this scenario into account in their
development.

* One the absolutely minimum things I'd expect to happen for this to
become a reality would be to have a build bot somewhere so that we
don't need to waste hours each time we do a release to make sure the
V8 variant works. My understanding is that you are not sure you can
provide this, so I think this would be an issue.

* The last point is about integration with upstream, which is kind of
a mixed bag. JSC is developed together with the rest of WebKit, while
V8 is not. JSC being upstream has the benefit of allowing us to
interact with its developers easily, since they share our same
community and procedures, and if problems arise we'll generally be
more likely to fix them quickly. On the other hand with V8 we could
just pick a given version and stick to that, which would simplify some
things. I tend to think the benefits of JSC here are more, but it's
one of the more gray areas.

Summary
------------

First of all, I don't want to come across as overly negative. I truly
appreciate your efforts in this and other areas and all you've done to
help the gtk+ port. I just believe adding support for multiple JS
engines adds a lot of complexity and issues that I don't believe are
really balanced by V8 being overwhelmingly superior, at least for now.
I might change my mind eventually, but for now I think that I could be
more easily convinced to just switch to V8 for good (provided that we
think it's just a much better engine) than leave that decision as
optional and up to the distributors. Other than that, for me the main
contention point is the increased maintenance burden and complexity of
the codebase and developer story, so anything you do to alleviate that
will help.

Cheers,

Xan