>> 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.
Yes, I share that worry. In fact, I think it's basically a certainty that whatever (non-)pattern is chosen, it will fail once the compiler matures and more and more AS3 needs to be mapped. I think a period of trail and error and lots of test cases will be inevitable. False starts will be made and weird workarounds will be needed, no doubt about it. If it were easy, where would the fun be, right ;-) >>>> 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. 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. 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. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
