After some time off, I just became aware of this discussion, and it has already become quite longish, so please forgive me if I missed or misunderstood some arguments.
That said, my understanding of MXML is that it is just another (for some use cases more convenient) syntax to write an ActionScript class. From MXML, you can use any other AS class that has a no-arg constructor and properties, and from AS, MXML components can be referenced like normal classes, too. When using a component library, you do not even know whether the components were written in AS or MXML. An MXML component can inherit from an AS class and vice versa. I find this mix-and-match approach very charming. And if that is the correct semantics, I don't see any reason to not generate JavaScript code from the (temporary) AS class generated from MXML. Now in this thread, I read that you should not generate an ActionScript class / JavaScript from MXML, but instead a data structure that gets instantiated into a component (later). That sounds like a similar approach to Ext JS, where they use object literals with "xtypes" as component descriptors, which can then be instantiated into "real" components as needed. Sounds good, too, and indeed has some advantages ("lazy" components), but how does that go together with the "old" approach of MXML? Or is my understanding wrong? How would you use an MXML component from AS3 code if it is not a class? Can you still "mix and match"? Hoping someone can shed light on all of this, *-Frank-*