Thanks Alex! > What I hope to accomplish with FlexJS is to make a great second-generation > SDK for building FP and AIR apps that can then be compiled to JS/CSS. If > you can get your users to use FP and AIR then you save a lot of > browser-specific testing, but lots of people don't seem to control over > that decision. Yes, there will be some API surface trade-offs required to > make your code portable to JS/CSS. FlexJS won't take advantage of weak > references and dictionaries unless it is part of emulating a browser > built-in. But if you look at the prototypes so far, you'll see that > FlexJS SWFs can be as small as 20K, don't need RSLs, preloader frames that > can't use Flex widgets, a base class that is 13K lines long, etc.
FlexJS sound really exciting! Thank you for all the hard works and looking forward to the release of FlexJS soon. Joel On Jul 1, 2013, at 1:25 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 6/30/13 7:58 PM, "Organet Systems" <organet...@gmail.com> wrote: > >> Thanks Jude for the input! >> >>> There are a couple of good things about the FlexJS project that may not >>> be >>> apparent to us as Flex users. That is, if FlexJS becomes popular >>> (especially to HTML devs) then it brings Flex into a good light. When >>> HTML >>> devs see how they can create great apps with the Flex syntax they're >>> learning and using they'll see they can cross compile to FP and AIR for >>> free. Then, their client says we now want to run that app on mobile. >>> Then >>> being able to compile to Flash and AIR becomes a valuable asset to them. >> >> Now I can see the benefits of being able to output Flex in HTML format, >> for better accessibility and attract more developers to use Flex. Like >> what Adobe Flash Professional CC is able to do now to output it in HTML5 >> and Dart. Personally, I felt that HTML output should be an OPTION and >> shouldn't be the CORE for Flex dev (Like Flash Pro). Putting Flex dev >> focus on HTML is a great risk, it might end up losing Flex users who love >> FP and AIR (who don't believe HTML and Javascript can do what Flex is >> able to do and go away and look for something else like Feather UI, >> MadCompanents and etc.), just for my personal opinion, I felt that Flex >> dev for HTML should be an option and definitely it's a great option to go >> for, but should not be the core. > > What I hope to accomplish with FlexJS is to make a great second-generation > SDK for building FP and AIR apps that can then be compiled to JS/CSS. If > you can get your users to use FP and AIR then you save a lot of > browser-specific testing, but lots of people don't seem to control over > that decision. Yes, there will be some API surface trade-offs required to > make your code portable to JS/CSS. FlexJS won't take advantage of weak > references and dictionaries unless it is part of emulating a browser > built-in. But if you look at the prototypes so far, you'll see that > FlexJS SWFs can be as small as 20K, don't need RSLs, preloader frames that > can't use Flex widgets, a base class that is 13K lines long, etc. > > -Alex >
