You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Daniel Wasilewski <de...@gmail.com> on 2012/11/28 21:01:39 UTC
[FalconJS] concepts
Ok will try again by changing a subject because you seems to moved away
from original topic, and I don't want to interrupt :)
So far I have a test to compare very simple model of prototypal
inheritance and proposed module pattern that seems to be out of falconJS
compiler little syntactic sugar.
I have minimised this source a bit, there was few more additional fields
that I guess something is depends on but even striping it out:
http://jsperf.com/inheritance-yet-another-test/3
If you go to the revision 2 of this test, there will be different
comparison.
http://jsperf.com/inheritance-yet-another-test/3
Speed of accession of those objects.
However I would like to improve it, because adobe.js implementation
doesn't seems to call super as the classic does.
So it might be not relevant test right now. Does anybody know how to
call super from there?
Dan
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
When I was thinking about how to make distinction between canvas and DOM
based display list output, I thought of letting developer choose on
compile time.
But I really like your solution with casheAsBitmap. On top of graphics
API I was planing to add another feature casheStyle("id") and what it
does it will store
css properties that you can reuse by graphics.getStyle("id") within
other sprites/shapes. It will minimise overbloatnes of custom style per div.
I guess for stuff like flex application html DOM will be more desirable
solution, but things like simulating Bitmap or interactive Charts,
Canvas still is must have.
I know there are some issues with transform on DOM elements but where is
a problem there is a solution.
What I can tell, you seems not to pay attention to that part yet, since
lots of matrix transformations are not implemented yet.
However, flex apps don't rotate/skew/scale too much :)
Dan
On 11/30/2012 10:40 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
>>> Primarily, I also map DOs to DOM elements!
>>>
>>> Greetings
>>> -Frank-
>> Just curious, but how does this mapping work? How many DOM objects are
>> being created and what does the drawing, SVG?
>>
>> Usually only one DOM object, but that can be different in each
> DisplayObject subclass.
> The actual drawing (flash.display.Graphics) is always done through a canvas
> (which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite
> consists of a <div> container with a <canvas> for rendering and more DOM
> elements for all contained child-DOs.
> Because in typical gaming scenarios, this approach led to a lot of canvases
> being created and turned out to be slow and memory-consuming, I implemented
> a mode where a complete DisplayList-subtree (well, the thing called
> DisplayList actually is a tree!) is rendered into a single canvas. This is
> the approach taken by DartFlash and works extremely well for games and
> animations where almost all DOs are graphics or simple text, but is not so
> good for interactive components like TextField, where you would have to
> emulate all the interactive behavior on a low-level basis (blinking cursor
> etc.).
> Since it seems none of the two solutions is always preferable, I now let
> the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
> activates canvas mode for that DL-subtree, but other parts of the DL can
> still use DOM-mode, so you can mix-and-match graphics and interactive parts
> of your UI.
> Note however that the DOM-mode supports less Flash features and has several
> known bugs concerning scaling and rotation (it is really tough to map these
> on CSS3 transforms and it turned out to be much easier when using canvas 2D
> API). It might even be that after the canvas-refactoring, DOM-mode work
> worse than before...
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Btw, since only the "cacheAsBitmap" feature and the Graphics implementation
use canvas, it is completely possible to implement SVG rendering as an
alternative. The "cacheAsBitmap" flag of a flash.display.Bitmap object
could be used as the switch whether to use canvas or SVG.
On Fri, Nov 30, 2012 at 11:40 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
>> > Primarily, I also map DOs to DOM elements!
>> >
>> > Greetings
>> > -Frank-
>> Just curious, but how does this mapping work? How many DOM objects are
>> being created and what does the drawing, SVG?
>>
>> Usually only one DOM object, but that can be different in each
> DisplayObject subclass.
> The actual drawing (flash.display.Graphics) is always done through a
> canvas (which is, of course, also a DOM element!). Thus, in DOM-mode, a
> Sprite consists of a <div> container with a <canvas> for rendering and more
> DOM elements for all contained child-DOs.
> Because in typical gaming scenarios, this approach led to a lot of
> canvases being created and turned out to be slow and memory-consuming, I
> implemented a mode where a complete DisplayList-subtree (well, the thing
> called DisplayList actually is a tree!) is rendered into a single canvas.
> This is the approach taken by DartFlash and works extremely well for games
> and animations where almost all DOs are graphics or simple text, but is not
> so good for interactive components like TextField, where you would have to
> emulate all the interactive behavior on a low-level basis (blinking cursor
> etc.).
> Since it seems none of the two solutions is always preferable, I now let
> the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
> activates canvas mode for that DL-subtree, but other parts of the DL can
> still use DOM-mode, so you can mix-and-match graphics and interactive parts
> of your UI.
> Note however that the DOM-mode supports less Flash features and has
> several known bugs concerning scaling and rotation (it is really tough to
> map these on CSS3 transforms and it turned out to be much easier when using
> canvas 2D API). It might even be that after the canvas-refactoring,
> DOM-mode work worse than before...
>
>
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
Ah ok. Makes sense to me.
We should certainly have support for vector drawing for those who need it.
I'm still going to build the interactive widgets using as much of the native
HTML/HTML5 controls as possible.
Thanks,
-Alex
On 11/30/12 2:40 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
>>> Primarily, I also map DOs to DOM elements!
>>>
>>> Greetings
>>> -Frank-
>> Just curious, but how does this mapping work? How many DOM objects are
>> being created and what does the drawing, SVG?
>>
>> Usually only one DOM object, but that can be different in each
> DisplayObject subclass.
> The actual drawing (flash.display.Graphics) is always done through a canvas
> (which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite
> consists of a <div> container with a <canvas> for rendering and more DOM
> elements for all contained child-DOs.
> Because in typical gaming scenarios, this approach led to a lot of canvases
> being created and turned out to be slow and memory-consuming, I implemented
> a mode where a complete DisplayList-subtree (well, the thing called
> DisplayList actually is a tree!) is rendered into a single canvas. This is
> the approach taken by DartFlash and works extremely well for games and
> animations where almost all DOs are graphics or simple text, but is not so
> good for interactive components like TextField, where you would have to
> emulate all the interactive behavior on a low-level basis (blinking cursor
> etc.).
> Since it seems none of the two solutions is always preferable, I now let
> the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
> activates canvas mode for that DL-subtree, but other parts of the DL can
> still use DOM-mode, so you can mix-and-match graphics and interactive parts
> of your UI.
> Note however that the DOM-mode supports less Flash features and has several
> known bugs concerning scaling and rotation (it is really tough to map these
> on CSS3 transforms and it turned out to be much easier when using canvas 2D
> API). It might even be that after the canvas-refactoring, DOM-mode work
> worse than before...
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
> On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>
> > Primarily, I also map DOs to DOM elements!
> >
> > Greetings
> > -Frank-
> Just curious, but how does this mapping work? How many DOM objects are
> being created and what does the drawing, SVG?
>
> Usually only one DOM object, but that can be different in each
DisplayObject subclass.
The actual drawing (flash.display.Graphics) is always done through a canvas
(which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite
consists of a <div> container with a <canvas> for rendering and more DOM
elements for all contained child-DOs.
Because in typical gaming scenarios, this approach led to a lot of canvases
being created and turned out to be slow and memory-consuming, I implemented
a mode where a complete DisplayList-subtree (well, the thing called
DisplayList actually is a tree!) is rendered into a single canvas. This is
the approach taken by DartFlash and works extremely well for games and
animations where almost all DOs are graphics or simple text, but is not so
good for interactive components like TextField, where you would have to
emulate all the interactive behavior on a low-level basis (blinking cursor
etc.).
Since it seems none of the two solutions is always preferable, I now let
the developer decide. Setting "cacheAsBitmap" to true on a DO-Container
activates canvas mode for that DL-subtree, but other parts of the DL can
still use DOM-mode, so you can mix-and-match graphics and interactive parts
of your UI.
Note however that the DOM-mode supports less Flash features and has several
known bugs concerning scaling and rotation (it is really tough to map these
on CSS3 transforms and it turned out to be much easier when using canvas 2D
API). It might even be that after the canvas-refactoring, DOM-mode work
worse than before...
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
Interesting info on this, thanks!
There is also Mozilla Shumway (based on Gordon I believe), which
actually parses and runs SWFs without a need for a head of time AS3->JS
compile, and has a whole Flash API layer (I don't know how complete any
of it is).
How does Shumway compare with the way Jangaroo handles the display list?
Could parts of that project be useful for the SWF/SWC areas of the
FalconJS compiler?
Kevin N.
On 11/30/12 5:25 AM, Frank Wienberg wrote:
> Yes and no. I implemented single-canvas-mode on a branch, but when merging
> into the master, I re-activated the DOM mode.
> Single-canvas-mode is activated by setting cacheAsBitmap on the stage!
>
>
> On Thu, Nov 29, 2012 at 4:47 PM, Kevin Newman <Ca...@unfocus.com> wrote:
>
>> Oh, I thought Jangaroo switched to a single Canvas a while back. I may
>> have introduced that incorrect information. Sorry about that.
>>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Yes and no. I implemented single-canvas-mode on a branch, but when merging
into the master, I re-activated the DOM mode.
Single-canvas-mode is activated by setting cacheAsBitmap on the stage!
On Thu, Nov 29, 2012 at 4:47 PM, Kevin Newman <Ca...@unfocus.com> wrote:
> Oh, I thought Jangaroo switched to a single Canvas a while back. I may
> have introduced that incorrect information. Sorry about that.
>
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
Oh, I thought Jangaroo switched to a single Canvas a while back. I may
have introduced that incorrect information. Sorry about that.
Kevin N.
On 11/29/12 6:31 AM, Frank Wienberg wrote:
> Primarily, I also map DOs to DOM elements!
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Yes I do, I was doing research on this subject.
In fact my project is about something else, high performance application
framework on top of native platforms.
AS a bare bones to make a common ground for development. And trying to
add few new concepts into it.
http://www.bixbite.org/BixBitePresentation.swf (work in progress ;) )
But this little experiment that mimic display list was just to have a
go, prove of concept, In many cases is not even needed for me.
There is a difference between writing API for native platform and let
developers deal with it directly.
Rather than stay with AS3 and compile/interpret into target platform.
And I have to say jangaroo was on my research-in-development bookmarks
for a while as well.
You did big progress from what I remember.
Dan
On 11/29/2012 11:31 AM, Frank Wienberg wrote:
> Dan, are you aware of FlashJS <http://flashjs.com/>?
> Btw, JooFlash also uses canvas optionally, namely for Graphics and if you
> set DisplayObject#cacheAsBitmap to true.
> Primarily, I also map DOs to DOM elements!
>
> Greetings
> -Frank-
>
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/29/12 3:31 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> Dan, are you aware of FlashJS <http://flashjs.com/>?
> Btw, JooFlash also uses canvas optionally, namely for Graphics and if you
> set DisplayObject#cacheAsBitmap to true.
> Primarily, I also map DOs to DOM elements!
>
> Greetings
> -Frank-
Just curious, but how does this mapping work? How many DOM objects are
being created and what does the drawing, SVG?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Dan, are you aware of FlashJS <http://flashjs.com/>?
Btw, JooFlash also uses canvas optionally, namely for Graphics and if you
set DisplayObject#cacheAsBitmap to true.
Primarily, I also map DOs to DOM elements!
Greetings
-Frank-
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
One more idea/concept in regards of mimic flash display list.
This is copy paste from my code I am working on. Early prototype stage
but...
http://www.bixbite.org/html/dsp.html
var s,sc;
var max = 1000;
var stage = new Stage();
var time = getTimer();
for (var i = 0; i<max; i++) {
sc = new Sprite();
sc.graphics.beginFill(0x444444, 1);
sc.graphics.drawRect(0,0,50,50);
sc.x = Math.random()*1900;
sc.y = Math.random()*800;
stage.addChild(sc);
s = new Shape();
s.graphics.beginFill(0xFF0000, 1);
s.graphics.drawRect(-20,-20,40,40);
s.x = 25;
s.y = 25;
s.rotation = 45;
sc.addChild(s);
}
trace("TIME: " + (getTimer()-time));
I bet you could easily confuse it with Action Script. And yes it's a display-list-like 4kb API using DOM not canvas.
I don't even need compiler to translate my code, just getting rid of :Type.
Here is another example:
http://www.bixbite.org/html/dsp2.html
And that thing is using TweenLite port to JS to move stuff around.
Dan
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
What I am trying to understand in regards to this.
Is it, that AS3 -> AST needs to deal with those but AST->JS simply
ignore it?
AS3 -> AST -> JS
Type safe we don't care
as long output represents input? Abstract syntax tree is abstract by
definition right?
On 11/29/2012 8:26 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 8:45 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> Well, there is the JavaScript operator "instanceof", what's wrong with
>> that?
>>
> Nothing, but it only works when you actually use the
> prototype chain, not when you copy all members from
> the superclass to the subclass.
> Also, when using ActionScript, you will want to use "is"
> for interfaces, where "instanceof" does not work.
> Bernd Paradies points out in his
> blog<http://blogs.adobe.com/bparadie/2012/10/21/kicking-typescipts-tires/>that
> a real drawback
> of TypeScript is that there is no runtime type information
> about interfaces. The Jangaroo Compiler + Runtime
> implement the "is" and "as" operators to work with
> interfaces seamlessly and efficiently!
>
> Greetings,
> -Frank-
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 8:45 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Well, there is the JavaScript operator "instanceof", what's wrong with
> that?
>
Nothing, but it only works when you actually use the
prototype chain, not when you copy all members from
the superclass to the subclass.
Also, when using ActionScript, you will want to use "is"
for interfaces, where "instanceof" does not work.
Bernd Paradies points out in his
blog<http://blogs.adobe.com/bparadie/2012/10/21/kicking-typescipts-tires/>that
a real drawback
of TypeScript is that there is no runtime type information
about interfaces. The Jangaroo Compiler + Runtime
implement the "is" and "as" operators to work with
interfaces seamlessly and efficiently!
Greetings,
-Frank-
Re: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> That said, because we are cross compiling AS, does the classic route support
> as many features of AS, especially the reflection-oriented features? We
> want to try to compile business logic untouched and it might be using "is",
> "in", "instanceof", etc. Resig's blog seems to indicate that support for
> instanceOf was important and required all of that code.
Well, there is the JavaScript operator "instanceof", what's wrong with that?
Stuff like 'is', 'as' and 'in' we'll need to syntactically work
around, just like we do with class creation, constructors etc., no big
deal, the compiler should be able to take care of that.
As to classic vs. other routes, a final thought: while bare bones
performance might favour one over the other, we also have to take into
account that probably 99% of performance gain or loss will be due to
feature implementation, not the way we choose to implement a specific
language feature (inheritance, class creation etc.). Also, things like
easy of coding and maintenance are major factors.
Having said all that, I think the bottom line is that there is already
a lot of work done to make the current solution happen. I have looked
at it in dept yesterday and can't find any major fault, although some
of the design decisions might not have been my own. Then again, I
don't know all the considerations that went into it, nor am I familiar
with the limitations (if any) of the compiler. I am happy with take
the current solution forward instead of starting from scratch.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/29/2012 12:59 PM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> It's not that you can't use a framework and "vanilla" js...
>
> Yeah, we use this framework: http://vanilla-js.com/
> ;-)
>
Hehe, me too without even knowing ;)
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> It's not that you can't use a framework and "vanilla" js...
Yeah, we use this framework: http://vanilla-js.com/
;-)
Re: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Actually, the third argument of 'adobe.extend()' is what can probably
considered "the rest" of the output of the JSEmitter (yes, Mike, it
did make a little more sense). And that "the rest: is a "simple"
object literal, which can easily be parse (as the 'extend' method
does).
If you want to change stuff on the JS side, all you need to do is
replace the implementation of the 'adobe' object methods, leaving the
"API" (basically 'extend' and a few utility methods) untouched. I
don't suggest this as a permanent solution, but while better minds
than mine are working on getting the compiler under control it does
provide a method to experiment with the JS side of things.
EdB
On Thu, Nov 29, 2012 at 2:48 PM, Daniel Wasilewski <de...@gmail.com> wrote:
> On 11/29/2012 1:36 PM, Michael Schmalle wrote:
>>
>>
>>
>> Laymans; A SWF is created for all classes just like in MXMLC, there is a
>> visitor pattern that is used that traverses the internals of the ISWF. As
>> each of the elements in the SWF are traversed (classes, methods, members
>> etc) calls to the JSEmitter and other classes happens and the js is created
>> during the traversal.
>>
> And this is the place 'JSEmitter ' that has the JS grammar rules specified,
> but instead spiting out pure JS syntax it relies on little adobe.js that
> simplifies the process and grammar rules. Am I right? if so, How hard it
> would be to make it adobe.js independent, if too hard, adobe.js would be a
> subject to change/polishing up, we just need to know what fields JSEmiter is
> expecting to match.
>
>> JBurg is compiled to actually create the class and rules that does the
>> actual traversal logic through the SWF file.
>>
>> Does that make more sense?
>>
>> Mike
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/29/2012 1:36 PM, Michael Schmalle wrote:
>
>
> Laymans; A SWF is created for all classes just like in MXMLC, there is
> a visitor pattern that is used that traverses the internals of the
> ISWF. As each of the elements in the SWF are traversed (classes,
> methods, members etc) calls to the JSEmitter and other classes happens
> and the js is created during the traversal.
>
And this is the place 'JSEmitter ' that has the JS grammar rules
specified, but instead spiting out pure JS syntax it relies on little
adobe.js that simplifies the process and grammar rules. Am I right? if
so, How hard it would be to make it adobe.js independent, if too hard,
adobe.js would be a subject to change/polishing up, we just need to know
what fields JSEmiter is expecting to match.
> JBurg is compiled to actually create the class and rules that does the
> actual traversal logic through the SWF file.
>
> Does that make more sense?
>
> Mike
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> "The SWF file is then used to write out the js using a JBurg bottom up
> reducer/emitter." ;-)
Laymans; A SWF is created for all classes just like in MXMLC, there is
a visitor pattern that is used that traverses the internals of the
ISWF. As each of the elements in the SWF are traversed (classes,
methods, members etc) calls to the JSEmitter and other classes happens
and the js is created during the traversal.
JBurg is compiled to actually create the class and rules that does the
actual traversal logic through the SWF file.
Does that make more sense?
Mike
> That means so little to me, while it probably explains everything to
> someone with the proper background. I'll try to get some more
> background, so I may be of some use when the time comes to start
> hacking the JS output.
>
> EdB
>
>
> On Thu, Nov 29, 2012 at 2:22 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> Well you may have missed it since this thread is going forever but I did
>> write something [0]
>>
>> There was one concept I screwed up and that is in the end the loop and write
>> doesn't happen on the monolithic SWF, I think it's for external files that
>> were not linked into the main SWF.
>>
>> Basically, the compiler loads like MXMLC, using configuration files and args
>> passed to it.
>>
>> It the parses all files and then creates an SWF of those files with
>> dependencies.
>>
>> The SWF file is then used to write out the js using a JBurg bottom up
>> reducer/emitter. I am sure these were the classes you were looking at.
>>
>> The JSEmitter is something that probably could be hacked into but, I would
>> make sure you have a baseline before you do.
>>
>> The thing is, everytime I write about this framework I am learning more. It
>> seems to me the IBackend interface could be golden.
>>
>> If you look the Only time JSEmitter is created is in a call to;
>>
>> - JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
>>
>> This means we could swap out emitters at runtime! I still need to
>> investigate this further and don't take anything I say as gold right now,
>> I'm still learning myself.
>>
>> NOTE: The first thing I am going to experiement with is "how modular" the
>> IBackend really is and what it would enable us todo as far as creating
>> different implementations of emitters.
>>
>> Mike
>>
>>
>>
>>
>>
>>
>> - [0]
>> http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
>>
>>
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>> Mike,
>>>
>>> Can you explain a little bit (maybe in pseudo-code or whatever) about
>>> how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
>>> What I'm looking for is an idea of how the JS output is put together,
>>> if you will. Example: how easy (or difficult) is it to exchange one JS
>>> "class" creation method for another? Right now it's "Class =
>>> adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
>>> change that output to something like "function Class() { theClassBody
>>> }"?
>>>
>>> I did look at some of the Java classes that seemed relevant, but soon
>>> realised that without first having some idea of the concepts involved,
>>> "use the Force, read the source" wasn't going to be a useful way to
>>> spend my time ;-)
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
>>> <ap...@teotigraphix.com> wrote:
>>>>
>>>> It's not that you can't use a framework and "vanilla" js, it's that it
>>>> has
>>>> been shown that these candy frameworks that hide vanilla method calls to
>>>> the
>>>> DOM severely kill performance. ... For the sake of just entering a $()
>>>> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
>>>> alittle dev time saved, you kill the actual applications performance.
>>>>
>>>> I was just saying that using AS, you can already have a "framework" you
>>>> use
>>>> that is light, but the compiler would transcode it to the fastest
>>>> possible
>>>> js implementation, since it's now hands off.
>>>>
>>>> Mike
>>>>
>>>>
>>>> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>>>>
>>>>> Funniest site I've been to today. It's a good point, but it's prob
>>>>> pretty
>>>>> difficult to not use a framework at all.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>>>>> Mclean
>>>>> Sent: Wednesday, November 28, 2012 18:21
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: Re: [FalconJS] concepts
>>>>>
>>>>> Hi,
>>>>>
>>>>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>>>>> one:
>>>>>> http://jsperf.com/jqury-vs-plainjs
>>>>>
>>>>>
>>>>>
>>>>> Slightly off topic but amusing all the same:
>>>>> http://vanilla-js.com
>>>>>
>>>>> Reinforces the point that if you want pure performance don't use a
>>>>> framework and as we're generating the JS there's probably no need to use
>>>>> one, especially one as heavy as jQuery.
>>>>>
>>>>> Justin
>>>>>
>>>>>
>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
"The SWF file is then used to write out the js using a JBurg bottom up
reducer/emitter." ;-)
That means so little to me, while it probably explains everything to
someone with the proper background. I'll try to get some more
background, so I may be of some use when the time comes to start
hacking the JS output.
EdB
On Thu, Nov 29, 2012 at 2:22 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Well you may have missed it since this thread is going forever but I did
> write something [0]
>
> There was one concept I screwed up and that is in the end the loop and write
> doesn't happen on the monolithic SWF, I think it's for external files that
> were not linked into the main SWF.
>
> Basically, the compiler loads like MXMLC, using configuration files and args
> passed to it.
>
> It the parses all files and then creates an SWF of those files with
> dependencies.
>
> The SWF file is then used to write out the js using a JBurg bottom up
> reducer/emitter. I am sure these were the classes you were looking at.
>
> The JSEmitter is something that probably could be hacked into but, I would
> make sure you have a baseline before you do.
>
> The thing is, everytime I write about this framework I am learning more. It
> seems to me the IBackend interface could be golden.
>
> If you look the Only time JSEmitter is created is in a call to;
>
> - JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
>
> This means we could swap out emitters at runtime! I still need to
> investigate this further and don't take anything I say as gold right now,
> I'm still learning myself.
>
> NOTE: The first thing I am going to experiement with is "how modular" the
> IBackend really is and what it would enable us todo as far as creating
> different implementations of emitters.
>
> Mike
>
>
>
>
>
>
> - [0]
> http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
>
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Mike,
>>
>> Can you explain a little bit (maybe in pseudo-code or whatever) about
>> how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
>> What I'm looking for is an idea of how the JS output is put together,
>> if you will. Example: how easy (or difficult) is it to exchange one JS
>> "class" creation method for another? Right now it's "Class =
>> adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
>> change that output to something like "function Class() { theClassBody
>> }"?
>>
>> I did look at some of the Java classes that seemed relevant, but soon
>> realised that without first having some idea of the concepts involved,
>> "use the Force, read the source" wasn't going to be a useful way to
>> spend my time ;-)
>>
>> EdB
>>
>>
>>
>> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>> It's not that you can't use a framework and "vanilla" js, it's that it
>>> has
>>> been shown that these candy frameworks that hide vanilla method calls to
>>> the
>>> DOM severely kill performance. ... For the sake of just entering a $()
>>> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
>>> alittle dev time saved, you kill the actual applications performance.
>>>
>>> I was just saying that using AS, you can already have a "framework" you
>>> use
>>> that is light, but the compiler would transcode it to the fastest
>>> possible
>>> js implementation, since it's now hands off.
>>>
>>> Mike
>>>
>>>
>>> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>>>
>>>> Funniest site I've been to today. It's a good point, but it's prob
>>>> pretty
>>>> difficult to not use a framework at all.
>>>>
>>>> -----Original Message-----
>>>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>>>> Mclean
>>>> Sent: Wednesday, November 28, 2012 18:21
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: Re: [FalconJS] concepts
>>>>
>>>> Hi,
>>>>
>>>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>>>> one:
>>>>> http://jsperf.com/jqury-vs-plainjs
>>>>
>>>>
>>>>
>>>> Slightly off topic but amusing all the same:
>>>> http://vanilla-js.com
>>>>
>>>> Reinforces the point that if you want pure performance don't use a
>>>> framework and as we're generating the JS there's probably no need to use
>>>> one, especially one as heavy as jQuery.
>>>>
>>>> Justin
>>>>
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Well you may have missed it since this thread is going forever but I
did write something [0]
There was one concept I screwed up and that is in the end the loop and
write doesn't happen on the monolithic SWF, I think it's for external
files that were not linked into the main SWF.
Basically, the compiler loads like MXMLC, using configuration files
and args passed to it.
It the parses all files and then creates an SWF of those files with
dependencies.
The SWF file is then used to write out the js using a JBurg bottom up
reducer/emitter. I am sure these were the classes you were looking at.
The JSEmitter is something that probably could be hacked into but, I
would make sure you have a baseline before you do.
The thing is, everytime I write about this framework I am learning
more. It seems to me the IBackend interface could be golden.
If you look the Only time JSEmitter is created is in a call to;
- JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
This means we could swap out emitters at runtime! I still need to
investigate this further and don't take anything I say as gold right
now, I'm still learning myself.
NOTE: The first thing I am going to experiement with is "how modular"
the IBackend really is and what it would enable us todo as far as
creating different implementations of emitters.
Mike
- [0]
http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Mike,
>
> Can you explain a little bit (maybe in pseudo-code or whatever) about
> how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
> What I'm looking for is an idea of how the JS output is put together,
> if you will. Example: how easy (or difficult) is it to exchange one JS
> "class" creation method for another? Right now it's "Class =
> adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
> change that output to something like "function Class() { theClassBody
> }"?
>
> I did look at some of the Java classes that seemed relevant, but soon
> realised that without first having some idea of the concepts involved,
> "use the Force, read the source" wasn't going to be a useful way to
> spend my time ;-)
>
> EdB
>
>
>
> On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> It's not that you can't use a framework and "vanilla" js, it's that it has
>> been shown that these candy frameworks that hide vanilla method calls to the
>> DOM severely kill performance. ... For the sake of just entering a $()
>> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
>> alittle dev time saved, you kill the actual applications performance.
>>
>> I was just saying that using AS, you can already have a "framework" you use
>> that is light, but the compiler would transcode it to the fastest possible
>> js implementation, since it's now hands off.
>>
>> Mike
>>
>>
>> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>>
>>> Funniest site I've been to today. It's a good point, but it's prob pretty
>>> difficult to not use a framework at all.
>>>
>>> -----Original Message-----
>>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>>> Mclean
>>> Sent: Wednesday, November 28, 2012 18:21
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: [FalconJS] concepts
>>>
>>> Hi,
>>>
>>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>>> one:
>>>> http://jsperf.com/jqury-vs-plainjs
>>>
>>>
>>> Slightly off topic but amusing all the same:
>>> http://vanilla-js.com
>>>
>>> Reinforces the point that if you want pure performance don't use a
>>> framework and as we're generating the JS there's probably no need to use
>>> one, especially one as heavy as jQuery.
>>>
>>> Justin
>>>
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
Can you explain a little bit (maybe in pseudo-code or whatever) about
how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
What I'm looking for is an idea of how the JS output is put together,
if you will. Example: how easy (or difficult) is it to exchange one JS
"class" creation method for another? Right now it's "Class =
adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
change that output to something like "function Class() { theClassBody
}"?
I did look at some of the Java classes that seemed relevant, but soon
realised that without first having some idea of the concepts involved,
"use the Force, read the source" wasn't going to be a useful way to
spend my time ;-)
EdB
On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> It's not that you can't use a framework and "vanilla" js, it's that it has
> been shown that these candy frameworks that hide vanilla method calls to the
> DOM severely kill performance. ... For the sake of just entering a $()
> dollar sign? That's a crazy tradeoff but thousands do it everyday. For
> alittle dev time saved, you kill the actual applications performance.
>
> I was just saying that using AS, you can already have a "framework" you use
> that is light, but the compiler would transcode it to the fastest possible
> js implementation, since it's now hands off.
>
> Mike
>
>
> Quoting Kessler CTR Mark J <ma...@usmc.mil>:
>
>> Funniest site I've been to today. It's a good point, but it's prob pretty
>> difficult to not use a framework at all.
>>
>> -----Original Message-----
>> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin
>> Mclean
>> Sent: Wednesday, November 28, 2012 18:21
>> To: flex-dev@incubator.apache.org
>> Subject: Re: [FalconJS] concepts
>>
>> Hi,
>>
>>> And to eliminate the 'IF' from your conditional statement, just a quick
>>> one:
>>> http://jsperf.com/jqury-vs-plainjs
>>
>>
>> Slightly off topic but amusing all the same:
>> http://vanilla-js.com
>>
>> Reinforces the point that if you want pure performance don't use a
>> framework and as we're generating the JS there's probably no need to use
>> one, especially one as heavy as jQuery.
>>
>> Justin
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
It's not that you can't use a framework and "vanilla" js, it's that it
has been shown that these candy frameworks that hide vanilla method
calls to the DOM severely kill performance. ... For the sake of just
entering a $() dollar sign? That's a crazy tradeoff but thousands do
it everyday. For alittle dev time saved, you kill the actual
applications performance.
I was just saying that using AS, you can already have a "framework"
you use that is light, but the compiler would transcode it to the
fastest possible js implementation, since it's now hands off.
Mike
Quoting Kessler CTR Mark J <ma...@usmc.mil>:
> Funniest site I've been to today. It's a good point, but it's prob
> pretty difficult to not use a framework at all.
>
> -----Original Message-----
> From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of
> Justin Mclean
> Sent: Wednesday, November 28, 2012 18:21
> To: flex-dev@incubator.apache.org
> Subject: Re: [FalconJS] concepts
>
> Hi,
>
>> And to eliminate the 'IF' from your conditional statement, just a quick one:
>> http://jsperf.com/jqury-vs-plainjs
>
> Slightly off topic but amusing all the same:
> http://vanilla-js.com
>
> Reinforces the point that if you want pure performance don't use a
> framework and as we're generating the JS there's probably no need to
> use one, especially one as heavy as jQuery.
>
> Justin
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FalconJS] concepts
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Funniest site I've been to today. It's a good point, but it's prob pretty difficult to not use a framework at all.
-----Original Message-----
From: Justin Mclean [mailto:justinmclean@gmail.com] On Behalf Of Justin Mclean
Sent: Wednesday, November 28, 2012 18:21
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJS] concepts
Hi,
> And to eliminate the 'IF' from your conditional statement, just a quick one:
> http://jsperf.com/jqury-vs-plainjs
Slightly off topic but amusing all the same:
http://vanilla-js.com
Reinforces the point that if you want pure performance don't use a framework and as we're generating the JS there's probably no need to use one, especially one as heavy as jQuery.
Justin
Re: [FalconJS] concepts
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> And to eliminate the 'IF' from your conditional statement, just a quick one:
> http://jsperf.com/jqury-vs-plainjs
Slightly off topic but amusing all the same:
http://vanilla-js.com
Reinforces the point that if you want pure performance don't use a framework and as we're generating the JS there's probably no need to use one, especially one as heavy as jQuery.
Justin
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 1:35 AM, Daniel Wasilewski <de...@gmail.com>wrote:
> Man, what can I say, I love you :)
>
>
> On 11/29/2012 12:13 AM, Frank Wienberg wrote:
>
>> ...Open Flash Charts<http://jangaron.net/**ofc3/data-files/joo.html<http://jangaron.net/ofc3/data-files/joo.html>
>> >
>>
>
Thanks! :-)
Did you check out the animations, e.g. "pie-bug-green"? OFC uses a
tweening<https://code.google.com/p/tweener/>
library <https://code.google.com/p/tweener/>, completely written in AS3,
which again is using the (Joo)Flash API,
which again is drawing on an HTML5 canvas.
Despite of the many abstraction layers, it even works fast enough on an
iPad 2.
So why should we need jQuery animations?!
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Man, what can I say, I love you :)
On 11/29/2012 12:13 AM, Frank Wienberg wrote:
> On Thu, Nov 29, 2012 at 12:51 AM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> One question straight away after looking at your source code
>> implementation.
>>
>> Why did you have to implement custom display list for AS3 itself?
>>
> Do you mean JooFlash? Well, Adobe still did not open-source the Flash
> runtime, so we had to re-implement it. I wrote a tool that "screen-scraped"
> the whole FlashPlayer 11 API from the HTML ASDoc and reverse-engineers it
> into AS3 code -- of course API-only, and started to fill the gaps. As you
> can see, it suffices for several games, Box2D and Open Flash Charts, but
> not yet for Flex.
>
>
>> Was my assumption correct? That you were trying to bridge a gaps? If so,
>> how much effort it would be to do the same with mxml?
>>
>> Actually, I am currently working on MXML support for the Jangaroo
> compiler. Another case of redoing Adobe's work! ;-)
> But really, until now, we did not dare to dig into the Flex compiler code,
> and what I read in this mailing list is not very encouraging, too.
> Thus, so far, we kept our own compiler, which is much more light-weight and
> controllable (at least for us), but of course lacks some important features
> and is still not 100% compatible with mxmlc. However, we were able to take
> quite complex AS3 projects and recompile them without changing a single
> line of code, e.g. Open Flash
> Charts<http://jangaron.net/ofc3/data-files/joo.html>
> .
> More about this in my upcoming answer to Michael.
>
> -Frank-
>
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 12:51 AM, Daniel Wasilewski <de...@gmail.com>wrote:
> One question straight away after looking at your source code
> implementation.
>
> Why did you have to implement custom display list for AS3 itself?
>
Do you mean JooFlash? Well, Adobe still did not open-source the Flash
runtime, so we had to re-implement it. I wrote a tool that "screen-scraped"
the whole FlashPlayer 11 API from the HTML ASDoc and reverse-engineers it
into AS3 code -- of course API-only, and started to fill the gaps. As you
can see, it suffices for several games, Box2D and Open Flash Charts, but
not yet for Flex.
> Was my assumption correct? That you were trying to bridge a gaps? If so,
> how much effort it would be to do the same with mxml?
>
> Actually, I am currently working on MXML support for the Jangaroo
compiler. Another case of redoing Adobe's work! ;-)
But really, until now, we did not dare to dig into the Flex compiler code,
and what I read in this mailing list is not very encouraging, too.
Thus, so far, we kept our own compiler, which is much more light-weight and
controllable (at least for us), but of course lacks some important features
and is still not 100% compatible with mxmlc. However, we were able to take
quite complex AS3 projects and recompile them without changing a single
line of code, e.g. Open Flash
Charts<http://jangaron.net/ofc3/data-files/joo.html>
.
More about this in my upcoming answer to Michael.
-Frank-
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
One question straight away after looking at your source code implementation.
Why did you have to implement custom display list for AS3 itself?
Was my assumption correct? That you were trying to bridge a gaps? If so,
how much effort it would be to do the same with mxml?
Dan
On 11/28/2012 11:43 PM, Frank Wienberg wrote:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hi Frank,
I was just looking at your code today in GIT, all I can say is what a
great job coding that!!! Seriously I have always loved AS3 AST and
code generation I have some experience as well and I was actually
looking at your visitor/sink pattern today for ideas!
I have gone through your whole code generation framework today, I
would love to see if we could collaborate on something because you
have put so much work into it and obviously love ActionScript as well.
How do you think this project and your project could create some type
of symbiotic relationship without completely redoing each others
efforts?
Thanks for being so upfront, I think both project have the same goals.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
>
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
>
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
>
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Here we go! welcome on board :)
On 11/28/2012 11:43 PM, Frank Wienberg wrote:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I hate adding on to my own reply but I have on more comment on this.
As Dan and I were discussing and others as well, performance.
Obviously browser execution is top most priority but what about the
other performance not mentioned... the community contributions.
If you have something as complex as what FlaconJS is on the backend,
with 1 maybe two part time developers to push it forward only because
they are the only ones that understand it (JBurg, SWF). Then where
does this actually leav the performance of the project as a whole?
Dead locked in stale code as the months and years role by.
I'm usually not this passionate about something but, I think it would
be a serious mistake to count on FalconJS in it's current
implementation. I have years of experience in a different area then
the professional engineers, which just means maybe I have a unique
perspective here.
So bottom line is, I really think we need to think about whether the
current js generation of js or whatever other platform we do is
feasible to carry on into the future being maintained by developers
that may not have a computer science degree.
Long story short, by not choosing the correct implementation of the
cross compiler now, we could seriously be affecting the other
performance area of this project in the future, lets not neglect this
important area.
Go look at TypeScript's parser and emitters, they use the same visitor
pattern using straight AST!
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
> jangaroo/jooc/backend/JsCodeGenerator.java
>
> This is the exact pattern I was talking about implementing. I think
> it's so solid and you have done a great job at implementing it.
>
> As I have said in previous posts today, The way FalconJS digests
> it's AST is through SWF visitors. You are using straight AST from
> your parser.
>
> Folks, having Frank drop this line and the discussions going on at
> the moment, there are definitely a couple different paths that can
> be taken with producing javascript.
>
> If I have my way we would use an implementation like Franks, the
> problem with it as it stands in Apache is there is no infrastructure
> built like Frank has built, this is why the engineers used an SWF to
> represent that infrastructure.
>
> The problem with the current SWF/JBurg implementation is it VERY
> confusing for most developers. With Franks implementation I was able
> to understand what he was doing today within 20 minutes and could
> jump right in and start coding things. With the current FalconJS
> emitters there is no way that would happen.
>
> So, I would love to see if we could think about a common goal to
> energize both projects and see where one could help the other. I
> truly believe now by looking at the code BEFORE this post our
> projects have the exact same goal but can do different things.
>
> Mike
>
>
>
>
>
>
>
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> Hi folks,
>>
>> here is another "outsider" who would like to contribute to the JS runtime
>> format, if you are interested.
>> I am co-founder of the Open Source project Jangaroo, and as such have been
>> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
>> In response to Bernd Paradies blogging about FalconJS, I blogged about
>> "simulating ActionScript 3 language features" extensively:
>>
>> -
>>
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
>> -
>>
>> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
>> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
>> -
>>
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>>
>> All described solutions are actually implemented in the Jangaroo Runtime,
>> which takes care of the code translated from AS3 to JS by the Jangaroo
>> Compiler coming alive.
>> In principle, we follow the "classic route", with the exception of how we
>> simulate private members: see the first two blog posts.
>> At first look the Jangaroo Runtime may seem overly complex to you, but it
>> does many more things (class loading / dependency management; class
>> initialization = execute static code at the right time; allow keeping
>> generated JS code and source AS3 code as similar as possible; automatic
>> method binding / correct "this", etc.), and the concepts described in the
>> blob posts also work without these additional features.
>> The Jangaroo Compiler is written in Java and has a separate code generator
>> (well you obviously won't need the parser) which might be worth having a
>> look at:
>> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
>> If you dare to use Maven ;-), it is really easy to play around with our
>> code generation: Just set up your own projects within minutes, starting
>> from an example project like
>> https://github.com/fwienber/jooflash-app-template or
>> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>>
>> Greetings,
>> -Frank-
>>
>> Frank Wienberg
>> Software Architect & Jangaroo Evangelist
>>
>> *frank.wienberg@coremedia.com*
>>
>> * frank@jangaroo <fr...@jangaroo.net>.net*
>>
>> CoreMedia AG
>> content | context | conversion
>>
>> Ludwig-Erhard-Str. 18
>> 20459 Hamburg, Germany
>> www.coremedia.com
>>
>> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
>> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
>> Trade Register: Amtsgericht Hamburg, HR B 76277
>> --------------------------------------------------------
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Thanks for the pointer, Alex! I'll hand it on to Andreas Gawecki who is the
Jangaroo compiler guy.
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Right,
Yeah, comparing the old MXMLC compiler to Falcon MXMLC code base is
like going from a stone cave to a highrise building in terms of
engineering.
It uses JFlex to create the tokenizer so there is not lexer from antlr.
Anyway, others... I am not saying ditch work that has been done on
FalconJS and what it does, I'm going to experiment with Jangaroo and
there YEARS of development to see what I might come up with as far as
JS generation.
Besides in the end, there could always be "options". I want to be able
to work on coding something, this I can get right to work trying out
some ideas.
As with GCC, I haven't read enough about it but, sounds like I will
need to research it as well.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Thu, Nov 29, 2012 at 1:44 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> I bet if I had some time I could port some of your generation code using
>> the Falcon AST.
>
>
> Mike, that would be the way to go!
> I believe every word you say about the Falcon compiler, since my
> information about the Flex compiler is surely outdated. I guess they were
> not using ANTLR back then and the whole architecture has been cleaned up in
> the meantime.
> We wanted to have had a closer look recently, but honestly we did not know
> where to start.
> Sounds to me like in a common effort, it should be possible to join Falcon
> and Jangaroo's AST-based JS code generation! Wow!
>
> Concerning GCC, it is said to have the best compression factor in the
> market when using "advanced optimizations", which only work when providing
> the correct type hints, so we would have to generate these like Bernd
> proposed on his FalconJS blog. And GCC has some real cool features like it
> can output JavaScript source
> maps<http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/>,
> which again is the optimal way to support debugging generated JS code
> directly in the browser. However, for this feature, I would not run the
> generated JS code through GCC, but experimented with reusing their Java
> library for creating the source maps directly during code generation (this
> is on a branch called "source-maps" in the jangaroo-tools github project).
>
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 5:03 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> On Thu, Nov 29, 2012 at 1:44 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> I bet if I had some time I could port some of your generation code using
>> the Falcon AST.
>
>
> Mike, that would be the way to go!
> I believe every word you say about the Falcon compiler, since my
> information about the Flex compiler is surely outdated. I guess they were
> not using ANTLR back then and the whole architecture has been cleaned up in
> the meantime.
I'm not sure what Flex compiler source you looked at and when, but Falcon is
a complete rewrite. We tossed out the MXMLC code base that compiles every
Flex app to date. Falcon is still under development and yet to be released.
> We wanted to have had a closer look recently, but honestly we did not know
> where to start.
Start with the Falcon folder in Apache Flex SVN.
> Sounds to me like in a common effort, it should be possible to join Falcon
> and Jangaroo's AST-based JS code generation! Wow!
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 1:44 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> I bet if I had some time I could port some of your generation code using
> the Falcon AST.
Mike, that would be the way to go!
I believe every word you say about the Falcon compiler, since my
information about the Flex compiler is surely outdated. I guess they were
not using ANTLR back then and the whole architecture has been cleaned up in
the meantime.
We wanted to have had a closer look recently, but honestly we did not know
where to start.
Sounds to me like in a common effort, it should be possible to join Falcon
and Jangaroo's AST-based JS code generation! Wow!
Concerning GCC, it is said to have the best compression factor in the
market when using "advanced optimizations", which only work when providing
the correct type hints, so we would have to generate these like Bernd
proposed on his FalconJS blog. And GCC has some real cool features like it
can output JavaScript source
maps<http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/>,
which again is the optimal way to support debugging generated JS code
directly in the browser. However, for this feature, I would not run the
generated JS code through GCC, but experimented with reusing their Java
library for creating the source maps directly during code generation (this
is on a branch called "source-maps" in the jangaroo-tools github project).
-Frank-
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Totally agreed, Mike! We're facing a great opportunity, but also a big
> challenge.
> Adobe's code is, especially considering the lack of a language
> specification, the best you can get to parse ActionScript 3.
I have written an AS3.g (1600 lines) file with a rewrite tree, I know
how bad the language is. BTW, Falcon uses an antlr grammar for the
parser, did you know that?
However, when
> we (especially Andreas Gawecki, the original author of the Jangaroo
> compiler) looked at the Flex compiler code, we found it quite complex and
> wondered why no grammer / parser generator had been used. It all seems
> hand-coded. So we decided to stick with our compiler, at least for a while.
> Also, we did not want to emulate SWF / SWC, but rely on generated JS code +
> AS3 API stubs. All relevant tools can handle that very well: we use ASDoc
> and IntelliJ IDEA's ActionScript support successfully. We only had to
> create Jangaroo-specific build-tool support, namely a Maven plugin.
> So both compilers have their advantages, and we would like to unite them,
> but that seems like a long way to go.
I don't think so. The Falcon compiler has a two APIs, ast nodes(low
level) and definition nodes(high level). It is a very robust design.
> Can somebody explain why it is not easy or even not possible to use Falcon
> to create the AST and refactor the Jangaroo JSCodeGenerator from the
> Jangaroo-AST to the Falcon-AST to produce the JS output? I don't really get
> the SWF/JBurg part...
I think as far as AST we could do anything, I love the Falcon
compiler. I think the way JS is created AFTER the compile sucks.
I bet if I had some time I could port some of your generation code
using the Falcon AST.
Maybe there is a translation thing happening here, I didn't say that
it's not easy to create falcon AST, I said the processing step AFTER
AST creation is convoluted in my opinion. It's not accessible to the
average higher level dev.
JBurg is used to create a reducer and emitter for js source code.
> One thing that's good in FalconJS and missing in Jangaroo is to produce
> output that Google Closure Compiler can optimize well. I think it should
> not be too hard, but it seems to conflict with Jangaroo's goal to keep the
> output format as close as possible to the AS source code, and of course it
> has to be done.
I can't comment on this since I'm not to versed in JS.
Mike
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Totally agreed, Mike! We're facing a great opportunity, but also a big
challenge.
Adobe's code is, especially considering the lack of a language
specification, the best you can get to parse ActionScript 3. However, when
we (especially Andreas Gawecki, the original author of the Jangaroo
compiler) looked at the Flex compiler code, we found it quite complex and
wondered why no grammer / parser generator had been used. It all seems
hand-coded. So we decided to stick with our compiler, at least for a while.
Also, we did not want to emulate SWF / SWC, but rely on generated JS code +
AS3 API stubs. All relevant tools can handle that very well: we use ASDoc
and IntelliJ IDEA's ActionScript support successfully. We only had to
create Jangaroo-specific build-tool support, namely a Maven plugin.
So both compilers have their advantages, and we would like to unite them,
but that seems like a long way to go.
Can somebody explain why it is not easy or even not possible to use Falcon
to create the AST and refactor the Jangaroo JSCodeGenerator from the
Jangaroo-AST to the Falcon-AST to produce the JS output? I don't really get
the SWF/JBurg part...
One thing that's good in FalconJS and missing in Jangaroo is to produce
output that Google Closure Compiler can optimize well. I think it should
not be too hard, but it seems to conflict with Jangaroo's goal to keep the
output format as close as possible to the AS source code, and of course it
has to be done.
-Frank-
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 4:44 PM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> Dan,
>
> I am completely with you in ditching jQuery for FalconJS.
I'm not at all clear that the Jquery code path in the donation works. I'm
sure it did when Bernd did his demo, but I have not tested it in the
donation.
And I'm not particularly interested in using it either.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Dan,
I am completely with you in ditching jQuery for FalconJS. While we would
have to deal with some cross-browser issues ourselves, jQuery is mainly
tailored at providing convenience for JavaScript developers. That
convenience is not necessary for ActionScript/Flex developers, since many
features are already in the language, and others are in the libraries (e.g.
Flash DisplayList). For Jangaroo, we refrained from using any JavaScript
library, but only provide the basic browser APIs
(jangaroo-libs/jangaroo-browser) and, on top of these, I implemented a
large part of the Flash API, taking inspiration from Lightspark and
DartFlash. Well, one small library we do use is XMLHttpRequest, which is
rather a Polyfill than a library. Polyfills are okay. They just tame
browsers to behave like they should. But jQuery is much more than a
Polyfill!
-Frank-
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Yeah, sorry guys, it was quite late yesterday :)
On 11/29/2012 5:47 AM, Kevin Newman wrote:
> I believe that's Frank's blog. :)
>
> Kevin N.
>
>
> On 11/28/2012 7:28 PM, Daniel Wasilewski wrote:
>> But I know what the community is capable of, and seeing stuff like
>> jangaroo (I went trough Kevin's blog already, very good read) and
>> many initiatives I remember from the past, like make AS3 evaluators,
>> AST parsers etc. Flexibility of JS is vast, but the key to good
>> performance is one, stay native. Key for us is that we already have
>> an good structured environment. And Kevin, as the 1st comment on your
>> blog under
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
>
>
>
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
I believe that's Frank's blog. :)
Kevin N.
On 11/28/2012 7:28 PM, Daniel Wasilewski wrote:
> But I know what the community is capable of, and seeing stuff like
> jangaroo (I went trough Kevin's blog already, very good read) and many
> initiatives I remember from the past, like make AS3 evaluators, AST
> parsers etc. Flexibility of JS is vast, but the key to good
> performance is one, stay native. Key for us is that we already have an
> good structured environment. And Kevin, as the 1st comment on your
> blog under
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Well,
I'm not a compiler expert, have a basic undertaking of AST, parsing and
compiling it back to desire language.
In fact I didn't even grasp a Java side of FalconJS yet. But knowing the
Adobe way of doing things I wouldn't be surprised if somebody have it
worked out a better way.
Adobe itself stated many times, it is a concept, prototype, experiment.
I lost my attitude a bit by watching their presentation yesterday, when
the main developer presented so many layers involved in the entire
process. Including jQuery as support for animation and interactivity.
But I took a look at this as it was a cannon fodder for developers to
calm them down during a difficult PR time for them.
But I know what the community is capable of, and seeing stuff like
jangaroo (I went trough Kevin's blog already, very good read) and many
initiatives I remember from the past, like make AS3 evaluators, AST
parsers etc. Flexibility of JS is vast, but the key to good performance
is one, stay native. Key for us is that we already have an good
structured environment. And Kevin, as the 1st comment on your blog under
http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html.
We don't have to worry about violating fields of OOP so much, since we
are protected by language of the platform. But I see you guys have put a
lot of thinking and ideas in how to make the performance the best
possible. I am sure that ripping of the obstacles we can go even further.
Mike, if your assessment is correct and you see much bigger potential in
this. What can I say, the goal is the same, translate AS3 to JS. Does it
need to be falcon? This is what Adobe told/promised us, but...
Dan
On 11/29/2012 12:06 AM, Michael Schmalle wrote:
>
> jangaroo/jooc/backend/JsCodeGenerator.java
>
> This is the exact pattern I was talking about implementing. I think
> it's so solid and you have done a great job at implementing it.
>
> As I have said in previous posts today, The way FalconJS digests it's
> AST is through SWF visitors. You are using straight AST from your parser.
>
> Folks, having Frank drop this line and the discussions going on at the
> moment, there are definitely a couple different paths that can be
> taken with producing javascript.
>
> If I have my way we would use an implementation like Franks, the
> problem with it as it stands in Apache is there is no infrastructure
> built like Frank has built, this is why the engineers used an SWF to
> represent that infrastructure.
>
> The problem with the current SWF/JBurg implementation is it VERY
> confusing for most developers. With Franks implementation I was able
> to understand what he was doing today within 20 minutes and could jump
> right in and start coding things. With the current FalconJS emitters
> there is no way that would happen.
>
> So, I would love to see if we could think about a common goal to
> energize both projects and see where one could help the other. I truly
> believe now by looking at the code BEFORE this post our projects have
> the exact same goal but can do different things.
>
> Mike
>
>
>
>
>
>
>
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> Hi folks,
>>
>> here is another "outsider" who would like to contribute to the JS
>> runtime
>> format, if you are interested.
>> I am co-founder of the Open Source project Jangaroo, and as such have
>> been
>> dealing with JavaScript-to-ActionScript-3 compilation for several
>> years now.
>> In response to Bernd Paradies blogging about FalconJS, I blogged about
>> "simulating ActionScript 3 language features" extensively:
>>
>> -
>> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
>> -
>> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
>> -
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
>> -
>> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>>
>> All described solutions are actually implemented in the Jangaroo
>> Runtime,
>> which takes care of the code translated from AS3 to JS by the Jangaroo
>> Compiler coming alive.
>> In principle, we follow the "classic route", with the exception of
>> how we
>> simulate private members: see the first two blog posts.
>> At first look the Jangaroo Runtime may seem overly complex to you,
>> but it
>> does many more things (class loading / dependency management; class
>> initialization = execute static code at the right time; allow keeping
>> generated JS code and source AS3 code as similar as possible; automatic
>> method binding / correct "this", etc.), and the concepts described in
>> the
>> blob posts also work without these additional features.
>> The Jangaroo Compiler is written in Java and has a separate code
>> generator
>> (well you obviously won't need the parser) which might be worth having a
>> look at:
>> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
>>
>> If you dare to use Maven ;-), it is really easy to play around with our
>> code generation: Just set up your own projects within minutes, starting
>> from an example project like
>> https://github.com/fwienber/jooflash-app-template or
>> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>>
>> Greetings,
>> -Frank-
>>
>> Frank Wienberg
>> Software Architect & Jangaroo Evangelist
>>
>> *frank.wienberg@coremedia.com*
>>
>> * frank@jangaroo <fr...@jangaroo.net>.net*
>>
>> CoreMedia AG
>> content | context | conversion
>>
>> Ludwig-Erhard-Str. 18
>> 20459 Hamburg, Germany
>> www.coremedia.com
>>
>> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
>> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
>> Trade Register: Amtsgericht Hamburg, HR B 76277
>> --------------------------------------------------------
>>
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
jangaroo/jooc/backend/JsCodeGenerator.java
This is the exact pattern I was talking about implementing. I think
it's so solid and you have done a great job at implementing it.
As I have said in previous posts today, The way FalconJS digests it's
AST is through SWF visitors. You are using straight AST from your
parser.
Folks, having Frank drop this line and the discussions going on at the
moment, there are definitely a couple different paths that can be
taken with producing javascript.
If I have my way we would use an implementation like Franks, the
problem with it as it stands in Apache is there is no infrastructure
built like Frank has built, this is why the engineers used an SWF to
represent that infrastructure.
The problem with the current SWF/JBurg implementation is it VERY
confusing for most developers. With Franks implementation I was able
to understand what he was doing today within 20 minutes and could jump
right in and start coding things. With the current FalconJS emitters
there is no way that would happen.
So, I would love to see if we could think about a common goal to
energize both projects and see where one could help the other. I truly
believe now by looking at the code BEFORE this post our projects have
the exact same goal but can do different things.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi folks,
>
> here is another "outsider" who would like to contribute to the JS runtime
> format, if you are interested.
> I am co-founder of the Open Source project Jangaroo, and as such have been
> dealing with JavaScript-to-ActionScript-3 compilation for several years now.
> In response to Bernd Paradies blogging about FalconJS, I blogged about
> "simulating ActionScript 3 language features" extensively:
>
> -
>
> http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
> -
>
> http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
> - http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> -
>
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
>
> All described solutions are actually implemented in the Jangaroo Runtime,
> which takes care of the code translated from AS3 to JS by the Jangaroo
> Compiler coming alive.
> In principle, we follow the "classic route", with the exception of how we
> simulate private members: see the first two blog posts.
> At first look the Jangaroo Runtime may seem overly complex to you, but it
> does many more things (class loading / dependency management; class
> initialization = execute static code at the right time; allow keeping
> generated JS code and source AS3 code as similar as possible; automatic
> method binding / correct "this", etc.), and the concepts described in the
> blob posts also work without these additional features.
> The Jangaroo Compiler is written in Java and has a separate code generator
> (well you obviously won't need the parser) which might be worth having a
> look at:
> https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
> If you dare to use Maven ;-), it is really easy to play around with our
> code generation: Just set up your own projects within minutes, starting
> from an example project like
> https://github.com/fwienber/jooflash-app-template or
> https://github.com/CoreMedia/jangaroo-ext-as-examples .
>
> Greetings,
> -Frank-
>
> Frank Wienberg
> Software Architect & Jangaroo Evangelist
>
> *frank.wienberg@coremedia.com*
>
> * frank@jangaroo <fr...@jangaroo.net>.net*
>
> CoreMedia AG
> content | context | conversion
>
> Ludwig-Erhard-Str. 18
> 20459 Hamburg, Germany
> www.coremedia.com
>
> Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
> Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
> Trade Register: Amtsgericht Hamburg, HR B 76277
> --------------------------------------------------------
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi folks,
here is another "outsider" who would like to contribute to the JS runtime
format, if you are interested.
I am co-founder of the Open Source project Jangaroo, and as such have been
dealing with JavaScript-to-ActionScript-3 compilation for several years now.
In response to Bernd Paradies blogging about FalconJS, I blogged about
"simulating ActionScript 3 language features" extensively:
-
http://blog.jangaroo.net/2011/11/simulating-actionscript-in-javascript.html
-
http://blog.jangaroo.net/2011/12/simulating-actionscript-in-javascript.html
- http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
-
http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
All described solutions are actually implemented in the Jangaroo Runtime,
which takes care of the code translated from AS3 to JS by the Jangaroo
Compiler coming alive.
In principle, we follow the "classic route", with the exception of how we
simulate private members: see the first two blog posts.
At first look the Jangaroo Runtime may seem overly complex to you, but it
does many more things (class loading / dependency management; class
initialization = execute static code at the right time; allow keeping
generated JS code and source AS3 code as similar as possible; automatic
method binding / correct "this", etc.), and the concepts described in the
blob posts also work without these additional features.
The Jangaroo Compiler is written in Java and has a separate code generator
(well you obviously won't need the parser) which might be worth having a
look at:
https://github.com/CoreMedia/jangaroo-tools/blob/master/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java
If you dare to use Maven ;-), it is really easy to play around with our
code generation: Just set up your own projects within minutes, starting
from an example project like
https://github.com/fwienber/jooflash-app-template or
https://github.com/CoreMedia/jangaroo-ext-as-examples .
Greetings,
-Frank-
Frank Wienberg
Software Architect & Jangaroo Evangelist
*frank.wienberg@coremedia.com*
* frank@jangaroo <fr...@jangaroo.net>.net*
CoreMedia AG
content | context | conversion
Ludwig-Erhard-Str. 18
20459 Hamburg, Germany
www.coremedia.com
Executive Board: Gerrit Kolb (CEO), Dr. Klemens Kleiminger (CFO)
Supervisory Board: Prof. Dr. Florian Matthes (Chairman)
Trade Register: Amtsgericht Hamburg, HR B 76277
--------------------------------------------------------
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/28/2012 11:08 PM, Michael Schmalle wrote:
> That being said.
>
> I may be a complete idiot in thinking here but, why use a framework
> like jQuery if you have a framework in ActionScript.
>
> Now let me finish my thought, I know we arn't talking about using
> jQuery but we do have the compiler that can do "majic" when
> transcoding. So I agree that isn't it the best for us as a group to
> figure out the bare bones fasted possible javascript implementation
> and bend the compiler to service the needs of the performat code path?
>
I am trying hard to encourage people to answer positively on this
question :)
> The compiler is just a tool, it doesn't care how it compiles as to js.
>
> Pretty much what has been said in this thread is why I am still on
> this project. I don't even use ActionScript right now. But to think I
> could have a hand at helping an underdog take an implementation route
> that was not a "candy" route for gaining top followers is a great
> feeling. If this project gets started based on performance arguments
> it has a good chance at succeeding.
>
I do believe so. I am running my own project which is pretty much about
this, AS3 -> JS, but I would sacrifice it for the sake of seeing Flex
reborn on JS platform as a king of RIA again.
> Mike
>
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> Well,
>>
>> I feel like one, because only FalconJS subject activated me on this
>> list :)
>>
>> And to eliminate the 'IF' from your conditional statement, just a
>> quick one:
>>
>> http://jsperf.com/jqury-vs-plainjs
>>
>> Dan
>>
>> On 11/28/2012 10:26 PM, Michael Schmalle wrote:
>>> Hey,
>>>
>>> Your not an outsider, everything I have read of yours is golden. At
>>> least you are trying to explain this stuff to people who don't have
>>> a lot of js experience.
>>>
>>> If what you are saying about jQuery and performance is true then;
>>>
>>> "I do believe that it is possible to make a easy to develop
>>> environment and spit out efficient code on the other side.
>>> And not many ongoing development in this area has as much
>>> opportunity to get something done well as Apache has at the moment."
>>>
>>> I couldn't agree more. Sometimes being an infant has it's advantages
>>> in a new world because you don't have any bad habits yet!
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> Quoting Daniel Wasilewski <de...@gmail.com>:
>>>
>>>> I can spare my free time on this, Possibly not on Apache
>>>> contributor level because I am total noob when comes to it. I don't
>>>> even managed to set up my environment for flexSDK ;) But this is
>>>> because I've got AIR corrupted and some windows x86 redistributable
>>>> corupted libs blabla, the only reasonable solution is to go for
>>>> fresh Windows installation. Hell no...!! ;)
>>>>
>>>> I am not JS guru, but would like to get involved and do my best
>>>> even as outsider.
>>>> I was digging into JS for past year just to investigate the
>>>> possibilities. Mostly from performance point of view and mobile
>>>> development.
>>>>
>>>>
>>>> In regards to instanceof:
>>>>
>>>>
>>>> Here is something that haxe is using
>>>>
>>>> js.Boot.__instanceof = function(o,cl) {
>>>> try {
>>>> if(o instanceof cl) {
>>>> if(cl == Array) return o.__enum__ == null;
>>>> return true;
>>>> }
>>>> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
>>>> } catch( e ) {
>>>> if(cl == null) return false;
>>>> }
>>>> switch(cl) {
>>>> case Int:
>>>> return Math.ceil(o%2147483648.0) === o;
>>>> case Float:
>>>> return typeof(o) == "number";
>>>> case Bool:
>>>> return o === true || o === false;
>>>> case String:
>>>> return typeof(o) == "string";
>>>> case Dynamic:
>>>> return true;
>>>> default:
>>>> if(o == null) return false;
>>>> if(cl == Class && o.__name__ != null) return true; else null;
>>>> if(cl == Enum && o.__ename__ != null) return true; else null;
>>>> return o.__enum__ == cl;
>>>> }
>>>> }
>>>>
>>>>
>>>> having something like that implemented
>>>>
>>>> 'is' is as easy as:
>>>>
>>>> Std["is"] = function(v,t) {
>>>> return js.Boot.__instanceof(v,t);
>>>> }
>>>>
>>>> But obviously, it needs to live within rest of the sugar :).
>>>>
>>>> Are you able to provide the list of stuff/fields that compiler is
>>>> expecting to meet on the other side?
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>>>>
>>>>>
>>>>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> So, please tell me why not to go the classic route as a very
>>>>>> little overhaul
>>>>>> for the application that can be built on top of AS3/Flex?
>>>>>> This is bloody 3 classes with 4 methods in it, and we are not
>>>>>> talking here
>>>>>> about few % but tens.
>>>>>> It can only grow exponentially to the scale of your project.
>>>>> I don't know enough to have an reason not to go the classic
>>>>> route. But
>>>>> someone else will have to step up to do the work.
>>>>>
>>>>> That said, because we are cross compiling AS, does the classic
>>>>> route support
>>>>> as many features of AS, especially the reflection-oriented
>>>>> features? We
>>>>> want to try to compile business logic untouched and it might be
>>>>> using "is",
>>>>> "in", "instanceof", etc. Resig's blog seems to indicate that
>>>>> support for
>>>>> instanceOf was important and required all of that code.
>>>>>
>>>>>> Dan
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
That being said.
I may be a complete idiot in thinking here but, why use a framework
like jQuery if you have a framework in ActionScript.
Now let me finish my thought, I know we arn't talking about using
jQuery but we do have the compiler that can do "majic" when
transcoding. So I agree that isn't it the best for us as a group to
figure out the bare bones fasted possible javascript implementation
and bend the compiler to service the needs of the performat code path?
The compiler is just a tool, it doesn't care how it compiles as to js.
Pretty much what has been said in this thread is why I am still on
this project. I don't even use ActionScript right now. But to think I
could have a hand at helping an underdog take an implementation route
that was not a "candy" route for gaining top followers is a great
feeling. If this project gets started based on performance arguments
it has a good chance at succeeding.
Mike
Quoting Daniel Wasilewski <de...@gmail.com>:
> Well,
>
> I feel like one, because only FalconJS subject activated me on this list :)
>
> And to eliminate the 'IF' from your conditional statement, just a quick one:
>
> http://jsperf.com/jqury-vs-plainjs
>
> Dan
>
> On 11/28/2012 10:26 PM, Michael Schmalle wrote:
>> Hey,
>>
>> Your not an outsider, everything I have read of yours is golden. At
>> least you are trying to explain this stuff to people who don't have
>> a lot of js experience.
>>
>> If what you are saying about jQuery and performance is true then;
>>
>> "I do believe that it is possible to make a easy to develop
>> environment and spit out efficient code on the other side.
>> And not many ongoing development in this area has as much
>> opportunity to get something done well as Apache has at the moment."
>>
>> I couldn't agree more. Sometimes being an infant has it's
>> advantages in a new world because you don't have any bad habits yet!
>>
>>
>> Mike
>>
>>
>>
>>
>> Quoting Daniel Wasilewski <de...@gmail.com>:
>>
>>> I can spare my free time on this, Possibly not on Apache
>>> contributor level because I am total noob when comes to it. I
>>> don't even managed to set up my environment for flexSDK ;) But
>>> this is because I've got AIR corrupted and some windows x86
>>> redistributable corupted libs blabla, the only reasonable solution
>>> is to go for fresh Windows installation. Hell no...!! ;)
>>>
>>> I am not JS guru, but would like to get involved and do my best
>>> even as outsider.
>>> I was digging into JS for past year just to investigate the
>>> possibilities. Mostly from performance point of view and mobile
>>> development.
>>>
>>>
>>> In regards to instanceof:
>>>
>>>
>>> Here is something that haxe is using
>>>
>>> js.Boot.__instanceof = function(o,cl) {
>>> try {
>>> if(o instanceof cl) {
>>> if(cl == Array) return o.__enum__ == null;
>>> return true;
>>> }
>>> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
>>> } catch( e ) {
>>> if(cl == null) return false;
>>> }
>>> switch(cl) {
>>> case Int:
>>> return Math.ceil(o%2147483648.0) === o;
>>> case Float:
>>> return typeof(o) == "number";
>>> case Bool:
>>> return o === true || o === false;
>>> case String:
>>> return typeof(o) == "string";
>>> case Dynamic:
>>> return true;
>>> default:
>>> if(o == null) return false;
>>> if(cl == Class && o.__name__ != null) return true; else null;
>>> if(cl == Enum && o.__ename__ != null) return true; else null;
>>> return o.__enum__ == cl;
>>> }
>>> }
>>>
>>>
>>> having something like that implemented
>>>
>>> 'is' is as easy as:
>>>
>>> Std["is"] = function(v,t) {
>>> return js.Boot.__instanceof(v,t);
>>> }
>>>
>>> But obviously, it needs to live within rest of the sugar :).
>>>
>>> Are you able to provide the list of stuff/fields that compiler is
>>> expecting to meet on the other side?
>>>
>>> Dan
>>>
>>>
>>> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>>>
>>>>
>>>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>>>
>>>>> So, please tell me why not to go the classic route as a very
>>>>> little overhaul
>>>>> for the application that can be built on top of AS3/Flex?
>>>>> This is bloody 3 classes with 4 methods in it, and we are not
>>>>> talking here
>>>>> about few % but tens.
>>>>> It can only grow exponentially to the scale of your project.
>>>> I don't know enough to have an reason not to go the classic route. But
>>>> someone else will have to step up to do the work.
>>>>
>>>> That said, because we are cross compiling AS, does the classic
>>>> route support
>>>> as many features of AS, especially the reflection-oriented features? We
>>>> want to try to compile business logic untouched and it might be
>>>> using "is",
>>>> "in", "instanceof", etc. Resig's blog seems to indicate that support for
>>>> instanceOf was important and required all of that code.
>>>>
>>>>> Dan
>>>>
>>>
>>>
>>
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Well,
I feel like one, because only FalconJS subject activated me on this list :)
And to eliminate the 'IF' from your conditional statement, just a quick one:
http://jsperf.com/jqury-vs-plainjs
Dan
On 11/28/2012 10:26 PM, Michael Schmalle wrote:
> Hey,
>
> Your not an outsider, everything I have read of yours is golden. At
> least you are trying to explain this stuff to people who don't have a
> lot of js experience.
>
> If what you are saying about jQuery and performance is true then;
>
> "I do believe that it is possible to make a easy to develop
> environment and spit out efficient code on the other side.
> And not many ongoing development in this area has as much opportunity
> to get something done well as Apache has at the moment."
>
> I couldn't agree more. Sometimes being an infant has it's advantages
> in a new world because you don't have any bad habits yet!
>
>
> Mike
>
>
>
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> I can spare my free time on this, Possibly not on Apache contributor
>> level because I am total noob when comes to it. I don't even managed
>> to set up my environment for flexSDK ;) But this is because I've got
>> AIR corrupted and some windows x86 redistributable corupted libs
>> blabla, the only reasonable solution is to go for fresh Windows
>> installation. Hell no...!! ;)
>>
>> I am not JS guru, but would like to get involved and do my best even
>> as outsider.
>> I was digging into JS for past year just to investigate the
>> possibilities. Mostly from performance point of view and mobile
>> development.
>>
>>
>> In regards to instanceof:
>>
>>
>> Here is something that haxe is using
>>
>> js.Boot.__instanceof = function(o,cl) {
>> try {
>> if(o instanceof cl) {
>> if(cl == Array) return o.__enum__ == null;
>> return true;
>> }
>> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
>> } catch( e ) {
>> if(cl == null) return false;
>> }
>> switch(cl) {
>> case Int:
>> return Math.ceil(o%2147483648.0) === o;
>> case Float:
>> return typeof(o) == "number";
>> case Bool:
>> return o === true || o === false;
>> case String:
>> return typeof(o) == "string";
>> case Dynamic:
>> return true;
>> default:
>> if(o == null) return false;
>> if(cl == Class && o.__name__ != null) return true; else null;
>> if(cl == Enum && o.__ename__ != null) return true; else null;
>> return o.__enum__ == cl;
>> }
>> }
>>
>>
>> having something like that implemented
>>
>> 'is' is as easy as:
>>
>> Std["is"] = function(v,t) {
>> return js.Boot.__instanceof(v,t);
>> }
>>
>> But obviously, it needs to live within rest of the sugar :).
>>
>> Are you able to provide the list of stuff/fields that compiler is
>> expecting to meet on the other side?
>>
>> Dan
>>
>>
>> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>>
>>>
>>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>>
>>>> So, please tell me why not to go the classic route as a very little
>>>> overhaul
>>>> for the application that can be built on top of AS3/Flex?
>>>> This is bloody 3 classes with 4 methods in it, and we are not
>>>> talking here
>>>> about few % but tens.
>>>> It can only grow exponentially to the scale of your project.
>>> I don't know enough to have an reason not to go the classic route. But
>>> someone else will have to step up to do the work.
>>>
>>> That said, because we are cross compiling AS, does the classic route
>>> support
>>> as many features of AS, especially the reflection-oriented
>>> features? We
>>> want to try to compile business logic untouched and it might be
>>> using "is",
>>> "in", "instanceof", etc. Resig's blog seems to indicate that
>>> support for
>>> instanceOf was important and required all of that code.
>>>
>>>> Dan
>>>
>>
>>
>
Re: [FalconJS] concepts
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hey,
Your not an outsider, everything I have read of yours is golden. At
least you are trying to explain this stuff to people who don't have a
lot of js experience.
If what you are saying about jQuery and performance is true then;
"I do believe that it is possible to make a easy to develop
environment and spit out efficient code on the other side.
And not many ongoing development in this area has as much opportunity
to get something done well as Apache has at the moment."
I couldn't agree more. Sometimes being an infant has it's advantages
in a new world because you don't have any bad habits yet!
Mike
Quoting Daniel Wasilewski <de...@gmail.com>:
> I can spare my free time on this, Possibly not on Apache contributor
> level because I am total noob when comes to it. I don't even managed
> to set up my environment for flexSDK ;) But this is because I've got
> AIR corrupted and some windows x86 redistributable corupted libs
> blabla, the only reasonable solution is to go for fresh Windows
> installation. Hell no...!! ;)
>
> I am not JS guru, but would like to get involved and do my best even
> as outsider.
> I was digging into JS for past year just to investigate the
> possibilities. Mostly from performance point of view and mobile
> development.
>
>
> In regards to instanceof:
>
>
> Here is something that haxe is using
>
> js.Boot.__instanceof = function(o,cl) {
> try {
> if(o instanceof cl) {
> if(cl == Array) return o.__enum__ == null;
> return true;
> }
> if(js.Boot.__interfLoop(o.__class__,cl)) return true;
> } catch( e ) {
> if(cl == null) return false;
> }
> switch(cl) {
> case Int:
> return Math.ceil(o%2147483648.0) === o;
> case Float:
> return typeof(o) == "number";
> case Bool:
> return o === true || o === false;
> case String:
> return typeof(o) == "string";
> case Dynamic:
> return true;
> default:
> if(o == null) return false;
> if(cl == Class && o.__name__ != null) return true; else null;
> if(cl == Enum && o.__ename__ != null) return true; else null;
> return o.__enum__ == cl;
> }
> }
>
>
> having something like that implemented
>
> 'is' is as easy as:
>
> Std["is"] = function(v,t) {
> return js.Boot.__instanceof(v,t);
> }
>
> But obviously, it needs to live within rest of the sugar :).
>
> Are you able to provide the list of stuff/fields that compiler is
> expecting to meet on the other side?
>
> Dan
>
>
> On 11/28/2012 9:42 PM, Alex Harui wrote:
>>
>>
>> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> So, please tell me why not to go the classic route as a very
>>> little overhaul
>>> for the application that can be built on top of AS3/Flex?
>>> This is bloody 3 classes with 4 methods in it, and we are not talking here
>>> about few % but tens.
>>> It can only grow exponentially to the scale of your project.
>> I don't know enough to have an reason not to go the classic route. But
>> someone else will have to step up to do the work.
>>
>> That said, because we are cross compiling AS, does the classic route support
>> as many features of AS, especially the reflection-oriented features? We
>> want to try to compile business logic untouched and it might be using "is",
>> "in", "instanceof", etc. Resig's blog seems to indicate that support for
>> instanceOf was important and required all of that code.
>>
>>> Dan
>>
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
I can spare my free time on this, Possibly not on Apache contributor
level because I am total noob when comes to it. I don't even managed to
set up my environment for flexSDK ;) But this is because I've got AIR
corrupted and some windows x86 redistributable corupted libs blabla, the
only reasonable solution is to go for fresh Windows installation. Hell
no...!! ;)
I am not JS guru, but would like to get involved and do my best even as
outsider.
I was digging into JS for past year just to investigate the
possibilities. Mostly from performance point of view and mobile development.
In regards to instanceof:
Here is something that haxe is using
js.Boot.__instanceof = function(o,cl) {
try {
if(o instanceof cl) {
if(cl == Array) return o.__enum__ == null;
return true;
}
if(js.Boot.__interfLoop(o.__class__,cl)) return true;
} catch( e ) {
if(cl == null) return false;
}
switch(cl) {
case Int:
return Math.ceil(o%2147483648.0) === o;
case Float:
return typeof(o) == "number";
case Bool:
return o === true || o === false;
case String:
return typeof(o) == "string";
case Dynamic:
return true;
default:
if(o == null) return false;
if(cl == Class && o.__name__ != null) return true; else null;
if(cl == Enum && o.__ename__ != null) return true; else null;
return o.__enum__ == cl;
}
}
having something like that implemented
'is' is as easy as:
Std["is"] = function(v,t) {
return js.Boot.__instanceof(v,t);
}
But obviously, it needs to live within rest of the sugar :).
Are you able to provide the list of stuff/fields that compiler is
expecting to meet on the other side?
Dan
On 11/28/2012 9:42 PM, Alex Harui wrote:
>
>
> On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> So, please tell me why not to go the classic route as a very little overhaul
>> for the application that can be built on top of AS3/Flex?
>> This is bloody 3 classes with 4 methods in it, and we are not talking here
>> about few % but tens.
>> It can only grow exponentially to the scale of your project.
> I don't know enough to have an reason not to go the classic route. But
> someone else will have to step up to do the work.
>
> That said, because we are cross compiling AS, does the classic route support
> as many features of AS, especially the reflection-oriented features? We
> want to try to compile business logic untouched and it might be using "is",
> "in", "instanceof", etc. Resig's blog seems to indicate that support for
> instanceOf was important and required all of that code.
>
>> Dan
>
Re: [FalconJS] concepts
Posted by Kevin Newman <Ca...@unFocus.com>.
On 11/28/12 4:42 PM, Alex Harui wrote:
> I don't know enough to have an reason not to go the classic route. But
> someone else will have to step up to do the work.
Classic is the fastest for me (often by a lot) - at least in Firefox.
Maybe I'm missing some reason to go with the others?
> That said, because we are cross compiling AS, does the classic route support
> as many features of AS, especially the reflection-oriented features? We
> want to try to compile business logic untouched and it might be using "is",
> "in", "instanceof", etc. Resig's blog seems to indicate that support for
> instanceOf was important and required all of that code.
I don't think you need all that code, you can do this:
function BaseClass( yourVal ) {
this.someVal = yourVal;
}
BaseClass.prototype = {
myMethod: function() {
console.log( this.someVal );
}
};
function Extended( yourVal ) {
// super
BaseClass.apply( this, arguments );
this.someOtherVal = yourVal + " other";
}
Extended.prototype = Object.create( BaseClass.prototype ); // avoids
calling parent
Extended.prototype.myExtendedMethod = function() {
console.log( this.someOtherVal );
};
// override
Extended.prototype.myMethod = function() {
// super
BaseClass.prototype.myMethod.apply( this, arguments);
};
var ext = new Extended( "test" );
ext.myMethod(); // test
ext.myExtendedMethod(); // test other
ext instanceof BaseClass; // true
ext instanceof Extended; // true
Object.create is native in modern browsers, and has a simple polyfill
(for the relevant portions) for IE.
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create
Part of what John Resig was trying to do was to create editable and
writable classical inheritance from working within JS. FalconJS doesn't
have this constraint. We don't need to edit the generated Javascript
since the next AS3 compile would wipe out any changes anyway? Better to
make it fast (and besides, that's still readable, and you even could
edit it if you wanted).
Kevin N.
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 1:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
> So, please tell me why not to go the classic route as a very little overhaul
> for the application that can be built on top of AS3/Flex?
> This is bloody 3 classes with 4 methods in it, and we are not talking here
> about few % but tens.
> It can only grow exponentially to the scale of your project.
I don't know enough to have an reason not to go the classic route. But
someone else will have to step up to do the work.
That said, because we are cross compiling AS, does the classic route support
as many features of AS, especially the reflection-oriented features? We
want to try to compile business logic untouched and it might be using "is",
"in", "instanceof", etc. Resig's blog seems to indicate that support for
instanceOf was important and required all of that code.
>
> Dan
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Ok, both test are up to date including HaXe.
*Test of creation of this little structure*
http://jsperf.com/inheritance-yet-another-test/3
*Test of speed of accession already created objects*
http://jsperf.com/inheritance-yet-another-test/4
Which confirms what I have said before, that is a best out there but not
the best possible ;)
There was also a functionality test for all of them, not unit test really ;)
*//Classic*
//Just a Java like setters/getters for backward compatibility
var instanceA = new MySubSubClassA();
//Having public variable when setter/getter pattern is not needed it
shouldn't even be there, but this is just a test
instanceA.setName("James");
//instead of using setter we assigned it directly to public variable to
see if you can omit setters for public variables
instanceA.surname = "Bond";
console.log(instanceA.name); //expected undefined, because it's a
private field and not accessible from outside of prototypal chain.
It makes it perfect for hiding internals when getter/setter patterns
applies.
console.log(instanceA.surname); //Bond, because it's public
console.log(instanceA.getSurname()); //"my name is Bond", because getter
has been overridden in subclass
console.log(instanceA.getFullName()); //"James Bond"
*
**Output*
-::constructed
--::constructed
---::constructed
// to see if all Classes in the chain has been invoked on constructor in the correct order; Passed
undefined, as expected, private field not accessible
Bond
my name is Bond
James Bond
// All good here
*
**//adobe.js* I took only essence of it and renamed adobe to mod.
*Output
*
-::constructed
--::constructed
---::constructed
//super figured out, all good
James - it shouldn't be here! safety of module pattern fails ;)
It might not be considered as an issue since we don't really care about safety of output.
Bond
my name is Bond
JamesBond
*HaXe*
Same scenario like for other tests but I need to mention one thing here.
*IMPORTANT:*
I took just $extend model of HaXe, there is much more going on in the final output, also,
I kept the structure on the same level as the Main.hx class to avoid namespace issue.
otherwise instead:
var instanceC = new MyExExClassC();
var instanceC = new com.apache.flex.MyExExClassC();
not to mention that you have massive bunch of objects represents entire tree of your project like this:
var com = com || {}
if(!com.apache) com.apache = {}
if(!com.apache.flex) com.apache.flex = {}
com.apache.flex.MyClassC = function() {
};
com.apache.flex.MyClassC.__name__ = true;
com.apache.flex.MyClassC.prototype = {
setSurname: function(value) {
this.surname = value;
}
,getSurname: function() {
return this.surname;
}
,setName: function(value) {
this.name = value;
}
,getName: function() {
return this.name;
}
,__class__: com.apache.flex.MyClassC
}
That will slow down both test and I am sure adobe.js is the winner in this situation.
This very little thing destroys performance of everything. JavaScript is a shallow water friendly more than anything else.
And this very test does not represents real world example unless you crazy enough and keep your all classes next to Main.hx a t all time :)
*Output*
---::constructed
--::constructed
-::constructed
Reverse order of instantiation..!? interesting
James - same issue aka adobe'js. It might not be considered as an issue since we don't really care about safety of output.
Bond
my name is Bond
James Bond
this part is correct
So, please tell me why not to go the classic route as a very little overhaul for the application that can be built on top of AS3/Flex?
This is bloody 3 classes with 4 methods in it, and we are not talking here about few % but tens.
It can only grow exponentially to the scale of your project.
Dan
On 11/28/2012 8:26 PM, Markus Gritsch wrote:
> Hi everyone,
>
> Maybe someone can clarify the difference between haxe`s - as3-2-js output target and falcon-js. Both are producing js code. Haxe supports a collection of multiple output formats, too. Maybe the solution everyone is talking about is already out there - have???
>
> Thanks for your input
>
>
>
> On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
>
>> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> Ok will try again by changing a subject because you seems to moved away
>>> from original topic, and I don't want to interrupt :)
>>>
>>> So far I have a test to compare very simple model of prototypal
>>> inheritance and proposed module pattern that seems to be out of falconJS
>>> compiler little syntactic sugar.
>>> I have minimised this source a bit, there was few more additional fields
>>> that I guess something is depends on but even striping it out:
>>>
>>> http://jsperf.com/inheritance-yet-another-test/3
>>>
>>> If you go to the revision 2 of this test, there will be different
>>> comparison.
>>> http://jsperf.com/inheritance-yet-another-test/3
>>> Speed of accession of those objects.
>>>
>>> However I would like to improve it, because adobe.js implementation
>>> doesn't seems to call super as the classic does.
>>> So it might be not relevant test right now. Does anybody know how to
>>> call super from there?
>> It looks like in adobe.js around line 61 it tests to see if the super class
>> has the function and creates a _super function you can call.
>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Good point, I will try to add HaXe output to this test as well. But as
far as I can tell.
It was the best JS output out there but had some fundamental issues with
namespaces represented by object chain. I was playing around it a while ago.
Dan
On 11/28/2012 8:26 PM, Markus Gritsch wrote:
> Hi everyone,
>
> Maybe someone can clarify the difference between haxe`s - as3-2-js output target and falcon-js. Both are producing js code. Haxe supports a collection of multiple output formats, too. Maybe the solution everyone is talking about is already out there - have???
>
> Thanks for your input
>
>
>
> On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
>
>> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> Ok will try again by changing a subject because you seems to moved away
>>> from original topic, and I don't want to interrupt :)
>>>
>>> So far I have a test to compare very simple model of prototypal
>>> inheritance and proposed module pattern that seems to be out of falconJS
>>> compiler little syntactic sugar.
>>> I have minimised this source a bit, there was few more additional fields
>>> that I guess something is depends on but even striping it out:
>>>
>>> http://jsperf.com/inheritance-yet-another-test/3
>>>
>>> If you go to the revision 2 of this test, there will be different
>>> comparison.
>>> http://jsperf.com/inheritance-yet-another-test/3
>>> Speed of accession of those objects.
>>>
>>> However I would like to improve it, because adobe.js implementation
>>> doesn't seems to call super as the classic does.
>>> So it might be not relevant test right now. Does anybody know how to
>>> call super from there?
>> It looks like in adobe.js around line 61 it tests to see if the super class
>> has the function and creates a _super function you can call.
>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
Re: [FalconJS] concepts
Posted by Markus Gritsch <ma...@gmx.de>.
Hi everyone,
Maybe someone can clarify the difference between haxe`s - as3-2-js output target and falcon-js. Both are producing js code. Haxe supports a collection of multiple output formats, too. Maybe the solution everyone is talking about is already out there - have???
Thanks for your input
On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
>
> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> Ok will try again by changing a subject because you seems to moved away
>> from original topic, and I don't want to interrupt :)
>>
>> So far I have a test to compare very simple model of prototypal
>> inheritance and proposed module pattern that seems to be out of falconJS
>> compiler little syntactic sugar.
>> I have minimised this source a bit, there was few more additional fields
>> that I guess something is depends on but even striping it out:
>>
>> http://jsperf.com/inheritance-yet-another-test/3
>>
>> If you go to the revision 2 of this test, there will be different
>> comparison.
>> http://jsperf.com/inheritance-yet-another-test/3
>> Speed of accession of those objects.
>>
>> However I would like to improve it, because adobe.js implementation
>> doesn't seems to call super as the classic does.
>> So it might be not relevant test right now. Does anybody know how to
>> call super from there?
> It looks like in adobe.js around line 61 it tests to see if the super class
> has the function and creates a _super function you can call.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [FalconJS] concepts
Posted by Daniel Wasilewski <de...@gmail.com>.
Thanks for hint, I figured it out.
I was confused about it and was trying to call this._super.init();
but just this._super() inside the init does a job.
Here is speed of accession test
http://jsperf.com/inheritance-yet-another-test/4
Dan
On 11/28/2012 8:04 PM, Alex Harui wrote:
> On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> Ok will try again by changing a subject because you seems to moved away
>> from original topic, and I don't want to interrupt :)
>>
>> So far I have a test to compare very simple model of prototypal
>> inheritance and proposed module pattern that seems to be out of falconJS
>> compiler little syntactic sugar.
>> I have minimised this source a bit, there was few more additional fields
>> that I guess something is depends on but even striping it out:
>>
>> http://jsperf.com/inheritance-yet-another-test/3
>>
>> If you go to the revision 2 of this test, there will be different
>> comparison.
>> http://jsperf.com/inheritance-yet-another-test/3
>> Speed of accession of those objects.
>>
>> However I would like to improve it, because adobe.js implementation
>> doesn't seems to call super as the classic does.
>> So it might be not relevant test right now. Does anybody know how to
>> call super from there?
> It looks like in adobe.js around line 61 it tests to see if the super class
> has the function and creates a _super function you can call.
>
>
Re: [FalconJS] concepts
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 12:01 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> Ok will try again by changing a subject because you seems to moved away
> from original topic, and I don't want to interrupt :)
>
> So far I have a test to compare very simple model of prototypal
> inheritance and proposed module pattern that seems to be out of falconJS
> compiler little syntactic sugar.
> I have minimised this source a bit, there was few more additional fields
> that I guess something is depends on but even striping it out:
>
> http://jsperf.com/inheritance-yet-another-test/3
>
> If you go to the revision 2 of this test, there will be different
> comparison.
> http://jsperf.com/inheritance-yet-another-test/3
> Speed of accession of those objects.
>
> However I would like to improve it, because adobe.js implementation
> doesn't seems to call super as the classic does.
> So it might be not relevant test right now. Does anybody know how to
> call super from there?
It looks like in adobe.js around line 61 it tests to see if the super class
has the function and creates a _super function you can call.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui