HTML5: how replaceable is Flex?

Posted on August 11, 2010


With HTML5 and the Video-tag a lot of people who hate Flash hope Flash will die. What I have not seen addressed enough is the position of Flex. Very likely because it is even more of a niche-product than Flash is for online applications. (“Niche” meaning here: used for very specific purposes in very specific situations)

I have been working with Adobe Flex on and off on projects for the past three years. Brief on Flex: it was released around 2004 by Macromedia (now part of Adobe) to get into the Rich Internet Applications market left open by Java and the unfulfilled potential of HTML 4. It is an extra layer on top of Flash specifically designed to build web applications. It was also one of the reasons for me to drop my own Fluid Flash Interfaces Engine project in 2004.

Where online applications based on Java plugins were heavy to load, looked horrid and were not always working that properly due to lack of support of the right plugins, HTML4 simply failed due to browser incompatibilities.

Flash will do just fine

I think Flash will do just fine as long as Adobe continues to invest in it. It is and always has been a niche-technology with very specific uses which HTML and the browser can not provide. It bypasses all the things web browsers do not (yet) provide to build interactive websites (see the history of releases here). A stable “looks and works the same anywhere” WYSIWYG, using audio and camera-input, socket connections and streaming video and audio to the server are four examples HTML can not counter yet. The (hope and pray, based on rumors) move towards 3D and a better use of memory and the GPU is another. Where Flash-banners are everywhere, sites built on Flash are sparse compared to their HTML counterparts.

HTML fanboy

I am an HTML fanboy. I think,  combined with JavaScript, it is one of the most powerful and successful “visual programming environments” for applications which you can deploy on a huge scale – ever. The main reason for me to move to Flash and to remain there for a at least a few years more is the Browser Incompatibility hell. With Flash, what I build, works almost anywhere, the way I expect it to do. HTML leaves me hoping and praying my more advanced HTML / JavaScript magic will not break at some point.

Flex is replaceable

Flex is – in my personal opinion – best used to build web based applications. I know people also use it to build interactive websites, but as a Flasher, in my opinion that is not where it’s strong points are.

When you look at web-applications, you talk about forms, tab sheets, lists, buttons and smart ways to prevent the dreaded – you break my user experience of an seamless workflow – page-loads when you do a submit or load new content.

I am going to be crude.

Flex for it’s use for RIAs is completely replaceable by HTML5.

  1. Using the HTML Document Object Model and JavaScript, you can dynamically load application parts and build  single page user experiences to keep a fluid workflow and flow of information (since 1998)
  2. Web-sockets make it possible to create asynchronous push/pull connections to make your applications interactive with your server and server data in ways a normal HTML GET/POST can not (as of 2010 on some browsers).
  3. GET and POST are your fallback scenarios when Websockets fail.
  4. Binary data can be sent as clear text. Flash has a protocol called AMF. It allows you to “directly” communicate with objects on the server. Forget about XML and SOAP. About 70% of the data you send is overhead. Using Web-sockets and data-serialization will reduce the amount of overhead and allows for direct mapping of objects from Java, .NET, PhP and whatever you use server side
  5. Canvas and JavaScript can be used to generate interactive charts, another benefit of the default Flex package. Already people are building interactive chart in JavaScript / HTML / Canvas (I saw the first examples by Kilian Kerkhof in early 2010).
  6. HTML benefits directly of the optimized render engine of the web browser. Flash runs in a Virtual Machine and renders (until august 2010) visual elements via the CPU. There is a (significant) loss in performance for Flex due to that.

The one point about HTML 5

You can not dictate what browser people should use. So in your potential audience you will find people using older versions of browsers that will break your application, either on performance or in possibilities.

The alternative is to build fallback-scenarios:

  1. Multiple libraries in JavaScript to deal with specific ways specific browsers deal with specific ways of rendering your content
  2. Multiple ways to pass data to the front end to cover for the lack of support for newer technologies like Websockets
  3. Multiple sets of CSS to deal with incompatibilities

Look here to see how relevant the people of this HTML5 framework consider these issues. To me RIA in HTML, due to the current browser incompatibilities is a little bit like this.


Once you get past this point (and no doubt there are multiple libraries who deal with this, of which this one is one) HTML and HTML5 becomes a serious candidate for these project that use Flex now.

  1. HTML is by default “load on demand”. Thus (When you do it right):
  2. HTML applications are easier to maintain and expand due to the “load on demand” character of it and the “do not compile, replace the files you need to replace, run directly” aspect of it.
  3. HTML applications are less of a strain for the browser and your computer memory again due to the “load on demand” aspect. (In Flex, by default, you compile everything in one package and throw that entire package to the browser, whether your user will use 50% or 1% of it.)

Yes: you can counter these three arguments (maintenance, strain and load on demand) from a Flex point of view. Point here is that you need to make a stretch to NOT create you application as one single bulky package and a real big effort to keep your memory use within acceptable limits. Due to how Flash deals with visual objects in memory until now (August 2010), many Flex projects start at eating 200 MB of your computer’s RAM right when loaded in memory.

Posted in: Opinions