Archive: A Review of Flash Killers


#1

Sometimes to understand why a technology end up the way it is, it’s good to remember why and how it got there.

Even if this forum is mainly about ActionScript 3 a programming language, I thought it would be interesting to post some selected archives of blog posts or other writing to give more context around surrounding and related subjects like Flash, browser plugins, etc.

TL;DR I find some stuff interesting so I made a big copy/paste.

That does not mean I fully agree or disagree with the original article, I just find it interesting and a good knowledge to share with others.


A Review of Flash Killers
25 oct 2011
author: rblank ( @rblank9 )

original: http://labs.almerblank.com/2011/10/a-review-of-flash-killers
archive: http://web.archive.org/web/20150708113304/http://labs.almerblank.com/2011/10/a-review-of-flash-killers

Disclaimer:
This is the copy of an archive of a blog post, I did not write the following.
Everything under the “line” are the words of the original author,
only things that have been edited are the links, and maybe a bit of layout.


A Review of Flash Killers

I wanted to continue the discussion that I started last week on my personal blog, on the subject of HTML5 and Flash, by addressing the notion of “Flash Killers”. Because, in some circles HTML5 has assumed this same designation, and it’s useful to remember that this is not the first time that the term has been invoked to describe a new technology. In fact, Flash Killers have come along about once every two years.

A review of some past ‘Flash Killers’ might help illuminate the discussion as to whether or not HTML5 is.

Flash Killers

Before diving into a list of Flash Killers, it will be useful to define the term.

A Flash Killing technology is a technology that will kill off Adobe Flash Player — either by:

  1. eliminating the Flash Player from a sufficient number of viewers’ devices to defeat Flash’s positioning as a ubiquitous technology
  2. or by eliminating demand for Flash technology amongst firms and developers by supplanting Flash’s features and functionality

Each of the following examples was either explicitly positioned by a firm as a Flash Killer, or was seen by the broader market, or some segment of the market, as a Flash Killer. I do not claim that this list is complete or definitive, but these are definite highlights I can call from my experience in this industry. If you can think of some that I missed, please let me know in the comments.

Scalable Vector Graphics (SVG)

SVG is an XML-based open standard, overseen by the W3C, in development since 1999. Despite the name, SVG accommodates for raster, as well as vector graphics, in addition to text. Today, SVG is increasingly accepted as a graphics and data format (it is, for example, one of the filters that you can apply on a Google Image search).

However, when it was introduced, it was seen by many as having a chance at being a Flash Killer (remember, this was at a time when Flash essentially only provided vector graphics, raster graphics, text, audio and a tiny bit of interactivity). And many firms — notably, Adobe — saw SVG as having a particularly good chance of taking out FlashLite as a threat on mobile. Adobe has long authored SVG viewers, and indeed, today Adobe still is involved in developing and promoting SVG.

Still, unfortunately, to this day discrepancies in browsers have prevented SVG from widespread adoption as a format for graphics, or any other type of data at all. Internet Explorer appears to be the main culprit, not adding basic SVG support until version 9.

Verdict: SVG may be a lot of things, but it was certainly no Flash Killer.
There may have been multiple reasons, but the absence of universal browser support effectively made this technology a non-starter from the get-go. And today, SVG pales in comparison to the functionality offered by Flash.

Adobe Live Motion

This one is sort of my personal favorite, for a few reasons.

  1. First, Adobe Live Motion is a relic from the days when Macromedia and Adobe were enemies entangled in litigation, rather than a single firm dominating creative workflows across industries;
  2. Second, because it seems that people barely remember this product;
  3. And third, because unlike many of the other technologies included in this list, Live Motion did not challenge the Macromedia Flash Player — instead, Live Motion relied on the Flash Player, and went after the Macromedia Flash authoring tool market.

In other words, Live Motion was Adobe’s attempt to cut off Macromedia’s revenues, using Macromedia’s own runtime as the weapon. In case you aren’t aware, Macromedia (then) and Adobe (now) do not make a dime from the Flash Player — the revenues come from the authoring tools used to create the content that is viewed through the Flash Player.

Released in 2000, Live Motion offered, to my recollection, three notable features:

  1. Time-based animations (instead of the frame-based animations in the Flash authoring tool, then and now)
  2. No ActionScript
  3. An animation interface similar to After Effects

