You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/11/23 22:01:54 UTC
FalconJS has landed
It is in the falcon folder under trunk/compiler.js.
Happy cross-compiling!
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
Hmm... I just actually managed to see that keynote to the very end.
http://tv.adobe.com/watch/flex-community-summit-december-2011/open-discussion-about-falcon-and-falconjs
And if you can't see that full responsibility of success of this project
(due to Adobe representatives attitude and goal) is all on your
shoulders, and is up to you what you can do with it... I just lost my
attitude after watching this material to be honest. I am very
appreciated that people from adobe working on it are still here for this
hand over process and contributing their time and effort, after what I
have seen. Thank you for your hard work. It has to be be hard.
On 11/27/2012 11:20 PM, Dasa Paddock wrote:
> The original developer of FalconJS seems to have lots of good information about it and the things he considered in blog posts at:
> http://blogs.adobe.com/bparadie/tag/falconjs/page/4/
>
> I didn't find a good list of just the relevant posts, but they all seem to be available at the link above if you start there and click the "Previous" button on the bottom of the page.
>
> --Dasa
>
> On Nov 23, 2012, at 1:01 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> It is in the falcon folder under trunk/compiler.js.
>>
>> Happy cross-compiling!
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Igor Costa <ig...@gmail.com>.
Kudos do Gordon and the left team.
If you guys want diff way of literals or sort of, dig into the code, make a
patch and send to us.
We'd love to see inovation.
----------------------------
Igor Costa
On Wed, Nov 28, 2012 at 3:29 AM, Alex Harui <ah...@adobe.com> wrote:
> Keep in mind that not all of the code you see in the demo was donated.
> There is no flash API emulation, only AST to JS.
>
>
> On 11/27/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
> > And in this article there is a link to:
> >
> >
> http://tv.adobe.com/watch/flex-community-summit-december-2011/open-discussion-
> > about-falcon-and-falconjs
> >
> > Just seek to frame 4:46 and in front of your eyes:
> >
> > Pros:
> > supported existing Flex SDK
> > leverage FB tooling
> >
> > Cons:
> > Not as HTMLey' SEO
> > *potentially not as fast*
> > harder to leverage future HTML tooling
> >
> > In Pros section, I do not care about FB at all.
> >
> > In Cons section
> > Not as HTMLey' SEO - can be done
> > *potentially not as fast* - main biggest concern, and in current state
> > not potentially, but for sure!
> > harder to leverage future HTML tooling - Apache Flex + FlaconJS have
> > opportunity and potential to become future tooling of HTML
> >
> > Dan
> >
> > On 11/27/2012 11:20 PM, Dasa Paddock wrote:
> >> The original developer of FalconJS seems to have lots of good
> information
> >> about it and the things he considered in blog posts at:
> >> http://blogs.adobe.com/bparadie/tag/falconjs/page/4/
> >>
> >> I didn't find a good list of just the relevant posts, but they all seem
> to be
> >> available at the link above if you start there and click the "Previous"
> >> button on the bottom of the page.
> >>
> >> --Dasa
> >>
> >> On Nov 23, 2012, at 1:01 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>> It is in the falcon folder under trunk/compiler.js.
> >>>
> >>> Happy cross-compiling!
> >>>
> >>> --
> >>> Alex Harui
> >>> Flex SDK Team
> >>> Adobe Systems, Inc.
> >>> http://blogs.adobe.com/aharui
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
The one that Kevin proposed below (jangaroo) and you keep talking about
licensing it :).
Sorry if that wasn't clear but trying follow the wave here.
Dan
On 11/28/2012 6:50 PM, Alex Harui wrote:
>
>
> On 11/28/12 10:35 AM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> What I have noticed up there as well, this project not only have JS bits
>> implemented to mimic flash player, but Action Script bits as well with
>> lots of missing features.
>> I see the point behind this idea, and the guys were trying to find a
>> common ground between both platforms. But ended up rewriting code for
>> both platforms.
>>
>> I am not sure this is what we need, don't we? I saw potential behind
>> FalconJS to at least make this heavy lifting on AST level as the common
>> ground. Otherwise will go back to project I am doing, which is pretty
>> much jangaroo approach as well, but philosophy and implementation behind
>> it differ.
> I'm not sure what project you are referring to, but at this time, we're at
> such an early stage, I would encourage folks to try different angles. I
> have mine and am eager to have folks help shape it, but that doesn't mean
> other approaches should not be explored.
>
>> Dan
>>
>> On 11/28/2012 6:09 PM, Kevin Newman wrote:
>>> Anyway, a lot of the current popular plan seems to revolve around
>>> doing direct bindings from Flex into JS/DOM objects and not using a
>>> Flash layer at all, so it does seem like it may not be needed. Still,
>>> it seems like an option, and there is useful core items in there, like
>>> BitmapData, etc. that are already implemented.
>>>
>>> Maybe the legal overhead outweighs the benefits of an already
>>> completed code base?
>>>
>>> Kevin N.
>>>
>>>
>>> On 11/28/12 12:47 PM, Alex Harui wrote:
>>>> I don't think we need it. But if folks want to try, they need to
>>>> make sure
>>>> it is legally ok with Apache if we do so.
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 10:35 AM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> What I have noticed up there as well, this project not only have JS bits
> implemented to mimic flash player, but Action Script bits as well with
> lots of missing features.
> I see the point behind this idea, and the guys were trying to find a
> common ground between both platforms. But ended up rewriting code for
> both platforms.
>
> I am not sure this is what we need, don't we? I saw potential behind
> FalconJS to at least make this heavy lifting on AST level as the common
> ground. Otherwise will go back to project I am doing, which is pretty
> much jangaroo approach as well, but philosophy and implementation behind
> it differ.
I'm not sure what project you are referring to, but at this time, we're at
such an early stage, I would encourage folks to try different angles. I
have mine and am eager to have folks help shape it, but that doesn't mean
other approaches should not be explored.
> Dan
>
> On 11/28/2012 6:09 PM, Kevin Newman wrote:
>> Anyway, a lot of the current popular plan seems to revolve around
>> doing direct bindings from Flex into JS/DOM objects and not using a
>> Flash layer at all, so it does seem like it may not be needed. Still,
>> it seems like an option, and there is useful core items in there, like
>> BitmapData, etc. that are already implemented.
>>
>> Maybe the legal overhead outweighs the benefits of an already
>> completed code base?
>>
>> Kevin N.
>>
>>
>> On 11/28/12 12:47 PM, Alex Harui wrote:
>>> I don't think we need it. But if folks want to try, they need to
>>> make sure
>>> it is legally ok with Apache if we do so.
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
What I have noticed up there as well, this project not only have JS bits
implemented to mimic flash player, but Action Script bits as well with
lots of missing features.
I see the point behind this idea, and the guys were trying to find a
common ground between both platforms. But ended up rewriting code for
both platforms.
I am not sure this is what we need, don't we? I saw potential behind
FalconJS to at least make this heavy lifting on AST level as the common
ground. Otherwise will go back to project I am doing, which is pretty
much jangaroo approach as well, but philosophy and implementation behind
it differ.
Dan
On 11/28/2012 6:09 PM, Kevin Newman wrote:
> Anyway, a lot of the current popular plan seems to revolve around
> doing direct bindings from Flex into JS/DOM objects and not using a
> Flash layer at all, so it does seem like it may not be needed. Still,
> it seems like an option, and there is useful core items in there, like
> BitmapData, etc. that are already implemented.
>
> Maybe the legal overhead outweighs the benefits of an already
> completed code base?
>
> Kevin N.
>
>
> On 11/28/12 12:47 PM, Alex Harui wrote:
>> I don't think we need it. But if folks want to try, they need to
>> make sure
>> it is legally ok with Apache if we do so.
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/28/12 10:09 AM, "Kevin Newman" <Ca...@unFocus.com> wrote:
> What's required for the legal ok? Is that like a full copyright/patent
> audit? Or is it more of checking the license requirements, or getting
> signoff from the current copyright holder? Or both? Or something else? :-)
>
> It's already licensed under Apache 2.0, so that's a good start.
If it is under Apache license, then all we need is a software grant from the
owner.
But we can certainly use it without modification as an external dependency
today.
>
> Anyway, a lot of the current popular plan seems to revolve around doing
> direct bindings from Flex into JS/DOM objects and not using a Flash
> layer at all, so it does seem like it may not be needed. Still, it seems
> like an option, and there is useful core items in there, like
> BitmapData, etc. that are already implemented.
>
> Maybe the legal overhead outweighs the benefits of an already completed
> code base?
Well, I'm not currently seeing a need for it, but if other folks do, they
have to weigh the tradeoffs and make their own decision.
>
> Kevin N.
>
>
> On 11/28/12 12:47 PM, Alex Harui wrote:
>> I don't think we need it. But if folks want to try, they need to make sure
>> it is legally ok with Apache if we do so.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Kevin Newman <Ca...@unFocus.com>.
What's required for the legal ok? Is that like a full copyright/patent
audit? Or is it more of checking the license requirements, or getting
signoff from the current copyright holder? Or both? Or something else? :-)
It's already licensed under Apache 2.0, so that's a good start.
Anyway, a lot of the current popular plan seems to revolve around doing
direct bindings from Flex into JS/DOM objects and not using a Flash
layer at all, so it does seem like it may not be needed. Still, it seems
like an option, and there is useful core items in there, like
BitmapData, etc. that are already implemented.
Maybe the legal overhead outweighs the benefits of an already completed
code base?
Kevin N.
On 11/28/12 12:47 PM, Alex Harui wrote:
> I don't think we need it. But if folks want to try, they need to make sure
> it is legally ok with Apache if we do so.
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
I don't think we need it. But if folks want to try, they need to make sure
it is legally ok with Apache if we do so.
On 11/28/12 8:30 AM, "Kevin Newman" <Ca...@unFocus.com> wrote:
> Here are theAS3 -> JS externs that Jangaroo's AS3 Flash API is built on:
> https://github.com/CoreMedia/jangaroo-libs/tree/master/jangaroo-browser/src/ma
> in/joo/js
>
> Kevin N.
>
>
> On 11/28/12 11:04 AM, Kevin Newman wrote:
>> Could always use (easiest) or port Jangaroo's implementation (it's
>> written in AS3 - might even be able to port it to compile under
>> FalconJS).
>>
>> https://github.com/CoreMedia/jangaroo-libs/tree/master/jooflash/src/main/joo
>>
>>
>> Kevin N.
>>
>>
>> On 11/28/12 12:29 AM, Alex Harui wrote:
>>> There is no flash API emulation
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Kevin Newman <Ca...@unFocus.com>.
Here are theAS3 -> JS externs that Jangaroo's AS3 Flash API is built on:
https://github.com/CoreMedia/jangaroo-libs/tree/master/jangaroo-browser/src/main/joo/js
Kevin N.
On 11/28/12 11:04 AM, Kevin Newman wrote:
> Could always use (easiest) or port Jangaroo's implementation (it's
> written in AS3 - might even be able to port it to compile under
> FalconJS).
>
> https://github.com/CoreMedia/jangaroo-libs/tree/master/jooflash/src/main/joo
>
>
> Kevin N.
>
>
> On 11/28/12 12:29 AM, Alex Harui wrote:
>> There is no flash API emulation
>
Re: FalconJS has landed
Posted by Kevin Newman <Ca...@unFocus.com>.
Could always use (easiest) or port Jangaroo's implementation (it's
written in AS3 - might even be able to port it to compile under FalconJS).
https://github.com/CoreMedia/jangaroo-libs/tree/master/jooflash/src/main/joo
Kevin N.
On 11/28/12 12:29 AM, Alex Harui wrote:
> There is no flash API emulation
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
Keep in mind that not all of the code you see in the demo was donated.
There is no flash API emulation, only AST to JS.
On 11/27/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> And in this article there is a link to:
>
> http://tv.adobe.com/watch/flex-community-summit-december-2011/open-discussion-
> about-falcon-and-falconjs
>
> Just seek to frame 4:46 and in front of your eyes:
>
> Pros:
> supported existing Flex SDK
> leverage FB tooling
>
> Cons:
> Not as HTMLey' SEO
> *potentially not as fast*
> harder to leverage future HTML tooling
>
> In Pros section, I do not care about FB at all.
>
> In Cons section
> Not as HTMLey' SEO - can be done
> *potentially not as fast* - main biggest concern, and in current state
> not potentially, but for sure!
> harder to leverage future HTML tooling - Apache Flex + FlaconJS have
> opportunity and potential to become future tooling of HTML
>
> Dan
>
> On 11/27/2012 11:20 PM, Dasa Paddock wrote:
>> The original developer of FalconJS seems to have lots of good information
>> about it and the things he considered in blog posts at:
>> http://blogs.adobe.com/bparadie/tag/falconjs/page/4/
>>
>> I didn't find a good list of just the relevant posts, but they all seem to be
>> available at the link above if you start there and click the "Previous"
>> button on the bottom of the page.
>>
>> --Dasa
>>
>> On Nov 23, 2012, at 1:01 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> It is in the falcon folder under trunk/compiler.js.
>>>
>>> Happy cross-compiling!
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
And in this article there is a link to:
http://tv.adobe.com/watch/flex-community-summit-december-2011/open-discussion-about-falcon-and-falconjs
Just seek to frame 4:46 and in front of your eyes:
Pros:
supported existing Flex SDK
leverage FB tooling
Cons:
Not as HTMLey' SEO
*potentially not as fast*
harder to leverage future HTML tooling
In Pros section, I do not care about FB at all.
In Cons section
Not as HTMLey' SEO - can be done
*potentially not as fast* - main biggest concern, and in current state
not potentially, but for sure!
harder to leverage future HTML tooling - Apache Flex + FlaconJS have
opportunity and potential to become future tooling of HTML
Dan
On 11/27/2012 11:20 PM, Dasa Paddock wrote:
> The original developer of FalconJS seems to have lots of good information about it and the things he considered in blog posts at:
> http://blogs.adobe.com/bparadie/tag/falconjs/page/4/
>
> I didn't find a good list of just the relevant posts, but they all seem to be available at the link above if you start there and click the "Previous" button on the bottom of the page.
>
> --Dasa
>
> On Nov 23, 2012, at 1:01 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> It is in the falcon folder under trunk/compiler.js.
>>
>> Happy cross-compiling!
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Dasa Paddock <dp...@esri.com>.
The original developer of FalconJS seems to have lots of good information about it and the things he considered in blog posts at:
http://blogs.adobe.com/bparadie/tag/falconjs/page/4/
I didn't find a good list of just the relevant posts, but they all seem to be available at the link above if you start there and click the "Previous" button on the bottom of the page.
--Dasa
On Nov 23, 2012, at 1:01 PM, Alex Harui <ah...@adobe.com> wrote:
> It is in the falcon folder under trunk/compiler.js.
>
> Happy cross-compiling!
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Nice, thank you!
EdB
On Tue, Nov 27, 2012 at 6:13 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/27/12 12:06 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> Alex,
>>
>> You keep referring to a "prototype". I might be missing something.
>> Where can I find it/how do I run it?
>>
> I need management sign off before I can check it in. One of the managers
> returns from vacation today so hopefully you will see it today or tomorrow.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Kevin Newman <Ca...@unFocus.com>.
On 11/27/12 2:11 PM, Daniel Wasilewski wrote:
> On 11/27/2012 6:36 PM, Kevin Newman wrote:
>> definitions be outside the testing loop
> Very good point :)
>
> Just modified this test up there
> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/5
>
> And will prepare the one, that has inheritance involved as well.
>
> Dan
The results are very different now. :-)
Kevin N.
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
On 11/27/2012 6:36 PM, Kevin Newman wrote:
> definitions be outside the testing loop
Very good point :)
Just modified this test up there
http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/5
And will prepare the one, that has inheritance involved as well.
Dan
Re: FalconJS has landed
Posted by Kevin Newman <Ca...@unFocus.com>.
Shouldn't the Function (class) definitions be outside the testing loop?
Kevin N.
Re: FalconJS has landed
Posted by Kevin Newman <Ca...@unFocus.com>.
On 11/27/12 5:56 PM, Daniel Wasilewski wrote:
>
> However, when comes to FalconJS the task is to use strict proper OOP
> language like AS3 to translate into JS. In my humble opinion, this is
> what is all about, to protect us and give us more robust development
> environment and target the platform we need without writing FOR the
> platform. The fact that we are using AS3, output doesn't need to
> leverage all those concepts on the target level at all. Even if the
> output code would be set of plain objects or procedural style chain of
> objects, if better for performance and the final result, better for
> everyone. Good for marketing Apache Flex JS as the robust environment,
> web RIA development environment.
I agree, and I can't see how you'd emulate certain things in a clean way
anway - like protected or internal class members. You can kinda do
privates with closures and literals, but you lose a bunch of stuff, like
instanceof, it uses more memory, and it's actually slower at runtime
(even if definition - boot up - is a bit faster).
As for perf tests, maybe throw one of these in there:
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
constructing parent
Extended.prototype.myExtendedMethod = function() {
console.log( this.someOtherVal );
};
var ext = new Extended( "test" );
ext.myMethod(); // test
ext.myExtendedMethod(); // test other
ext instanceof BaseClass; // true
ext instanceof Extended; // true
That's the closest I think you can get to classical inheritance in pure
JS (you'll need to polyfill Object.create for IE), while maintaining the
prototype chain.
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/create
Kevin N.
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
No no, don't shout up :) keep going.
I have read the article provided by you carefully.
If you will copy and paste it, and prepare a little function to
find/replace this sentence
"The simplest way to create a module in JavaScript is to use an *object
literal"* with "*prototype*"
The rest of above that sentence seems to be perfect.
Anything below is just a consequence of statement.
In JS word you will find bunch of old school JScripters they will
advocate and stands for the one thing:
Why on earth language that have a 'globals' concept needs a Singleton
pattern? The only thing/feature that can come to mind of proper OOP
language developer like C#, Java, AS3 is safety. We understand a concept
of public, final, abstract, private, protected. When writing API for
others to reuse it is even more important to use all advantage of those
languages. How many times in AS3 we using abstract or singleton
regardless of lack of native support? Because we do understand
importance of strict and structured language in rapid development.
However, when comes to FalconJS the task is to use strict proper OOP
language like AS3 to translate into JS. In my humble opinion, this is
what is all about, to protect us and give us more robust development
environment and target the platform we need without writing FOR the
platform. The fact that we are using AS3, output doesn't need to
leverage all those concepts on the target level at all. Even if the
output code would be set of plain objects or procedural style chain of
objects, if better for performance and the final result, better for
everyone. Good for marketing Apache Flex JS as the robust environment,
web RIA development environment.
P.S.
I took a break after my previous email, but I will definitely do some
JSperf test for tomorrow with inheritance, to show a full picture.
Dan
On 11/27/2012 7:46 PM, Erik de Bruin wrote:
> One more thought (yes, I really can't help myself):
>
> Google chose to go with closures (obviously), and I'm sure they care
> about all the stuff you mention... And I'd say they have some
> experience with building and maintaining large javascript projects. As
> does Yahoo (YUI), jQuery and I'm sure others as well. They most likely
> did their due diligence before choosing this technique over the
> others, something we could benefit from.
>
> A good place - albeit a bit random - to start reading about the
> benefits of the approach I am advocating is:
>
> http://www.examplejs.com/?p=250
>
> Ok, I'll shut up now ;-)
>
> EdB
>
>
>
>
> On Tue, Nov 27, 2012 at 7:23 PM, Daniel Wasilewski <de...@gmail.com> wrote:
>> Erik,
>>
>> If you don't care about memory consumption, output file size, long prototype
>> chain, inheritance, slow downs on bigger structures than 1 plain objects...
>> use it.
>> Again, not saying let's prefer or favour one of the method over another,
>> those things keeps changing over the time.
>> This test just 2 years ago would be a different picture.
>>
>> All I am saying is to have ability to control he output of grammar of JS. I
>> know my English is not perfect but that's my only point i am trying to make.
>> If you feel it's endless... sorry. It wasn't my intention to make it long.
>> But rather invite to constructive discussion. It is easy to say NO to
>> solution I think doesn't suits me without giving any reason.
>>
>> I would like to hear about pros of module pattern myself. Prove me wrong, I
>> will shout up :)
>> I am not JS expert. But let's not make design decisions based on the latests
>> trends, but technical reasoning.
>>
>> Dan
>>
>>
>> On 11/27/2012 4:38 PM, Erik de Bruin wrote:
>>> Dan,
>>>
>>> This is my last comment on the subject, as I foresee another endless
>>> discussion, but:
>>>
>>> Closure (Module Pattern) outperforms any other 'style' at least 2 to 1
>>> on the test you quote, yet you recommend that we don't use it?
>>>
>>> EdB
>>>
>>>
>>>
>>> On Tue, Nov 27, 2012 at 5:22 PM, Daniel Wasilewski <de...@gmail.com>
>>> wrote:
>>>> I'll try to help Alex :)
>>>> But he may correct me if I am wrong.
>>>>
>>>>
>>>> I believe this little test will show full picture and all 4 common styles
>>>> of
>>>> JS programming we are talking about here.
>>>>
>>>> Notice there is nothing about inheritance, just plain objects (classes)
>>>> Once inheritance is involved things are slowing down with different
>>>> ratios.
>>>>
>>>> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
>>>>
>>>> Current proposed style of JS output is Object Literal (red bar in that
>>>> test);
>>>> Prototype (green bar) in plain object test seems to be 2nd solution
>>>> outperformed by closure (blue bar) these days.
>>>>
>>>> But when inheritance is involved blue bar is getting shorter and
>>>> prototype
>>>> is catching up.
>>>> Prototype pattern has also less footprint, since you adding 1 shared
>>>> behaviour to your object that will be reused wherever possible instead
>>>> creating brand new object.
>>>>
>>>> There is no surprise why Closure style runs very well on web kit based
>>>> browsers since Google promoting this style and making optimisation just
>>>> for
>>>> it.
>>>> FireFox trying to catch up, but Safari seems to do well both.
>>>>
>>>>
>>>> Here is a little example of inheritance done with prototype pattern
>>>>
>>>> var Class = function(){}; //empty function to avoid invocation during
>>>>
>>>> Function.prototype.extend = function(C){
>>>> Class.prototype = C.prototype;
>>>> this.prototype = new Class();
>>>> this.prototype.constructor = this;
>>>> return this.prototype
>>>> };
>>>>
>>>> now you can easily do this:
>>>>
>>>> function EventDispatcher(){}
>>>> p = EventDispatcher.prototype;
>>>>
>>>> function DisplayObject(){
>>>> EventDispatcher.call(this); //equivalent of super
>>>> }
>>>> p = DisplayObject.extend(EventDispatcher);
>>>>
>>>> THis is obviously simplified form of what is really needed but it is good
>>>> enough to cover lots of aspects already.
>>>> Don't want to repeat what has been already sent here as examples, but
>>>> simplicity and speed of this solution will outperform anything in
>>>> real-project-use-case-scenario.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 11/27/2012 8:06 AM, Erik de Bruin wrote:
>>>>> Alex,
>>>>>
>>>>> You keep referring to a "prototype". I might be missing something.
>>>>> Where can I find it/how do I run it?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>
>>>
>
>
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
One more thought (yes, I really can't help myself):
Google chose to go with closures (obviously), and I'm sure they care
about all the stuff you mention... And I'd say they have some
experience with building and maintaining large javascript projects. As
does Yahoo (YUI), jQuery and I'm sure others as well. They most likely
did their due diligence before choosing this technique over the
others, something we could benefit from.
A good place - albeit a bit random - to start reading about the
benefits of the approach I am advocating is:
http://www.examplejs.com/?p=250
Ok, I'll shut up now ;-)
EdB
On Tue, Nov 27, 2012 at 7:23 PM, Daniel Wasilewski <de...@gmail.com> wrote:
> Erik,
>
> If you don't care about memory consumption, output file size, long prototype
> chain, inheritance, slow downs on bigger structures than 1 plain objects...
> use it.
> Again, not saying let's prefer or favour one of the method over another,
> those things keeps changing over the time.
> This test just 2 years ago would be a different picture.
>
> All I am saying is to have ability to control he output of grammar of JS. I
> know my English is not perfect but that's my only point i am trying to make.
> If you feel it's endless... sorry. It wasn't my intention to make it long.
> But rather invite to constructive discussion. It is easy to say NO to
> solution I think doesn't suits me without giving any reason.
>
> I would like to hear about pros of module pattern myself. Prove me wrong, I
> will shout up :)
> I am not JS expert. But let's not make design decisions based on the latests
> trends, but technical reasoning.
>
> Dan
>
>
> On 11/27/2012 4:38 PM, Erik de Bruin wrote:
>>
>> Dan,
>>
>> This is my last comment on the subject, as I foresee another endless
>> discussion, but:
>>
>> Closure (Module Pattern) outperforms any other 'style' at least 2 to 1
>> on the test you quote, yet you recommend that we don't use it?
>>
>> EdB
>>
>>
>>
>> On Tue, Nov 27, 2012 at 5:22 PM, Daniel Wasilewski <de...@gmail.com>
>> wrote:
>>>
>>> I'll try to help Alex :)
>>> But he may correct me if I am wrong.
>>>
>>>
>>> I believe this little test will show full picture and all 4 common styles
>>> of
>>> JS programming we are talking about here.
>>>
>>> Notice there is nothing about inheritance, just plain objects (classes)
>>> Once inheritance is involved things are slowing down with different
>>> ratios.
>>>
>>> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
>>>
>>> Current proposed style of JS output is Object Literal (red bar in that
>>> test);
>>> Prototype (green bar) in plain object test seems to be 2nd solution
>>> outperformed by closure (blue bar) these days.
>>>
>>> But when inheritance is involved blue bar is getting shorter and
>>> prototype
>>> is catching up.
>>> Prototype pattern has also less footprint, since you adding 1 shared
>>> behaviour to your object that will be reused wherever possible instead
>>> creating brand new object.
>>>
>>> There is no surprise why Closure style runs very well on web kit based
>>> browsers since Google promoting this style and making optimisation just
>>> for
>>> it.
>>> FireFox trying to catch up, but Safari seems to do well both.
>>>
>>>
>>> Here is a little example of inheritance done with prototype pattern
>>>
>>> var Class = function(){}; //empty function to avoid invocation during
>>>
>>> Function.prototype.extend = function(C){
>>> Class.prototype = C.prototype;
>>> this.prototype = new Class();
>>> this.prototype.constructor = this;
>>> return this.prototype
>>> };
>>>
>>> now you can easily do this:
>>>
>>> function EventDispatcher(){}
>>> p = EventDispatcher.prototype;
>>>
>>> function DisplayObject(){
>>> EventDispatcher.call(this); //equivalent of super
>>> }
>>> p = DisplayObject.extend(EventDispatcher);
>>>
>>> THis is obviously simplified form of what is really needed but it is good
>>> enough to cover lots of aspects already.
>>> Don't want to repeat what has been already sent here as examples, but
>>> simplicity and speed of this solution will outperform anything in
>>> real-project-use-case-scenario.
>>>
>>> Dan
>>>
>>>
>>> On 11/27/2012 8:06 AM, Erik de Bruin wrote:
>>>>
>>>> Alex,
>>>>
>>>> You keep referring to a "prototype". I might be missing something.
>>>> Where can I find it/how do I run it?
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>
>>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
Erik,
If you don't care about memory consumption, output file size, long
prototype chain, inheritance, slow downs on bigger structures than 1
plain objects... use it.
Again, not saying let's prefer or favour one of the method over another,
those things keeps changing over the time.
This test just 2 years ago would be a different picture.
All I am saying is to have ability to control he output of grammar of
JS. I know my English is not perfect but that's my only point i am
trying to make.
If you feel it's endless... sorry. It wasn't my intention to make it long.
But rather invite to constructive discussion. It is easy to say NO to
solution I think doesn't suits me without giving any reason.
I would like to hear about pros of module pattern myself. Prove me
wrong, I will shout up :)
I am not JS expert. But let's not make design decisions based on the
latests trends, but technical reasoning.
Dan
On 11/27/2012 4:38 PM, Erik de Bruin wrote:
> Dan,
>
> This is my last comment on the subject, as I foresee another endless
> discussion, but:
>
> Closure (Module Pattern) outperforms any other 'style' at least 2 to 1
> on the test you quote, yet you recommend that we don't use it?
>
> EdB
>
>
>
> On Tue, Nov 27, 2012 at 5:22 PM, Daniel Wasilewski <de...@gmail.com> wrote:
>> I'll try to help Alex :)
>> But he may correct me if I am wrong.
>>
>>
>> I believe this little test will show full picture and all 4 common styles of
>> JS programming we are talking about here.
>>
>> Notice there is nothing about inheritance, just plain objects (classes)
>> Once inheritance is involved things are slowing down with different ratios.
>>
>> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
>>
>> Current proposed style of JS output is Object Literal (red bar in that
>> test);
>> Prototype (green bar) in plain object test seems to be 2nd solution
>> outperformed by closure (blue bar) these days.
>>
>> But when inheritance is involved blue bar is getting shorter and prototype
>> is catching up.
>> Prototype pattern has also less footprint, since you adding 1 shared
>> behaviour to your object that will be reused wherever possible instead
>> creating brand new object.
>>
>> There is no surprise why Closure style runs very well on web kit based
>> browsers since Google promoting this style and making optimisation just for
>> it.
>> FireFox trying to catch up, but Safari seems to do well both.
>>
>>
>> Here is a little example of inheritance done with prototype pattern
>>
>> var Class = function(){}; //empty function to avoid invocation during
>>
>> Function.prototype.extend = function(C){
>> Class.prototype = C.prototype;
>> this.prototype = new Class();
>> this.prototype.constructor = this;
>> return this.prototype
>> };
>>
>> now you can easily do this:
>>
>> function EventDispatcher(){}
>> p = EventDispatcher.prototype;
>>
>> function DisplayObject(){
>> EventDispatcher.call(this); //equivalent of super
>> }
>> p = DisplayObject.extend(EventDispatcher);
>>
>> THis is obviously simplified form of what is really needed but it is good
>> enough to cover lots of aspects already.
>> Don't want to repeat what has been already sent here as examples, but
>> simplicity and speed of this solution will outperform anything in
>> real-project-use-case-scenario.
>>
>> Dan
>>
>>
>> On 11/27/2012 8:06 AM, Erik de Bruin wrote:
>>> Alex,
>>>
>>> You keep referring to a "prototype". I might be missing something.
>>> Where can I find it/how do I run it?
>>>
>>> EdB
>>>
>>>
>>>
>>> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>
>
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Dan,
This is my last comment on the subject, as I foresee another endless
discussion, but:
Closure (Module Pattern) outperforms any other 'style' at least 2 to 1
on the test you quote, yet you recommend that we don't use it?
EdB
On Tue, Nov 27, 2012 at 5:22 PM, Daniel Wasilewski <de...@gmail.com> wrote:
> I'll try to help Alex :)
> But he may correct me if I am wrong.
>
>
> I believe this little test will show full picture and all 4 common styles of
> JS programming we are talking about here.
>
> Notice there is nothing about inheritance, just plain objects (classes)
> Once inheritance is involved things are slowing down with different ratios.
>
> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
>
> Current proposed style of JS output is Object Literal (red bar in that
> test);
> Prototype (green bar) in plain object test seems to be 2nd solution
> outperformed by closure (blue bar) these days.
>
> But when inheritance is involved blue bar is getting shorter and prototype
> is catching up.
> Prototype pattern has also less footprint, since you adding 1 shared
> behaviour to your object that will be reused wherever possible instead
> creating brand new object.
>
> There is no surprise why Closure style runs very well on web kit based
> browsers since Google promoting this style and making optimisation just for
> it.
> FireFox trying to catch up, but Safari seems to do well both.
>
>
> Here is a little example of inheritance done with prototype pattern
>
> var Class = function(){}; //empty function to avoid invocation during
>
> Function.prototype.extend = function(C){
> Class.prototype = C.prototype;
> this.prototype = new Class();
> this.prototype.constructor = this;
> return this.prototype
> };
>
> now you can easily do this:
>
> function EventDispatcher(){}
> p = EventDispatcher.prototype;
>
> function DisplayObject(){
> EventDispatcher.call(this); //equivalent of super
> }
> p = DisplayObject.extend(EventDispatcher);
>
> THis is obviously simplified form of what is really needed but it is good
> enough to cover lots of aspects already.
> Don't want to repeat what has been already sent here as examples, but
> simplicity and speed of this solution will outperform anything in
> real-project-use-case-scenario.
>
> Dan
>
>
> On 11/27/2012 8:06 AM, Erik de Bruin wrote:
>>
>> Alex,
>>
>> You keep referring to a "prototype". I might be missing something.
>> Where can I find it/how do I run it?
>>
>> EdB
>>
>>
>>
>> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: FalconJS has landed
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
For my prototype work I have been using a C# to JS compiler called SharpiKit.
It might be useful to look at how they are generating code as it works pretty damn well. Also, their output is easily captured by the closure compiler and made even more optimal.
It is not perfect but has about the best feature set of any project of this nature I have seen.
Mike
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
I'll try to help Alex :)
But he may correct me if I am wrong.
I believe this little test will show full picture and all 4 common
styles of JS programming we are talking about here.
Notice there is nothing about inheritance, just plain objects (classes)
Once inheritance is involved things are slowing down with different ratios.
http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
Current proposed style of JS output is Object Literal (red bar in that
test);
Prototype (green bar) in plain object test seems to be 2nd solution
outperformed by closure (blue bar) these days.
But when inheritance is involved blue bar is getting shorter and
prototype is catching up.
Prototype pattern has also less footprint, since you adding 1 shared
behaviour to your object that will be reused wherever possible instead
creating brand new object.
There is no surprise why Closure style runs very well on web kit based
browsers since Google promoting this style and making optimisation just
for it.
FireFox trying to catch up, but Safari seems to do well both.
Here is a little example of inheritance done with prototype pattern
var Class = function(){}; //empty function to avoid invocation during
Function.prototype.extend = function(C){
Class.prototype = C.prototype;
this.prototype = new Class();
this.prototype.constructor = this;
return this.prototype
};
now you can easily do this:
function EventDispatcher(){}
p = EventDispatcher.prototype;
function DisplayObject(){
EventDispatcher.call(this); //equivalent of super
}
p = DisplayObject.extend(EventDispatcher);
THis is obviously simplified form of what is really needed but it is
good enough to cover lots of aspects already.
Don't want to repeat what has been already sent here as examples, but
simplicity and speed of this solution will outperform anything in
real-project-use-case-scenario.
Dan
On 11/27/2012 8:06 AM, Erik de Bruin wrote:
> Alex,
>
> You keep referring to a "prototype". I might be missing something.
> Where can I find it/how do I run it?
>
> EdB
>
>
>
> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <ah...@adobe.com> wrote:
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/27/12 12:06 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Alex,
>
> You keep referring to a "prototype". I might be missing something.
> Where can I find it/how do I run it?
>
I need management sign off before I can check it in. One of the managers
returns from vacation today so hopefully you will see it today or tomorrow.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alex,
You keep referring to a "prototype". I might be missing something.
Where can I find it/how do I run it?
EdB
On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/26/12 1:15 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>> Instead, I want to leverage what is there, and specifically disallow support
>>> for Flash APIs that will be hard to implement, at least in the early going.
>>> In fact, the right test when building an app in this new framework would be
>>> to not import any Flash classes. I would prefer to wrap important Flash
>>> concepts in a way that makes them easier to implement on the HTML/JS side.
>>> For example, why cross-compile all of the AS Flex button code? There's a
>>> pretty good button baked into the HTML/JS stack.
>>
>> I think I abused the term API a bit. With JS player I meant the entire
>> JS 'engine' (actively avoiding the term framework ;-)) that takes the
>> compiled JS app and makes it "happen" in the browser.
> Well, I may not understand what you mean by "engine", but in my prototype, I
> don't think there really is one. The way I see it, apps are an assembly of
> components with some glue code. I don't want to try to write another layer
> that is like a VM/engine.
>>
>> The 'native' HTML/JS controls, as you call them, don't provide a
>> consistent look and feel across browsers and platforms and certainly
>> don't allow for skinning (yes, CSS allows for some, but not nearly
>> what we're used to). This has always been one of the strong points of
>> Flex and I think we should seriously consider making it one of the
>> strong points of FlexJS.
> Sure, folks are welcome to embark on an advanced skinnable set of
> components, but IMO, the basic set should be pretty bare bones. Hopefully
> there is some existing pattern for providing custom buttons in HTML/JS we
> can just wrap. But I hope we don't have to try to transcode an AS button
> implementation. That just sounds like a lot of work.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
By a term API I've understood something that JS developers use to call
'syntactic sugar' witch seems to be a necessity if you need to use
/leverage one of the popular patterns on top of native/standard JS. They
keep saying about a beauty and flexibility of JS, then, inventing some
patterns and over bloating it with this. I have heard from my fellow JS
co-workers, "yes, you need to do a lots of dirty hacks to make JS going
as you wish, but just once, then wrap it up and forget about it ;)
This is why I belong to those 50% conservatives that believe in
something more than only just getting job done. I believe in getting job
done well, no room for 'just' here.
But when comes to productivity, I believe AS3 outperforms JS in many
aspects, and I don't really care about how beautiful the output is, all
I am concern about, is to how to utilise the best performance possible.
Because I dived into this subject a while ago, seeing things like JQuery
as a main animation engine behind Edge just drives me crazy. Design or
commercial decision? Or maybe desperate decision to deliver something ASAP?
Every single test native vs jQuery shows 100:1 performance ratio. Still
widely accepted by JS community because of one reason. Ease of development.
What I'm trying to say, having ability to write a code with the ease of
AS3 and output it into best performing JS is the key of the project like
this.
If the result will not outperform already known solutions there is no
future for such thing.
If FalconJS will prove that it's worth it, you may count on bunch of JS
people learning AS3 to get stuff performing better. This is the way to
keep this language alive and relevant in development.
If not, there will be a bunch of former AS3 coders learning JQuery
instead. Not really pure JS.
As you may know it already, I am trying a different approach by writing
native fully flagged framework as a bare-bones to join those 2 platforms
together.
Make the best possible implementation of framework on both platforms and
then, on top of that make an interpreter. Leaving no gap for
interpretation, styles, variations, patterns at all. The best performing
solution is the winner.
Sad true is, when I am actually have my prototype working on both sides
and performs same task, I see that JS outperforms ActionScript in many
cases, on at least desktop machines.
So, if I will see some interpreter/framework whatever trying to
translate from one language to another and the output is like 100:1 or
even worst, this is complete waste of time. I fell strange myself by
saying that, but JS and over-hyped HTM5 indeed has a potential to bring
very similar experience to what we know from flash/flex on your browser.
IT IS technically here and now. But there is no solution on the market
yet, that made it happen from a tool set point of view. And I would love
to see flex taking a lead on his very own territory, RIA.
Despite of the fact I am running my own project on this very subject, I
would love to contribute and help us much as I can in my spare time,
share some concepts or ideas.
Don't take my words here as moaning but more as a constructive debate.
But as I said before, I have big hopes for FalconJS and more options to
keep AS3 alive, better for community as a whole.
Dan
On 11/26/2012 9:32 PM, Alex Harui wrote:
>
>
> On 11/26/12 1:15 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>> Instead, I want to leverage what is there, and specifically disallow support
>>> for Flash APIs that will be hard to implement, at least in the early going.
>>> In fact, the right test when building an app in this new framework would be
>>> to not import any Flash classes. I would prefer to wrap important Flash
>>> concepts in a way that makes them easier to implement on the HTML/JS side.
>>> For example, why cross-compile all of the AS Flex button code? There's a
>>> pretty good button baked into the HTML/JS stack.
>> I think I abused the term API a bit. With JS player I meant the entire
>> JS 'engine' (actively avoiding the term framework ;-)) that takes the
>> compiled JS app and makes it "happen" in the browser.
> Well, I may not understand what you mean by "engine", but in my prototype, I
> don't think there really is one. The way I see it, apps are an assembly of
> components with some glue code. I don't want to try to write another layer
> that is like a VM/engine.
>> The 'native' HTML/JS controls, as you call them, don't provide a
>> consistent look and feel across browsers and platforms and certainly
>> don't allow for skinning (yes, CSS allows for some, but not nearly
>> what we're used to). This has always been one of the strong points of
>> Flex and I think we should seriously consider making it one of the
>> strong points of FlexJS.
> Sure, folks are welcome to embark on an advanced skinnable set of
> components, but IMO, the basic set should be pretty bare bones. Hopefully
> there is some existing pattern for providing custom buttons in HTML/JS we
> can just wrap. But I hope we don't have to try to transcode an AS button
> implementation. That just sounds like a lot of work.
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/26/12 1:15 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> Instead, I want to leverage what is there, and specifically disallow support
>> for Flash APIs that will be hard to implement, at least in the early going.
>> In fact, the right test when building an app in this new framework would be
>> to not import any Flash classes. I would prefer to wrap important Flash
>> concepts in a way that makes them easier to implement on the HTML/JS side.
>> For example, why cross-compile all of the AS Flex button code? There's a
>> pretty good button baked into the HTML/JS stack.
>
> I think I abused the term API a bit. With JS player I meant the entire
> JS 'engine' (actively avoiding the term framework ;-)) that takes the
> compiled JS app and makes it "happen" in the browser.
Well, I may not understand what you mean by "engine", but in my prototype, I
don't think there really is one. The way I see it, apps are an assembly of
components with some glue code. I don't want to try to write another layer
that is like a VM/engine.
>
> The 'native' HTML/JS controls, as you call them, don't provide a
> consistent look and feel across browsers and platforms and certainly
> don't allow for skinning (yes, CSS allows for some, but not nearly
> what we're used to). This has always been one of the strong points of
> Flex and I think we should seriously consider making it one of the
> strong points of FlexJS.
Sure, folks are welcome to embark on an advanced skinnable set of
components, but IMO, the basic set should be pretty bare bones. Hopefully
there is some existing pattern for providing custom buttons in HTML/JS we
can just wrap. But I hope we don't have to try to transcode an AS button
implementation. That just sounds like a lot of work.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> Me, I don't like to have to use a 'framework' (even a tiny one) to
>> make something happen. It adds a layer between the code and the
>> execution that I think we don't need and therefor should avoid. As
>> others have pointed out, maintaining performance will be major
>> challenge, so using JS as the browser's "assembly" language, naked and
>> without intermediaries seems like the best way to go.
>
> I would agree with that, but I don't see the original pattern by Resig as a
> framework, and am still not sure why the original developer of FalconJS
> switched to make it more like a framework.
>
> But because the main goal of this output code is to service the transcoding
> of AS to JS, I worry that there is something in the mapping that might
> require not using one of the popular patterns.
Yes, I share that worry. In fact, I think it's basically a certainty
that whatever (non-)pattern is chosen, it will fail once the compiler
matures and more and more AS3 needs to be mapped. I think a period of
trail and error and lots of test cases will be inevitable. False
starts will be made and weird workarounds will be needed, no doubt
about it. If it were easy, where would the fun be, right ;-)
>>>> I wonder how Falcon will deal with a display list.
>>>> Is it going to be similar to the output of Edge? Or just Canvas based api?
>>> Falcon doesn't deal with the display list, it deals with libraries and for
>>> Flash apps, one of them (playerglobal.swc) maps to the display list API.
>>>
>>> For FalconJS, there is currently no JS implementation of the APIs in
>>> playerglobal.swc. We could build one, but I am not using in my POC.
>>
>> As it seems that a JS player is surely needed for the compiler to make
>> any sense and I'm far out of my depth where the FalconJS code is
>> concerned (without some additional tutoring, at least), I'd like to
>> work on that. Is there anywhere I can get a full description of the
>> player APIs the Flex Frameworks uses? Better to dive right into the
>> deep end ;-)
>>
> I'm not sure anybody knows which player APIs the Flex SDK uses, but I will
> argue that it doesn't matter because whether or not the SDK used an API, we
> certainly did not prevent someone from using other APIs in their extensions
> of the SDK.
>
> I still don't think we want to go down the road of emulating the player in
> JS. Talk about having a layer to hurt performance. And we'll be spending a
> lot of time trying to nail the emulation on all of these browsers. But you
> are welcome to take a shot at it.
>
> Instead, I want to leverage what is there, and specifically disallow support
> for Flash APIs that will be hard to implement, at least in the early going.
> In fact, the right test when building an app in this new framework would be
> to not import any Flash classes. I would prefer to wrap important Flash
> concepts in a way that makes them easier to implement on the HTML/JS side.
> For example, why cross-compile all of the AS Flex button code? There's a
> pretty good button baked into the HTML/JS stack.
I think I abused the term API a bit. With JS player I meant the entire
JS 'engine' (actively avoiding the term framework ;-)) that takes the
compiled JS app and makes it "happen" in the browser.
The 'native' HTML/JS controls, as you call them, don't provide a
consistent look and feel across browsers and platforms and certainly
don't allow for skinning (yes, CSS allows for some, but not nearly
what we're used to). This has always been one of the strong points of
Flex and I think we should seriously consider making it one of the
strong points of FlexJS.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/26/12 11:12 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> Looks like we'll have some fun debating which JS pattern to use. In a five
>> minute drive-by of the Module Pattern, I found this [1].
>
> The internet is split 50-50 on this subject, as is usual for these
> types of discussions. Having read a few more articles on this and
> similar subjects over the last 10 years, I can safely say that
> especially with modern JS VMs being as fast and efficient as they are,
> it boils down to developer preference.
>
>> I'm not advocating one pattern vs the other. I'm still wondering why basic
>> object/prototype wasn't good enough.
>
> As with all Design Patterns, they supplement the underlying language,
> mask some of it's shortcomings and maybe provide additional
> functionality. Mostly they are meant to make coding in said language
> more consistent, maintainable and scalable.
>
>> The current FalconJS pattern is based on [2]. I'm still not clear why we
>> are not using it verbatim. One of the interesting points of [2] is that it
>> doesn't fully run the constructors of the base classes when creating an
>> extension.
>
> Me, I don't like to have to use a 'framework' (even a tiny one) to
> make something happen. It adds a layer between the code and the
> execution that I think we don't need and therefor should avoid. As
> others have pointed out, maintaining performance will be major
> challenge, so using JS as the browser's "assembly" language, naked and
> without intermediaries seems like the best way to go.
I would agree with that, but I don't see the original pattern by Resig as a
framework, and am still not sure why the original developer of FalconJS
switched to make it more like a framework.
But because the main goal of this output code is to service the transcoding
of AS to JS, I worry that there is something in the mapping that might
require not using one of the popular patterns.
> From your other email:
>
>>> I wonder how Falcon will deal with a display list.
>>> Is it going to be similar to the output of Edge? Or just Canvas based api?
>> Falcon doesn't deal with the display list, it deals with libraries and for
>> Flash apps, one of them (playerglobal.swc) maps to the display list API.
>>
>> For FalconJS, there is currently no JS implementation of the APIs in
>> playerglobal.swc. We could build one, but I am not using in my POC.
>
> As it seems that a JS player is surely needed for the compiler to make
> any sense and I'm far out of my depth where the FalconJS code is
> concerned (without some additional tutoring, at least), I'd like to
> work on that. Is there anywhere I can get a full description of the
> player APIs the Flex Frameworks uses? Better to dive right into the
> deep end ;-)
>
I'm not sure anybody knows which player APIs the Flex SDK uses, but I will
argue that it doesn't matter because whether or not the SDK used an API, we
certainly did not prevent someone from using other APIs in their extensions
of the SDK.
I still don't think we want to go down the road of emulating the player in
JS. Talk about having a layer to hurt performance. And we'll be spending a
lot of time trying to nail the emulation on all of these browsers. But you
are welcome to take a shot at it.
Instead, I want to leverage what is there, and specifically disallow support
for Flash APIs that will be hard to implement, at least in the early going.
In fact, the right test when building an app in this new framework would be
to not import any Flash classes. I would prefer to wrap important Flash
concepts in a way that makes them easier to implement on the HTML/JS side.
For example, why cross-compile all of the AS Flex button code? There's a
pretty good button baked into the HTML/JS stack.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> Looks like we'll have some fun debating which JS pattern to use. In a five
> minute drive-by of the Module Pattern, I found this [1].
The internet is split 50-50 on this subject, as is usual for these
types of discussions. Having read a few more articles on this and
similar subjects over the last 10 years, I can safely say that
especially with modern JS VMs being as fast and efficient as they are,
it boils down to developer preference.
> I'm not advocating one pattern vs the other. I'm still wondering why basic
> object/prototype wasn't good enough.
As with all Design Patterns, they supplement the underlying language,
mask some of it's shortcomings and maybe provide additional
functionality. Mostly they are meant to make coding in said language
more consistent, maintainable and scalable.
> The current FalconJS pattern is based on [2]. I'm still not clear why we
> are not using it verbatim. One of the interesting points of [2] is that it
> doesn't fully run the constructors of the base classes when creating an
> extension.
Me, I don't like to have to use a 'framework' (even a tiny one) to
make something happen. It adds a layer between the code and the
execution that I think we don't need and therefor should avoid. As
others have pointed out, maintaining performance will be major
challenge, so using JS as the browser's "assembly" language, naked and
without intermediaries seems like the best way to go.
> FalconJS will shove its output through Google Closure Compiler under the
> right conditions. I may have disabled it accidentally because I want to see
> what the raw code looks like.
I did see references to GCC in my brief and confusing look into the
FalconJS code, so I thought I'd include the annotations to show how
they relate to the pattern I used.
> Couple of other thoughts:
> A) We are translating code from a real class-based language to JS. Lots of
> JS patterns I take quick looks at seem to use lots of interesting
> conventions, but they may not support all of the things we may come to
> expect in the existing AS3 code bases we want to transcode, like "is" and
> "instanceof".
I'm sure we can build replacements as there is at least rudimentary
support for most concepts.
> B) Do we need to support truly separate compilation "units" for large
> projects? Minification seems to require that you have all of the JS you
> will ever load available at minification time. With AS, you could load just
> about anything from anywhere at any time.
Depends on the minification tooling you use and the choices you make.
The GCC lets you minify individual classes, files or whatever and I
know of several other solutions (some server side, some that work at
publication time) and schemes that allow you to load only what your
application needs, when it needs it.
>From your other email:
>> I wonder how Falcon will deal with a display list.
>> Is it going to be similar to the output of Edge? Or just Canvas based api?
> Falcon doesn't deal with the display list, it deals with libraries and for
> Flash apps, one of them (playerglobal.swc) maps to the display list API.
>
> For FalconJS, there is currently no JS implementation of the APIs in
> playerglobal.swc. We could build one, but I am not using in my POC.
As it seems that a JS player is surely needed for the compiler to make
any sense and I'm far out of my depth where the FalconJS code is
concerned (without some additional tutoring, at least), I'd like to
work on that. Is there anywhere I can get a full description of the
player APIs the Flex Frameworks uses? Better to dive right into the
deep end ;-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
Looks like we'll have some fun debating which JS pattern to use. In a five
minute drive-by of the Module Pattern, I found this [1].
I'm not advocating one pattern vs the other. I'm still wondering why basic
object/prototype wasn't good enough.
The current FalconJS pattern is based on [2]. I'm still not clear why we
are not using it verbatim. One of the interesting points of [2] is that it
doesn't fully run the constructors of the base classes when creating an
extension.
FalconJS will shove its output through Google Closure Compiler under the
right conditions. I may have disabled it accidentally because I want to see
what the raw code looks like.
Couple of other thoughts:
A) We are translating code from a real class-based language to JS. Lots of
JS patterns I take quick looks at seem to use lots of interesting
conventions, but they may not support all of the things we may come to
expect in the existing AS3 code bases we want to transcode, like "is" and
"instanceof".
B) Do we need to support truly separate compilation "units" for large
projects? Minification seems to require that you have all of the JS you
will ever load available at minification time. With AS, you could load just
about anything from anywhere at any time.
[1] http://snook.ca/archives/javascript/no-love-for-module-pattern
[2] http://ejohn.org/blog/simple-javascript-inheritance/
On 11/26/12 5:04 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Ok, simple example implementation of the use of the Module Pattern in
> combination with the Google Closure Compiler can be found here:
>
> https://www.ixsoftware.nl/apache-flex/falcon-poc/compile.php
>
> It basically takes 2 "class" files, and puts them through the GCC
> (ADVANCED optimisation) and runs the resulting minimised JS to show
> functionality. I've provided links to the original JS at the top of
> the file, for easy access.
>
> The GCC has some more features that might be nice for us to implement,
> but for now, I'll have a look at how I can get the FalconJS compiler
> to output code that might come close to what the above example uses as
> input.
>
> EdB
>
>
>
> On Mon, Nov 26, 2012 at 12:10 PM, Daniel Wasilewski
> <de...@gmail.com> wrote:
>> That's sounds promising. Having ability to specify grammar on output will
>> give Falcon a lot more horse power.
>> I was pointing at HaXe JS output as an example, because it is the best
>> (performance/footprint wise) out there.
>>
>> However scope and chain of accessibility in JS slowing down a lot.
>> And they've decided to represent entire source structure exactly the way you
>> have your namesapces in that source.
>> Each link of this chain is represented as an Object. It sounds like a safe
>> solution to avoid clashes but it comes with a cost.
>> This is a biggest drawback of HaXe, but definitely something that can be
>> avoided.
>>
>> There is another concept of extern classes that can be implemented directly
>> in the output and Compiler can map the code on architecture level.
>> Eventually inject missing bits directly into it. Does Falcon could be
>> adopted to this?
>>
>> I wonder how Falcon will deal with a display list.
>> Is it going to be similar to the output of Edge? Or just Canvas based api?
>>
>> I am having big hopes for Falcon as the only part of the hand-over process
>> to be honest.
>> And not necessarily in conjunction of flex but as a pure AS3 - JS evaluator.
>>
>> Best
>> Dan
>>
>>
>>
>> On 11/26/2012 10:48 AM, Erik de Bruin wrote:
>>>
>>> Hi,
>>>
>>> FYI, I'm working on an POC for using a Module Pattern combined with
>>> Google Closure annotations to get a Javascript class as close to AS3
>>> as I can get it. This might serve as a starting point for defining the
>>> FalconJS output.
>>>
>>> EdB
>>>
>>>
>>>
>>> On Sun, Nov 25, 2012 at 4:59 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>>
>>>> On 11/24/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>>>
>>>>> And here is a little example of
>>>>> the very nature of this problem:
>>>>>
>>>>> http://jsperf.com/object-create-with-object-literal-vs-prototype
>>>>
>>>> I must be missing something, but I don't see where the output code calls
>>>> Object.create().
>>>>>
>>>>> We don't know what future will bring, maybe they will go crazy and
>>>>> built-in jQuery interpreter in their browsers, or do more crazy
>>>>> things...
>>>>> I am not saying that current output is wrong, but did you consider
>>>>> different styles?
>>>>
>>>> This is not my code or Gordon's. Another engineer on another team put
>>>> this
>>>> together very quickly. I just made it appear to work before donation.
>>>> We
>>>> have no way of knowing what he did or did not consider, all we know is
>>>> what
>>>> is in the code that was donated.
>>>>>
>>>>> Or at least have a choice to spit out a code in the
>>>>> way you can configure, specify some rules of AST?.
>>>>
>>>> I think you can change the code there, but I don't see any config options
>>>> other than it appears to be able to hook into Jquery.
>>>>>
>>>>> Take a look at HaXe
>>>>> output for instance.
>>>>>
>>>>> I don't care if the output code is ugly and messy. What I do care about,
>>>>> is that this very code is the best performer. I am writing AS3/Flex code
>>>>> for clarity and speed of production, and what I expect is the best
>>>>> performance on the other side. No more slow downs and bloated stuff.
>>>>> Because it will only tell people, pick one of the native JS framework if
>>>>> you need to develop RIA application for HTML5. The last thing Flex need
>>>>> is reputation of over-bloated stuff on the future platform of the web.
>>>>> Do this the best way, or do this well enough otherwise don't do it at
>>>>> all.
>>>>
>>>> Well, that is all in our control now. I will say that there is a good
>>>> chance that the final output won't be the absolute fastest as we are
>>>> translating from AS to JS so there is likely to be some impedance
>>>> mismatch
>>>> there.
>>>>
>>>> For example, it appears that the current code has chosen a fancier
>>>> inheritance scheme than the bare bones object.prototype pattern,
>>>> potentially
>>>> to allow for class reflection kinds of stuff. I'm not sure how much this
>>>> costs us and whether we truly have to have it.
>>>>
>>>> I also noted the output code calls newObject in certain cases. I'm not
>>>> sure
>>>> if that is done for object pooling or memory management or for some other
>>>> reason. The adobe.js file I checked in was written by me and only has
>>>> enough code in it to make my demo run. I have no idea how much other
>>>> infrastructure was actually behind those calls.
>>>>
>>>>>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>>>>>>
>>>>>> Well, it shouldn't be "adobe", but I'm not sure what we should change
>>>>>> it to.
>>>>>
>>>>> If apache sounds too general maybe just flex? Keep in mind that
>>>>> apache.flex.classes will destroy performance a bit, yeap that's what JS
>>>>> is about, shallow water ;)
>>>>
>>>> I left it as "adobe" until we argue over what to call it and make a
>>>> decision.
>>>>>
>>>>> Dan
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>
>>>
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ok, simple example implementation of the use of the Module Pattern in
combination with the Google Closure Compiler can be found here:
https://www.ixsoftware.nl/apache-flex/falcon-poc/compile.php
It basically takes 2 "class" files, and puts them through the GCC
(ADVANCED optimisation) and runs the resulting minimised JS to show
functionality. I've provided links to the original JS at the top of
the file, for easy access.
The GCC has some more features that might be nice for us to implement,
but for now, I'll have a look at how I can get the FalconJS compiler
to output code that might come close to what the above example uses as
input.
EdB
On Mon, Nov 26, 2012 at 12:10 PM, Daniel Wasilewski
<de...@gmail.com> wrote:
> That's sounds promising. Having ability to specify grammar on output will
> give Falcon a lot more horse power.
> I was pointing at HaXe JS output as an example, because it is the best
> (performance/footprint wise) out there.
>
> However scope and chain of accessibility in JS slowing down a lot.
> And they've decided to represent entire source structure exactly the way you
> have your namesapces in that source.
> Each link of this chain is represented as an Object. It sounds like a safe
> solution to avoid clashes but it comes with a cost.
> This is a biggest drawback of HaXe, but definitely something that can be
> avoided.
>
> There is another concept of extern classes that can be implemented directly
> in the output and Compiler can map the code on architecture level.
> Eventually inject missing bits directly into it. Does Falcon could be
> adopted to this?
>
> I wonder how Falcon will deal with a display list.
> Is it going to be similar to the output of Edge? Or just Canvas based api?
>
> I am having big hopes for Falcon as the only part of the hand-over process
> to be honest.
> And not necessarily in conjunction of flex but as a pure AS3 - JS evaluator.
>
> Best
> Dan
>
>
>
> On 11/26/2012 10:48 AM, Erik de Bruin wrote:
>>
>> Hi,
>>
>> FYI, I'm working on an POC for using a Module Pattern combined with
>> Google Closure annotations to get a Javascript class as close to AS3
>> as I can get it. This might serve as a starting point for defining the
>> FalconJS output.
>>
>> EdB
>>
>>
>>
>> On Sun, Nov 25, 2012 at 4:59 AM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 11/24/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>>
>>>> And here is a little example of
>>>> the very nature of this problem:
>>>>
>>>> http://jsperf.com/object-create-with-object-literal-vs-prototype
>>>
>>> I must be missing something, but I don't see where the output code calls
>>> Object.create().
>>>>
>>>> We don't know what future will bring, maybe they will go crazy and
>>>> built-in jQuery interpreter in their browsers, or do more crazy
>>>> things...
>>>> I am not saying that current output is wrong, but did you consider
>>>> different styles?
>>>
>>> This is not my code or Gordon's. Another engineer on another team put
>>> this
>>> together very quickly. I just made it appear to work before donation.
>>> We
>>> have no way of knowing what he did or did not consider, all we know is
>>> what
>>> is in the code that was donated.
>>>>
>>>> Or at least have a choice to spit out a code in the
>>>> way you can configure, specify some rules of AST?.
>>>
>>> I think you can change the code there, but I don't see any config options
>>> other than it appears to be able to hook into Jquery.
>>>>
>>>> Take a look at HaXe
>>>> output for instance.
>>>>
>>>> I don't care if the output code is ugly and messy. What I do care about,
>>>> is that this very code is the best performer. I am writing AS3/Flex code
>>>> for clarity and speed of production, and what I expect is the best
>>>> performance on the other side. No more slow downs and bloated stuff.
>>>> Because it will only tell people, pick one of the native JS framework if
>>>> you need to develop RIA application for HTML5. The last thing Flex need
>>>> is reputation of over-bloated stuff on the future platform of the web.
>>>> Do this the best way, or do this well enough otherwise don't do it at
>>>> all.
>>>
>>> Well, that is all in our control now. I will say that there is a good
>>> chance that the final output won't be the absolute fastest as we are
>>> translating from AS to JS so there is likely to be some impedance
>>> mismatch
>>> there.
>>>
>>> For example, it appears that the current code has chosen a fancier
>>> inheritance scheme than the bare bones object.prototype pattern,
>>> potentially
>>> to allow for class reflection kinds of stuff. I'm not sure how much this
>>> costs us and whether we truly have to have it.
>>>
>>> I also noted the output code calls newObject in certain cases. I'm not
>>> sure
>>> if that is done for object pooling or memory management or for some other
>>> reason. The adobe.js file I checked in was written by me and only has
>>> enough code in it to make my demo run. I have no idea how much other
>>> infrastructure was actually behind those calls.
>>>
>>>>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>>>>>
>>>>> Well, it shouldn't be "adobe", but I'm not sure what we should change
>>>>> it to.
>>>>
>>>> If apache sounds too general maybe just flex? Keep in mind that
>>>> apache.flex.classes will destroy performance a bit, yeap that's what JS
>>>> is about, shallow water ;)
>>>
>>> I left it as "adobe" until we argue over what to call it and make a
>>> decision.
>>>>
>>>> Dan
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/26/12 3:10 AM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
> I wonder how Falcon will deal with a display list.
> Is it going to be similar to the output of Edge? Or just Canvas based api?
Falcon doesn't deal with the display list, it deals with libraries and for
Flash apps, one of them (playerglobal.swc) maps to the display list API.
For FalconJS, there is currently no JS implementation of the APIs in
playerglobal.swc. We could build one, but I am not using in my POC.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
That's sounds promising. Having ability to specify grammar on output
will give Falcon a lot more horse power.
I was pointing at HaXe JS output as an example, because it is the best
(performance/footprint wise) out there.
However scope and chain of accessibility in JS slowing down a lot.
And they've decided to represent entire source structure exactly the way
you have your namesapces in that source.
Each link of this chain is represented as an Object. It sounds like a
safe solution to avoid clashes but it comes with a cost.
This is a biggest drawback of HaXe, but definitely something that can be
avoided.
There is another concept of extern classes that can be implemented
directly in the output and Compiler can map the code on architecture level.
Eventually inject missing bits directly into it. Does Falcon could be
adopted to this?
I wonder how Falcon will deal with a display list.
Is it going to be similar to the output of Edge? Or just Canvas based api?
I am having big hopes for Falcon as the only part of the hand-over
process to be honest.
And not necessarily in conjunction of flex but as a pure AS3 - JS evaluator.
Best
Dan
On 11/26/2012 10:48 AM, Erik de Bruin wrote:
> Hi,
>
> FYI, I'm working on an POC for using a Module Pattern combined with
> Google Closure annotations to get a Javascript class as close to AS3
> as I can get it. This might serve as a starting point for defining the
> FalconJS output.
>
> EdB
>
>
>
> On Sun, Nov 25, 2012 at 4:59 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 11/24/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
>>> And here is a little example of
>>> the very nature of this problem:
>>>
>>> http://jsperf.com/object-create-with-object-literal-vs-prototype
>> I must be missing something, but I don't see where the output code calls
>> Object.create().
>>> We don't know what future will bring, maybe they will go crazy and
>>> built-in jQuery interpreter in their browsers, or do more crazy things...
>>> I am not saying that current output is wrong, but did you consider
>>> different styles?
>> This is not my code or Gordon's. Another engineer on another team put this
>> together very quickly. I just made it appear to work before donation. We
>> have no way of knowing what he did or did not consider, all we know is what
>> is in the code that was donated.
>>> Or at least have a choice to spit out a code in the
>>> way you can configure, specify some rules of AST?.
>> I think you can change the code there, but I don't see any config options
>> other than it appears to be able to hook into Jquery.
>>> Take a look at HaXe
>>> output for instance.
>>>
>>> I don't care if the output code is ugly and messy. What I do care about,
>>> is that this very code is the best performer. I am writing AS3/Flex code
>>> for clarity and speed of production, and what I expect is the best
>>> performance on the other side. No more slow downs and bloated stuff.
>>> Because it will only tell people, pick one of the native JS framework if
>>> you need to develop RIA application for HTML5. The last thing Flex need
>>> is reputation of over-bloated stuff on the future platform of the web.
>>> Do this the best way, or do this well enough otherwise don't do it at all.
>> Well, that is all in our control now. I will say that there is a good
>> chance that the final output won't be the absolute fastest as we are
>> translating from AS to JS so there is likely to be some impedance mismatch
>> there.
>>
>> For example, it appears that the current code has chosen a fancier
>> inheritance scheme than the bare bones object.prototype pattern, potentially
>> to allow for class reflection kinds of stuff. I'm not sure how much this
>> costs us and whether we truly have to have it.
>>
>> I also noted the output code calls newObject in certain cases. I'm not sure
>> if that is done for object pooling or memory management or for some other
>> reason. The adobe.js file I checked in was written by me and only has
>> enough code in it to make my demo run. I have no idea how much other
>> infrastructure was actually behind those calls.
>>
>>>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>>>> Well, it shouldn't be "adobe", but I'm not sure what we should change it to.
>>> If apache sounds too general maybe just flex? Keep in mind that
>>> apache.flex.classes will destroy performance a bit, yeap that's what JS
>>> is about, shallow water ;)
>> I left it as "adobe" until we argue over what to call it and make a
>> decision.
>>> Dan
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
>
Re: FalconJS has landed
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
FYI, I'm working on an POC for using a Module Pattern combined with
Google Closure annotations to get a Javascript class as close to AS3
as I can get it. This might serve as a starting point for defining the
FalconJS output.
EdB
On Sun, Nov 25, 2012 at 4:59 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/24/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>
>> And here is a little example of
>> the very nature of this problem:
>>
>> http://jsperf.com/object-create-with-object-literal-vs-prototype
> I must be missing something, but I don't see where the output code calls
> Object.create().
>>
>> We don't know what future will bring, maybe they will go crazy and
>> built-in jQuery interpreter in their browsers, or do more crazy things...
>> I am not saying that current output is wrong, but did you consider
>> different styles?
> This is not my code or Gordon's. Another engineer on another team put this
> together very quickly. I just made it appear to work before donation. We
> have no way of knowing what he did or did not consider, all we know is what
> is in the code that was donated.
>> Or at least have a choice to spit out a code in the
>> way you can configure, specify some rules of AST?.
> I think you can change the code there, but I don't see any config options
> other than it appears to be able to hook into Jquery.
>> Take a look at HaXe
>> output for instance.
>>
>> I don't care if the output code is ugly and messy. What I do care about,
>> is that this very code is the best performer. I am writing AS3/Flex code
>> for clarity and speed of production, and what I expect is the best
>> performance on the other side. No more slow downs and bloated stuff.
>> Because it will only tell people, pick one of the native JS framework if
>> you need to develop RIA application for HTML5. The last thing Flex need
>> is reputation of over-bloated stuff on the future platform of the web.
>> Do this the best way, or do this well enough otherwise don't do it at all.
> Well, that is all in our control now. I will say that there is a good
> chance that the final output won't be the absolute fastest as we are
> translating from AS to JS so there is likely to be some impedance mismatch
> there.
>
> For example, it appears that the current code has chosen a fancier
> inheritance scheme than the bare bones object.prototype pattern, potentially
> to allow for class reflection kinds of stuff. I'm not sure how much this
> costs us and whether we truly have to have it.
>
> I also noted the output code calls newObject in certain cases. I'm not sure
> if that is done for object pooling or memory management or for some other
> reason. The adobe.js file I checked in was written by me and only has
> enough code in it to make my demo run. I have no idea how much other
> infrastructure was actually behind those calls.
>
>>
>>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>>> Well, it shouldn't be "adobe", but I'm not sure what we should change it to.
>>
>> If apache sounds too general maybe just flex? Keep in mind that
>> apache.flex.classes will destroy performance a bit, yeap that's what JS
>> is about, shallow water ;)
> I left it as "adobe" until we argue over what to call it and make a
> decision.
>>
>> Dan
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/24/12 3:42 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> And here is a little example of
> the very nature of this problem:
>
> http://jsperf.com/object-create-with-object-literal-vs-prototype
I must be missing something, but I don't see where the output code calls
Object.create().
>
> We don't know what future will bring, maybe they will go crazy and
> built-in jQuery interpreter in their browsers, or do more crazy things...
> I am not saying that current output is wrong, but did you consider
> different styles?
This is not my code or Gordon's. Another engineer on another team put this
together very quickly. I just made it appear to work before donation. We
have no way of knowing what he did or did not consider, all we know is what
is in the code that was donated.
> Or at least have a choice to spit out a code in the
> way you can configure, specify some rules of AST?.
I think you can change the code there, but I don't see any config options
other than it appears to be able to hook into Jquery.
> Take a look at HaXe
> output for instance.
>
> I don't care if the output code is ugly and messy. What I do care about,
> is that this very code is the best performer. I am writing AS3/Flex code
> for clarity and speed of production, and what I expect is the best
> performance on the other side. No more slow downs and bloated stuff.
> Because it will only tell people, pick one of the native JS framework if
> you need to develop RIA application for HTML5. The last thing Flex need
> is reputation of over-bloated stuff on the future platform of the web.
> Do this the best way, or do this well enough otherwise don't do it at all.
Well, that is all in our control now. I will say that there is a good
chance that the final output won't be the absolute fastest as we are
translating from AS to JS so there is likely to be some impedance mismatch
there.
For example, it appears that the current code has chosen a fancier
inheritance scheme than the bare bones object.prototype pattern, potentially
to allow for class reflection kinds of stuff. I'm not sure how much this
costs us and whether we truly have to have it.
I also noted the output code calls newObject in certain cases. I'm not sure
if that is done for object pooling or memory management or for some other
reason. The adobe.js file I checked in was written by me and only has
enough code in it to make my demo run. I have no idea how much other
infrastructure was actually behind those calls.
>
>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>> Well, it shouldn't be "adobe", but I'm not sure what we should change it to.
>
> If apache sounds too general maybe just flex? Keep in mind that
> apache.flex.classes will destroy performance a bit, yeap that's what JS
> is about, shallow water ;)
I left it as "adobe" until we argue over what to call it and make a
decision.
>
> Dan
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
> I'm a JS newbie. What other output would be more desirable and why?
Well, I am JS newbie too. I guess even bigger than you ;)
But after Adobe ceased a fire on Flash Mobile Plug-in (that was 3times
faster in execution speed that any JS comparable code on flash capable
mobile devices) I've spent some time on JS target. Especially when
comes to JS and OOP. I have been running many tests and comparing
efficiency and performance against the style you can choose from when
writing JS.
This very subject is a bit 'liquid' as browser vendors seems to do a lot
of work in favour of trends instead art of programming and sane logic,
but in general standard JS prototyping seems to be more efficient
solution. (Why I think this is wrong? Because they speeding up features
of stuff like jQuerry or literal notation based frameworks and sacrifice
the performance of standards of Ecma script, is not a addition, but
trade-off, they adjusting technology to popularity of 3rd party solutions )
Some small tests involves jQuery and literal notation based frameworks
shows that they gaining some speed over the time, sometimes they proved
to be faster. (something that wasn't true just a year ago at all). But
still, when comes to a bigger structures and applications (when I
believe this is what flex is about) more objects to deal with, standard
prototype seems to be more efficient. And here is a little example of
the very nature of this problem:
http://jsperf.com/object-create-with-object-literal-vs-prototype
We don't know what future will bring, maybe they will go crazy and
built-in jQuery interpreter in their browsers, or do more crazy things...
I am not saying that current output is wrong, but did you consider
different styles? Or at least have a choice to spit out a code in the
way you can configure, specify some rules of AST?. Take a look at HaXe
output for instance.
I don't care if the output code is ugly and messy. What I do care about,
is that this very code is the best performer. I am writing AS3/Flex code
for clarity and speed of production, and what I expect is the best
performance on the other side. No more slow downs and bloated stuff.
Because it will only tell people, pick one of the native JS framework if
you need to develop RIA application for HTML5. The last thing Flex need
is reputation of over-bloated stuff on the future platform of the web.
Do this the best way, or do this well enough otherwise don't do it at all.
>> 2. adobe.extend / adobe.classes? shouldn't be apache?
> Well, it shouldn't be "adobe", but I'm not sure what we should change it to.
If apache sounds too general maybe just flex? Keep in mind that
apache.flex.classes will destroy performance a bit, yeap that's what JS
is about, shallow water ;)
Dan
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/24/12 8:53 AM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> 2 questions:
>
> 1. Why literal notation for JS output? Is it the only output mode available?
I'm a JS newbie. What other output would be more desirable and why?
> 2. adobe.extend / adobe.classes? shouldn't be apache?
Well, it shouldn't be "adobe", but I'm not sure what we should change it to.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Daniel Wasilewski <de...@gmail.com>:
> 2 questions:
>
> 1. Why literal notation for JS output? Is it the only output mode available?
I have no idea, this is a prototype. It uses JBurg which is a bottom
up rewritter so I guess anything could be emitted based on the
semantics of the js language.
> 2. adobe.extend / adobe.classes? shouldn't be apache?
Probably but if you look at the code, there are serious issues.
That being said, I think Alex tried to warn that this was just a prototype.
Also, I would have no idea where to begin hacking this stuff since it
uses the byte code emitter for SWF then visits nodes (I think) with
the JSEmitter.
I'm guessing it compiles to virtual SWF byte code because the emitter
has already taken care of ActionScript semantics.
For anything done with this code, there will have to be others that
have a clue to whats going on. I don't know if what is there is the
best way to implement a cross compiler. I would have to study this
stuff more.
It will be interesting to hear others opinions eventually.
Mike
> Dan
>
> On 11/24/2012 1:00 PM, Michael Schmalle wrote:
>> Hey,
>>
>> I try to avoid the command line when ever possible. :)
>>
>> I set up a simple runner just like we did in functional testing using the;
>>
>> MXMLJSC.main(args);
>>
>>
>> For those that are interested, MainCode.as;
>>
>>
>> package
>> {
>> public class MainCode
>> {
>> public function MainCode()
>> {
>>
>> }
>>
>> public var foo:String;
>>
>> private var bar:int = 0;
>>
>> public function get baz():String
>> {
>> return foo;
>> }
>>
>> public function set baz(value:String):void
>> {
>> foo = value;
>> }
>> }
>> }
>>
>> and TestApp.as
>>
>> package
>> {
>> public class TestApp
>> {
>> private var linker:MainCode;
>>
>> public function TestApp()
>> {
>>
>> }
>> }
>>
>> }
>>
>>
>> Produces the following .js file;
>>
>>
>> /*
>> CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-11-24 07:54:52
>> */
>> MainCode = adobe.extend("MainCode", Object, {
>> init : function() {
>> return this
>> },
>> foo : void 0,
>> bar : 0,
>> get_baz : function() {
>> return this.foo
>> },
>> set_baz : function(a) {
>> this.foo = a
>> }
>> });
>> MainCode.prototype._CLASS = MainCode;
>> MainCode._PACKAGE = adobe.globals;
>> MainCode._NAME = "MainCode";
>> MainCode._FULLNAME = "MainCode";
>> MainCode._SUPER = Object;
>> MainCode._NAMESPACES = {
>> "foo::2" : !0,
>> "bar::7:MainCode" : !0,
>> "baz::2" : !0,
>> "baz::2" : !0
>> };
>> adobe.classes.MainCode = MainCode;
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>> Quoting Cyrill Zadra <cy...@gmail.com>:
>>
>>> Sure.. just commited.
>>>
>>> Cyrill
>>>
>>> On Sat, Nov 24, 2012 at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>>>> Please checkin your changes to build.xml, the manifest, and make a note in
>>>> the README.
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>>
>>>> On 11/23/12 11:27 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>>>
>>>>> Finally .. I could compile a js file Yihaa ;-).
>>>>>
>>>>> There were 2 things todo:
>>>>>
>>>>> 1) I had to remove the absolute path in the MANIFEST.MF to the falcon
>>>>> compiler.jar through a relative one.
>>>>>
>>>>> 2) The command ./bin/mxmlc MainCode.as returns a
>>>>>
>>>>> java.lang.NullPointerException
>>>>> at java.io.File.<init>(File.java:222)
>>>>> at
>>>>> org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:483)
>>>>> at
>>>>> org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:217)
>>>>> at
>>>>> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:177)
>>>>> at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:153)
>>>>>
>>>>> But with following command everything works fine.
>>>>> ../bin/mxmlc MainCode.as -output MainCode.js
>>>>>
>>>>> On Fri, Nov 23, 2012 at 10:42 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>> that will dump out the jar and see if that class is in there or not.
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>
>>
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FalconJS has landed
Posted by Daniel Wasilewski <de...@gmail.com>.
2 questions:
1. Why literal notation for JS output? Is it the only output mode available?
2. adobe.extend / adobe.classes? shouldn't be apache?
Dan
On 11/24/2012 1:00 PM, Michael Schmalle wrote:
> Hey,
>
> I try to avoid the command line when ever possible. :)
>
> I set up a simple runner just like we did in functional testing using
> the;
>
> MXMLJSC.main(args);
>
>
> For those that are interested, MainCode.as;
>
>
> package
> {
> public class MainCode
> {
> public function MainCode()
> {
>
> }
>
> public var foo:String;
>
> private var bar:int = 0;
>
> public function get baz():String
> {
> return foo;
> }
>
> public function set baz(value:String):void
> {
> foo = value;
> }
> }
> }
>
> and TestApp.as
>
> package
> {
> public class TestApp
> {
> private var linker:MainCode;
>
> public function TestApp()
> {
>
> }
> }
>
> }
>
>
> Produces the following .js file;
>
>
> /*
> CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-11-24 07:54:52
> */
> MainCode = adobe.extend("MainCode", Object, {
> init : function() {
> return this
> },
> foo : void 0,
> bar : 0,
> get_baz : function() {
> return this.foo
> },
> set_baz : function(a) {
> this.foo = a
> }
> });
> MainCode.prototype._CLASS = MainCode;
> MainCode._PACKAGE = adobe.globals;
> MainCode._NAME = "MainCode";
> MainCode._FULLNAME = "MainCode";
> MainCode._SUPER = Object;
> MainCode._NAMESPACES = {
> "foo::2" : !0,
> "bar::7:MainCode" : !0,
> "baz::2" : !0,
> "baz::2" : !0
> };
> adobe.classes.MainCode = MainCode;
>
>
>
> Mike
>
>
>
>
>
> Quoting Cyrill Zadra <cy...@gmail.com>:
>
>> Sure.. just commited.
>>
>> Cyrill
>>
>> On Sat, Nov 24, 2012 at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>>> Please checkin your changes to build.xml, the manifest, and make a
>>> note in
>>> the README.
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>> On 11/23/12 11:27 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>>
>>>> Finally .. I could compile a js file Yihaa ;-).
>>>>
>>>> There were 2 things todo:
>>>>
>>>> 1) I had to remove the absolute path in the MANIFEST.MF to the falcon
>>>> compiler.jar through a relative one.
>>>>
>>>> 2) The command ./bin/mxmlc MainCode.as returns a
>>>>
>>>> java.lang.NullPointerException
>>>> at java.io.File.<init>(File.java:222)
>>>> at
>>>> org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:483)
>>>> at
>>>> org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:217)
>>>> at
>>>> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:177)
>>>> at
>>>> org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:153)
>>>>
>>>> But with following command everything works fine.
>>>> ../bin/mxmlc MainCode.as -output MainCode.js
>>>>
>>>> On Fri, Nov 23, 2012 at 10:42 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>> that will dump out the jar and see if that class is in there or not.
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>
Re: FalconJS has landed
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hey,
I try to avoid the command line when ever possible. :)
I set up a simple runner just like we did in functional testing using the;
MXMLJSC.main(args);
For those that are interested, MainCode.as;
package
{
public class MainCode
{
public function MainCode()
{
}
public var foo:String;
private var bar:int = 0;
public function get baz():String
{
return foo;
}
public function set baz(value:String):void
{
foo = value;
}
}
}
and TestApp.as
package
{
public class TestApp
{
private var linker:MainCode;
public function TestApp()
{
}
}
}
Produces the following .js file;
/*
CROSS-COMPILED BY MXMLJSC (329449.1) ON 2012-11-24 07:54:52
*/
MainCode = adobe.extend("MainCode", Object, {
init : function() {
return this
},
foo : void 0,
bar : 0,
get_baz : function() {
return this.foo
},
set_baz : function(a) {
this.foo = a
}
});
MainCode.prototype._CLASS = MainCode;
MainCode._PACKAGE = adobe.globals;
MainCode._NAME = "MainCode";
MainCode._FULLNAME = "MainCode";
MainCode._SUPER = Object;
MainCode._NAMESPACES = {
"foo::2" : !0,
"bar::7:MainCode" : !0,
"baz::2" : !0,
"baz::2" : !0
};
adobe.classes.MainCode = MainCode;
Mike
Quoting Cyrill Zadra <cy...@gmail.com>:
> Sure.. just commited.
>
> Cyrill
>
> On Sat, Nov 24, 2012 at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
>> Please checkin your changes to build.xml, the manifest, and make a note in
>> the README.
>>
>> Thanks,
>> -Alex
>>
>>
>> On 11/23/12 11:27 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>
>>> Finally .. I could compile a js file Yihaa ;-).
>>>
>>> There were 2 things todo:
>>>
>>> 1) I had to remove the absolute path in the MANIFEST.MF to the falcon
>>> compiler.jar through a relative one.
>>>
>>> 2) The command ./bin/mxmlc MainCode.as returns a
>>>
>>> java.lang.NullPointerException
>>> at java.io.File.<init>(File.java:222)
>>> at
>>> org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:483)
>>> at
>>> org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:217)
>>> at
>>> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:177)
>>> at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:153)
>>>
>>> But with following command everything works fine.
>>> ../bin/mxmlc MainCode.as -output MainCode.js
>>>
>>> On Fri, Nov 23, 2012 at 10:42 PM, Alex Harui <ah...@adobe.com> wrote:
>>>> that will dump out the jar and see if that class is in there or not.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FalconJS has landed
Posted by Cyrill Zadra <cy...@gmail.com>.
Sure.. just commited.
Cyrill
On Sat, Nov 24, 2012 at 12:05 AM, Alex Harui <ah...@adobe.com> wrote:
> Please checkin your changes to build.xml, the manifest, and make a note in
> the README.
>
> Thanks,
> -Alex
>
>
> On 11/23/12 11:27 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>
>> Finally .. I could compile a js file Yihaa ;-).
>>
>> There were 2 things todo:
>>
>> 1) I had to remove the absolute path in the MANIFEST.MF to the falcon
>> compiler.jar through a relative one.
>>
>> 2) The command ./bin/mxmlc MainCode.as returns a
>>
>> java.lang.NullPointerException
>> at java.io.File.<init>(File.java:222)
>> at org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:483)
>> at
>> org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:217)
>> at
>> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:177)
>> at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:153)
>>
>> But with following command everything works fine.
>> ../bin/mxmlc MainCode.as -output MainCode.js
>>
>> On Fri, Nov 23, 2012 at 10:42 PM, Alex Harui <ah...@adobe.com> wrote:
>>> that will dump out the jar and see if that class is in there or not.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
Please checkin your changes to build.xml, the manifest, and make a note in
the README.
Thanks,
-Alex
On 11/23/12 11:27 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
> Finally .. I could compile a js file Yihaa ;-).
>
> There were 2 things todo:
>
> 1) I had to remove the absolute path in the MANIFEST.MF to the falcon
> compiler.jar through a relative one.
>
> 2) The command ./bin/mxmlc MainCode.as returns a
>
> java.lang.NullPointerException
> at java.io.File.<init>(File.java:222)
> at org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:483)
> at
> org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:217)
> at
> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:177)
> at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:153)
>
> But with following command everything works fine.
> ../bin/mxmlc MainCode.as -output MainCode.js
>
> On Fri, Nov 23, 2012 at 10:42 PM, Alex Harui <ah...@adobe.com> wrote:
>> that will dump out the jar and see if that class is in there or not.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Cyrill Zadra <cy...@gmail.com>.
Finally .. I could compile a js file Yihaa ;-).
There were 2 things todo:
1) I had to remove the absolute path in the MANIFEST.MF to the falcon
compiler.jar through a relative one.
2) The command ./bin/mxmlc MainCode.as returns a
java.lang.NullPointerException
at java.io.File.<init>(File.java:222)
at org.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:483)
at org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:217)
at org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:177)
at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:153)
But with following command everything works fine.
../bin/mxmlc MainCode.as -output MainCode.js
On Fri, Nov 23, 2012 at 10:42 PM, Alex Harui <ah...@adobe.com> wrote:
> that will dump out the jar and see if that class is in there or not.
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/23/12 10:19 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
> One step further. Could execute the ant target jar and it created all
> the libraries.
>
> Now I've got following exception.
>
> tiezad@elitebook-zadra /cygdrive/c/dev/apache-flex/falcon/compiler.js/bin
> $ ./mxmlc ../test/TestApp.as
> Using Falcon codebase: ./../../compiler
> Using Flex SDK: ./../../compiler/generated/dist/sdk
> java.lang.NoClassDefFoundError: org/apache/flex/compiler/clients/MXMLJSC
> Caused by: java.lang.ClassNotFoundException:
> org.apache.flex.compiler.clients.MXMLJSC
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> Could not find the main class:
> org.apache.flex.compiler.clients.MXMLJSC. Program will exit.
> Exception in thread "main
>
> I use windows (cygwin) so maybe thats the issue.
Maybe. I haven't tried it on Windows. I think there is some Java utility
that will dump out the jar and see if that class is in there or not.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Cyrill Zadra <cy...@gmail.com>.
One step further. Could execute the ant target jar and it created all
the libraries.
Now I've got following exception.
tiezad@elitebook-zadra /cygdrive/c/dev/apache-flex/falcon/compiler.js/bin
$ ./mxmlc ../test/TestApp.as
Using Falcon codebase: ./../../compiler
Using Flex SDK: ./../../compiler/generated/dist/sdk
java.lang.NoClassDefFoundError: org/apache/flex/compiler/clients/MXMLJSC
Caused by: java.lang.ClassNotFoundException:
org.apache.flex.compiler.clients.MXMLJSC
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class:
org.apache.flex.compiler.clients.MXMLJSC. Program will exit.
Exception in thread "main
I use windows (cygwin) so maybe thats the issue.
On Fri, Nov 23, 2012 at 9:07 PM, Alex Harui <ah...@adobe.com> wrote:
> Try taking out that line.
>
>
> On 11/23/12 9:04 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>
>> Tried it again still the same but it occurs on line 231:
>>
>> BUILD FAILED
>> C:\dev\apache-flex\falcon\compiler.js\build.xml:231: Warning: Could
>> not find resource file
>> "C:\dev\apache-flex\falcon\compiler.js\build\lib\asc.jar" to copy.
>>
>> Cyrill
>>
>> On Fri, Nov 23, 2012 at 8:42 PM, Alex Harui <ah...@adobe.com> wrote:
>>> Hmm. My system must be ignoring those errors. Not sure why. I updated the
>>> build.xml. Please try again.
>>>
>>>
>>> On 11/23/12 7:01 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>>
>>>> Looks like it's working again.
>>>>
>>>> I run into another problem. The directory lib/google/closure-compiler
>>>> wasn't created.
>>>> Updated the download.xml to create that directory.
>>>>
>>>> After that I get also the same error as mike.
>>>>
>>>>> BUILD FAILED
>>>>> C:\dev\apache-flex\falcon\compiler.js\build.xml:136: Warning: Could not
>>>>> find
>>>>> resource file "C:\dev\apache-flex\falcon\compiler.js\lib\abc\asc.jar" to
>>>>> copy.
>>>>
>>>> Cyrill
>>>>
>>>> On Fri, Nov 23, 2012 at 6:08 PM, Om <bi...@gmail.com> wrote:
>>>>> Unable to download antlr stuff. Hopefully this is a temporary issue:
>>>>>
>>>>> download-jar:
>>>>> [get] Getting: http://www.antlr.org/download/antlr-3.3-complete.jar
>>>>> [get] To:
>>>>> C:\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\ant
>>>>> lr.jar
>>>>> [get] Error opening connection java.io.IOException: Server returned
>>>>> HTTP r
>>>>> esponse code: 400 for URL:
>>>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>>>> [get] Error opening connection java.io.IOException: Server returned
>>>>> HTTP r
>>>>> esponse code: 400 for URL:
>>>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>>>> [get] Error opening connection java.io.IOException: Server returned
>>>>> HTTP r
>>>>> esponse code: 400 for URL:
>>>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>>>> [get] Can't get
>>>>> http://www.antlr.org/download/antlr-3.3-complete.jarto
>>>>> C:
>>>>> \p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\antlr.jar
>>>>>
>>>>> On Fri, Nov 23, 2012 at 3:35 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
Try taking out that line.
On 11/23/12 9:04 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
> Tried it again still the same but it occurs on line 231:
>
> BUILD FAILED
> C:\dev\apache-flex\falcon\compiler.js\build.xml:231: Warning: Could
> not find resource file
> "C:\dev\apache-flex\falcon\compiler.js\build\lib\asc.jar" to copy.
>
> Cyrill
>
> On Fri, Nov 23, 2012 at 8:42 PM, Alex Harui <ah...@adobe.com> wrote:
>> Hmm. My system must be ignoring those errors. Not sure why. I updated the
>> build.xml. Please try again.
>>
>>
>> On 11/23/12 7:01 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>>
>>> Looks like it's working again.
>>>
>>> I run into another problem. The directory lib/google/closure-compiler
>>> wasn't created.
>>> Updated the download.xml to create that directory.
>>>
>>> After that I get also the same error as mike.
>>>
>>>> BUILD FAILED
>>>> C:\dev\apache-flex\falcon\compiler.js\build.xml:136: Warning: Could not
>>>> find
>>>> resource file "C:\dev\apache-flex\falcon\compiler.js\lib\abc\asc.jar" to
>>>> copy.
>>>
>>> Cyrill
>>>
>>> On Fri, Nov 23, 2012 at 6:08 PM, Om <bi...@gmail.com> wrote:
>>>> Unable to download antlr stuff. Hopefully this is a temporary issue:
>>>>
>>>> download-jar:
>>>> [get] Getting: http://www.antlr.org/download/antlr-3.3-complete.jar
>>>> [get] To:
>>>> C:\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\ant
>>>> lr.jar
>>>> [get] Error opening connection java.io.IOException: Server returned
>>>> HTTP r
>>>> esponse code: 400 for URL:
>>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>>> [get] Error opening connection java.io.IOException: Server returned
>>>> HTTP r
>>>> esponse code: 400 for URL:
>>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>>> [get] Error opening connection java.io.IOException: Server returned
>>>> HTTP r
>>>> esponse code: 400 for URL:
>>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>>> [get] Can't get
>>>> http://www.antlr.org/download/antlr-3.3-complete.jarto
>>>> C:
>>>> \p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\antlr.jar
>>>>
>>>> On Fri, Nov 23, 2012 at 3:35 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Cyrill Zadra <cy...@gmail.com>.
Tried it again still the same but it occurs on line 231:
BUILD FAILED
C:\dev\apache-flex\falcon\compiler.js\build.xml:231: Warning: Could
not find resource file
"C:\dev\apache-flex\falcon\compiler.js\build\lib\asc.jar" to copy.
Cyrill
On Fri, Nov 23, 2012 at 8:42 PM, Alex Harui <ah...@adobe.com> wrote:
> Hmm. My system must be ignoring those errors. Not sure why. I updated the
> build.xml. Please try again.
>
>
> On 11/23/12 7:01 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
>
>> Looks like it's working again.
>>
>> I run into another problem. The directory lib/google/closure-compiler
>> wasn't created.
>> Updated the download.xml to create that directory.
>>
>> After that I get also the same error as mike.
>>
>>> BUILD FAILED
>>> C:\dev\apache-flex\falcon\compiler.js\build.xml:136: Warning: Could not find
>>> resource file "C:\dev\apache-flex\falcon\compiler.js\lib\abc\asc.jar" to
>>> copy.
>>
>> Cyrill
>>
>> On Fri, Nov 23, 2012 at 6:08 PM, Om <bi...@gmail.com> wrote:
>>> Unable to download antlr stuff. Hopefully this is a temporary issue:
>>>
>>> download-jar:
>>> [get] Getting: http://www.antlr.org/download/antlr-3.3-complete.jar
>>> [get] To:
>>> C:\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\ant
>>> lr.jar
>>> [get] Error opening connection java.io.IOException: Server returned
>>> HTTP r
>>> esponse code: 400 for URL:
>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>> [get] Error opening connection java.io.IOException: Server returned
>>> HTTP r
>>> esponse code: 400 for URL:
>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>> [get] Error opening connection java.io.IOException: Server returned
>>> HTTP r
>>> esponse code: 400 for URL:
>>> http://www.antlr.org/download/antlr-3.3-complete.jar
>>> [get] Can't get http://www.antlr.org/download/antlr-3.3-complete.jarto
>>> C:
>>> \p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\antlr.jar
>>>
>>> On Fri, Nov 23, 2012 at 3:35 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
Hmm. My system must be ignoring those errors. Not sure why. I updated the
build.xml. Please try again.
On 11/23/12 7:01 PM, "Cyrill Zadra" <cy...@gmail.com> wrote:
> Looks like it's working again.
>
> I run into another problem. The directory lib/google/closure-compiler
> wasn't created.
> Updated the download.xml to create that directory.
>
> After that I get also the same error as mike.
>
>> BUILD FAILED
>> C:\dev\apache-flex\falcon\compiler.js\build.xml:136: Warning: Could not find
>> resource file "C:\dev\apache-flex\falcon\compiler.js\lib\abc\asc.jar" to
>> copy.
>
> Cyrill
>
> On Fri, Nov 23, 2012 at 6:08 PM, Om <bi...@gmail.com> wrote:
>> Unable to download antlr stuff. Hopefully this is a temporary issue:
>>
>> download-jar:
>> [get] Getting: http://www.antlr.org/download/antlr-3.3-complete.jar
>> [get] To:
>> C:\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\ant
>> lr.jar
>> [get] Error opening connection java.io.IOException: Server returned
>> HTTP r
>> esponse code: 400 for URL:
>> http://www.antlr.org/download/antlr-3.3-complete.jar
>> [get] Error opening connection java.io.IOException: Server returned
>> HTTP r
>> esponse code: 400 for URL:
>> http://www.antlr.org/download/antlr-3.3-complete.jar
>> [get] Error opening connection java.io.IOException: Server returned
>> HTTP r
>> esponse code: 400 for URL:
>> http://www.antlr.org/download/antlr-3.3-complete.jar
>> [get] Can't get http://www.antlr.org/download/antlr-3.3-complete.jarto
>> C:
>> \p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\antlr.jar
>>
>> On Fri, Nov 23, 2012 at 3:35 PM, Alex Harui <ah...@adobe.com> wrote:
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Cyrill Zadra <cy...@gmail.com>.
Looks like it's working again.
I run into another problem. The directory lib/google/closure-compiler
wasn't created.
Updated the download.xml to create that directory.
After that I get also the same error as mike.
>BUILD FAILED
>C:\dev\apache-flex\falcon\compiler.js\build.xml:136: Warning: Could not find resource file "C:\dev\apache-flex\falcon\compiler.js\lib\abc\asc.jar" to copy.
Cyrill
On Fri, Nov 23, 2012 at 6:08 PM, Om <bi...@gmail.com> wrote:
> Unable to download antlr stuff. Hopefully this is a temporary issue:
>
> download-jar:
> [get] Getting: http://www.antlr.org/download/antlr-3.3-complete.jar
> [get] To:
> C:\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\ant
> lr.jar
> [get] Error opening connection java.io.IOException: Server returned
> HTTP r
> esponse code: 400 for URL:
> http://www.antlr.org/download/antlr-3.3-complete.jar
> [get] Error opening connection java.io.IOException: Server returned
> HTTP r
> esponse code: 400 for URL:
> http://www.antlr.org/download/antlr-3.3-complete.jar
> [get] Error opening connection java.io.IOException: Server returned
> HTTP r
> esponse code: 400 for URL:
> http://www.antlr.org/download/antlr-3.3-complete.jar
> [get] Can't get http://www.antlr.org/download/antlr-3.3-complete.jarto C:
> \p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\antlr.jar
>
> On Fri, Nov 23, 2012 at 3:35 PM, Alex Harui <ah...@adobe.com> wrote:
>
Re: FalconJS has landed
Posted by Om <bi...@gmail.com>.
Unable to download antlr stuff. Hopefully this is a temporary issue:
download-jar:
[get] Getting: http://www.antlr.org/download/antlr-3.3-complete.jar
[get] To:
C:\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\ant
lr.jar
[get] Error opening connection java.io.IOException: Server returned
HTTP r
esponse code: 400 for URL:
http://www.antlr.org/download/antlr-3.3-complete.jar
[get] Error opening connection java.io.IOException: Server returned
HTTP r
esponse code: 400 for URL:
http://www.antlr.org/download/antlr-3.3-complete.jar
[get] Error opening connection java.io.IOException: Server returned
HTTP r
esponse code: 400 for URL:
http://www.antlr.org/download/antlr-3.3-complete.jar
[get] Can't get http://www.antlr.org/download/antlr-3.3-complete.jarto C:
\p\flex_os\workspace\flexroot\falcon\trunk\compiler.js\lib\antlr.jar
On Fri, Nov 23, 2012 at 3:35 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 11/23/12 3:32 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> > Looks like it's going to take a bit of time digesting for myself. :)
> >
> > Next week I will write a wiki page explaining what I "See", if anybody
> > else wants to join in...
> >
> > Definitely a WIP though.
> >
> > Thanks for your effort Alex.
> >
> > Did we have to rebuild the comiler? I didn't see if it copies asc.jar
> > to the libs folder in compiler.js. THee is a build error that it can't
> > find /libs/asc.jar.
> There could be issues with the build script. It assumes Falcon has been
> built and its jars are sitting around, but I might have made some faulty
> assumption.
> >
> > Mike
> >
> > Quoting Alex Harui <ah...@adobe.com>:
> >
> >> It is in the falcon folder under trunk/compiler.js.
> >>
> >> Happy cross-compiling!
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: FalconJS has landed
Posted by Alex Harui <ah...@adobe.com>.
On 11/23/12 3:32 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Looks like it's going to take a bit of time digesting for myself. :)
>
> Next week I will write a wiki page explaining what I "See", if anybody
> else wants to join in...
>
> Definitely a WIP though.
>
> Thanks for your effort Alex.
>
> Did we have to rebuild the comiler? I didn't see if it copies asc.jar
> to the libs folder in compiler.js. THee is a build error that it can't
> find /libs/asc.jar.
There could be issues with the build script. It assumes Falcon has been
built and its jars are sitting around, but I might have made some faulty
assumption.
>
> Mike
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>> It is in the falcon folder under trunk/compiler.js.
>>
>> Happy cross-compiling!
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FalconJS has landed
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Looks like it's going to take a bit of time digesting for myself. :)
Next week I will write a wiki page explaining what I "See", if anybody
else wants to join in...
Definitely a WIP though.
Thanks for your effort Alex.
Did we have to rebuild the comiler? I didn't see if it copies asc.jar
to the libs folder in compiler.js. THee is a build error that it can't
find /libs/asc.jar.
Mike
Quoting Alex Harui <ah...@adobe.com>:
> It is in the falcon folder under trunk/compiler.js.
>
> Happy cross-compiling!
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com