3 ms·

Why does the Java VM run in a browser but the Dart VM is too hard?

BrendanEich 11y ago
Please read anything I've written on the topic over the years. Java runs as a plugin, like Flash. It has no deep DOM integration. Both Java and Flash have become security problems, so they're in various penalty boxes, beyond the plugin prison. Back in 1995, when I did JS in the shadow of Java, as a sidekick Robin-the-boy-hostage language, I did the primordial DOM too. Java was in only applets then -- pretty much the same as a plugin. We did connect JS and Java via LiveConnect, which led to the JRI (Warren Harris at Netscape), which led to the JNI. To solve the GC problem, the JRI user had to manage handles for global and local roots. This did not solve the inter-heap cycle problem, however. Netscape never implemented a cycle collector, but we did at Mozilla, based on [Bacon & Rajan, 2001]. It was required for C++ and JS cycle collection. Around that time, IE would still leak memory if you made a C++/JS cycle by capturing certain global object property references in closures. Their C++ side used COM reference counting, so once the cycle closed through JScript, there was no way to drop the cycle-internal refcount. Mozilla's C++/JS cycle collector was originally meant to handle C-Python too (and possibly other languages with full XPCOM/DOM access), since we had an optional integration of that engine, courtesy Mark Hammond of Active State. But both the C-Python integration and the polyglot support in the CC got ripped out. Browsers cannot afford overhead, even mostly-dead (but still hazardous in the 0day sense) code. (Updated to note that LiveConnect is long-gone too. Java is just a plugin.) I suspect you still have not read Filip Pizlo's post at that lists.webkit.org link I left, or the paper it references. Please take more time to study problems before casting aspersions!
- michaelwww 11y ago
  What aspersions? I've noted your opposition to Dart. You've explained that it has to do with memory management difficulties that seem intractable. I now understand this better, so I thank you. The world has moved on and now transpilers are coming into their own, so we do have real choice in the language we use in the browser, which as a programmer is all I want.
  - BrendanEich 11y ago
    What aspersions? Let's start with your "Mozilla disliked Dart", full of personalizing words that obfuscate the objective arguments. Just the "dislike" usage is subjective and vague -- and inaccurate when applied to my comments on HN about Dart. DartVM never had a chance, I told 'em so and gave concrete reasons why it didn't. Worse, the leaked DASH memo was arrogant and wrong in declaring that JS "cannot be fixed by evolving the language". Anders Hejlsberg gently pushed back against that bogus assertion in 2012: https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-... and events have proven him correct. Read the leaked DASH memo if you haven't yet: http://pastebin.com/NUMTTrKj http://pastebin.com/NUMTTrKj via http://lambda-the-ultimate.org/node/4355 http://lambda-the-ultimate.org/node/4355 (Note that Mark Miller did not write this memo, he just accidentally posted it to a public Google Group thinking that group was private to Google employees.) A lot of water under the bridge since 2010, and some of it had good effects for Dart users for sure, even with Dart now only a compile-to-JS language. But a lot was wasted. Dart could have used bignums (Dart `int` support) in ES6, for example, and this would have helped JS users too. The lack of it is a direct cost of focusing on DartVM at the expense of dart2js; see https://github.com/dart-lang/sdk/issues/1533 https://github.com/dart-lang/sdk/issues/1533 You are right that I disliked the stinky politics and enormous question-begging on display in the DASH memo. (That's me disliking a set of bad arguments, not me disliking Dart.) It was a statement of intent, to fund a project because some people of note wanted to do that project, even if it wouldn't work cross-browser, and even if it imposed high opportunity cost to JS both in Chrome (the whole V8 team had to be reconstituted in Munich) and in Ecma TC39 (no one showed up to argue for better cross-compiling support in general). WebAssembly should grow dynamic language support for Dart and languages like it, but that's years out. In the mean time, only JS as compile-from-Dart target is available. ES6 could have used the help. It's fine for well-funded entities to waste money on boondoggles (well, not really, but I was not a shareholder, and Google is free to "experiment" for any reason it pleases). But I'm not obligated to praise a bogus justification when it leaks, or honor the two-faced way that JS was dealt with in the memo, and evident from the direct and opportunity costs of DartVM.
    - michaelwww 11y ago

