Alex, Wow! Awesome email, if nothing else then only by weight of the bytes ;-)
I'm not sure you entirely get what I'm trying to do, but keeping an open mind I'm looking for ways to combine the two approaches. You seem to be suggesting that VF2JS can exist as an option in FlexJS. We need to explore that idea to see if we might be able to make it work. 1) Currently, FlexJS has it's own AS framework, without any of the Spark/MX components. VF2JS needs those; remember, VF2JS let's users develop their SWF apps in the classic SDK, like they are used to. Do you suggest we merge FlexJS into the current SDK? 2) The FlexJS JS implementation uses data arrays to represent MXML. This means that class member names are stored as strings. The GCC can't rename strings. In order to match the strings to the actual properties, the properties cannot be renamed either - you can't match 'myComponent.width' to 'a.b' ;-) This is why all public properties have the @expose annotation. But here is the kicker: using @expose prevents the GCC from doing a significant amount of optimisations. In VF2JS I'm planning on doing away with the data arrays so we get to use the full force of GCC optimisation and minification, and can do away with the client side dynamic object creation from the array. 3) I'm liking the idea of having FalconJX detect the namespaces it is fed and use that information to decide the compile path. That way if it reads Spark/MX, it would use the VF2JS JS framework, if it reads Basic/Core, if would go the FlexJS route. 4) The organisation of the JS frameworks would need some rethinking. FlexJS also uses the 'flash.display' and 'mx.core'/'mx.states' namespaces. We don't want collisions there. 5) The reason I'm hiding the AS SWC because I don't want to bother the user with having to use different xmlns. It would be sweet though to have Falcon do the switching on the fly, so we get compiler feedback about portability during development, e.g. using a compiler argument indicating you want to also be able to cross compile your code to JS. That way the shim SWCs could still be that, shims, but I like the idea of adding metadata to indicate JS (un)availability. 6) We need to rethink the naming convention. I like FlexJS, it should stay for the name of the AS to JS project. But the various frameworks need different names. On the AS side, after we 'merge', I guess there are 4: Flex (the regular SDK, used by the VF2JS approach), FlexJSUI, FlexJS and MXMLCClasses. On the JS side, there would be lots and lots, some of them (possibly) colliding: see point 4). What is your view on the organisation of these various aspects, especially given that (see point 1) we might merge FlexJS into the regular SDK? That should be enough food for thought ;-) Let's see if we can make this work! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
