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

[Anton Muhin]

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?

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