SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

How Should We Think of Flash Going Forward?

Posted by Bob Warfield on November 22, 2011

Before writing this second part of my two-part series on Flash (first part: Flash: Misunderstood by Adobe, Apple, the Haters, and the Press), I wanted to allow sufficient time for all the shoes to drop.  Adobe needed to get their word out and the blogosphere needed to get its word out as well.  Now it’s time to go back and analyze what the future of Flash, Flex, and AIR look like going forward.

HTML5 is Inevitable

With apologies to Agent Smith, if there was ever the slightest doubt, and there should not have been, the noisy sound of Flash disappearing from mobile platforms is the sound of HTML5’s inevitability.  It’s the standard, and it was always going to be inevitable.  HTML5 is also inevitable just because it’s easier not to think of doing a project for more than one platform.   Companies prefer fewer platforms, all other things considered.

But, not only is it inevitable, the demise of Flash for mobile browsers should accelerate HTML5’s evolution and inevitability.  After all, the world used to be able to use Flash as a crutch whenever HTML couldn’t hack it.  That crutch has now been kicked out from underneath us, courtesy of Apple and Adobe deciding not to allow Flash on mobile browsers.  That will put market forces behind getting HTML5 up to the capabilities needed sooner rather than later.

Fragmentation is Inevitable

One thing Flash made it possible to do was to ignore fragmentation to a degree.  Write once, run everywhere was a beautiful thing.  It always is.  That promise is what put Java firmly ahead of C++ for a long time, and it is also a large part of what fueled Flash, together with the minimal capabilities that HTML and Javascript had for a long time.

Now companies are going to face fragmentation.  That means browsers will have differing levels of compatibility with HTML5, either due to features being missing, or to differences in how the features are implemented.  This is a problem that just never came up with Flash.  You wrote the code and it ran.  It’s been a huge problem for HTML/AJAX applications, and it will continue to be as bad or worse for HTML5.

If you run a software company, it means you’ll have to invest resources dealing with these browser incompatibilities.  This is some of the worst kind of pain for developers, because often the incompatibilities are not clearly documented.  You just have to keep trying different variations of code until you find code that works on all browsers, or you have to maintain different versions by browser.  You’re shooting in the dark.  It is an opportunity for those HTML5 tool makers that make the investment to ease the pain, but that’s a big investment and it remains to be seen who will really step up with a broad enough and well-proven solution.

In the worst case, your software development costs may go up substantially depending on how bad the fragmentation is.  This is not unlike the problem of supporting many databases, or many application servers, for Old School Enterprise Software.  At one company where I ran R&D, we invested as much as 40% of our R&D cycles basically on portability across many DB and app server platforms.  It shouldn’t be that bad here, but I could easily see it costing 20-25% more.  Or, companies will simply decide to quit supporting some platforms.  We’ve all been to sites that forced us to upgrade or switch browsers before we could use the site.  Unfortunately, for mobile platforms that only support one browser, that’s going to be tough.

It will be years before HTML5 catches up to where Flash is today

Flash has always been about a lot more than video and annoying animations on web sites, but the press and the haters never seem quite able to make that conceptual leap.  It’s a pity, but even if we limit ourselves to comparing Flash to HTML5 on movies and such, HTML5 has a long ways to go.  Consider for example ArsTechnica’s article, “The Trials and Tribulations of HTML5 Video in the Post-Flash Era.”  This is an unabashedly pro-HTML5 article that points out just how far HTML5 has to go on video alone.  Read the article, but the highlights for me is that the Open Standard lovers at Mozilla still have to use Flash to do real time streaming of their Red Panda cub mascots and the discussion of how the lack of DRM standards and availability for HTML5 means the content owners and streamers still can’t endorse it.  BTW, the latter are only too happy to drag their feet until they perceive some perfect solution.  They don’t want it to be easy to get access to their content.

If we’re lucky, we may get these video issues resolved by this time next year.  Finally, we’ll have video, but that’s a tiny part of what you can do with Flash today, and most Flash proponents would argue it is an unimportant part.  What about the rest of what you could do with the Flash ensemble?  What about Apps?

Flash/Flex/AIR Going Forward:  King of Apps Platforms?

Putting aside video, why would anyone have cared about Flash/Flex/AIR to start with?  If things were as bad as the haters said, it just wouldn’t matter.  Let’s go back a very short while in time, to before the iOS/Jobs kerfluffle started the process of killing Flash.  To a time when it was largely about the desktop.  We had largely the same Flash/Flex/AIR that we have today.  In fact, one could argue Adobe’s failure to evolve them fast enough led to their demise on mobile because they just didn’t present well–too many performance problems, too much battery consumption.

