VM plans (in the browser) are gone - now what should I do?

[Bluenuance]

Hi,

about roughly 2 years ago (was it some dart 0.x version? :o ) I stumbled upon dart and finally did see a chance where I can do a game with sophisticated AI, Skeletal Animations and all the stuff. All because Dart in it's VM was (is) fast enough. Now two years later I really got it to a point where it seemed all my (hobby) dreams came true. I have most of the features I want (still some missing - as the game is evolving all the time ;) ) and a steady 60fps - again in the VM (Dartium). With all features I targeted for "1.0" I would have expected dropping to 30fps. (so already on the edge)
All my hopes therefor where that the VM will land in Chrome and I can present it to a much broader audience...

Now this dream is shattered by the decision of Google to not implement the VM in Chrome. 

Can you please suggest me alternatives where to move on?

*when compiled to JS my 60fps drop to under 20fps - not to think what would happen when all features are in (5fps?)

[Vyacheslav Egorov]

> *when compiled to JS my 60fps drop to under 20fps - not to think what would happen when all features are in (5fps?)

You should report all performance drops like these as dart2js bugs. 

Once those are fixed you'll reach 60fps in all modern browsers and can present your work to a much broader audience than a Chrome-only VM would ever allow you.

// Vyacheslav Egorov

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Bluenuance]

> Once those are fixed you'll reach 60fps in all modern browsers

