[webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

Tue Dec 6 06:06:13 PST 2011

On Tue, Dec 6, 2011 at 8:17 AM, Anton Muhin <antonm at chromium.org> wrote:

> Thanks a lot, Jarred.
>
> We're fine w/ hosting in other repo (but we'll be happier to live
> close to the WebKit).  What would you suggest as a measure of success
> for this extra-repo branch?
>

I think that's a fair question.  Based on current dialogue, there are some
points to be proven such as no performance degradation or large increase of
memory consumption to run the status quo, hackability, etc.

Posting the patches was a good first step to viewing the changes, but the
separate repo would allow those interested to follow along without the
worries (on both sides) of how the separate branch affects WebKit proper.
 From the performance/memory standpoint, one good measure of success is
empirical evidence that neither are compromised when running the current
VMs.  Even if no additional VMs are supported in WebKit proper, I
understand the benefits to having the interface available for other
consumers of the engine in closed/embedded scenarios, regardless of the
controversial issues of what's best for the open web (it reminds me of the
controversies around supported video codecs for the <video> element and
what a nightmare that is for the open web).

I'm fairly new to the WebKit community myself, so I'm just suggesting what
I would do that would be frictionless :)

>
> yours,
> anton.
>
> On Tue, Dec 6, 2011 at 2:10 PM, Jarred Nicholls <jarred at webkit.org> wrote:
> > On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin <antonm at chromium.org> wrote:
> >>
> >> Good day, everyone!
> >>
> >> I am sorry if it didn't sound clear enough in our original message,
> >> but we're not proposing a new language support, but we're proposing a
> >> patch which allows others runtimes to run along with JS in the
> >> browser.
> >>
> >> Of course, we're doing this because of our work on Dart, but our
> >> intent was to solicit a feedback from the WebKit community if there is
> >> any interest in supporting runtimes additional to JS (and not JS +
> >> Dart) in the first place.
> >>
> >> And we're not only talking about the browsers proper, our hope was,
> >> for example, that people embedding WebKit into apps may benefit from
> >> hopefully tight integration or, another idea, if we can provide better
> >> isolation for JS proper using similar approach.
> >>
> >> And sure, this patch--- https://bugs.webkit.org/show_bug.cgi?id=73897
> >> ---is only a tiny step in this direction---Fillip is absolutely right
> >> that integrating several GCing VMs is tricky---we're pretty much aware
> >> of this and hope we can address this, but, again, the patch is only
> >> initial infrastructure to enable more than a single runtime.
> >>
> >> If consensus in the community is nobody needs more than JS runtime in
> >> the browser (for any reason), so it be---we looked for feedback from
> >> the community and we got it.  If the community response is idea is
> >> good, but you need to account for..., great, we're happy to do that.
> >> Maybe it'll make this patch feel less experimental and Geoff would be
> >> less reluctant to see it on the branch.
> >
> >
> > It would be easier to just host the branch in a mirror somewhere else,
> > continue experiments there, and report back to the community.  Many
> others
> > do this, e.g., Samsung and WebCL.
> >
> >>
> >>
> >> And I can definitely understand concerns which are raised by Dart in
> >> the browser, but I really hope it's a separate issue.
> >>
> >> Thank you very much all for your feedback!
> >>
> >> yours,
> >> anton.
> >>
> >> On Tue, Dec 6, 2011 at 8:24 AM, Oliver Hunt <oliver at apple.com> wrote:
> >> > No.  People are using EcmaScript on the web.
> >> >
> >> > They have languages that compile to EcmaScript as an intermediate
> >> > language.  Dart could also do this (emscripten demonstrates that raw
> C can
> >> > be compiled to EcmaScript), so if people wished they could do that.
>  These
> >> > are also not a significant proportion of websites at all.  If we were
> to
> >> > decide to support one of these natively it would make sense to
> support the
> >> > most popular and widely used languages, but currently none of the
> languages
> >> > that compile to ES have made any significant headway -- mostly
> because ES is
> >> > actually a pretty good language (yes it has rough edges, but the same
> is
> >> > true of _all_ languages).
> >> >
> >> > Adding direct and exposed support for a non-standard language is
> hostile
> >> > to the open-web by skipping any form "consensus" driven language
> development
> >> > that might happen (say the path taken by json2.js -> the native JSON
> >> > object), and foisting whatever language we want on the web instead.
> >> > This implicitly puts any browser that supports additional proprietary
> >> > extensions in the same position as a browser supporting something like
> >> > vbscript, and has the same effect: breaking the open web by making
> content
> >> > that only works effectively in a single product.
> >> >
> >> > For example back in the 90s Netscape had a feature called "layers" any
> >> > browser could display the pages, but they would only look "good" in
> >> > netscape.  If we were to natively support some other language on the
> web say
> >> > OliversAwesomeWebLanguage, and provided a tool to compile OAWL to ES
> any
> >> > site that used OAWL would perform significantly worse on other
> browsers than
> >> > on our own (this is a given as the only argument in favour of native
> support
> >> > vs. compilation to JS is that native support is meant faster than
> going
> >> > through JS).
> >> >
> >> > If OAWL did become a big enough platform then other vendors _might_
> end
> >> > up reversing engineering it and reimplementing it themselves, put us
> back in
> >> > the position of the 90s browsers and the many variants of what is now
> called
> >> > EcmaScript.
> >> >
> >> > On Dec 5, 2011, at 10:43 PM, Vijay Menon wrote:
> >> >
> >> >> On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt <oliver at apple.com>
> wrote:
> >> >>>
> >> >>> The issue here isn't "can we make multiple vms live in webkit" it's
> >> >>> "can we
> >> >>> expose multiple languages to the web", to the former i say obviously
> >> >>> as we
> >> >>> already do, to the latter I say that we don't want to.
> >> >>
> >> >> People are already using multiple languages on the web.  E.g.,
> >> >>
> >> >>
> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
> .
> >> >> Native runtime support is a natural next step.
> >> >>
> >> >> WebKit does support multiple VMs, but it does not support them
> >> >> concurrently at runtime.  That is essentially what we want to enable.
> >> >
> >> > WebKit does support multiple bindings concurrently at runtime -- a lot
> >> > of mac clients make use of the obj-c dom bindings while JS is
> executing,
> >> > some also make use of the JS<->ObjC bridge so that you have two
> different
> >> > sets of bindings for the same objects at the same time, being used
> together
> >> > in beautiful harmony ;)
> >> >
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Vijay
> >> >
> >> > --Oliver
> >> > _______________________________________________
> >> > webkit-dev mailing list
> >> > webkit-dev at lists.webkit.org
> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111206/a0a772dd/attachment.html>