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, 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.


Reply via email to