So you assume that (let's say 1 year) compiled js is as fast as Dart in the VM now? 

Sorry but I cannot believe that when looking at the benchmarks over the years(!) https://www.dartlang.org/performance/

[Bob Nystrom]

On Thu, Mar 26, 2015 at 3:16 AM, Bluenuance <manuel....@gmail.com> wrote:

> Once those are fixed you'll reach 60fps in all modern browsers

So you assume that (let's say 1 year) compiled js is as fast as Dart in the VM now? 

Sorry but I cannot believe that when looking at the benchmarks over the years(!) https://www.dartlang.org/performance/

dart2js and our dart-on-the-web story in general were developed under a lot of technical constraints over the past several years. One of the biggest constraints was that whatever Dart code people wrote had to work both when compiled to JS and running in Chrome with a native Dart VM. This made dart2js's life a lot harder:

1. Any JS interop story has to handle the fact that it may be communicating with a different VM with its own GC.
   
   
2. dart2js has to support every single corner of the Dart language* since it would break the web if something worked in Chrome-with-a-native-VM but not in Firefox-with-dart-compiled-to-JS.
   

Those constraints are gone now. I can't speak for the dart2js folks, but I really hope they use this new reality to their advantage.

- bob

* except big integers

[Lex Berezhny]

On Thu, Mar 26, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

dart2js and our dart-on-the-web story in general were developed under a lot of technical constraints over the past several years. One of the biggest constraints was that whatever Dart code people wrote had to work both when compiled to JS and running in Chrome with a native Dart VM. This made dart2js's life a lot harder:

1. Any JS interop story has to handle the fact that it may be communicating with a different VM with its own GC.
   
   
2. dart2js has to support every single corner of the Dart language* since it would break the web if something worked in Chrome-with-a-native-VM but not in Firefox-with-dart-compiled-to-JS.
   

Those constraints are gone now. I can't speak for the dart2js folks, but I really hope they use this new reality to their advantage.

On Wed, Mar 25, 2015 at 2:02 PM, Kevin Moore <kev...@google.com> wrote:

Question: Presumably Dartium remains in the picture because it an essential Dart development tool? 

Absolutely. We are committed to fast dev turn-around with great debugging.

 I'm getting conflicting messages from different people at google.

Bob is saying that Dart VM support in browser is going to be dropped.

Kevin is saying that Dartium will remain.

Isn't Dartium a Chrome browser with Dart VM?

So, will Dartium (with Dart VM) remain or will it be dropped?

 - lex

[Vijay Menon]

Dartium is a Chromium branch with important security features disabled.  You'll be able to continue using it for Dart development, but it is not suitable for deploying apps or as a general web browser.

 - lex

[Lex Berezhny]

On Thu, Mar 26, 2015 at 12:52 PM, 'Vijay Menon' via Dart Misc <mi...@dartlang.org> wrote:

On Thu, Mar 26, 2015 at 9:44 AM, Lex Berezhny <l...@damoti.com> wrote:

On Thu, Mar 26, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

dart2js and our dart-on-the-web story in general were developed under a lot of technical constraints over the past several years. One of the biggest constraints was that whatever Dart code people wrote had to work both when compiled to JS and running in Chrome with a native Dart VM. This made dart2js's life a lot harder:

1. Any JS interop story has to handle the fact that it may be communicating with a different VM with its own GC.
   
   
2. dart2js has to support every single corner of the Dart language* since it would break the web if something worked in Chrome-with-a-native-VM but not in Firefox-with-dart-compiled-to-JS.
   

Those constraints are gone now. I can't speak for the dart2js folks, but I really hope they use this new reality to their advantage.

On Wed, Mar 25, 2015 at 2:02 PM, Kevin Moore <kev...@google.com> wrote:

Question: Presumably Dartium remains in the picture because it an essential Dart development tool? 

Absolutely. We are committed to fast dev turn-around with great debugging.

 I'm getting conflicting messages from different people at google.

Bob is saying that Dart VM support in browser is going to be dropped.

Kevin is saying that Dartium will remain.

Isn't Dartium a Chrome browser with Dart VM?

So, will Dartium (with Dart VM) remain or will it be dropped?

Dartium is a Chromium branch with important security features disabled.  You'll be able to continue using it for Dart development, but it is not suitable for deploying apps or as a general web browser.

I only use Dartium for development and that is the only use cases I ever expected from Dartium. But the recent announcement and the conflicting information is very disconcerting.

Maybe today Dartium is just a less-secure version of Chromium with Dart VM. But Bob has pointed out that this is because Dart team has made great effort in Dart VM to make it work well within certain "constraints".

What happens when these constraints are no longer observed? Will Dartium be updated to compensate for the new direction that Dart is taking? If so, how does the new direction reduce the level of effort in maintaining the Dart ecosystem from Googles perspective (you're just moving the complexity of adhering to constraints from Dart VM to Dartium).

Can someone from Google please address the Dartium story because from just reading the announcement it's hard to understand how dropping Dart VM in Chrome does not also mean dropping Dartium.

 - lex

[Bob Nystrom]

On Thu, Mar 26, 2015 at 9:44 AM, Lex Berezhny <l...@damoti.com> wrote:

On Thu, Mar 26, 2015 at 12:36 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

dart2js and our dart-on-the-web story in general were developed under a lot of technical constraints over the past several years. One of the biggest constraints was that whatever Dart code people wrote had to work both when compiled to JS and running in Chrome with a native Dart VM. This made dart2js's life a lot harder:

1. Any JS interop story has to handle the fact that it may be communicating with a different VM with its own GC.
   
   
2. dart2js has to support every single corner of the Dart language* since it would break the web if something worked in Chrome-with-a-native-VM but not in Firefox-with-dart-compiled-to-JS.
   

Those constraints are gone now. I can't speak for the dart2js folks, but I really hope they use this new reality to their advantage.

On Wed, Mar 25, 2015 at 2:02 PM, Kevin Moore <kev...@google.com> wrote:

Question: Presumably Dartium remains in the picture because it an essential Dart development tool? 

Absolutely. We are committed to fast dev turn-around with great debugging.

 I'm getting conflicting messages from different people at google.

Bob is saying that Dart VM support in browser is going to be dropped.

Sorry, I should have been clearer. We fully intend to support Dartium. But there's a big difference between the Dart VM integrated into a development tool (which is what Dartium is) versus it being integrated into a browser that's part of the public open web.

For example (and to be clear, these are hypothetical), let's say people on the team come up with a much nicer way of doing JS interop. However, when used in a browser with the Dart VM, it leaks a little bit of memory of time. If we are focused on a production-quality Dart VM in public Chrome, then that's not acceptable and it's enough to kill that interop story. But if we only have to worry about Dartium, leaking a few bytes here and there may be acceptable.

Or, say we come up with a different way of interacting with the DOM that is faster when compiled to JS but slower when used in a browser with a native Dart VM. That would be an unacceptable trade-off if Chrome had the Dart VM, but might be reasonable when we know it will never affect end users on the web.

Cheers!

- bob

[Lex Berezhny]

Okay, thank you! Your response alleviates a bunch of my concerns.

I hope you understand why myself and many others on this list and in the announcement comments and elsewhere may have misunderstood the plan to "end plans for Dart VM in Chrome".

Especially since there is no Dart VM in Chrome other than Dartium...

 - lex

[Mark H]

I agree with the original poster that this is rather a disappointment to anyone wanting to use Dart for performance orientated apps. My app is very graphics and maths heavy and, although I haven't done any meaningful benchmarks, is obviously much faster running in Dartium than Chrome. I was hoping that Dart would be a viable alternative to native apps via the use of a fast VM. However, this now seems less likely if everything has to be compiled to JS.

[Eric Snellman]

Switch to asm.js

[Don Olmstead]

Yes because asm.js works for a garbage collected language...

[Danny Tuppeny]

On Thursday, 26 March 2015 19:32:06 UTC, Bob wrote:

Sorry, I should have been clearer. We fully intend to support Dartium. But there's a big difference between the Dart VM integrated into a development tool (which is what Dartium is) versus it being integrated into a browser that's part of the public open web.

For example (and to be clear, these are hypothetical), let's say people on the team come up with a much nicer way of doing JS interop. However, when used in a browser with the Dart VM, it leaks a little bit of memory of time. If we are focused on a production-quality Dart VM in public Chrome, then that's not acceptable and it's enough to kill that interop story. But if we only have to worry about Dartium, leaking a few bytes here and there may be acceptable.

Is any effort going to go into addressing all of the differences between the VM and dart2js? It seems there's even less motivation for this now (since it won't result in a difference between Chrome and other production browsers), but it's one of our big concerns... It's not just things like numbers; I've got code that writes "undefined" into textboxes in Chrome after writing empty strings in Dartium. Subtle differences like that make us very nervous. 

[Alan Knight]

Yes. If you see such things, please file bugs.

--

[Danny Tuppeny]

On 27 March 2015 at 16:24, 'Alan Knight' via Dart Misc <mi...@dartlang.org> wrote:

Yes. If you see such things, please file bugs.

There are already bugs; but it's not clear if they'll ever be addressed :-/

eg.:

http://dartbug.com/21555

http://dartbug.com/1533

[Alan Knight]

Well, numbers are tricky. For the 'undefined' toStrings, that seems pretty tractable. We don't want to put in a lot of checks that slow down deployed JavaScript. However, if we're less concerned with Dartium performance, and we can assume that having 'undefined' displayed in the text widgets is never desirable behaviour, then it seems like we could just add a null check on the Dartium end and disallow it. That's not quite identical behaviour, in that it would throw an exception in Dartium, but run in JS and display 'undefined'. But that might be acceptable, in that you probably aren't deploying to JS programs that won't run in Dartium.

--

[Danny Tuppeny]

That would be better, but I don't think having differences in behaviour in the name of performance are good. If Dartium/VM is never production, why not make Dartium behave the same as the JS? What's the advantage in crashing instead of mirroring the production browser behaviour?

Eg. if I have a try/catch around some code I might end up with code that "works" (not realising Dartium is throwing) but takes different paths in Dartium/Chrome. Every difference between dev/production is just another risk. We've worked hard over the last few years to ensure our development environments (not just local QA servers, but also dev machines) are near-clones of our production environment to reduce these risks; and currently is feels like Dart is just going backwards there :(

[David Notik]

"Or, say we come up with a different way of interacting with the DOM"

So, something Google supported akin to Virtual DOM? :) Hypothetical, I know. I do think React has demonstrated how that approach yields big performance gains, and I wonder what the Dart team's stance is there. Yes I know there are contrib libe working on that.

[Cristian Garcia]

I think Angular 2, seems pretty performant. Dont know about something like react for Dart

[Alan Knight]

I'm not so worried about Dartium performance. The worry would be thing that impact production JS performance.

For the example of taking an item from an uninitialized list and setting it as the value of an input text widget, how would we do that in Dartium?

Dart doesn't distinguish between a value of null and a value of undefined. So it seems tricky to come up with something such that

      new List(5)[0].toString() == 'undefined'

I can't really do it in Dartium at the widget level because I can't tell if you mean to give me null or if you're passing me an undefined value. So if you don't want it to be an error, it seems to me that you'd have to modify the setter on the widget in JavaScript, which has performance and code size implications there. It might not be too bad, those values aren't set all that often, but it depends how many of those cases there are.

[Danny Tuppeny]

On 30 March 2015 at 18:59, 'Alan Knight' via Dart Misc <mi...@dartlang.org> wrote:

I'm not so worried about Dartium performance. The worry would be thing that impact production JS performance.

For the example of taking an item from an uninitialized list and setting it as the value of an input text widget, how would we do that in Dartium?

Dart doesn't distinguish between a value of null and a value of undefined. So it seems tricky to come up with something such that

      new List(5)[0].toString() == 'undefined'

I can't really do it in Dartium at the widget level because I can't tell if you mean to give me null or if you're passing me an undefined value. So if you don't want it to be an error, it seems to me that you'd have to modify the setter on the widget in JavaScript, which has performance and code size implications there. It might not be too bad, those values aren't set all that often, but it depends how many of those cases there are.

Ok, I see now why it's complicated; but if the end result is always JS (for web), it feels like the normalisation of null/undefined is just asking for more trouble :(

If your incremental compiler is fast; is there a reason Dartium can't effectively run the Dart code through Dart2JS interally? I would much rather lose a little performance in Dartium than have difference in behaviour between Dev and QA/Live. If no production browser will ever run Dart VM anymore; why use it in Dartium? Converting to JS would surely eliminate a bunch of complications of cross-VM interop and dart/JS interop?

(Obviously I know absolutely nothing about Chromium/Dartium/etc.; there may be obvious reasons why this won't work; but maybe it's worth asking; it sounds like having the VM work well in a browser is tremendously complicated?)

[Alan Knight]

Yes, compiling a language to another language with different semantics can result in some tricky corner cases. But I can't see a DEP for introducing "undefined", separate from "null" to Dart being well-received.

Fast compiling to JS for the development cycle could be done, but there are a few practical difficulties right now. We don't really have an incremental compiler that's production-ready, and current dart2js is not fast enough to use in an iteration loop. Also, the output is not very readable, so debugging is an issue. Even where the structures correspond directly to JS, things get inlined and renamed, so it's not easy to read. There's the DDC work on compiling to ES6 in a more idiomatic way and doing it more incrementally. If that got to the point where it was a fast, debuggable experience as good as Dartium and with better compatibility, that would be awesome, and we might be able to start doing that.

Though I'm still not sure what it would do for the null/undefined case. It might just be what Stephen suggested in the bug, that the compiler would reject that code outright and require you to provide a String, rather than just doing a toString() on null/undefined.

--

[Danny Tuppeny]

On 30 March 2015 at 20:55, 'Alan Knight' via Dart Misc <mi...@dartlang.org> wrote:

Though I'm still not sure what it would do for the null/undefined case. It might just be what Stephen suggested in the bug, that the compiler would reject that code outright and require you to provide a String, rather than just doing a toString() on null/undefined.

If Dartium was running the same dart2js'd code as production browsers, the behaviour would be the same; so I don't think it would need changing. Being consistent is more important than what the behaviour is.

(Also; think about the complexity you have in doing Dart<->JS interop in the VM that now only exists in Dartium... Imagine being able to just have one implementation of this; which is for dart2js output! ;)) 

