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" <e...@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.
