Reading another funny document by Adobe

Today Adobe released another document that brought tears into my eyes. Why they think that people are dumb? Why not just say, “We couldn’t figure out how to monetize Flex and we’re getting rid of the ballast”? Adobe is a public company, and, beside developers they have investors and their stock went more than 10% up since last (infamous) November. They’ve chosen investors over developers. This is understandable, but why keep lying to developers?

Today’s doc contains lots of words, but the most important section is this:

Adobe runtime support of Flex

Flash Player 11.2 and Adobe AIR 3.2, which are anticipated to ship in the first quarter of 2012, will be tested
with applications built using Adobe Flex 4.6. Adobe will test future releases of Flash Player and AIR against the
Adobe Flex 4.6 SDK and maintain backwards compatibility for five years.

While Adobe will ensure that the Adobe Flex SDK 4.6 and prior will be supported in future versions of Flash
Player and AIR, it will be the responsibility of the Apache Flex Project to test future versions of the Apache Flex
SDK against released Adobe runtimes to ensure compatibility and proper functioning.

In the past, features were added to Flash Player and AIR specifically to support the needs of Flex applications.
Going forward, features will be added to the runtimes to support Adobe’s vision for the Flash Platform. The
Apache Flex Project may choose to take advantage of those features; however, new features will not be added
to the runtimes specifically to support the Apache project’s efforts.

Let me re-write it in plain English:”We’ll release the new version of Flash Player, and we ‘ll test our past versions of Flex against it. We love (kinda) Apache Flex, but we don’t give a shit about what these guys will come up with. Flash Player is OUR runtime, and you’d better make sure that your smart-ass next generation Flex works with it, or else… In the past, every release of Flash Player would accommodate for the new features of Flex. From now on, ” We are not adding new features to Flash Player to support whatever you come up with”. Or as we say it in New York City, “Fuggeddaboudid.”

Keep reading Adobe’s doc. Their version states, “Flash Catalyst CS5.5 is the last release of Flash® Catalyst®“. BTW, why do they even add these ® signs to Catalyst? Anyone wants to reuse this lousy brand? OK, maybe. Let me translate it into simplified Chinese: “It was stupid in the first place to work on such a tool, and we wasted two years of our Flex team re-writing the FLex Halo components into Spark architecture just to accomodate the need of this still born baby – Flash Catalyst” .

Keep reading – it’ll get even funnier: “Development of Flash Builder continues. Adobe plans to maintain support for Flex projects in updates to Flash Builder 4.x, including additional work to ensure Apache Flex based SDKs can work within Flash Builder“. This is what it means in Bengali language, “During six years we tried hard, but couldn’t create a stable and performant version of Flash Builder for our own Flex SDK. For some weird reason, Flex developers would spend half of their time waiting for Flash Builder’s workspace to finish rebuilding itself. Design mode never really worked for Spark components. We are off the hook now, yay! Noone would even expect us to fix this for some Apache product. Just use IntelliJ Idea, will you? ”

The only product that was not mentioned in this doc was LiveCycle Data Services. What’s the fate of this highly overpriced monster? Is it dead in the water? I don’t really care about this one. During the last six years I ran into one client who bought its licenses. On multiple ocasions I was trying to convey to Adobe that they should lower LCDS price, but they didn’t give a damn.

Adobe has inspired these T-shirts. Still, it’s sad. I’m going to miss Adobe Max conferences. They knew how to put up great events, really.

Yakov