[Rich Eakin]

On Thu, Apr 2, 2015 at 2:08 PM, Danny Tuppeny <da...@tuppeny.com> wrote:

On 30 March 2015 at 20:55, 'Alan Knight' via Dart Misc <mi...@dartlang.org> wrote:

Though I'm still not sure what it would do for the null/undefined case. It might just be what Stephen suggested in the bug, that the compiler would reject that code outright and require you to provide a String, rather than just doing a toString() on null/undefined.

If Dartium was running the same dart2js'd code as production browsers, the behaviour would be the same; so I don't think it would need changing. Being consistent is more important than what the behaviour is.

If this were the case, why would Dartium exist at all, why not use chrome for development?  The power I see in dartium is faster build cycles since there is no transpilation required, and being able to debug dart code (typed) rather than js code (spaghetti).

I think extra checks in dartium is the way to go, leaving the js side of things as lean as possible. It is typical for development builds to have more checks than production code anyway, and dartium is the dev tool.

[Danny Tuppeny]

On 2 April 2015 at 20:12, Rich Eakin <rte...@gmail.com> wrote:

Though I'm still not sure what it would do for the null/undefined case. It might just be what Stephen suggested in the bug, that the compiler would reject that code outright and require you to provide a String, rather than just doing a toString() on null/undefined.