The time-based timelines were a kind of a nifty feature (eliminating the need to re-key your animations when you adjust your framerate) — in fact, there are still times today when I wished Adobe Flash offered this same option. And the integration with an After Effects-style GUI was likely quite useful for those coming to Flash from that tool.

However, in my opinion, LiveMotion was fatally flawed from conception because of the lack of ActionScript support. True, LiveMotion was positioned as an animation tool (and thus wouldn’t require ActionScript), but even back in 2000, when ActionScript was a pale imitation of the coding language we have today, basic AS was required to do things even as simple as banner ads. And when you needed to use AS in your project, LiveMotion wasn’t an option.

LiveMotion was discontinued after two versions.

Verdict: LiveMotion was not only not a Flash Killer — it wasn’t even a viable product. Though, it is notable as the only member of this list to explicitly attack Flash as an authoring tool, while reinforcing the dominance of the Flash Player and underscoring the importance of ActionScript to the future of Flash technology.

Processing

Originally developed as a language and IDE (‘integrated development environment’, aka ‘authoring tool’) to teach programming to more design-oriented creatives, Processing made its way through the Flash community in the middle part of the naughties (the term I prefer for the first decade of this millennium). One of Processing’s main innovations was the inclusion of a ‘Sketchbook’ as the IDE, simplifying and reducing the learning curve for designers to program.

To my recollection, Processing was not a sufficiently high-profile technology for much of the media to take note, but the Flash creative community (which Flash, unlike any other web or programming technology, has in droves) did. And they complained vocally that Macromedia needed to add features to cater more to designers and designer-based workflows, as Processing had done. (It is important to note that, by this point, Flash had seen the two most recent versions include new features that catered to developers more than designers or animators). I remember hearing that more and more of the design community was considering a switch to Processing if Flash didn’t add more considerations for designers. Processing was (perhaps inadvertently) making a play for the hybrid designer/developer for which Flash had become so well known.

Processing is, to this day, a successful niche technology, enabling some wild creativity. But it never made a real or long-lasting impact on the Flash world. Why? Well, in my opinion, there were three main issues:

  1. First, compiled Processing experiences require the Java runtime to view. Java is just not that widely-distributed — certainly not in comparison to Adobe Flash Player. A technology does you no good, no matter how expressive it is, or easy to work with it is, if the end-result can not be seen or experienced by your audience.
  2. Second, while Processing features an IDE that makes coding much easier for designers, it doesn’t include any design tools to speak of. Whether you are outputting to Flash or HTML, Adobe has tools that provide the entire design workflow prior to engineering. By comparison, it’s just not that easy to port Photoshop and Illustrator designs into Processing.
  3. And third, Flash got more visually expressive in subsequent versions.

Verdict: Processing is popular, innovative and fosters a wide degree of creativity. As well, it is has found a market in which it continues to be adopted and utilized. I would say that it is a successful technology on its own terms, but in the end, was no sort of ‘Flash Killer’.

Microsoft Silverlight

Microsoft Silverlight was introduced in 2007, and was positioned, to my recollection, explicitly as a Flash Killer. And, while you can debate which technology is better for which purposes, I believe that it is difficult to argue that Silverlight has been a successful web technology, or has come anywhere near achieving Microsoft’s goals of supplanting Flash.

Microsoft faced three challenges with Silverlight:

  1. to get developers using their tools
  2. to get clients approving Silverlight work
  3. to get their Silverlight Player installed on computers

On the first item of tools, Microsoft has two tools to author experiences in Silverlight. The first is their powerful Visual Studio, which can be used to code and debug applications. The second tool is Expression Blend which is a tool more positioned to design and animate interfaces and content. You can think of Blend as roughly analogous to Flash Professional in function and purpose.

Visual Studio is really an impressive tool, enjoyed by coders of many languages. And, you can program Silverlight experiences in multiple languages. So Silverlight included a robust engineering IDE. However, without going into the details of Expression Blend, let’s just say that Microsoft doesn’t excel at creating professional design tools.

Beyond the capabilities of Blend, it’s important to remember that Microsoft does not make any solutions for content creation further up the workflow (I mean, it’s not like you’re going to use Microsoft Paint to design your web apps). Almost all of the time when working in Flash, you are working with designs that originated in Photoshop or Illustrator. All of those tools are Adobe’s, and thus there is a clean workflow between design of an experience, and creation of that experience. Microsoft offered no design tools of their own, and only more recently has added workflows to support working with Photoshop designs.