16 thoughts on “Reading another funny document by Adobe

  1. Haters).
    do u guys have a 1 successful project using flex?
    another question how u do training on technology u don’t trust?

  2. I agree with most point except Flash Catalyst. Granted their marketing sucked and I had no idea what it did really up until I started playing with it.

    I design and implement very complex and pixel perfect user interfaces – and Catalyst has saved me weeks worth of work. It has its quirks but to implement components and UI it has real business value.

    FXG is a great move forward. Halo was a dump of horse shit compared to spark components (if we omit the disaster that IndexChangeEvent are vs itemclick).

    In other words I’m truly sorry to hear that they’re dropping FC. Not for the promises it had given and never delivered, but for the actual use I have for it. Creating skins in minutes rather than hours.

  3. Here’s a question for you Yakov. If you were going to build mobile applications for IOS and Android (not games), would you use Air/Flex to do it or would you decide to go native and build applications with java for android/object c for IOS?

    I’m just curious, because I’m struggling with that decision everyday despite AIR having native extensions now. I just don’t want to get screwed and I’m finding it challenging to use the Flashbuilder 4.6 to build mobile AIR apps for android using native extensions. I find I spend more time trying to get the android debugger to play nice than I do coding. And it also seems like Adobe can’t resolve any issues on their bug forum. They blame all the external sdks or don’t seem to be able to fix any problems. Just frustrating…

    I can tell you that I’m leaning toward discarding flashbuilder4.6 and starting fresh with Xcode and eclipse(or intelij). What about you. Any advice in this area?

    Thanks
    Ron

  4. Ron, If you’d asked me about this 3 months ago, I’d say stick to Adobe AIR for anything cross-platform mobile. But after 11/9, I don’t believe that Adobe will be investing into the AIR project sufficient financial and human resources.

    As to Flash Builder, I have no trust in Adobe. They couldn’t make it to work properly on Desktop in 6 years. Now they’re facing a plethora of different mobile devices which should be properly emulated. This is tough.

    With the native extensions, you’ll be running into this pointing-fingers game over and over again.

    Having said that, I can’t say, “Don’t use AIR”. Let the money talk: just take a piece of paper and do some math calculating the cost of developing these applications with and without AIR. Do you have the right skill set in house? If not, do you have a budget to hire people with different skill sets to develop natively? If the answer is No to these questions, stick to Adobe AIR and learn to live with Flash Builder.

  5. It’s nice to get candid and honest feedback for a change. Thank you and keep up the good work here. Always keeping you guys in mind for projects.
    –Ron

  6. Well, that’s the pessimistic view anyway. The other view is, now Flex follows the same paradigm as Eclipse (which we all know is a “miserable failure”….) and will be a “true” open source project, which addresses one of the past critiques of OSS extremists.

    And while the Falcon JavaScript compiler (target JavaScript for the Flex SDK, like GWT does with Java) is still yet to be seen, I think that should do something to calm people down after the FUD slinging session we had a few months ago. The Flex SDK & development methodology will be preserved even if browser plugins die. Actually simply getting that compiler to a stable state would probably be big news. Targeting Flash or JS makes Flex one of the most versatile and mature web SDKs out there.

    I couldn’t care less about Flex and Flash dev on mobile, or adding new features to Flash mobile. Mobile is a lot of hype these days. Good riddance to something that was stealing valuable resources from Flex/Flash Enterprise/Desktop. You could argue that Flex and Flash are overkill on these little devices, for such simple little apps. They can barely run crummy JS toys.

    It’s akin to an un-needed government agency being shut down and privatized (open sourced, here), and people are reacting with predictable unproven FUD. The worst thing about the news is the news (and the over-reation) itself. I admit maybe, that could be enough to cripple the SDK going forward, if Fx proponents keep acting grumpy about these changes… so stop. No good can come from negativity.

  7. And HTML5 is a pile of hype too. A slow moving 20 ft tidal wave sure, but not the 100 ft wave that’ll hit tomorrow like it’s fanatics claim. Didn’t Java teach us that depending on standardization by committee is risky? Rod Johnson was talking about this calling it a failure years ago, and cautioned about committee standardization in the rich client space. Of course Flex is immune to this problem, when in a Flash VM.

    http://www.infoq.com/presentations/Lessons-Learned-from-Java-EE

    Mobile, VM platforms (like Flash or Silverlight) is the way to go if you want a consistent, stable environment. (Admittedly the technical superior solution isn’t always an industry’s choice.) So that problem is already solved w/Flash – I think what Flex is missing, is something like SpringSource – a company that charges for and offers enterprise support.

  8. Here is something I would like to add-in. If you are planning to develop mobile applications for iOS and Android (not games), and it is not a very advance complex application, I would highly recommend using phonegap with HTML5. One of the main reason is that, although AIR is cross-platform, but it doesn’t really cross model. Adobe AIR has high requirement on the mobile processor which it can only run on ARMv7 and above. There are still many people using older model of phone and some of the new popular low budget phone such as Samsung Galaxy Y runs on ARMv6. So, if you are developing some “basic” application using AIR you are losing a huge portion of potential customer which is bad for business.

  9. Since Adobe stated loud and clear that the new versions of Flash Player won’t support features introduced by Apache Flex, something has to be done in the framework level.

    If in the past creating a framework that supported MVC Dependency Injection would make a framework popular, this won’t be the key to success in the future. The next generation frameworks will make sure that your Flex app still works even if Adobe’s Flash Player 5+ doesn’t support a feature that Apache Flex SDK needs.

    This is what the modern JavaScript frameworks do under the hood. Instead of just calling a function abc(), the code first checks if such a function even exists. If not, the PlanB-code gets invoked. Most likely, the upcoming Apache Flex code itself will have to incorporate such preventive measures.

  10. “new versions of Flash Player won’t support features introduced by Apache Flex” – not sure what kinds of features this could be referring to. I think I recall something about 5 year backwards compatibility? That’s probably a long enough time frame that I doubt such “PlanB-code” would be common.

    • Haven’t heard about ZK. The app written in Java and magically turned in Javascript is great, but you’re still deploying/debugging JavaScript and I don’t buy the promises like “you don’t need to know JavaScript”. It might be a great framework, but what makes it better than GWT, which promised the same was backed by Google, but never took off nevertheless?

  11. Thank you very much for your reply. Just would like to say that I read all your books and I love them all!

  12. You are right about the build times being outrageous. I am now looking at Sencha Touch and I am enjoying the instant gratification by hitting the refresh button. Not to mention that the project would sometimes want to rebuild for what appeared to be no reason, but was actually a bug in the compiler and just changing a simple color or pixel width would require the whole shebang to start again.

Comments are closed.