Before Flash had these mobile issues, it was a pretty neat platform.  It could build the richest UX anyone had ever seen.  The world had been pursuing interface builders for a long time.  I saw my first one on Steve Jobs’ NeXT, and most of the reason we bought one for Borland’s labs was to study the developer tools on NeXT.  Visual Basic got to be what it was largely because of its nifty interface builder.  That was the Visual in Visual Basic.  Adobe brought together an interface builder, a very nice OOP framework of objects called Flex, and a great language called Actionscript under one roof, and they made it run everywhere.  Even better, it was completely portable, write once, run anywhere.  With AIR, we could build powerful desktop applications.

Let’s be really clear about the advantages versus the alternatives:

– Write once run anywhere.  Still true for apps, no longer even in the running for browsers.

– Better language.  Actionscript is a much more modern than Javascript.  It has even run a lot faster for most of its life than Javascript.  Ironically, it was more the runtime functions, such as how video was implemented without supporting the native GPU, that hampered Flash performance.  If there is one thing developers seem to get wrapped around the axle about, it is their religion around their languages.  A lot of Actionscript developers really have to hold their noses when they try to switch to javascript.  Ironically (lots of irony for Flash), it is an Ecmascript language like javascript and one could directly graft its features into javascript if only you could get all the standards-making players to agree to do so.  One wonders whether HTML5 (or 6?) will ever tackle the problem of improving javascript.

– Rich Ecosystem.  There is a ton of code and expertise out there waiting to be leveraged for your Flash project.

– Standard Framework:  Love the Flex framework or hate it, at least it was standard and there was a considerable investment in it.  And if you didn’t like it, there were lots of other frameworks.

For some reason, most of the developer stack sex appeal has been on the back end server side.  MySQL and NoSQL.  Cloud Technologies.  Ruby on Rails, node.js, or name your favorite language du jour.  The client has always been sorely neglected.  Perhaps this is a function of the Internet revolution, where the focus has been on HTML, and innovative front end languages like Smalltalk fell by the wayside.  HTML itself is hacks layered on hacks.  It started out not much better off than half duplex 3270 green screens.  After years and years we finally added the AJAX hacks to make things a little nicer.  But it was never really designed to be elegant.  The original prototype for javascript was built in 10 days and rushed out the door.  That’s not to say the prototype didn’t have good breeding, Brendan Eich, it’s creator, has gone into all that, but nevertheless, it’s not a language that’s particularly polished.

Where are the cool client side stacks that are open and portable across many platforms?

There are some stacks built for writing games.  I’ve looked at a bunch of them hoping one will be a good Flash successor.  Sure doesn’t look like it.  They’re just so game-centric, and they have other issues that mitigate against calling them the ultimate app technologies.

What about HTML5 itself?  Well it just isn’t set up to live outside the browser.  I suppose it could someday.  After all, if node.js can bring javascript to the server, it seems very likely we can build some kind of equivalent to AIR for javascript.  In fact, AIR itself can be used with other languages and one would think making it work with HTML5 will be a high priority for Adobe.  For a time, Google supported this thing called Gears that was aimed at being able to run web apps while disconnected from the net.  But the future of gears is somewhat in doubt.  Whatever may come of turning HTML5 into an app platform has to wait until it has caught up on the web with things like video.

As far as I can tell, if you want a killer rich UX environment for creating powerful apps that are write once run anywhere on the desktop or mobile, Flash/Flex/AIR is the only game in town.  It’s no wonder, then, that this is where Adobe has chosen to make their final stand with Flash, targeting precisely that audience.  It’s unfortunate that they have so poorly understood the trust issues that their other announcements would create.  It may be that even though they have this fabulous platform, there’s been so much damage to the trust of their developers that they will not be able to successfully leverage it.

Going forward, developers will have to decide whether they believe Adobe is sufficiently committed that they want to use this platform for apps, or whether they’d rather take a politically safer route and deal with an inferior platform.  The costs are not insignificant in going the politically correct route, and worse, you don’t even really have the HTML5 wind at your back for non-browser apps.  Flash will be here for years, and even if Adobe does not continue to improve it, you already have the best tools for creating rich UX apps on all platforms, so maybe its worth ignoring the political considerations for a while longer in order to give alternatives a few years to catch up.

What it means for Adobe and Google going forward