When it came to having clients approve Silverlight work, Microsoft underwrote several high-profile projects, encouraging adoption among clients. This (along with the fact that you can develop Silverlight solutions in multiple, existing languages), encouraged developers to pick up the technology and fostered market penetration of the Silverlight plugin. But, it clearly hasn’t been enough. Per Wikipedia, Silverlight has a player penetration around 65%, versus 95% for Adobe Flash; and Silverlight is utilized by approximately 0.3% of websites, as opposed to Adobe Flash’s site utilization rate of 27%.

Verdict: at the end of the day, while Silverlight may be seen as successful in some ways, and may still see other successes in the future, it’s safe to say that it has not been a Flash Killer.

Asynchronous Javascript And XML (AJAX)

The history of AJAX actually extends back to 2000. And, while we saw some cool early implementations starting in 2004 (with GMail), AJAX became increasingly popular around 2006 and 2007.

Unlike every other entry on this list, AJAX is not actually a technology — it is a way of using Javascript to work with client-side technologies, like HTML and CSS.

When AJAX came into popular use, it was often referred to as a Flash Killer. And, it is certainly true that AJAX enabled firms like Google to start building rich internet applications in HTML, that previously would have required Flash. At the same time, of course, Flash continued to extend in power, offering new features (like high quality video) stimulating increased adoption of Flash technology.

And, AJAX relies on web browsers to interpret and execute the instructions. Since web browsers are created by multiple companies, and run on operating systems created by other companies, that means that there are platform-specific discrepancies with how AJAX experiences are rendered — leading to increased time spent in developing and debugging AJAX applications. And, of course, each time a new version of a new browser is introduced, you have to go back and test all of your older AJAX work for compliance.

Verdict: AJAX made the web better — a lot better — but it has certainly not been a Flash Killer. From my perspective, AJAX is used to enhance and improve experiences that are going to be written in HTML; very few AJAX experiences would otherwise be built in Flash if AJAX didn’t exist — they would just have fewer features and be less enjoyable to use.

The Ingredients of a ‘Flash Killer’

A review of the above contenders for Flash Killers is instructive on a few points. First, of course, it shows that we’ve been down this road before. Almost since Flash was invented, people have been trying to find the next ‘Flash Killer’ — and to date, no technology has proven itself capable of taking down Flash. At the same time, I think the above examples help illuminate what a successful Flash Killer would look like.

A Flash Killer would, to my mind, have to offer three things:

1) Compelling Feature Set

Of course, a technology seeking to become a Flash Killer would have to offer a compelling feature-set — at least roughly equivalent to the features and power currently available inside of the Flash Player and utilized by developers in projects, sites, apps and games.

2) Widely Distributed Runtime

Second, the Flash Killer would need to be viewable by a large audience. It doesn’t matter if you can create the most amazing experiences with a technology — if those experiences can not be viewed by anyone.

The Adobe Flash Player is the most widely distributed software in history — no other software comes close. According to the Adobe Census penetration of the Flash Player is currently at 99%; according to Wikipedia, that number is closer to 95% (depending on which entry you read). In any case, that’s a lot of computers. Which means that if you author something in Flash and post it on a website, most anyone in the world who browses the web can view it (and for those who can not, it is possible to install or upgrade the Flash Player pretty easily and seamlessly).

I also think it is worth mentioning that, not only can most anyone on a computer view your Flash, but when they view it, it will look, feel and operate the same — no matter what type of computer or web browser they are viewing on (or what future version of the Flash Player that they may have installed). I can literally open up some of my Flash 3 work today in the Flash Player 11, and it will still run perfectly, as it did the day it was first published. That’s a big difference from a technology like HTML, which is also universally viewable, but does not have a consistent, backwards-compatible runtime.

3) Tools and Creative Workflows

This is a key, and often overlooked, aspect of Flash — that Adobe provides not only Flash Professional (and now, Flash Builder and Flash Catalyst) — but also a whole set of tools that power the experiences created in Flash (or HTML, with Dreamweaver and Fireworks), including Photoshop, Illustrator and After Effects. In order for a technology to be a viable replacement, it must include tools to enable (or, at a minimum, accommodate) the creative workflows utilized by industry professionals that are based almost entirely around Adobe’s content creation tools.

