Disclaimer. Everything posted on this blog is my personal opinion and does not necessarily represent the views of my employer.
Part 1. Emotions.
Three days ago I’ve received the following email from an enterprise architect of one of our former clients (we’ve conducted two Flex training classes there):
“Adobe has been in the news lately with Flash not being developed for mobile devices and then the Flex SDK being donated to Apache. With all these things going on I was thinking if it still makes sense to develop using Adobe Flex for RIA applications. There are several opinions out there on the web but would like your take on the future of Flex and Flash. Is it still a safe bet to develop in Flash for RIA applications. Does HTML5+CSS+jQuery come close in terms of functionality that Flex offers? Please let me know.”
I’ve quoted this email because it described well what many of enterprise IT shops are talking about after Adobe simply decided to change their priorities. It started with that infamous blog of November 9th stating that Adobe didn’t care about Flash Player in mobile devices. But they didn’t stop there. Now they’re donating Flex framework as well as BlazeDS to Apache Software Foundation. Flash Catalyst was a mistake. It seems that Adobe decided that enterprise IT shops extinct. Apparently someone invited Adobe’s executives to a wild orgy, and the morning after one of Adobe leaders said, “How about changing our vision? I clearly see us in digital marketing and digital media! Enterprises are soooo boring, right hun?” Then Adobe went berserk.
Five years ago no one in the enterprise IT considered Adobe capable of anything but making nice tools for designers. They put tremendous effort into getting their foot in the door and be treated seriously by most (if not all) Fortune 100 companies. Back in 2006 enterprise developers didn’t want to hear about Flex framework. It changed. Very serious applications were developed and deployed into production using Adobe Flex and AIR as a front end tool. Will Adobe respect their existing support contracts with all these customers? For how long? Who’s going to provide such support if Adobe laying off hundreds of people second year in a row? As of today (Dec 14, 2011) Adobe didn’t care to make a clear statement about support of their enterprise customers.
Adobe’s executives keep silence. Santanu Narayen, the CEO was always the man of few words. But is Kevin Lynch, the CTO, in town? On Earth?
A couple of technical managers and evangelists are trying to fix the ugliness of the situation, but there is not much they can do. They can’t speak up for executives. Their words like “we’re absolutely committed to…” can’t be trusted anymore. These nice professional people are not being invited to decision-making orgies.
One of the very respected software engineers (a former Adobe employee) twitted, “Watching Adobe remove engines, wings, drop fuel, seats while in midair flight with customers aboard is truly fascinating.”
I see the situation similarly: today’s Adobe is a plane driven by pilots who lost control and are trying to press random buttons hoping to find the way home.
Part 2. Business.
Coming back to the original question, “Is it still a safe bet to develop in Flash for RIA applications?” This was the question of an enterprise architect of a mid-size IT shop, who’s not into politics and honestly tries to make the right technical decision.
The short answer is yes, you have nowhere else to go if you’re planning to deploy applications in production in 2012-2013. Flex is the best Web framework available today, and the fact that Adobe is donating it to Apache is better for everyone. The same applies to BlazeDS. As a matter of fact, Adobe stopped supporting BlazeDS two years ago, anyway.
I’m sure, under Apache Flex framework will go strong. My main concern is if Adobe will be willing to keep their future releases of Flash Player in sink with the future releases of Apache Flex?
What about HTML 5 (a.k.a. JavaScript)? At least for the next two years HTML5 should be used only by the early adopters. But we are in the enterprise development and have to deliver a number of cross-browser Web applications under limited budget and with a team of regular developers, not geeks. Six month ago I joined the project that was developed in Java/Swing by a team of 4 developers. There seniors left the firm. The person who left had 2 years of Java experience but was a quick learner. This week the new financial Flex/Java application developed by two of us goes to production. I’m trying to be fair to all technologies, but it wouldn’t be possible to pull something like this off with any JavaScript or Java front end framework.
If you are planning to go mobile, the most cost-effective platform is Adobe AIR. Can you afford to hire three teams with three sets of skills to develop for desktop, Android, and iOS? If you can’t, stick to AIR.
Part 3. Political stuff in the large enterprises.
Back in 2006, enterprise architecture groups of large enterprises were the main obstacles for making Adobe Flex an approved tool for development of the Web applications. Now, because of those drunk pilots, it’s their “Told’ya!” time.
They will try to squeeze Flex out of the list of approved tools arguing that Flash Player has too many patch releases, security holes, and, after all, the mankind moves to a no-plugin Web browsing. If I’d be running an application development team of Flex developers in a large enterprise, and an enterprise architect tried to to push me away from Flex toward an XYZ Javascript framework, I’d ask if the suggested XYZ framework would patch these security holes. Most likely, the answer would be “No, but at least we can set the Web browser’s security to the highest level for the JavaScript applications, which is not the case with Flash Player”. This can be a valid argument, and if Adobe cared, they could have created a special JavaScript wrapper for Flash Player to mimic security settings of the Web browser. It doesn’t take a rocket scientist to write such a wrapper, but since Adobe remains the owner of Flash Player, it has to be done by them.
Part 4. What to read next on the subject?
I like this post by Adam Flatter from Roundarch.
Part 5. Summary
1. Flex remains my first choice framework for developing RIA and AIR for developing desktop and mobile applications.
2. I’m also planning to go deep under the skin of one JavaScript framework, and it’s not jQuery. I like to have more than one tool in my toolbox.
3. Our company, Farata Systems will offer commercial technical support for Flex, AIR and BlazeDS both on the desktops and on tablets. We’ll make an official announcement about it shortly.
4. Our company continues offering training in Flex and Java as we always did, but next spring we’ll add a class “HTML5/JavaScript for Enterprise Developers”.
5. Under such management Adobe won’t last long and will have to be acquired by another company.
Happy New Year, everyone! It’s going to be fun.
yakovfain.com 
Adobe fouled their nest. Now they get to lie in it. I’ve moved on. Life is short. No point in wallowing in someone else’s shit.
Thank you, Yakov. Let us know please what javascript framework are you going to pay attention to?
Thank you for the article, Yakov. “Can you afford to hire three teams with three sets of skills to develop for desktop, Android, and iOS?” – I see it even in small companies. When I ask them: “Why not use Adobe AIR?”. The frequent response is: “Yes, we tried, but the only possible success way was to have three teams”.
@Roman Most likely “We tried” means they wrote three Hello World applications by three different teams. The real world projects are just a little bit different than pilots though.
It is great when you have such guru as your colleague Anatole Tartakovsky who spent a lot of time trying to make the RIA portable and moving it to the tablet. 🙂
Let me guess… Is ZK the JS framework you’re going to try next?
I am a Flex developer working for a large Enterprise IT. Everyone in my company is surprisingly silent on this topic, absolutely no mention of it. If Adobe is closing Flex/Flash slowly, why don’t we accept it and plan towards other technologies? It would help if Flex community can come up with suggested tools/technologies for transition.
Everyone’s silent because Flex a) remains a very solid framework for the Enterprise IT and b) retraining your team to some JS framework, which is close to Flex in functionality is expensive.
Finally my company started discussions on alternative HTML technologies
The only company that should of provide such transition tool could be Adobe – in a form of acquiring/contributing to the JS framework and making code generator that would emit such JS/keep track of the modifications. Unfortunately, jQuery that is in the focus of Adobe technologies for HTML5 is not likely to be a match for Flex ever.
JavaScript is completely different animal in both programming style and scalability/maintainability. So even if automatic conversion would work 80+%, for most large scale applications you would still end up with code impossible to maintain. For applications moving to HTML5 redesign is inevitable – and that is a good thing.
You need to assess if HTML5 is required – and valid reasons are:
1. SEO requirements
2. Cross-integration/mashups requirements
3. Lack of Flash components/availability of HTML ones for specific tasks
and so on….
If Any of those apply – you need to consider HTML5 carefully as without corporate sponsorship community support can go in very different direction from enterprise technologies. If not, Flex is still the king of the hill with no comparable contender in terms of productivity – but it is going to change within a year or so.
Great article.
I would add some point about the Flex/JS choice for RIA today.
If for example you decide to switch from flex to JS TODAY because you think you have to get your hands on a long term technology and your guess is that its JS, don’t forget that JS is also changing fast, and when you’ll see the gap between JS 1 and JS 2, when you see how it was difficult for coders to switch from AS2 to AS3 in a flash world, i think letting flex bewind would not be a good idea.
At least you can wait JS2 to be out. And since it happend, flex will evolve too, and i hope myself that Flex with FalconJS will be successfully cross compiled to JS2.
Yakov my friend, your post is amazing as always. I don’t disagree with Flex’s superior set of features even on date but its not the features or the logical arguments that ever win a battle. Adobe pronounced that Flex is terminally ill and incurable. Now its only option is to die. Support it for sometime and then move on.
Thank you, Shashank! One of the main Adobe’s issues with Flex was their inability to monetize this tool. Another good example of this is their absolutely stupid pricing policy for LiveCycle Data Services. Requesting $100K+ for a typical setup of LCDS servers simply killed this technology. During the last 5 years only one of our clients was using LCDS and this was four years ago. Everyone else was happy with free BlazeDS.
LiveCycle is yet another super expensive monster.
I wish Adobe luck – they still employ a number of great people, but I lost my interest in this company after they turned their back on lots of their loyal customers and partners.
Yakov, very very interesting post !
Looks like Adobe is now a self destructing company (with regards to Flex),
and it hurts us as developers badly. 😦
I just heard from my architect: “After that I lost all interest in Flex”
As far as JS framework to try, how about that GWT based one – Vaadin:
https://vaadin.com You write code in Java, it does the rest, clean, simple,
a bit like Swing.
Nice post, Yakov. Sums pretty much up what I think about the situation. I feel a bit sad for the various teams at Adobe, with some talented and great people working on exciting open source products. Switching to a new strategy so quickly, without good preparations, seemed very desperate.
How much could Adobe have won, if the management would have planned the move to contribute Flex to the Apache Foundation. Now it feels like they were just trying to pacify the community with this move, although it seems to be a good decision, given the circumstances.
I have been involved with the OpenLaszlo project (which internally uses the Flex compiler for SWF10 generation), and am surprised how well the “DHTML runtime” works for the project. Flex is different from OpenLaszlo in that it uses a very light-weight component approach, which can be cross-compiled to JavaScript more effectively (simple OpenLaszlo app cross-compiled to JavaScript is less than 600kb uncompressed, a simple Falcon JS app cross-compiled is 5mb in size).
It’s still desirable to create a cross-compilation feature for Flex. The Apache Community could create a component set for Flex which is more light-weight, and supports cross-compilation features better. That wouldn’t help you to get your existing Flex application running as an HTML5 app (which is not necessary for the next 2-3 years, I believe), but it would make sure that Flex as a development platform is still interesting for new developers.
Much of what we see in the JavaScript world (Google Closure Compiler, CoffeeScript) aims at using a compiler to detect possible bugs in web apps during compile time. ActionScript 3 is a good language for doing that, that’s why I think it would be very useful to have ActionScript with cross-compilation working.