[webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Anton Muhin
antonm at chromium.org
Tue Dec 6 02:55:39 PST 2011
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.
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
More information about the webkit-dev
mailing list