This is where I think solutions like Silverlight were fundamentally flawed from inception. People not only need to be able to use your authoring tools — they need to be able to execute complete projects, from conception and design, all the way through engineering and deployment.

Where Does That Leave HTML5

Hopefully, as this post has attempted to convey, the history of Flash Killers is lousy with technologies that did not even come close to killing Flash. Some of these technologies were complete failures on their own terms (like LiveMotion) and some are successful and popular technologies that have just not killed off Flash (like AJAX).

Today we are revisiting this same discussion, but this time the market wonders if HTML5 will be the Flash Killer.

If we look at the criteria I highlighted above, that I believe are requirements for any technology to be a successful ‘Flash Killer’, HTML5 does offer a compelling feature set (although one not on par with Adobe Flash; more on that in a separate post). However, HTML5 still does not offer a consistent or universally available runtime, and the tooling to build HTML5 in professional environments is still quite early stage.

So, of course, it’s too early to tell if HTML5 can be a ‘Flash Killer’. That said, in my opinion, it seems obvious to me that HTML5 will play out much the same way that AJAX has. Yes, there will be some projects that will be done in HTML5 that would otherwise have been created in Flash; yet, by and large HTML5 will make the web better. HTML5 will improve the quality of experiences authored in HTML. It should not — again, at least on its own terms — supplant Flash technology. (I attempted to examine this question in much greater depth in last week’s post.)

So, when people ask ‘is HTML5 going to kill off Flash’ the answer should be ‘too soon to tell, but it’s unlikely.’

However, it is not possible to examine this question in isolation. Because when people ask ‘is HTML5 going to kill off Flash?’ they are really asking (whether or not they realize it) 'is Apple going to kill off Flash?'

Of course, everyone and their uncle knows that Flash Player has not run on iPhones and iPads since their initial release. Steve Jobs provided an explanation of their position in April, 2010 and concluded that “Adobe should focus more on creating great HTML5 tools.” Apple has additionally contributed significant efforts to creating and finalizing the HTML5 specification, and promoting its use in commerce.

Apple is trying to position HTML5 as a Flash Killer, because Apple wants to be a Flash Killer. HTML5 is simply the technology that Apple believes will offer an alternative for creating compelling, feature-rich experiences.

It is still too soon to tell how this will all play out. Adobe has recently created workflows to publish high-performing Flash work to iPhone and iPads, and we have to see how clients and the developer community adopt those new features. Perhaps Apple (in the post-Jobs era) might someday see their way to permitting the Flash Player on iOS; perhaps not. Perhaps HTML5 will be able to agree on a single video codec; perhaps not. We don’t know what features Flash Player 12 and 13 and 14 will offer (all of which will likely be released before HTML5 is universally viewable by web audiences). These are all open variables that will impact this discussion.

That said, Apple’s move was the first effective attack on Flash that I’ve witnessed in my 12 years of working with the technology. Because, this was the first time in the history of the technology that Flash was prevented from being distributed to a popular platform. One of Flash’s core advantages is that it can provide a consistent experience everywhere. And, for the first time, it didn’t actually work everywhere.

Still, it’s important to remember that HTML5 is only the latest in a longer list of also-ran Flash Killers. Flash is a very robust technology that offers an advantage that has proven to be unrepeatable and insurmountable — namely, that it works on every screen.

Verdict: It’s still too soon for a final determination whether HTML5 will be a Flash Killer, but I believe that history shows that, on its own, HTML5 does not have the ingredients to be a Flash Killer, and would instead prove to have much the same impact as AJAX has had, by making the web a better, more enjoyable place to spend time.

However, this is separate from whether iOS will be a successful Flash Killer. iOS has been effective at eating into Flash’s market, by attacking perceptions, and offering replacement functionality in the form of HTML5. But the absence of a technology that can actually, truly replace Flash on all platforms has given Adobe some breathing room to create publishing workflows to engage on the iOS platforms. And, without intending to sound harsh, the passing of Steve Jobs has removed the core actor in this drama from the stage. So, we’ll see in the next couple of years how this plays out.

Thus, HTML5 will not be a Flash Killer. Apple might. Time will tell.