On Thu, Dec 20, 2012 at 11:12 PM, Daniel Wasilewski <devudes...@gmail.com>wrote:
> You keep saying, for debugging reasons, your goal is to mimic as3 vs JS > output into even exact line of code. > Only in the debuggable compiler output. The optimized production code might look like machine code. > We are about to get compiler that can optimise everything before it will > get translated to JS, we don't care about the output in terms of accuracy > of representing input. > We do care about efficiency of how it performs and do, what input platform > wants it to do without errors. Our debugger and protector should be the > input platform. > You are arguing like the Java GWT guys: "we provide you with a 'hosted environment' for developing/debugging. If everything works, your application is optimized and deployed to the Web." The flaw is that the browser is not such a reliable environment like a Java- or Flash-VM. If you have browser-specific bugs in your highly optimized, un-debuggable code, you are screwed. JavaScript source maps (see above) might overcome this problem, but they are not there yet. > We have a descent tools to make it happen these days. Even if my code > needs to get over heavy lifting, closure compiler etc, I don't care. > My argumentation is that when we have fully-resolved ActionScript-AST or ABC as input format, we can deliver much better optimizations that Closure which has to reverse-engineer non-dynamic structures from JavaScript code (that's why it needs the annotations). > JS in many cases is faster that Flash Player these days. Sad, but true > statement. I still believe is possible to translate AS3 into JS without > loosing those benefits. > Why should we lose this benefit just because in debug mode, we keep ActionScript code untouched if it can be executed in JavaScript as-is? > It is possible to write AS3 language like in pure Java script, not other > way around. For this reason I cannot accept something that for sake of just > accurate translation ruin performance. > No, of course I'm trying to achieve both: accurate translation *and* performance! > > If flex will not get to this point, better look at Haxe JS output. Because > is the best performer for time being. > I had a look at Haxe JS output and was a bit disappointed. They tailored the language towards being easy to translate to JavaScript and sometimes chose the least common denominator, for example by abandoning private members. They generate nothing like lazy class initialization (running static code of a class exactly when FlashPlayer would). My goal is that at least on language level, most ActionScript 3 code runs as-is, otherwise we are implementing a different language. -Frank-
