Over the past week, I had a slew of press inquiries about the future of Flash, driven largely by the Apple iPad announcement — an event in which Flash was conspicuously absent. Of the top of my head, I put together some key points in the conversation, presented below.
As I mull these talking points over and discuss them with colleagues, some of these will likely end up in a research note, along with actionable advice. For now, here are some aspects of a multi-faceted situation.
- Plug-in based RIA is not only about Flash. Any discussion of Flash should also (depending on the level of detail) rope in discussion of Microsoft Silverlight and Java. Many of the issues that impact Flash also impact these other approaches. For example, none of these run on the iPhone or iPad today.
- HTML5 is the future of the Web, but that future could take a very long time. The HTML5 is large and complex, and current projections by the people working on the spec (Ian Hickson of Google and David Hyatt of Apple) are for all parts to be finished in the year 2022, some 18 years after the process began (in 2004).
- However, some Web sites are already using (a subset of) HTML5. You don’t have to wait until 2022 to use HTML5 or a working subset of it. For example, YouTube and Vimeo have already rolled out use of the video element in HTML5. Other web sites and applications are using Canvas and offline storage. There is a de-facto working subset of HTML5 that is already starting to appear, both on the “desktop Web” as well as the mobile Web.
- The working subset of HTML5 is nowhere near the power of Flash. There are many advanced effects that are only available in Flash or Silverlight or Java. For example, Google, which is driving HTML5, relies on Flash in Google Maps (for the Streetview) and in Gmail (for the multiple-file upload capability). There are tens of thousands of Flash games on the Web (at game portals like Pogo or as game apps within Facebook or Myspace) that would be difficult to do (in a performant way) with HTML5.
- However, a significant majority of Flash content on the Web does not need to be in Flash. Although there are tens of thousands of Flash-based games, there are millions of Web sites that use Flash in a simple manner (for basic interactive content such as banner ads or splash pages). One could argue that much of this content is of low value (users get “banner blindness”, and are habituated to skip useless intro or splash pages). Regardless of its value, much of this simple interactive content could be replaced today’s HTML5 working subset, although only from a browser technology perspective.
- It’s not just about features, but also about deployed infrastructure. This benefits Flash. A pragmatic perspective should look at the numerous tools, ad engines, business processes, infrastructure and platforms that support and/or enable Flash-based advertising. This aggregate mass will take a long time to shift to an alternative, no matter how good that alternative may be, due to sheer inertia of large scale systems that are operationally functional.
- The iPhone and iPad throw a harsh spotlight on Flash, at least for those readers who only read about Apple’s side of the story in the mainstream press. Apple says that Flash is low-performance, insecure, drains battery life, and this week Jobs was quoted in some articles as saying that Adobe programmers were “lazy” because they did not improve Flash.
- However, Apple’s resistance to Flash is irrational and long-standing. The comments about performance and security are hypocritical given that iPhone OS versions are regularly jailbroken through security flaws in Quicktime, Safari and other parts of the stack, and that there are many thousands of apps in the App Store written by semi-skilled programmers, or those who are in it for a quick buck. For example, the 3rd most prolific developer on the App Store had 943 apps to his name (releasing about five low-value, relatively high-priced, apps per day), until he was banned by Apple. So the resistance by Apple to Flash appears to be due, not to technical considerations, but to some kind of personal grudge or beef that Steve Jobs has with Adobe, one that perhaps dates back to the days of Display Postscript, John Warnock and the Next machine. Also playing a role is the potential for Flash to threaten Apple’s platform, given it is a cross-platform presentation layer on mobile and desktop machines. (However, Apple seems to grant Google a “most favored nation” status despite increasing competition with Android, which is why Apple’s objections to Flash seem irrational.) Barriers to Flash on the iPhone/iPad will linger as long as Jobs is at the helm of Apple. The question is what impact will this resistance have on Adobe, and to what extent Adobe can work around these limitations (as it has started to do with its Flash-to-iPhone compiler).
- Any large powerful app will consume CPU and battery , whether that app is written in Flash, Silverlight or HTML5. Simple apps consume minimal resources, and most HTML5 and Flash apps are simple. Complex apps with high interactivity and large amounts of computation will consume CPU and battery no matter what technology they are implemented in. Some may be better than others in this regards — perhaps even 20% or 30% better –but such differences are incremental, not game-changers, in the big picture. Granted, the iPad has the potential to change the rules of the game a bit with the A4 custom processor that can decode HD video without draining battery life quickly (Apple claims 10 hours). But if the A4 is such a leap forward, one would think Apple would let allow Flash on board so it can fall flat on its face.
- Flash has a long record of being light, fast and (reasonably) secure, which is why it is found in 98% of Internet connected PCs, and why it succeeded while other approaches failed in the market (client-side Java, ActiveX, WPF, etc). This does not mean Flash is the optimal choice for a Web page that requires simple interactivity (any more than client-side Java or Silverlight would be).
- HTML5 is the future of Web, for simple interactivity, including charting, some limited 3D vector graphics, image transforms, video, audio. It is possible that 90 to 95% of an average enterprise needs could be met by HTML5 There are only a few classes of corporate apps that would gain significant benefit from Flash, Silverlight or Java over what is available in HTML5 or even in Ajax.
- However, there is a portion of the Web that requires richer interaction,. Your mileage (i.e. requirements) may vary, of course. Your applications might require extensive offline processing, direct manipulation of graphics, real-time notifications and alerts, high-speed binary communication protocols, tight integration with local devices, and so on. In these scenarios, you might need to use Flash, Silverlight or Java (the exact choice would depend on your context, such as your development team, your IT landscape, your vendor relationships, and so on).
- The choice among these technologies is not “all or none”. One approach that many, if not most, organizations might end up pursuing is a hybrid approach — sometimes known as “islands of RIA” or supporting “hot spots of interactivity”. In the near term, this requires a plug-in based approach, such as Flash, Silverlight or Java. Over the long-term (5 or 10 years), HTML5 may fit the bill.
- The old anti-Microsoft alliance of Google, Adobe, and Apple is splintering. This was only a loose alliance to begin with (“the enemy of my enemy is my friend”). But now there are multi-way tensions and collision courses (Apple vs Google in mobile space, Apple vs Adobe in browser/plugin, and of course Microsoft vs each one of these).
- HTML5 poses a strategic threat to Adobe, as well as to Microsoft and Java. However, Adobe is the most impacted in the short term — because Microsoft has some solid territory in enterprise IT environment (for example, Silverlight is leveraging the success of the Sharepoint portal), and enterprises do not shift direction easily. Also, Silverlight leverages .NET developer skills directly. By contrast, the consumer Web (especially the smaller more agile Web properties) can change direction and platform more quickly. Flash is used in 70% of high traffic Web sites, but some of these uses are surface-level and easily removed. (However, as mentioned earlier, it will be harder to turn large scale ad-engine operations around).
- Adobe sees the writing on the wall and is responding. Adobe has undertaken various initiatives, from the Flash library for iPhone that allows compilation and embedding into native iPhone apps, to Flash 10.1 which is a more efficient implementation for mobile CPUs that need to conserve battery life, to improved security procedures and development process. Adobe’s future depends on how well and how fast it executes.
- Lastly, the average enterprise won’t effectively use Flash or HTML5 or any other shiny new UI technology. Because the root problem as I see it is not lack of powerful UI technology. Instead, the root causes for sub-optimal user experience have to do with lack of appropriate process, and governance, and lack of a genuine commitment to a quality user experience. Such a commitment would lead organizations to adopt a user-centered usability-oriented development process. Rather than taking these steps, we see a lot of projects that are “stakeholder driven” (i.e., driven by internal politics). Very few organizations center development around user needs by relying on objectively measured data about user behavior. Most enterprises don’t care enough about the user experience to change their habits (developer-driven, vendor-driven, stakeholder-driven). The principles of creating effective user experiences are well-known among successful external-facing ecommerce or consumer sites such as Amazon, Ebay, Expedia or Facebook. Unfortunately, it will likely be a long time before these principles become part of the average enterprise skillset.
Anyway, that’s probably too many talking points for now.
And you, what are your thoughts and reactions?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.