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/16 18:08:54 UTC
What to expect from FalconJS
It has been almost a year since we announced Flex would be donated to Apache. We’ve spent all of this time preparing donations of the code. It has taken much longer than I would have ever imagined, but we are almost done. The FalconJS code passed legal review yesterday and just needs a few other approvals before being donated.
I’ve had some time to play with it. It can definitely take a simple AS class and spit out that class in JS in a predictable pattern. What the donated code will not do is convert an entire Flex app into a running HTML/CSS/JS app. In fact, it won’t even take a simple AS project and generated a running HTML/CSS/JS page. That’s because only the code that converts the AST to JS is being donated. If you ever saw the demo, there was a whole bunch of JS code that could mimic FlashPlayer APIs and render Flash visuals to SVG. That code is not being donated, and, I don’t think we want it. That’s because Flex is all about interaction and rendering to SVG is not a rendering that would be interactive.
I have been playing around with Falcon JS to help me form an opinion on what the next steps are, but I need some sign-offs from folks in Adobe before I can make it public. In the meantime, make sure you look at the slide deck from Michael Labriola’s 360Min presentation on how he is developing apps for HTML. I’m sure he’ll reply with the link. There are three things I think you should take away from that deck: 1) that there is an alternative really soon if you want to move to C#, and 2) that “finishing” the UI is very expensive due to rendering differences between browsers, and 3) that having good separation between UI and business logic is key to having an efficient way of “finishing” your UI.
These will be important things to keep in mind as we go forward.
Later,
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Randori framework [was Re: What to expect from FalconJS]
Posted by Alain Ekambi <ja...@gmail.com>.
What is the difference between this new Framework and something like GWT or
SharpKit ?
2012/11/19 Michael A. Labriola <la...@digitalprimates.net>
> >* You say this could be C#/Java/AS and so on... I think you start in C#
> because you already have that js cross-compiler. You thoughts are about
> making the same in different platform versions in the end?.
>
> That is the goal.
>
> >* I understand that the final goal is that you end programming in your
> platform and don't touch JS...all will be in C# (or Java, or AS, orHaxe,...)
>
> Not true. There will be some JS because there are some things that should
> be JS. The goal is to make the logic of your program in a language that is
> more appropriate but still use JS libraries or create JS where it makes
> sense.
>
> >* For me the browsers VM is a real problem. Each one is diferent and
> fragmentation is a nightmare. In the end for me, in the past, all
> technologies wich is final product was HTML/JS where off consideration
> since the final technology was bad. (i.e: Java Server Faces, JSP, ...)
>
> I think you need to re-evaluate as I believe you are wrong. The VM in the
> browsers is very consistent and in many cases much faster than Flash. In
> many cases, it is much better. There is some (minimal) fragmentation on the
> JavaScript virtual machine. There is A LOT of fragmentation on how the
> browsers render HTML and CSS. All of these other technologies fail, IMO, as
> they try to encapsulate the view and logic in one programming model. To me,
> the view logic needs to be crafted for the browsers you care to use, but
> the logic should remain 100% consistent across all of them.
>
> * This approach seems to only take into account HTML/JS, and I think that
> it should have SWF, and other output possibilities.
> >You can certainly do so. I personally don't care about the SWF format.
>
> For me HTML/JS would be powerful to be ok with people demanding HTML5, but
> having the "advanced" solution to target Flash, mobile, etc...
> > Again, you are free to do so. IMO, this is not the direction the world
> is moving.
>
> * This is too new for me, but I'm learning how Haxe works and I see that
> they generates complete native projects. So you develop in Haxe and the
> output is native ios, android, flash, HTML...and so on. I think that your
> framework could fit very well in that space, what do you think?
>
> >I hope so. I originally wrote the prototype of this framework in Haxe. I
> went to C# honestly because I was targeting enterprises and the Microsoft
> tooling appealed to enterprises much more than the tooling available for
> Haxe.
>
> Mike
>
>
RE: Randori framework [was Re: What to expect from FalconJS]
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>* You say this could be C#/Java/AS and so on... I think you start in C# because you already have that js cross-compiler. You thoughts are about making the same in different platform versions in the end?.
That is the goal.
>* I understand that the final goal is that you end programming in your platform and don't touch JS...all will be in C# (or Java, or AS, orHaxe,...)
Not true. There will be some JS because there are some things that should be JS. The goal is to make the logic of your program in a language that is more appropriate but still use JS libraries or create JS where it makes sense.
>* For me the browsers VM is a real problem. Each one is diferent and fragmentation is a nightmare. In the end for me, in the past, all technologies wich is final product was HTML/JS where off consideration since the final technology was bad. (i.e: Java Server Faces, JSP, ...)
I think you need to re-evaluate as I believe you are wrong. The VM in the browsers is very consistent and in many cases much faster than Flash. In many cases, it is much better. There is some (minimal) fragmentation on the JavaScript virtual machine. There is A LOT of fragmentation on how the browsers render HTML and CSS. All of these other technologies fail, IMO, as they try to encapsulate the view and logic in one programming model. To me, the view logic needs to be crafted for the browsers you care to use, but the logic should remain 100% consistent across all of them.
* This approach seems to only take into account HTML/JS, and I think that it should have SWF, and other output possibilities.
>You can certainly do so. I personally don't care about the SWF format.
For me HTML/JS would be powerful to be ok with people demanding HTML5, but having the "advanced" solution to target Flash, mobile, etc...
> Again, you are free to do so. IMO, this is not the direction the world is moving.
* This is too new for me, but I'm learning how Haxe works and I see that they generates complete native projects. So you develop in Haxe and the output is native ios, android, flash, HTML...and so on. I think that your framework could fit very well in that space, what do you think?
>I hope so. I originally wrote the prototype of this framework in Haxe. I went to C# honestly because I was targeting enterprises and the Microsoft tooling appealed to enterprises much more than the tooling available for Haxe.
Mike
Re: Randori framework [was Re: What to expect from FalconJS]
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Mike,
I just saw the slides and it's very interesting. Thanks for sharing.
Various thoughts/questions here:
* You say this could be C#/Java/AS and so on... I think you start in C#
because you already have that js cross-compiler. You thoughts are about
making the same in different platform versions in the end?.
* I understand that the final goal is that you end programming in your
platform and don't touch JS...all will be in C# (or Java, or AS, or
Haxe,...)
* For me the browsers VM is a real problem. Each one is diferent and
fragmentation is a nightmare. In the end for me, in the past, all
technologies wich is final product was HTML/JS where off consideration
since the final technology was bad. (i.e: Java Server Faces, JSP, ...)
* This approach seems to only take into account HTML/JS, and I think that
it should have SWF, and other output possibilities. For me HTML/JS would be
powerful to be ok with people demanding HTML5, but having the "advanced"
solution to target Flash, mobile, etc...
* This is too new for me, but I'm learning how Haxe works and I see that
they generates complete native projects. So you develop in Haxe and the
output is native ios, android, flash, HTML...and so on. I think that your
framework could fit very well in that space, what do you think?
Again, thanks for share your vision. Very inspiring one.
Best,
Carlos
2012/11/17 Michael A. Labriola <la...@digitalprimates.net>
> >What I don't get is, Mike said all these other companies that had
> compiler engineers are not here, meaning they are somewhere else. So Mike
> has put his time working with C# and a cross compiler /JS framework.
>
> Actually, I found a really good cross-compiler from C# to JS that was
> extensible. So, instead of inventing the wheel to do a POC, I used
> something off the shelf. If FalconJS was here and extensible, I would have
> built it on top of that first.
>
> >Mike Does this have anything to do with this project? Or are you planning
> on heading in your own direction with the Randori framework?
>
> I think there are some borders and it will really depend on this group and
> what we all want to do. Randori isn’t really just about C#, it's more of an
> idea that we could do with Java/C#/AS/Whatever. I could see Flex being a
> component framework that follows a strategy and exists in the space to all
> a familiar development paradigm. I just don’t want to make the same
> mistakes that I think we have with Flex now.
>
> >BTW Mike, I really do agree with how you summarized the problems that are
> occurring today with Javascript and the View layer.
>
> Thanks,
>
> Mike
>
> Quoting Joan Llenas Masó <jo...@garnetworks.com>:
>
> > I think I'm able to get your point after watching these slides and
> > mixing it together with what you mentioned earlier on in another thread.
> > So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> > translation we just concentrate our efforts in the business logic code
> > translation AS3->{MyOutputTargetOfChioce}.
> > The views on the other hand are implemented natively in the language
> > of choice, being it AS3, JS or whatever.
> > Finally MXML comes to rescue giving us the power of componetization
> > and view declaration.
> > This way we can implement same set of components for different output
> > targets but declare them in the same way.
> > FalconJS will take care of the rest.
> >
> > Am I right? or did I make my own movie...
> >
> > Anyway, I see maaaaany advantages here. Wow, I love it. This is
> > actually the essence of Flex taken to the next level :) Well, I see
> > Haxe fitting here as well. Actually we could plug many packaging tools
> > in the FlaconJS "output port".
> >
> > Can't wait to see more!
> >
> > Cheers!
> >
> >
> > On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> >
> >> >> In the meantime, make sure you look at the slide deck from
> >> >> Michael Labriola¹s 360Min presentation on how he is developing apps
> for HTML.
> >> I¹m
> >> >> sure he¹ll reply with the link
> >> >
> >> > Is the slidedeck already pulished somewhere?
> >> >
> >>
> >> http://www.slideshare.net/michael.labriola/randori-design-goals-and-j
> >> ustific
> >> ation
> >>
> >> --
> >> 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
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
RE: Randori framework [was Re: What to expect from FalconJS]
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>What I don't get is, Mike said all these other companies that had compiler engineers are not here, meaning they are somewhere else. So Mike has put his time working with C# and a cross compiler /JS framework.
Actually, I found a really good cross-compiler from C# to JS that was extensible. So, instead of inventing the wheel to do a POC, I used something off the shelf. If FalconJS was here and extensible, I would have built it on top of that first.
>Mike Does this have anything to do with this project? Or are you planning on heading in your own direction with the Randori framework?
I think there are some borders and it will really depend on this group and what we all want to do. Randori isn’t really just about C#, it's more of an idea that we could do with Java/C#/AS/Whatever. I could see Flex being a component framework that follows a strategy and exists in the space to all a familiar development paradigm. I just don’t want to make the same mistakes that I think we have with Flex now.
>BTW Mike, I really do agree with how you summarized the problems that are occurring today with Javascript and the View layer.
Thanks,
Mike
Quoting Joan Llenas Masó <jo...@garnetworks.com>:
> I think I'm able to get your point after watching these slides and
> mixing it together with what you mentioned earlier on in another thread.
> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> translation we just concentrate our efforts in the business logic code
> translation AS3->{MyOutputTargetOfChioce}.
> The views on the other hand are implemented natively in the language
> of choice, being it AS3, JS or whatever.
> Finally MXML comes to rescue giving us the power of componetization
> and view declaration.
> This way we can implement same set of components for different output
> targets but declare them in the same way.
> FalconJS will take care of the rest.
>
> Am I right? or did I make my own movie...
>
> Anyway, I see maaaaany advantages here. Wow, I love it. This is
> actually the essence of Flex taken to the next level :) Well, I see
> Haxe fitting here as well. Actually we could plug many packaging tools
> in the FlaconJS "output port".
>
> Can't wait to see more!
>
> Cheers!
>
>
> On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> >
>> >> In the meantime, make sure you look at the slide deck from
>> >> Michael Labriola¹s 360Min presentation on how he is developing apps for HTML.
>> I¹m
>> >> sure he¹ll reply with the link
>> >
>> > Is the slidedeck already pulished somewhere?
>> >
>>
>> http://www.slideshare.net/michael.labriola/randori-design-goals-and-j
>> ustific
>> ation
>>
>> --
>> 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
Randori framework [was Re: What to expect from FalconJS]
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I watched the slides to, he mentioned C#. I saw something on Mike's
Twitter that said he would be getting something in GITHub next week
Joan, I agree his presentation made sense. What you are saying makes
sense to with the view mediator approach, you are completely dumbing
down the view using mediator injection.
What I don't get is, Mike said all these other companies that had
compiler engineers are not here, meaning they are somewhere else. So
Mike has put his time working with C# and a cross compiler /JS
framework.
Mike Does this have anything to do with this project? Or are you
planning on heading in your own direction with the Randori framework?
BTW Mike, I really do agree with how you summarized the problems that
are occurring today with Javascript and the View layer.
Mike
Quoting Joan Llenas Masó <jo...@garnetworks.com>:
> I think I'm able to get your point after watching these slides and mixing
> it together with what you mentioned earlier on in another thread.
> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> translation we just concentrate our efforts in the business logic code
> translation AS3->{MyOutputTargetOfChioce}.
> The views on the other hand are implemented natively in the language of
> choice, being it AS3, JS or whatever.
> Finally MXML comes to rescue giving us the power of componetization and
> view declaration.
> This way we can implement same set of components for different output
> targets but declare them in the same way.
> FalconJS will take care of the rest.
>
> Am I right? or did I make my own movie...
>
> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
> the essence of Flex taken to the next level :)
> Well, I see Haxe fitting here as well. Actually we could plug many
> packaging tools in the FlaconJS "output port".
>
> Can't wait to see more!
>
> Cheers!
>
>
> On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> >
>> >> In the meantime, make sure you look at the slide deck from Michael
>> >> Labriola¹s 360Min presentation on how he is developing apps for HTML.
>> I¹m
>> >> sure he¹ll reply with the link
>> >
>> > Is the slidedeck already pulished somewhere?
>> >
>>
>> http://www.slideshare.net/michael.labriola/randori-design-goals-and-justific
>> ation
>>
>> --
>> 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: What to expect from FalconJS
Posted by Gordon Smith <go...@adobe.com>.
We're not using LLVM in Adobe's AS4 compiler. The new compiler works just like Falcon's AS3 except it has a somewhat different lexer/parser due to the syntactic changes, a somewhat different semantic analyzer due to the semantic changes, and a quite different code generator due to the new byte code and ABC format for V12.
- Gordon
Sent from my iPad
On Nov 18, 2012, at 8:53 PM, "Kevin Newman" <Ca...@unFocus.com> wrote:
> There are two different Flash related LLVM products at Adobe, afaik.
>
> They have an LLVM frontend which takes ABC code and turns that into ARM
> code for packing on iPhone. Then there's the Alchemy stuff, which is an
> LLVM backend, for generating ABC bytecode from other front ends like C
> and C++. There are lots of stack exchange posts about both of these, and
> how they work.
>
> I'd guess neither of those are actually useful to build an AS3 front end
> (well maybe the ABC front end has similar data structures? IDK).
>
> Apache can't leverage either, since Adobe hasn't opened them up. I was
> more curious about what would be involved with starting from scratch on
> an LLVM frontend for AS3 (or starting from a similar one, like
> JavaScript - I couldn't find one though). I assume it's a great deal of
> work (probably prohibitively so) - but I'm still curious. :-)
>
> I have no idea if they are using LLVM in future versions of ASNext
> compilers - but I have thought they would, cause why not! Recent info on
> ASC2.0 (like their inline optimization) suggests maybe not. I don't
> know, you'd have to ask the folks at Adobe (so far they ain't talking
> much about ASNext though - I got the most info yet on it from this list).
>
> Kevin N.
>
>
> On 11/18/2012 12:17 AM, Alex Harui wrote:
>> I could be wrong, but I don't think LLVM is involved in Falcon or FalconJS.
>> It think it may be used in captive runtime so that may be why you associated
>> it with the compiler. But that stuff is in the AIR SDK and not in Apache.
>
Re: What to expect from FalconJS
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
Thanks for the clarification. I knew I saw some stuff about LLVM in one of
the presentations I attended -- I just wasn't sure to what degree.
-Nick
On Sun, Nov 18, 2012 at 11:53 PM, Kevin Newman <Ca...@unfocus.com> wrote:
> There are two different Flash related LLVM products at Adobe, afaik.
>
> They have an LLVM frontend which takes ABC code and turns that into ARM
> code for packing on iPhone. Then there's the Alchemy stuff, which is an
> LLVM backend, for generating ABC bytecode from other front ends like C and
> C++. There are lots of stack exchange posts about both of these, and how
> they work.
>
> I'd guess neither of those are actually useful to build an AS3 front end
> (well maybe the ABC front end has similar data structures? IDK).
>
> Apache can't leverage either, since Adobe hasn't opened them up. I was
> more curious about what would be involved with starting from scratch on an
> LLVM frontend for AS3 (or starting from a similar one, like JavaScript - I
> couldn't find one though). I assume it's a great deal of work (probably
> prohibitively so) - but I'm still curious. :-)
>
> I have no idea if they are using LLVM in future versions of ASNext
> compilers - but I have thought they would, cause why not! Recent info on
> ASC2.0 (like their inline optimization) suggests maybe not. I don't know,
> you'd have to ask the folks at Adobe (so far they ain't talking much about
> ASNext though - I got the most info yet on it from this list).
>
> Kevin N.
>
>
>
> On 11/18/2012 12:17 AM, Alex Harui wrote:
>
>> I could be wrong, but I don't think LLVM is involved in Falcon or
>> FalconJS.
>> It think it may be used in captive runtime so that may be why you
>> associated
>> it with the compiler. But that stuff is in the AIR SDK and not in Apache.
>>
>
>
Re: What to expect from FalconJS
Posted by Kevin Newman <Ca...@unFocus.com>.
There are two different Flash related LLVM products at Adobe, afaik.
They have an LLVM frontend which takes ABC code and turns that into ARM
code for packing on iPhone. Then there's the Alchemy stuff, which is an
LLVM backend, for generating ABC bytecode from other front ends like C
and C++. There are lots of stack exchange posts about both of these, and
how they work.
I'd guess neither of those are actually useful to build an AS3 front end
(well maybe the ABC front end has similar data structures? IDK).
Apache can't leverage either, since Adobe hasn't opened them up. I was
more curious about what would be involved with starting from scratch on
an LLVM frontend for AS3 (or starting from a similar one, like
JavaScript - I couldn't find one though). I assume it's a great deal of
work (probably prohibitively so) - but I'm still curious. :-)
I have no idea if they are using LLVM in future versions of ASNext
compilers - but I have thought they would, cause why not! Recent info on
ASC2.0 (like their inline optimization) suggests maybe not. I don't
know, you'd have to ask the folks at Adobe (so far they ain't talking
much about ASNext though - I got the most info yet on it from this list).
Kevin N.
On 11/18/2012 12:17 AM, Alex Harui wrote:
> I could be wrong, but I don't think LLVM is involved in Falcon or FalconJS.
> It think it may be used in captive runtime so that may be why you associated
> it with the compiler. But that stuff is in the AIR SDK and not in Apache.
RE: What to expect from FalconJS
Posted by Gordon Smith <go...@adobe.com>.
> I don't think LLVM is involved in Falcon or FalconJS.
That's correct.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Saturday, November 17, 2012 9:47 PM
To: flex-dev@incubator.apache.org
Subject: Re: What to expect from FalconJS
On 11/17/12 9:17 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 11/17/12 9:14 PM, "Nicholas Kwiatkowski" <ni...@spoon.as> wrote:
>
>> Kevin,
>>
>> I'm pretty sure that is what the existing compiler pretty much is. I
>> know they have mentioned LLMV being involved, but I'm not sure to
>> what point (I'm not experienced with this compiler myself...)
> I could be wrong, but I don't think LLVM is involved in Falcon or FalconJS.
> It think it may be used in captive runtime so that may be why you
> associated it with the compiler. But that stuff is in the AIR SDK and not in Apache.
Or maybe it is used in Alchemy. But I don't think it is used in AS3->SWF or
AS3->JS.
>>
>> -Nick
>>
>> On Sat, Nov 17, 2012 at 7:15 PM, Kevin Newman <Ca...@unfocus.com> wrote:
>>
>>> I don't know much about compilers, or about how much work it'll be,
>>> but that's my question.
>>>
>>> How much work would writing an AS3 front end for LLVM be? I imagine
>>> it's a lot of work.
>>>
>>> Adobe did it with ABC bytecode, so it seems it should be
>>> theoretically possible (if a lot of work). There are backends for a
>>> bunch of stuff in LLVM, including one for javascript.
>>>
>>> Kevin N.
>>>
>>>
>>>
>>> On 11/17/2012 1:01 PM, sébastien Paturel wrote:
>>>
>>>> "how can you cross compile AS3 to native code"
>>>>
>>>
>>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: What to expect from FalconJS
Posted by Alex Harui <ah...@adobe.com>.
On 11/17/12 9:17 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 11/17/12 9:14 PM, "Nicholas Kwiatkowski" <ni...@spoon.as> wrote:
>
>> Kevin,
>>
>> I'm pretty sure that is what the existing compiler pretty much is. I know
>> they have mentioned LLMV being involved, but I'm not sure to what point
>> (I'm not experienced with this compiler myself...)
> I could be wrong, but I don't think LLVM is involved in Falcon or FalconJS.
> It think it may be used in captive runtime so that may be why you associated
> it with the compiler. But that stuff is in the AIR SDK and not in Apache.
Or maybe it is used in Alchemy. But I don't think it is used in AS3->SWF or
AS3->JS.
>>
>> -Nick
>>
>> On Sat, Nov 17, 2012 at 7:15 PM, Kevin Newman <Ca...@unfocus.com> wrote:
>>
>>> I don't know much about compilers, or about how much work it'll be, but
>>> that's my question.
>>>
>>> How much work would writing an AS3 front end for LLVM be? I imagine it's a
>>> lot of work.
>>>
>>> Adobe did it with ABC bytecode, so it seems it should be theoretically
>>> possible (if a lot of work). There are backends for a bunch of stuff in
>>> LLVM, including one for javascript.
>>>
>>> Kevin N.
>>>
>>>
>>>
>>> On 11/17/2012 1:01 PM, sébastien Paturel wrote:
>>>
>>>> "how can you cross compile AS3 to native code"
>>>>
>>>
>>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: What to expect from FalconJS
Posted by Alex Harui <ah...@adobe.com>.
On 11/17/12 9:14 PM, "Nicholas Kwiatkowski" <ni...@spoon.as> wrote:
> Kevin,
>
> I'm pretty sure that is what the existing compiler pretty much is. I know
> they have mentioned LLMV being involved, but I'm not sure to what point
> (I'm not experienced with this compiler myself...)
I could be wrong, but I don't think LLVM is involved in Falcon or FalconJS.
It think it may be used in captive runtime so that may be why you associated
it with the compiler. But that stuff is in the AIR SDK and not in Apache.
>
> -Nick
>
> On Sat, Nov 17, 2012 at 7:15 PM, Kevin Newman <Ca...@unfocus.com> wrote:
>
>> I don't know much about compilers, or about how much work it'll be, but
>> that's my question.
>>
>> How much work would writing an AS3 front end for LLVM be? I imagine it's a
>> lot of work.
>>
>> Adobe did it with ABC bytecode, so it seems it should be theoretically
>> possible (if a lot of work). There are backends for a bunch of stuff in
>> LLVM, including one for javascript.
>>
>> Kevin N.
>>
>>
>>
>> On 11/17/2012 1:01 PM, sébastien Paturel wrote:
>>
>>> "how can you cross compile AS3 to native code"
>>>
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: What to expect from FalconJS
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
Kevin,
I'm pretty sure that is what the existing compiler pretty much is. I know
they have mentioned LLMV being involved, but I'm not sure to what point
(I'm not experienced with this compiler myself...)
-Nick
On Sat, Nov 17, 2012 at 7:15 PM, Kevin Newman <Ca...@unfocus.com> wrote:
> I don't know much about compilers, or about how much work it'll be, but
> that's my question.
>
> How much work would writing an AS3 front end for LLVM be? I imagine it's a
> lot of work.
>
> Adobe did it with ABC bytecode, so it seems it should be theoretically
> possible (if a lot of work). There are backends for a bunch of stuff in
> LLVM, including one for javascript.
>
> Kevin N.
>
>
>
> On 11/17/2012 1:01 PM, sébastien Paturel wrote:
>
>> "how can you cross compile AS3 to native code"
>>
>
>
Re: What to expect from FalconJS
Posted by Kevin Newman <Ca...@unFocus.com>.
I don't know much about compilers, or about how much work it'll be, but
that's my question.
How much work would writing an AS3 front end for LLVM be? I imagine it's
a lot of work.
Adobe did it with ABC bytecode, so it seems it should be theoretically
possible (if a lot of work). There are backends for a bunch of stuff in
LLVM, including one for javascript.
Kevin N.
On 11/17/2012 1:01 PM, sébastien Paturel wrote:
> "how can you cross compile AS3 to native code"
Re: What to expect from FalconJS
Posted by Alex Harui <ah...@adobe.com>.
On 11/17/12 10:01 AM, "sébastien Paturel" <se...@gmail.com> wrote:
> it depends.
> if the plan is to fully transcode flex app in HTML/JS and then use
> cordova to make it run as native app, yes i have reasons to think that
> it will have poor performances, because in the end it is still an
> HTML/JS app.
I haven't spent any time profiling JS apps. I have seen some data that says
that JS runs faster than AS in certain situations, and work continues with
JS runtimes to make them faster, the same is not true for the AS runtime.
> if you only use this path for UI, and managed to transcode the logic in
> a real native code, why not.
> If separating the UI management make the cross compilation more easy,
> maybe it can be a viable solution. but it gets back to the question "how
> can you cross compile AS3 to native code".
It isn't obvious to me that if you can translate AS3 to JS why you couldn't
spit out some other language instead.
> And haxe made the choice to change AS3 language to make it more easy to
> cross compile. it means that it is not easy task.
For sure, it won't be an easy task.
I'm just getting started with Cordova. If Cordova is too slow either they
will find a way to improve it, or it will fade away. But it is exists today
and a FalconJ or FalconObjectiveC doesn't. And, I believe it can at least
scroll a textinput and still give native text completion.
Everything we are doing is to provide abstractions to make different targets
possible. All of those things eat away at performance. That's the price you
pay.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: What to expect from FalconJS
Posted by sébastien Paturel <se...@gmail.com>.
it depends.
if the plan is to fully transcode flex app in HTML/JS and then use
cordova to make it run as native app, yes i have reasons to think that
it will have poor performances, because in the end it is still an
HTML/JS app.
if you only use this path for UI, and managed to transcode the logic in
a real native code, why not.
If separating the UI management make the cross compilation more easy,
maybe it can be a viable solution. but it gets back to the question "how
can you cross compile AS3 to native code".
And haxe made the choice to change AS3 language to make it more easy to
cross compile. it means that it is not easy task.
Le 17/11/2012 18:08, Joan Llenas Masó a écrit :
> I'm not Alex, but IMHO taking into account that most UI code will have to
> be written natively for each output target and that UI code tends to be the
> main bottleneck in nowdays apps there's no reason to think that this new
> system would output very poor performant code or bytecode.
> Also, for very performance intensive business operations (I guess) we could
> do the same as with UI code and create native versions and execute them
> through narrow interfaced proxies.
> Same philosophy as Randori I'd say.
>
> Cheers
>
>
>
>
> On Sat, Nov 17, 2012 at 5:51 PM, sébastien Paturel
> <se...@gmail.com>wrote:
>
>> Hi Alex,
>> do you also have in mind to use HTML/JS as main output before cross
>> platform achievment (for example using Cordova)?
>> if so, don't you expect very poor performances with this strategy?
>>
>>
>> Le 17/11/2012 17:05, Alex Harui a écrit :
>>
>>
>>> On 11/17/12 2:47 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
>>>
>>> I think I'm able to get your point after watching these slides and mixing
>>>> it together with what you mentioned earlier on in another thread.
>>>> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
>>>> translation we just concentrate our efforts in the business logic code
>>>> translation AS3->{MyOutputTargetOfChioce}.
>>>> The views on the other hand are implemented natively in the language of
>>>> choice, being it AS3, JS or whatever.
>>>> Finally MXML comes to rescue giving us the power of componetization and
>>>> view declaration.
>>>> This way we can implement same set of components for different output
>>>> targets but declare them in the same way.
>>>> FalconJS will take care of the rest.
>>>>
>>>> Am I right? or did I make my own movie...
>>>>
>>> Believe me, my vision and prototype is not completely thought out. I'm
>>> depending on the rest of the community to help steer and create, but I
>>> think
>>> that you have the basic idea that I have in my head.
>>>
>>>> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
>>>> the essence of Flex taken to the next level :)
>>>> Well, I see Haxe fitting here as well. Actually we could plug many
>>>> packaging tools in the FlaconJS "output port".
>>>>
>>>>
Re: What to expect from FalconJS
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Seems to me The same philosophy behind haxenme, isn'it?
Haxenme generates native code and projects for each platform...
El sábado, 17 de noviembre de 2012, Joan Llenas Masó escribió:
> I'm not Alex, but IMHO taking into account that most UI code will have to
> be written natively for each output target and that UI code tends to be the
> main bottleneck in nowdays apps there's no reason to think that this new
> system would output very poor performant code or bytecode.
> Also, for very performance intensive business operations (I guess) we could
> do the same as with UI code and create native versions and execute them
> through narrow interfaced proxies.
> Same philosophy as Randori I'd say.
>
> Cheers
>
>
>
>
> On Sat, Nov 17, 2012 at 5:51 PM, sébastien Paturel
> <sebpatu.flex@gmail.com <javascript:;>>wrote:
>
> > Hi Alex,
> > do you also have in mind to use HTML/JS as main output before cross
> > platform achievment (for example using Cordova)?
> > if so, don't you expect very poor performances with this strategy?
> >
> >
> > Le 17/11/2012 17:05, Alex Harui a écrit :
> >
> >
> >>
> >> On 11/17/12 2:47 AM, "Joan Llenas Masó" <joan@garnetworks.com<javascript:;>>
> wrote:
> >>
> >> I think I'm able to get your point after watching these slides and
> mixing
> >>> it together with what you mentioned earlier on in another thread.
> >>> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> >>> translation we just concentrate our efforts in the business logic code
> >>> translation AS3->{MyOutputTargetOfChioce}.
> >>> The views on the other hand are implemented natively in the language of
> >>> choice, being it AS3, JS or whatever.
> >>> Finally MXML comes to rescue giving us the power of componetization and
> >>> view declaration.
> >>> This way we can implement same set of components for different output
> >>> targets but declare them in the same way.
> >>> FalconJS will take care of the rest.
> >>>
> >>> Am I right? or did I make my own movie...
> >>>
> >> Believe me, my vision and prototype is not completely thought out. I'm
> >> depending on the rest of the community to help steer and create, but I
> >> think
> >> that you have the basic idea that I have in my head.
> >>
> >>> Anyway, I see maaaaany advantages here. Wow, I love it. This is
> actually
> >>> the essence of Flex taken to the next level :)
> >>> Well, I see Haxe fitting here as well. Actually we could plug many
> >>> packaging tools in the FlaconJS "output port".
> >>>
> >>>
> >
>
--
Sent from Gmail Mobile
Re: What to expect from FalconJS
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
I'm not Alex, but IMHO taking into account that most UI code will have to
be written natively for each output target and that UI code tends to be the
main bottleneck in nowdays apps there's no reason to think that this new
system would output very poor performant code or bytecode.
Also, for very performance intensive business operations (I guess) we could
do the same as with UI code and create native versions and execute them
through narrow interfaced proxies.
Same philosophy as Randori I'd say.
Cheers
On Sat, Nov 17, 2012 at 5:51 PM, sébastien Paturel
<se...@gmail.com>wrote:
> Hi Alex,
> do you also have in mind to use HTML/JS as main output before cross
> platform achievment (for example using Cordova)?
> if so, don't you expect very poor performances with this strategy?
>
>
> Le 17/11/2012 17:05, Alex Harui a écrit :
>
>
>>
>> On 11/17/12 2:47 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
>>
>> I think I'm able to get your point after watching these slides and mixing
>>> it together with what you mentioned earlier on in another thread.
>>> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
>>> translation we just concentrate our efforts in the business logic code
>>> translation AS3->{MyOutputTargetOfChioce}.
>>> The views on the other hand are implemented natively in the language of
>>> choice, being it AS3, JS or whatever.
>>> Finally MXML comes to rescue giving us the power of componetization and
>>> view declaration.
>>> This way we can implement same set of components for different output
>>> targets but declare them in the same way.
>>> FalconJS will take care of the rest.
>>>
>>> Am I right? or did I make my own movie...
>>>
>> Believe me, my vision and prototype is not completely thought out. I'm
>> depending on the rest of the community to help steer and create, but I
>> think
>> that you have the basic idea that I have in my head.
>>
>>> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
>>> the essence of Flex taken to the next level :)
>>> Well, I see Haxe fitting here as well. Actually we could plug many
>>> packaging tools in the FlaconJS "output port".
>>>
>>>
>
Re: What to expect from FalconJS
Posted by sébastien Paturel <se...@gmail.com>.
Hi Alex,
do you also have in mind to use HTML/JS as main output before cross
platform achievment (for example using Cordova)?
if so, don't you expect very poor performances with this strategy?
Le 17/11/2012 17:05, Alex Harui a écrit :
>
>
> On 11/17/12 2:47 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
>
>> I think I'm able to get your point after watching these slides and mixing
>> it together with what you mentioned earlier on in another thread.
>> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
>> translation we just concentrate our efforts in the business logic code
>> translation AS3->{MyOutputTargetOfChioce}.
>> The views on the other hand are implemented natively in the language of
>> choice, being it AS3, JS or whatever.
>> Finally MXML comes to rescue giving us the power of componetization and
>> view declaration.
>> This way we can implement same set of components for different output
>> targets but declare them in the same way.
>> FalconJS will take care of the rest.
>>
>> Am I right? or did I make my own movie...
> Believe me, my vision and prototype is not completely thought out. I'm
> depending on the rest of the community to help steer and create, but I think
> that you have the basic idea that I have in my head.
>> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
>> the essence of Flex taken to the next level :)
>> Well, I see Haxe fitting here as well. Actually we could plug many
>> packaging tools in the FlaconJS "output port".
>>
Re: What to expect from FalconJS
Posted by Alex Harui <ah...@adobe.com>.
On 11/17/12 2:47 AM, "Joan Llenas Masó" <jo...@garnetworks.com> wrote:
> I think I'm able to get your point after watching these slides and mixing
> it together with what you mentioned earlier on in another thread.
> So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
> translation we just concentrate our efforts in the business logic code
> translation AS3->{MyOutputTargetOfChioce}.
> The views on the other hand are implemented natively in the language of
> choice, being it AS3, JS or whatever.
> Finally MXML comes to rescue giving us the power of componetization and
> view declaration.
> This way we can implement same set of components for different output
> targets but declare them in the same way.
> FalconJS will take care of the rest.
>
> Am I right? or did I make my own movie...
Believe me, my vision and prototype is not completely thought out. I'm
depending on the rest of the community to help steer and create, but I think
that you have the basic idea that I have in my head.
>
> Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
> the essence of Flex taken to the next level :)
> Well, I see Haxe fitting here as well. Actually we could plug many
> packaging tools in the FlaconJS "output port".
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: What to expect from FalconJS
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
I think I'm able to get your point after watching these slides and mixing
it together with what you mentioned earlier on in another thread.
So instead of going through direct UI AS3->{MyOutputTargetOfChioce}
translation we just concentrate our efforts in the business logic code
translation AS3->{MyOutputTargetOfChioce}.
The views on the other hand are implemented natively in the language of
choice, being it AS3, JS or whatever.
Finally MXML comes to rescue giving us the power of componetization and
view declaration.
This way we can implement same set of components for different output
targets but declare them in the same way.
FalconJS will take care of the rest.
Am I right? or did I make my own movie...
Anyway, I see maaaaany advantages here. Wow, I love it. This is actually
the essence of Flex taken to the next level :)
Well, I see Haxe fitting here as well. Actually we could plug many
packaging tools in the FlaconJS "output port".
Can't wait to see more!
Cheers!
On Sat, Nov 17, 2012 at 4:57 AM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> In the meantime, make sure you look at the slide deck from Michael
> >> Labriola¹s 360Min presentation on how he is developing apps for HTML.
> I¹m
> >> sure he¹ll reply with the link
> >
> > Is the slidedeck already pulished somewhere?
> >
>
> http://www.slideshare.net/michael.labriola/randori-design-goals-and-justific
> ation
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: Presentation Recording ( was Re: What to expect from FalconJS)
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
Oh, Thank for letting us know!
Joan
Presentation Recording ( was Re: What to expect from FalconJS)
Posted by Jeffry Houser <je...@dot-com-it.com>.
The 360|Min posted a recording of this presentation, just for us:
http://www.360stack.com/session-videos/free-session-recording/
On 11/16/2012 10:57 PM, Alex Harui wrote:
>>> In the meantime, make sure you look at the slide deck from Michael
>>> Labriola¹s 360Min presentation on how he is developing apps for HTML. I¹m
>>> sure he¹ll reply with the link
>> Is the slidedeck already pulished somewhere?
>>
> http://www.slideshare.net/michael.labriola/randori-design-goals-and-justific
> ation
>
Re: What to expect from FalconJS
Posted by Alex Harui <ah...@adobe.com>.
>
>> In the meantime, make sure you look at the slide deck from Michael
>> Labriola¹s 360Min presentation on how he is developing apps for HTML. I¹m
>> sure he¹ll reply with the link
>
> Is the slidedeck already pulished somewhere?
>
http://www.slideshare.net/michael.labriola/randori-design-goals-and-justific
ation
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: What to expect from FalconJS
Posted by Cyrill Zadra <cy...@gmail.com>.
> I have been playing around with Falcon JS to help me form an opinion on what the next steps are, but I need some sign-offs from folks in Adobe before I can make it public
Looking forward to read your opinion.
> In the meantime, make sure you look at the slide deck from Michael Labriola’s 360Min presentation on how he is developing apps for HTML. I’m sure he’ll reply with the link
Is the slidedeck already pulished somewhere?
cyrill
On Fri, Nov 16, 2012 at 9:08 AM, Alex Harui <ah...@adobe.com> wrote:
> It has been almost a year since we announced Flex would be donated to Apache. We’ve spent all of this time preparing donations of the code. It has taken much longer than I would have ever imagined, but we are almost done. The FalconJS code passed legal review yesterday and just needs a few other approvals before being donated.
>
> I’ve had some time to play with it. It can definitely take a simple AS class and spit out that class in JS in a predictable pattern. What the donated code will not do is convert an entire Flex app into a running HTML/CSS/JS app. In fact, it won’t even take a simple AS project and generated a running HTML/CSS/JS page. That’s because only the code that converts the AST to JS is being donated. If you ever saw the demo, there was a whole bunch of JS code that could mimic FlashPlayer APIs and render Flash visuals to SVG. That code is not being donated, and, I don’t think we want it. That’s because Flex is all about interaction and rendering to SVG is not a rendering that would be interactive.
>
> I have been playing around with Falcon JS to help me form an opinion on what the next steps are, but I need some sign-offs from folks in Adobe before I can make it public. In the meantime, make sure you look at the slide deck from Michael Labriola’s 360Min presentation on how he is developing apps for HTML. I’m sure he’ll reply with the link. There are three things I think you should take away from that deck: 1) that there is an alternative really soon if you want to move to C#, and 2) that “finishing” the UI is very expensive due to rendering differences between browsers, and 3) that having good separation between UI and business logic is key to having an efficient way of “finishing” your UI.
>
> These will be important things to keep in mind as we go forward.
>
> Later,
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui