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