Please read anything I've written on the topic over the years. Java runs as a plugin, like Flash. It has no deep DOM integration. Both Java and Flash have become security problems, so they're in various penalty boxes, beyond the plugin prison. Back in 1995, when I did JS in the shadow of Java, as a sidekick Robin-the-boy-hostage language, I did the primordial DOM too. Java was in only applets then -- pretty much the same as a plugin. We did connect JS and Java via LiveConnect, which led to the JRI (Warren Harris at Netscape), which led to the JNI. To solve the GC problem, the JRI user had to manage handles for global and local roots. This did not solve the inter-heap cycle problem, however. Netscape never implemented a cycle collector, but we did at Mozilla, based on [Bacon & Rajan, 2001]. It was required for C++ and JS cycle collection. Around that time, IE would still leak memory if you made a C++/JS cycle by capturing certain global object property references in closures. Their C++ side used COM reference counting, so once the cycle closed through JScript, there was no way to drop the cycle-internal refcount. Mozilla's C++/JS cycle collector was originally meant to handle C-Python too (and possibly other languages with full XPCOM/DOM access), since we had an optional integration of that engine, courtesy Mark Hammond of Active State. But both the C-Python integration and the polyglot support in the CC got ripped out. Browsers cannot afford overhead, even mostly-dead (but still hazardous in the 0day sense) code. (Updated to note that LiveConnect is long-gone too. Java is just a plugin.) I suspect you still have not read Filip Pizlo's post at that lists.webkit.org link I left, or the paper it references. Please take more time to study problems before casting aspersions!

michaelwww 11y ago
What aspersions? I've noted your opposition to Dart. You've explained that it has to do with memory management difficulties that seem intractable. I now understand this better, so I thank you. The world has moved on and now transpilers are coming into their own, so we do have real choice in the language we use in the browser, which as a programmer is all I want.
- BrendanEich 11y ago
  What aspersions? Let's start with your "Mozilla disliked Dart", full of personalizing words that obfuscate the objective arguments. Just the "dislike" usage is subjective and vague -- and inaccurate when applied to my comments on HN about Dart. DartVM never had a chance, I told 'em so and gave concrete reasons why it didn't. Worse, the leaked DASH memo was arrogant and wrong in declaring that JS "cannot be fixed by evolving the language". Anders Hejlsberg gently pushed back against that bogus assertion in 2012: https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-... and events have proven him correct. Read the leaked DASH memo if you haven't yet: http://pastebin.com/NUMTTrKj http://pastebin.com/NUMTTrKj via http://lambda-the-ultimate.org/node/4355 http://lambda-the-ultimate.org/node/4355 (Note that Mark Miller did not write this memo, he just accidentally posted it to a public Google Group thinking that group was private to Google employees.) A lot of water under the bridge since 2010, and some of it had good effects for Dart users for sure, even with Dart now only a compile-to-JS language. But a lot was wasted. Dart could have used bignums (Dart `int` support) in ES6, for example, and this would have helped JS users too. The lack of it is a direct cost of focusing on DartVM at the expense of dart2js; see https://github.com/dart-lang/sdk/issues/1533 https://github.com/dart-lang/sdk/issues/1533 You are right that I disliked the stinky politics and enormous question-begging on display in the DASH memo. (That's me disliking a set of bad arguments, not me disliking Dart.) It was a statement of intent, to fund a project because some people of note wanted to do that project, even if it wouldn't work cross-browser, and even if it imposed high opportunity cost to JS both in Chrome (the whole V8 team had to be reconstituted in Munich) and in Ecma TC39 (no one showed up to argue for better cross-compiling support in general). WebAssembly should grow dynamic language support for Dart and languages like it, but that's years out. In the mean time, only JS as compile-from-Dart target is available. ES6 could have used the help. It's fine for well-funded entities to waste money on boondoggles (well, not really, but I was not a shareholder, and Google is free to "experiment" for any reason it pleases). But I'm not obligated to praise a bogus justification when it leaks, or honor the two-faced way that JS was dealt with in the memo, and evident from the direct and opportunity costs of DartVM.
  - michaelwww 11y ago