flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Sun, 02 Dec 2012 12:36:24 GMT
Hi Frank,

Based on the last week of my rambling I know one thing, I don't have  
enough knowledge of JavScript to be leading any concrete decisions  
regarding the actual implementation.

I read up on the source maps, this does seem like a logical route  
browser vendors would take since eventually I see JavScript not  
looking like script when broswers eat it due to performance (in the  
future). Maybe this is why Bob looks at it like the "webs machine  
language" as well.

I keep looking at the current FalconJS code generator and it's way  
over my head. I couldn't contribute to it until I knew how to use a  
couple key low level features such as ABC and JBurg. For now I have no  
reason and time to invest that amount of effort.

Thus, brings us back to 1 week ago when I proposed writing JS from AS  
AST. And now that you brought up, "it may not be the fastest" brings  
me to my next point.

The AST route is LEGIBLE. :) I read your JsCodeGenerator and in 10  
minutes I knew exactly how you implemented it!

So, do you sacrifice legibility for performance right now? Also,  
Gordon brought up ABC may produce faster JavaScript emitted code, but  
he didn't know. I guess we would only know if some wicked smart  
developers created a prototype of an AST emitter, then ran benchmarks  
against the FalconJS javascript? Right? Isn't this what you would do  
in a science lab? :)

> This should be possible using ABC with debug
> information, shouldn't it?

I'm not exactly sure how precise the source information in an ABC SWF  
is but, obviously it saves some information because the debugger has  
to know where errors occur and stacktraces when debugging an SWF in  
the player.

During the SWF building phase, the builders have access to all the  
code positions from the ISourceLocation API.

As far as MXML I'll let others comment since I am not involved in the  
part of the compiler and it's still getting completed but what you  
said makes perfect seems to me, getting it to AS would allow debugging.


Quoting Frank Wienberg <frank@jangaroo.net>:

> Sorry for joining this discussion so late. Like before, I just would like
> to contribute how we approached the problem at Jangaroo.
> Some time ago, we created our own declarative, XML-based language, targeted
> at creating Ext JS UIs, thus called EXML. EXML is very similar to MXML. The
> main difference is that, to have IDE support and validation, EXML is
> XML-Schema-based. For every module containing EXML files, an XSD is
> generated, describing all available classes and their properties. EXML is
> translated to ActionScript, which is then compiled to JavaScript, so we use
> two chained compilers for EXML->AS and AS->JS.
> After discovering that MXML is acutally not as tied to Flex components as I
> used to think (I stumbled across this blog
> post<http://dgrigg.com/blog/2010/04/12/when-flex-goes-on-a-slimfast-diet/>),
> I experimented with using MXML to define Ext JS UIs. I already have a
> prototype of MXML support for Jangaroo on a github
> branch<https://github.com/CoreMedia/jangaroo-tools/tree/mxml>which
> uses a different approach.
> Things became quite complicated with EXML when we wanted to make EXML->AS
> generation more intelligent. The EXML->AS compiler needed to inspect
> ActionScript classes, but these again could be referring to ActionScript
> classes generated from EXML. So we have a circular dependency here, which
> was complex to deal with.
> Thus, for my MXML prototype, I chose a different approach, namely to
> integrate MXML->JS compilation directly into the Jangaroo compiler, so that
> when the compilation process needs class acme.Foo, it looks for both
> acme/Foo.as and acme/Foo.mxml. If an MXML file is found, internally, the
> compiler still generates ActionScript code, parses it into an AST, and then
> hands it on to its standard JS code generator. While this may not be the
> most efficient solution, it provides best reuse of software components and
> works great!
> There is one important aspect to consider when deciding which route to take.
> If you, like Bernd Paradies, see JavaScript's role in this process as an
> machine language, it is completely valid to generate JS code from ABC.
> But this is not the viewpoint we take for Jangaroo. We chose ActionScript,
> not Dart, TypeScript or Haxe, as the high-level language to compile to
> JavaScript, because it is so very similar to JavaScript. In fact, it is a
> super set of JavaScript, so that you can copy-paste JavaScript code into
> your ActionScript program and it works!
> When you look at Jangaroo-generated JavaScript code, it closely resembles
> the original ActionScript source code. We optimized the compiler as well as
> the runtime to give the impression that the JS code is actually the AS code
> that you, the developer, wrote. Every source file results in a separate JS
> file, which is also loaded separately in "debug mode". Even the line
> numbers are kept precisely. This allows for debugging directly in the
> browser without the need for any additional / new debugger tools.
> Of course, this approach would not be possible at all when generating JS
> code from ABC, not from AS/AST.
> We would like to provide something similar for MXML, too. So the ideal
> solution would be a mixture of the approaches described in this thread.
> Combine Alex' datastructures and the AST->JS approach. This is also very
> similar to how Ext JS UIs are specified using nested JS Object literals.
> The idea would be to generate AS code from MXML that contains both the
> datastructures and the code fragments (<fx:Script>), keeping the line
> numbers (if possible). Then compile the resulting AS to JS, using the
> AST-based method.
> The format could look like so (pseudo-code):
> MyPanel.mxml:
> 01 <s:Panel xmlns:s="..."
> 02     title="hello world">
> 03   <s:Button label="click me!">
> 04     <s:click>
> 05       trace('clicked ' + event.source.label);
> 06     </s:click>
> 07   </s:Button>
> 08 </s:Panel>
> could become something like
> MyPanel.as:
> 01 package ... { import ...; public class MyPanel extends Panel { public
> function MyPanel() { MxmlUtil.apply(this, {
> 02     title: "hello world", children: [
> 03   { type: Button, label: "click me!",
> 04     click: function(event:MouseEvent) {
> 05       trace('clicked ' + event.source.label);
> 06     }
> 07   }
> 08 ]});}}}
> When using the Jangaroo approach, this could be compiled to JavaScript,
> keeping the line numbers for code fragments. So if you set a JavaScript
> breakpoint in line 05, this would exactly correspond to line 5 of your MXML
> source code!
> There is just one game changer that would convince me that this effort is
> not necessary, and that is JavaScript source maps support in all major
> browsers. Then, the generated JavaScript code could look as ugly as you
> like to have it, but the compiler would still have to provide the mapping
> to the original source code. This should be possible using ABC with debug
> information, shouldn't it?
> What do you think?

Michael Schmalle - Teoti Graphix, LLC

View raw message