As far as Adobe is concerned, they’ve got to be licking their wounds.  The strategy they’ve launched was poorly conceived and poorly communicated.  To the world it looked like Big Corporate Cutting Costs again, while they ignored the impact on the community.   Whether that’s what happened or not is immaterial, there is a large audience that feels betrayed.  Those who stick with it through inertia will be loath to be quite so loyal again, and in particular, their management will be much harder to convince going forward.  Everyone will be trying all the alternatives.

With that said, the Flash/Flex/AIR platform for apps is the best toolkit there is for building rich apps and it will take years to usurp that in any meaningful way.  Companies will have to choose between supporting fewer platforms (i.e. just iOS), living with fragmentation and loss of productivity if they walk from Flash, or living with the current political climate around Flash.  Not a happy choice to be sure.

What can Adobe do to shore up the trust issue?

I’d recommend two things.  First, in for a penny in for a pound.  Open Source the remaining bits of the platform–the Flash Player and AIR.  You’re in the business of selling tools, so keep Flash Builder to yourselves if need be, but you may as well put the rest of it out there so the community can at least be the masters of their own destiny.  You’ve already done it with Flex, and there are other bits and pieces.  Get it over with now.  Who knows, maybe this will re-ignite support for Flash in mobile browsers.  Second, declare your commitment in dollars and cents.  The secret fear everyone has is that the Adobe resources being committed to Flash dwindle day by day and announcement by announcement.  Put a stake in the ground around that.  If you have reduced the heads focused on Flash, tell us by how much.  Commit to keeping levels where they are, or at least be transparent about what’s really going on with your investment in Flash.

For Google, this has been as big a mess for you as for Adobe.  Guys, I don’t know how you can afford to let even one reason to pick an Android device over an iOS device go away.  There are definitely people picking Android over iOS because it (used to) support Flash.  Check out the comments on this thread.  The latest data sure shows lackluster interest in Android Tablets.  Apparently you have to slash prices all the way to Kindle Fire levels and put a huge name like Amazon’s on the device to get traction.  There’s also questions about how well apps sell even among the audience that bought Android.  Despite your 50% market share, Piper Jaffray says you only have 7% app revenue share.  That’s not good.  You should get with Adobe and embrace this whole Open Source movement for Flash.  Convince them to Open Source the rest of it and announce your own major commitment to keep it going.  Continue to build it into Chrome and keep it alive on your mobile platform.  Push as only Google can and Adobe clearly can’t.  You need to differentiate versus iOS.

For everybody else, analyze the impact of fragmentation

For everybody else, analyze the impact of fragmentation because that’s the big strategic move that’s afoot.

For smaller players, fragmentation is toxic.  If I am already being spread thin having to support more platforms, I will be looking for sensible cut off points where there is too little market share to matter.  I will draw my line in the sand there, and you will be stuck on the other side with not enough oxygen.  This is not an issue for iOS.  It is so successful, it goes at the top of the ports list.  Google Android, also safe, but needs to worry about the troubling preference of buyers for iOS as well as the patent wars.  Smaller share browser and mobile platform owners, look out.  You’re the ones who will be hardest hit by fragmentation.  Fragmentation benefits the incumbents and slows down the adoption of innovators.  It’s sand in the machine because it soaks up cycles that would otherwise be available for innovation.

Fragmentation is an interesting issue for Microsoft.  They’ve contributed to Flash’s demise by announcing they’re dropping plug-ins from Windows 8.  The question for Microsoft is going to be how much longer they can retain enough market share through their desktop hegemony to force people to deal with their platforms.  I have been watching incompatibility with current versions of IE get worse almost daily, particularly on G0ogle web properties, but fairly widespread.  IE hasn’t really changed, so it is the sites that are choosing to make changes without being concerned with IE compatibility.  Microsoft may already lack sufficient mindshare to convince developers to follow their lead if Win 8 and versions of IE related to Win 8 require much porting effort.

