Fantastic job on the conference, BTW Tom and John!! IT WAS AWESOME!

To those who were not there -- DUDES (and dudettes ;), you have like, a WHOLE YEAR to save up for the next one. Be there next year or be square, really: if you're a Flex developer, YOU NEED TO BE THERE.

Great tool, well done. The only thing I would suggest for the next one is have a more visual layout, maybe like a calendar, just like the session map that comes with your badge, instead of having to click repeatedly on pull-down menus, yuk. So that sessions could be searched for by day or by room as well as by track, which would make it easier to find the sessions you went to in order to comment on them effortlessly. And by organizing them by session slot, people could comment on the last minute open sessions, which were absent from the feedback tool.

Fantastic job on the conference, BTW Tom and John!! IT WAS AWESOME!

I've got more than a few ideas running around in my head... so I'm VERY guilty of brain crack, LOL. "But, but... I've been writing THE MOTHER OF ALL FLEX BOOKS for over a year now, how can I have time to build anything in my spare time?", I ask myself. "Well, don't write so damn much, for one, or don't work so many hours in the week", I tell myself. Easier said than done.

Though I have let go of some brain crack: still own the domain myzengarden.com, from when Flash 8 came out and you could do low level bitmap manipulations for the first time -- I thought it would be cool to create a virtual "zen garden" creation tool, and you would be able to export the image for your desktop. But that ship has sailed, so I think I'll sell the domain to this Ukrainian who's been bugging to buy it off me. If anyone else wants the idea, go for it.

That aside, some ideas need to stay private until they're ready to hatch, even if you are working on them. (Is fighting brain crack just building your ideas, or is it telling people about them while you're doing them, I'm confused.)

I mean, look what happened to Saffron: massive build-up, guy lectures around the world about it -- and then he disappears off the face of the planet (AFAIK) and still no one has seen a beta! There's brain crack, and then there's premature Flashturbation, if you know what I mean. I'd rather have brain crack then be the Flexer who cried wolf.

(...cont)

"They create support nightmares."
Well, I'm sorry for having to say so, but if this has been your experience with Flex applications deployed to the Flash Player and to AIR, then you've been working with amateurs who don't know their business. A properly developed Flex application creates no more support nighmares than does an AJAX or a .Net or a Java-based application. And your comment comparing Java Applets, which is a very antiquated browser-based technology no longer in common use, to Adobe AIR, which is a desktop-based RIA runtime, further belies your ignorance of the technologies you take aim at.

"They are prone to performance problems.":
Again, if this has been your experience of Flex applications, then you've been working with amateurs who don't know their business. There are very few ways to actively provoke critical memory leaks in the Flash Player, and those problems are easily circumvented by any Flash or Flex developer who knows how to use the Flex Builder memory profiler. Flex applications are considered to be "closed" source, in that they are binary files, but for the development team that created the application, there are many tools for introspecting and debugging live applications, including several automation and load testing frameworks and tools. The fact that the internal code cannot be introspected directly in a browser without a decompiler, is generally regarded as a good thing by corporations who have spend many months and a lot of capital developing applications. And this does in no way preclude developers from sharing their work open source, for all they have to do is post the code on an open repository and activate the "view source" right click capability in the Flash Player. So again, this statement belies your ignorance of the technology in question.

"You can't easily modify them.":
What, you mean if you somehow lose all the source code and all of your original programmers on the project are sent to a Martian penal colony, that kind of problem? :) The limitations of "lack of modification" of Flex-based applications you mention are a specific problem to GUI-based development tools IMO, which are bound only by its operating design parameters. There are absolutely no problems whatsoever in modifying applications in a development environment like Flex Builder, or heck, notepad even. True, the number of "turnkey" GUI-based development solutions for Flex applications development is currently a small list, but one cannot rationally paint with such a broad stroke the limitation of an entire technology based on such a narrow definition of its implementation.

"Naturally, audience members asked how the interface could be re-configured.":
So, not being able to do this, does this again assume that you've lost all of your source code and that your development team has been exiled to Mars? Your UX expert and your development team would have the tools to reconfigure the interface if necessary. Tools like Flash Catalyst make the job even easier, no more complex than taking a static mockup and slicing into components which outputs Flex-compatible MXML code. If the client wants a GUI-based development environment or a visual unit-testing administrative interface, there are several solutions available, or the team could easily create an admin console to assist in asset or CMS management. And any team worth their salt would use SCRUM-based development for an enterprise application which requires this kind of frequent feature modification. So again, your argument belies your ignorance of the technology in question.

In conclusion, an artist does not blame his tools for a job poorly done. So a developer or a team, or a client, should not blame the technology used for a poorly implemented solution, if the tools exist to create good work. Which they do in abundance in the case of the Flash Platform (of which Flex is a part). So given that the Flash Platform is IMO the most powerful and flexible RIA development platform on the market today, pardon me for saying so, all of your arguments sound more like a propagandized smear campaign than a valid debate.

@mjpucher
Well, if we're going to be absolutely transparent in our motives in this discussion, it should be stated that you work for a company whose goal it is to provide non-programming based development solutions, so of course you would not be a favour of a programming-based approach.

And if I many enter the debate here, I will state that as I've seen and worked with both GUI-based development solutions to completely programming-based solutions. I've seen enough of both types of projects in the Flash Platform sphere to know that it's the runtime that matters first and foremost, and the tools and methodologies second. Both need to be in place in order to build successful RIAs that solve particular user stories.
-------
@Tony Byrne
In regards to your article, it seems like you have some unstated motive in attacking Flex (and the Flash Platform) in particular, which can hardly be regarded as a fair and unbiased analysis. Because all of the points you mentioned are shared with every other RIA technology currently available. As a Flash Platform developer for over 10 years, I can state that all of these arguments are either complete non-issues or possible to overcome with the right team.

To wit,

"To me, turning to Flex for a content management interface is a cop-out":
You're right, there are many inappropriate use-cases for implementing an application deployed through the Flash Player. A hypertext-based website, a blog, and some social networks are other examples of inappropriate usage of Flash. But to ascribe an inappropriate use of a technology as a supposedly common or model implementation of that technology to prove the ineffectiveness of that technology is itself a cop-out borne of ignorance of best practices, and a completely invalid argument.

"Flex is essentially another semi-thick client akin to Java applets":
True in the sense that Flash applications are deployed through a plugin-based runtime, but comparing Flash apps to Java applets is like comparing an AJAX application to an HTML 1.0-based site, and is hardly an accurate comparison.

"They almost always violate web accessibility guidelines":
Since all non-hypertext-based applications (or RIAs) share this trait, from AJAX to Flash Player-based applications, I cannot see this as a viable argument against Flex applications specifically. And AIR applications are desktop applications, so they are in a different category altogether -- how many desktop-based applications do you know of that are accessible? The fact of the matter is that the tools are available to create a browser-transparent, vision-impaired accessible Flex applications. True, it may take a little more planning to create an accessible Flex application, but the choice is available. It is the choice of companies, not an inherent limitation of the technology in and of itself, whether an accessible application is built or not. So your claim that Flex applications by nature violate web accessibility is an argument born out of ignorance of the capabilities of the Flash Platform.

(cont...)