D to ASM.js vs D to Dart (VM)

[Etienne via Digitalmars-d]

On 2014-05-15 5:10 PM, "Ola Fosheim Grøstad"
> Ok, as a Dart developer I would never use this:
> 1a. The files will be too big.

There's really no issue with big files, because dart minify, tree 
shaking and the general VM caching opportunities & further optimizations 
can take care of it.

> 1b. Compiling from D to Dart to JS will lead to insanely big files.

This compiler would be a bet that the VM can offer more and better 
optimizations. Tree shaking and minification can provide good advantages 
and refactoring opportunities for the time being, it's nothing we've 
never seen with the current JS libraries.

> 2. The dart IDE has browser integrated debugging.

The dart code generated by D=>Dart compiler would be pretty-printed and 
suitable debugging through the dart IDE

> 3. What is the benefit, it will be wiped out once PNaCl is available as
> a D backend?

The idea so far has been that the Dart VM will run on source code rather 
than bytecode like PNaCl, and it will be faster for it.

First, you can further optimize the script if you're flexible on the 
data types. It's impossible to fit 2 longs into an int with PNaCl, but 
the Dart VM will do it if that could be something the source code allows.

Second, you can keep doing "tree shaking" even during the program 
execution. Haven't used a part of the code for a while? Fine, lets just 
take it out of the memory and serialize the data for later.

Finally, you keep the debug info with you in the browser. I don't know 
what the complexity of debugging bytecode in the browser would be, it's 
hard to come accross a good visual GDB debugger and we all know how long 
that's been around.

So, this is mostly a bet that minified files pushed in a Dart VM will be 
better off than bytecode in most cases