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 <oli...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