If Dartium was running the same dart2js'd code as production browsers, the behaviour would be the same; so I don't think it would need changing. Being consistent is more important than what the behaviour is.

If this were the case, why would Dartium exist at all, why not use chrome for development?  The power I see in dartium is faster build cycles since there is no transpilation required, and being able to debug dart code (typed) rather than js code (spaghetti).

I'm talking about effectively embedding dart2js in Dartium and compiling on the fly. Source maps for debugging. 

Now the VM isn't going into Chrome; Dartium looks incredibly expensive to me (stuff like dart<->js interop is presumably now being coded specifically for Dartium) and doesn't behave the same as any production browser will (even Chrome).

Making code behave the same in all browsers is already a pain in the ass; we don't need a development tool that has its own behaviour.

[Filipe Morgado]

I think Dart behaviour should be preserved and refined away from JS.

There's a server-side story as well and, hopefully in the future, native client targets.

If we constrain the language for a given target, it won't fit anywhere else.

Dart should follow its own (sane) path and not carry any historical stupidity.

[Danny Tuppeny]

I wasn't suggesting any changes to Dart as a language, I was solely talking about about Dartium/browser. The behaviour of Dart in Dartium should match production browsers; there's really no value in having it do its own thing there. It's a development tool to aid building for production browsers and nothing more.

[Danny Tuppeny]

Watched this video from the Dart Summit today:

https://www.youtube.com/watch?v=2Ef3ALvbkhA&list=PLOU2XLYxmsIIQorIS8gagUiMau9S84vZV&index=6

Seems like work is well underway to enable development with production browsers using dev_compiler. I suspect this means Dartium will ultimately go away. Sounds very positive :)

[Kirth Gersen]

On Saturday, May 2, 2015 at 8:37:08 PM UTC+2, Danny Tuppeny wrote:

Watched this video from the Dart Summit today:

https://www.youtube.com/watch?v=2Ef3ALvbkhA&list=PLOU2XLYxmsIIQorIS8gagUiMau9S84vZV&index=6

Seems like work is well underway to enable development with production browsers using dev_compiler. I suspect this means Dartium will ultimately go away. Sounds very positive :)

The big + of Dartium (and the VM) is the Observatory. Unless they have hidden plan to build an Observatory for JS (and also for Dart2JS with sourcemap ?!) I don't see anything positive in Dartium going away.

The big +'s of having the "Dart VM into Chrome" were the Observatory and allowing new features to "Dart for the Web" without depending on JS to support them first (for instance adding real lightweight parallelism that is much needed since most modern machines from smartphones to servers have multicore CPUs). 

'VM into Chrome' was basically "I can do stuff with Dart for the Web that I can't do with Javascript. I can be faster than JS. I can iterate faster on new features. I can lead the evolution of the Web". All that is gone now. JS remains what the Web is and should be. Progress and changes must happen in JS first, Dart will only follow...and then at some point "Dart for the Web" (DftW) and the Dart VM (on servers and Sky) will have to diverge because DftW won't be able to follow the evolution and changes they want to make to the Dart VM or the Dart language...or no major changes will be made just to keep them in sync.So basically we won't see much novelty and new features in the language itself, only in the form of libraries that can only be used server side (like dart:io)..leading to more client/server fragmentation and less code sharing between them...

But well, I'm still mad at this decision but I guess the Dart Team weighted all these aspects (and more) before taking such a drastic decision. I really hope they did.

[Jim Trainor]

The question was asked on this forum and the official answer was that Dartium will remain.

Everything beyond that is speculation.

[Danny Tuppeny]

On 3 May 2015 at 18:52, Jim Trainor <jim.train...@gmail.com> wrote:

The question was asked on this forum and the official answer was that Dartium will remain.

Everything beyond that is speculation.

In the video I linked at 4:35:

One way to think about this is that today the competition for dev_compiler today is Dartium and so right now, everyone does their web development using Dart in Dartium so that has the latest Chrome features. We're really imagining that people that use the dev_compiler would just develop against tip of Chrome and use the unflagged features there.

Right, so our plan in the short term is we'll continue to ship Dartium and support it, we know it's critical for you folks.

It's inconclusive; but I think it's pretty clear where things are going. If maintaining a VM in the browser wasn't such a big effort, it would've been in Chrome already. I can't see Dartium being maintained once the ability to develop using any browser is sufficient.

But, I see this as a good thing. I hit nasty differences between Dartium and Chrome within a few hours of starting a prototype in Dart. We need to be developing and debugging against what our users will see; Dartium will never provide that.

[alberto.ags]

Dart VM could be the future v8 & dart virtual machine two  vm in one multi-vm server.

it is other alternative.

al 

--