incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <>
Subject Re: FalconJS has landed
Date Tue, 27 Nov 2012 00:29:58 GMT
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 
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 
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.


On 11/26/2012 9:32 PM, Alex Harui wrote:
> On 11/26/12 1:15 PM, "Erik de Bruin" <> 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.

View raw message