[webkit-dev] Sharing code between WebCore/bindings/js and WebCore/bindings/v8

[Adam Barth]

On Thu, May 28, 2009 at 3:07 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> 1) We weren't super enthusiastic about the master WebKit tree trying to
> support two different JavaScript engines. But we finally agreed when the
> Chrome folks said this was a hard requirement to merge, and promised they
> would take on absolutely 100% of the maintenance burden and impose no cost
> on the rest of the WebKit project. As a result:

Oh, I didn't realize this was a sensitive issue.

>    1.a) We're not super keen on refactorings that wouldn't be justified just
> for JSC itself. If there is shareable code that is easily factored out
> without adding otherwise needless abstraction or layers of indirection,
> that's fine, but we don't want to add indirection that would add any code
> complexity or runtime cost.

Sounds like we should look for easy wins that don't impose a cost on
the JSC bindings.  I'll investigate and propose a list of candidates.

>    1.b) We couldn't commit to not breaking the v8 bindings when hacking on
> the shared layer, if there was one.

Yeah, my approach has been to test my patches in my Chromium tree as
well, but that's certainly not feasible for folks who don't have a
Chromium tree lying around.

> 2) My understanding is that the v8 bindings are not even fully merged into
> the WebKit tree yet - many pieces live externally in the Chromium
> repository. So we couldn't meaningfully maintain the v8 bindings even if we
> wanted to, and would have no good way to evaluate the soundness of the
> shared layer.

I'll follow up with dglazkov about seeing what the challenges are here.

> Again, I am sure maintaining a second set of JS bindings is annoying, but
> the Chrome team felt it was worth the cost to have a separate JS engine, and
> committed to taking on the burden.

My concern is mostly that having identical behavior between the JSC
and V8 bindings makes WebKit a more consistent platform for web
developers, and the more consistent the platform, the better the
economies of scale are for developers to make sure their site works
properly in WebKit browsers.

Thanks,
Adam