> 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
