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 _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
