incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: FalconJS has landed
Date Mon, 26 Nov 2012 19:12:01 GMT
> 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

Mime
View raw message