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.
Mike
Quoting Frank Wienberg <fr...@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
http://www.teotigraphix.com
http://blog.teotigraphix.com
