On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
