Why Mobile Flash was killed – the other meaning of virtual sustainability

This blog post by Mike Chambers details why Adobe killed mobile Flash. We all know part of the reason was HTML 5. But, interestingly, the other reason cited was “sustainability” in the context of keeping a program, framework, or project going.


Telling quote:

“In order to get Flash working properly, Adobe has had to work with multiple OS vendors, multiple device manufacturers, and even multiple chip makers. That kind of effort, Chambers says, was “‘simply not scalable or sustainable.'”

So, we have a connection between scalability and sustainability! This is in turn, tied to some of the basic definitions associated with sustainable things or processes – flexibility. In this context, Adobe meant that the complexity of the hardware ecosystem required that they repeatedly crank out new versions of Flash – all which would create new forks and require maintenance. So, the complexity of maintaining and updating Flash would grow, rather than remaining at the same level.

Therefore, one of the definitions of “sustainable virtual design” at the code level is:

1. You create a single, low-level standard (HTML 5)

2. You create a program with a higher-level API into that standard on a common software platform (i.e., a web browser)

3. The program is so important that hardware manufacturers are willing to make sure that the software runs on their system. So, a vendor that doesn’t support HTML5 aware browsers is left out of the action, and provides the really-low level hooks needed to cross-compile a working program on their platform.

The problem with Flash was while the SWF format is a kind of standard, Flash itself is not.

One of the reactions to this move will be people using programs like Google Swiffy – a Flash to HTML 5 cross-compiler.


But, despite the hopes of the legion of developers (along with Flash timeline weenies who don’t ever want to code – I suppose it will crush their artistic creativity) this is at best a stopgap solution. Unlike compilers, with a long history of optimization, it is very unlikely that a swiffy HTML 5 program will show the performance of a native flash or HTML 5-coded app.

We already have one energy-wasting inefficiency going on – the cross-compile of HTML 5 web browsers themselves. Swiffy will add a second layer of clumsy, machine-generated code that at the very least will require hand-picking by a ‘codebeast’ developer to improve its performance. Worse yet, there are bound to be “framework” assumptions in creating Swiffy that will make the entire program inefficient.

The lesson here – for sustainable virtual design, you want only ONE level of inefficiency, if you have to support one common bit of sofware on multiple hardware platforms. Authoring layers (e.g. Flash timeline) and high-level web-based programming language cross-compilers are inefficient, and require more people and resources to provide the same user experience. In other words, we can justify a common platform for development by invoking “sustainability”. Companies can also use “sustainability” to justify a choice of a “hybrid” designer-developer over a designer restricted to authoring layers for creating project. The general pressure sustainability creates at the social level is more designer/programmer hybrids, fewer specialists on design or programming. Specialization is a result of environments where sustainability is ignored or not important.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.