On 11/26/12 11:12 AM, "Erik de Bruin" <e...@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
