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

Reply via email to