Flex Vs Javascript

There is a debate currently brewing regarding the use of client-side view frameworks that provide Rich Internet Applications.  This document is a business-focused argument in favor of Javascript based on many merits:

1. The Ubiquity of Javascript
2. Javascript as an open standard as opposed to Flash as a closed standard.
3. Multi-vendor support of Javascript as opposed to the single-vendor support of Flash.
4. Performance of Javascript vs Flash.
5. Wide Range of Javascript frameworks vs. the limited number of mostly non-interchangeable Flash-based frameworks.
6. The ease of development within the Javascript ecosystem as opposed to the Flash ecosystem.
7. Other Issues (accessibility, and shortcomings in flash in general)
   

Ubiquity of Javascript

The Javascript programming technique that takes advantage of Asynchronous Javascript And XML (AJAX) gained popularity in roughly the same year as Adobe released a development kit for Flex, 2004.  Today, almost every web-based RIA application we use is a Javascript-based RIA which is an incredibly strong indication that industry-wide adoption of Flex has been dwarfed by in-browser Javascript RIAs likely because of the other arguments in this document. 

Javascript is one of the most common languages used today.  It's presence will probably always exist in the current code base (Javascript Links, form validation, etc), and there is a very low cost associated hiring new engineers to maintain current or future Javascript in our view layer.  Flex is disparate technology that will require special training for current and all future employees.

Open Implementation Of Javascript

Flash will only play back in a patent encumbered closed source virtual machine environment that exists on the majority but not entirety of all platform combinations.  Notable missing platforms include nearly all cellular phones and most operating system variants not running Intel architectures.    There are a few very incomplete open source implementations of the Flash player.  Flash 8 was never made available to Linux users, which left them unsupported for several years.

Several competing open
source Javascript engines exist, including the Mozilla Spidermonkey, KDE KJS, and Google Chrome V8
implementations.  Additionally, an open source JVM-based interpreter exists from
Mozilla known as Rhino which is integrated directly into Java 6.  Java 6 allows us to create Javascript unit tests directly within jUnit without the need for a browser, separate run-time environment, or even an additional jar file. 

Vendor Support Of Javascript

The flash player is completely controlled by Adobe, and no other outside vendor is capable of fully implementing a competing interpreter for it or extending its feature set should Adobe choose to discontinue its availability or remove functionality that we may have implemented.  This tight control over the market that can be manipulated on a fine grained device or operating system level which would allow Adobe to exert control over many different technology markets should Flex become a de-facto standard.

Currently, independent Javascript interpreters are being developed by many organizations including Microsoft, Apple, Mozilla, Google, KDE, and Opera.  Our development would continue to use frameworks that abstract the minor differences between these engines, and allow us to preserve functionality that may existed in different implementations from browser to browser (example: persist.js used in BigVisibleCruiseWeb).  The jQuery framework is open source, ships with Microsoft Visual Studio and has the support of the Ruby on Rails community and Google.

Performance Of Javascript

Javascript framework code is generally less than 100 kilobytes and packaged separately from our specific code which allows the download of framework code to be cached on the client.  Our specific code will generally be less than 20 uncompressed  kilobytes per page.  The web server will further compress Javascript code before sending it over the wire.

Most flex applications require several hundred pre-compressed kilobytes of uncacheable data to be downloaded for each component (and many components may exist on the page).  The web server will NOT compress Flash executables before sending them over the wire. 

Each flash executable runs as a separate browser process with a
separate virtual machine whereas javascript runs directly in the
browser as a part of the page's content.  For this reason, it is likely
that Flash will tend to run slower, although a direct comparison of
execution is impossible.

Coupling 10-100x (after compression) larger page loads with a separate
VM instance for each flash component, Flex-based interfaces are almost
assured to be noticeably slower to load and run than browser-based
Javascript interfaces.

Range of Interchangeable Javascript Frameworks

Flash-based applications may or may not be written in Flex.  But, once
flex is chosen, all of the shortcomings of flex are exposed.
Javascript frameworks can be mixed and matched in the same page, even
on the same elements to best support the features necessary for the
business.

Flex is not future-proof.  Should Flex be discontinued, all Flex applications would need to be completely re-written.  Should jQuery, Prototype, or any of the other Javascript frameworks be deprecated, we could slowly migrate to a competing framework, generally with very little effort.

Platform Features And Ease of Development

The Actionscript language is a full and complete Javascript language.  Therefore the features of the language vocabulary are nearly identical to those found in browser-based Javascript.  But, because Flash runs inside of a sandboxed plugin-based virtual machine, several use-cases are much more difficult to accomplish in Flash than browser-based Javascript.  These include:

• Video.  In HTML 5 a simple video file placed on a server and few lines of HTML with no Javascript are necessary to playback video - Javascript can be used to control the video.  Flash video requires a special authoring environment, hosting of a proprietary flash video file, hosting of a proprietary flash video player, and many more lines of HTML are necessary to bind the video player to the video file.  Integrating video into a flash interface is even more difficult requiring the use of a proprietary Actionscript library within the interface.
• User Experience.  Flash-based applications have a different user-interface from normal web pages.  Flex RIAs currently cannot blend properly into the rest of the operating system's user interface.  Javascript applications can take advantage of native HTML widgets which are drawn by the web browser directly and are usually native operating system widgets.
• Inter Applet Communication.  Communication between Flex applets requires proprietary and complicated serialization, and communication between Flex and the DOM of the web page itself is also needlessly complex.  Alternatively, in-browser Javascript controls the same DOM tree as all other Javascript processes and plain HTML that exist on the page.  One example is using the prototype extension features of Javascript to create RIA drawn using Javascript and then being altered at run-time when the user visits certain pages that override functionality.
  

Other Issues

• Form/Password managers are not supported for Flash.
• Browser shortcuts such as ctrl-tab are not supported in Flash.
• Screen Readers for the blind are poorly supported in Flash.
• Middle-click and mouse scrolling do not always work in Flash.
• Search engines poorly index Flash content (google is Good, Bing and Ask.com do not).