11 Responses to “How Should We Think of Flash Going Forward?”

  1. […] How Should We Think of Flash Going Forward? […]

  2. schlafly said

    Google listed last year a bunch of reasons why YouTube still needed Flash. It now says that some of the HTML5 deficiencies are being addressed.

    Google is pushing a Javacript-like programming language called Dart. I don’t get how that is going to catch on, unless Google released a bunch a good tools for doing Android apps in it, but Google does not seem to be doing that.

    • Google seems to do a lot of odd things. I have always assumed it is all about that free-time allotment to the engineers. Perhaps they’ll come out with a cool platform for desktop and mobile clients. Not sure they have the greatest track record for creating developer’s tools either though they do support a lot of Open Source reasonably well.

    • schlafly said

      Google is now killing Gears, as well as Bookmarks List, Friend Connect, Search Timeline, Wave, and Knol.

      • If you’re on the winning side of the fragmentation cutoff point as Apple and Google are, you should want to minimize portability tools and any other technology that pierces your walled garden. Interestingly, Amazon appears in a position to take over Google’s Walled Garden if Kindle Fire is the only non-iOS tablet that succeeds for long enough.

        What a tangled web we weave when trying to wall our gardens.



  3. “One thing Flash made it possible to do was to ignore fragmentation to a degree. Write once, run everywhere was a beautiful thing.”

    “Everywhere” meaning “platforms that Adobe decided to support”. I experienced that “run everywhere” first hand back when I ran 64bit Linux. Ooops, no Flash! Didn’t it take Adobe over 7 years to come up with some kind of support for 64bit Linux? Nice work Adobe!

    I bet that people will say “64bit Linux? Who cares about that?!”. But the point stands: Flash does not run “everywhere”, it only runs on platforms Adobe decided to support.

    And not only that, it also didn’t run on platforms where Flash was not allowed, like iOS. Andwhat about Android and Symbian? It was available on Android at least, but was it usable? What about Symbian? I don’t think Flash ever worked on any of my various Symbian-phones. So claiming that Flash ran “everywhere” is such blatant distortion of facts that I have no idea how that argument was even made with a straight face.

    • Pardon me, Janne, I should have said “platforms that mattered on the desktop.” 64 bit Linux didn’t. Complain to the Linux people about that. I think it is interesting that Apple can muster a Unix based OS that is popular but Linux hasn’t been able to. That’s a topic for another post, though.

  4. I also feel betrayed, I’ve been working with flash since version 5, and it has come a long way, and once you master ActionScript 3 it really is a nice language to work with.

  5. WaltFrench said

    “Let’s go back … to before the iOS/Jobs kerfluffle started the process of killing Flash. … The strategy [Adobe] launched was poorly conceived and poorly communicated.”

    I don’t think you’ve quite realized that these two are the same thing. Adobe has NEVER COME CLOSE to implementing Flash HALFWAY PROPERLY on a mobile machine anywhere as CPU- and memory-constrained as the early iPhones. (If you think that 2008’s ARM chips have as much as 25% of similarly-clocked Wintel machines’ performance, please contact me about a land investment in Florida.)

    That is, Jobs was ALWAYS right on one critical fact: Adobe was NEVER prepared to support Flash on anything close to diversity of mobile platforms of ANY year.

    A huge opportunity in terms of hungry consumers — mobiles already outsell PCs, and they’re growing towards parity in terms of hours of internet usage — and Adobe cannot afford the engineering talent? Saying this is about Jobs covers up the fact that Adobe never tried to support the then dominant platforms (BlackBerry, Windows Mobile, Symbian) with Flash. Heck, there will soon be more non-iOS mobiles than PCs, so blaming this on Apple looks like willful ignorance — i.e., a damnable lie.

    Why doesn’t Adobe address this huge opportunity? It’s obvious: multiple OS versions; multiple CPU/GPU platforms; a huge range of memory availability; multiple video codecs, at least one of which was tweaked to be highly Intel-dependent C and nearly impossible to port; heavy engineering expenses for the intricate coding required; a dynamic industry that could not afford to wait months for Adobe to support a platform.

    Look at how the bumbling Flash helped utterly kill the hapless Motorola Xoom, a machine that featured a powerful nVidia CPU that was DESIGNED for Flash.

    In other words, Adobe NEVER had a realistic business strategy for supporting Flash on mobile. They should have long ago realized that they could not continue the success that they enjoyed on the desktop. Perhaps they looked at dropping the copyright/licensing issues so that OS developers could support Flash instead, but didn’t see the money in it. Whatever; with Microsoft and Kindle forking the mobile space even further, Adobe can no longer hope that the industry would consolidate, and the game is obviously lost.

    If there’s any place for outrage, it’s that Adobe encouraged developers to believe that things would be great, when in fact, the recent action was always near-inevitable. The propagandists like Brimelow should issue public apologies for their intentionally misleading propaganda.

    • Walt, get down off the chair you’re shouting from before you hurt yourself, find a paper bag, and breath deeply until you’ve calmed down. Then go back and read BOTH posts. Especially the one where I said, “He was articulate about his reasons, and it hurts me to say that he was right,” in reference to Jobs’ pronouncements about Flash. While you’re at it, look carefully and see where I’ve blamed any of that on Apple or Jobs. You’re an investment advisor Walt, you need to read more critically and carefully than all that and not get caught up in the emotions!



  6. […] How Should We Think of Flash Going Forward? […]

Leave a Reply

%d bloggers like this: