Flex and FlashBuilder are not part of Adobe’s HTML strategy per-se. FlashBuilder is being directed towards Gaming in Flash, Flex is being donated to the community. It is the community that has lots of investment in the Flex/AS/FP stack that are looking reworking the Flex paradigm to output to the HTML/CSS/JS stack.
Meanwhile Adobe is not only updating Dreamweaver (see the PhoneGap features added in 5.5) but also looking at new tools for new development methodologies. While classic Java has been around for a while, and HTML/CSS/JS will likely meet your 15 year requirement, the question remains whether you will be willing to use more efficient and powerful development frameworks and methodologies over those years. If you don’t, you might lose competitive advantage as your competition gets their products finished better or faster, but if you do, you run the risk of choosing a new set of tools that turns out not to have lasting power. Tough call, no right answer, the choice is yours. It looks like the Apache Flex folks are going to try to provide one of those new sets of tools by making it possible to use the Flex paradigm for the HTML stack. On 1/12/12 6:10 PM, "Ron G" <rgri...@sinclairoil.com> wrote: So, I think we have a similar vision for where things are going with respect to Adobe supporting HTML5 for the enterprise. But, I fail to see why Flex and FlashBuilder would have any part of that. Why not just fall back to your excellent product, Dreamweaver, and enhance it as the IDE for building HTML5 style web applications? No translation is then required. I too like the FlashBuilder/Flex paradigm for development. But, it seems to me that, sooner or later, what you end up with is the FlashBuilder paradigm that allows the user to code with a pseudo OO type of HTML5 as an alternative option to MXML and AS3, since we agree that it's not the translation from as3 to HTML5 that makes sense, but the paradigm itself. As for "that doesn't mean you should stop using Flex/ActionScript/FlashPlayer right now", I would disagree. Over the past dozen years, I have already gone through 4 generations of web architecture: 1) CGI 2) server side XSLT transformation rendering a DHTML web page for client side 3) Flash 2004 until Adobe abandoned the push for developers to use Flash for applications and created... 4) Flex I would like to settle upon a single client-side technology that I can rely upon to be here in 15 years. Novell and Adobe have failed me in this regard. The only piece of my stack to not drop the ball on me is Java, which is why we are going with a Java based framework where the UI logic can reside server side. Do you know how hard it is to hire someone that can come in and be competent in all 4 of my web architecture generations? Very difficult. So, it's better to stop developing in Flex now so that I have less older generation architectures to eventually convert to ZKoss. Once that is done, finding someone who can help maintain all of our projects becomes a much easier task. Anyway, I very much appreciate hearing from an Adobe Flex SDK staff member. You have helped clarify that the direction I am taking is the right one. Hopefully, it's convinced a few others to not waste time writing in a technology that will one day require migration of an even greater backlog of projects to their inevitably new chosen technology stack. Ron --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> , Alex Harui <aharui@...> wrote: > I'm not in disagreement that in the long term, the advantages of > Flex/ActionScript/FlashPlayer will be diminished by advances in the > HTML/CSS/JS stack. That's why Adobe has made a major strategic shift to > become the tooling leader in the HTML stack. But that doesn't mean that you > should stop using Flex/ActionScript/FlashPlayer right now. > > Many folks who work with HTML/CSS/JS, even using the many libraries and > development methodologies available for it, still feel like the Flex paradigm > is superior. Apparently, even Google agrees because they are trying to > create their own version of that paradigm with DART. While translated code > is never as good, the productivity advantages of a better paradigm have been > pretty much proven to be worth it, otherwise, Flex wouldn't have been that > successful either since MXML isn't as efficient as pure ActionScript, and > Google wouldn't have invested so much in writing their website logic in Java > and/or Google Closure and/or DART. > > There is general support in the Apache Flex project for exploring ways of > using the Flex paradigm to create HTML5 apps. Those working on the project > are motivated to future-proof their investment in Flex. I don't see any > technical issue blocking us from translating the paradigm to HTML5, and I > invite all those who like the Flex paradigm to participate. But at the same > time, there is lots of work to be done, lots of solutions to be built, and > lots of money to be made on the Flex/AS/FP stack while we wait for the HTML5 > stack to deliver on its promises. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
