Site icon SmoothSpan Blog

How Should We Think of Flash Going Forward?

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.

Exit mobile version