Specialist for Rich Internet Applications and UI-Design

Around two years ago, I wrote a little article about OpenLaszlo, a promising RIA framework, for richability.com in which I compared it to Adobe’s Flex platform.
Since a lot of time has passed and many things changed since then, I think it’s time for an updated sight on this technology.

Back in the days when I wrote that article, my main arguments were (summarized):

1. Flex can only target the Flash Player while Laszlo offers both, a Flash compiler as well as a DHTML version.
2. Flex is much more popular than OL (OpenLaszlo).
3. Costs for OL development are lower since Adobe’s Flash Builder (formerly known as “Flex Builder”) is quite expensive while OL does not require a dedicated IDE.

While arguments 1 and 2 still apply, I need to correct my statements about #3:

Both, Flex as well as OpenLaszlo, are frameworks, which include a compiler and a component library. While Flex utilizes a combination of MXML and ActionScript3, Laszlo requires LZX and JavaScript knowledge. There is no much difference regarding the basic concept between these two but the developer must be aware that it’s the compilers job to transform these languages into plain ActionScript3 code. The reason for this is that the Flash Player, which runs these applications, cannot understand MXML, LZX or JavaScript. The only language it can process is ActionScript, which is the reason why a compiler is required.
Now, regarding argument #3 from above, it must be said that actually no money is required in order to develop Flex or OpenLaszlo applications, since both compilers can be invoked from command-line, similar to the “javac” command in Java. In order to create the source code, a random editor of choice can be used. In my arcticle on richability.com, I must admit that it looked like if OpenLaszlo development was completely free of charge while Flex always requires money. This was not correct. It is possible to create both, Flex and Laszlo applications, without paying a single cent.

Now, regarding coding comfort, it must be said that a special IDE for Flex/OL development would be nice. This is actually where things change: While Adobe offers the so called “Flash Builder”, a pretty expensive (but in the same time awesome) Eclipse-based tool for creating Flex applications (which is also available as a plugin-version), the OpenLaszlo founders do not offer a comparable IDE. There is a free 3rd-party alternative available though called IDE4Laszlo.

To sum it up: Flex development does not have to be more expensive than Laszlo, but it probably will be since serious application developed cannot be done without a good IDE these days.

Flex benefits

As already mentioned, application logic in OpenLaszlo is being written using JavaScript, which is a waay inferior programming language compared to ActionScript3. I know, JS is object-oriented and all but it lacks some very important features, like:

• Static type-safety
  In ActionScript3, we have static types (except for arrays, but vectors are a good replacement), which means that a compiler can give warning/error messages regarding type incompatibilities before runtime. In JavaScript, this is not possible.
• Interfaces
  In huge projects, the concept of interfaces is often important. ActionScript3 supports these. JavaScript does not.

I really wished, OpenLaszlo would support a better programming language, like for example Java or C#.

Update: Thanks to P T Withington for the note below:

“OpenLaszlo as of version 4.2 (currently at 4.7) supports extensions to Javascript modelled on Actionscript3. You can create classes and declare interfaces and types just as in as3. When compiling to DHTML, the type declarations are not (currently) enforced, but they are if you compile to Flash.”

OpenLaszlo benefits

Some days ago, a guy called Femery Arnaud from France sent me an email asking why the Flash-compiled versions of Flex are so much bigger than the ones from OpenLaszlo. According to a test made by him, a sample project consisting of a DataGrid, a tree component and an image required 2.5MB on Flex and only 250KB in OL.
To be honest, I didn’t really have a quick and smart answer since I never had a closer look into file-size related issues between both technologies. My guess was that this has something to do with the efficiency of the framework-compilers as well as the complexity and size of the UI component libraries but I couldn’t say for sure.
However, it seems like OpenLaszlo applications require much less space then their Flex-pendants if they are compiled into Flash. This fact should not be disregarded since there are still many users out there with small bandwidth internet connections.

The rise of the underdog

Due to the hype about HTML5, recent debates around Flash have probably made some developers feel uncomfortable about their future and rised some questions like for example: “Will Flash still exists in 4 or more years and is there still going to be a demand on Flex developers as there is today or is it better to switch to HTML5/JavaScript development now?”

To be honest, I have similar thoughts going around my head and I don’t have a real answer to this, but there are some facts which we are already aware of today:

• HTML5 definitely has the capability to be a replacement for many use-cases which made Flash required on the web.
• HTML5 is still in its baby-shoes. Neither is its specification finished, nor are the implementations in today’s browsers perfect.
• There are still some users out there surfing the web with HTML5-incompatible browsers.
• Flash requires a plugin which implies the fact that some users, who do not have it installed, are being prevented to access Flash content.
• Many people do not like Flash due to instability reasons. I know, this is not a hard fact, but I hear this complaint pretty often.
• HTML5 has no support for binary sockets and web-cams.

Keeping these informations in mind, I wouldn’t say that Flash gets completely “killed” by HTML5 but I think it’s reasonable to say that it will probably reduce the demand of Flash (and their developers) in the future. It is just a matter of time.

Now, here comes the bridge to OpenLaszlo since its one huge advantage compared to Flex is its compiler feature of giving the developer the opportunity to choose between Flash and DHTML output. According to rumors, even Silverlight and SVG output is being planned.
So, what does this mean to the developers? – Actually quite simple. Learning OpenLaszlo gives one the ability to target different platforms with one code base. Your customer does not want Flash? Flip the DHTML switch and you’re done. This feature makes the requirement of learning multiple additional technologies like GWT or Silverlight redundant and could give Laszlo a big boost regarding popularity among RIA developers.

What most people miss-understand is: It’s not the Flash Player which is supposed to be “open” or not. It’s the Flash/SWF specification, which is open. The Player is not and no-one said that it is.

Think of it like this:

• HTML is based on an open specification made by the W3C. Browsers interpret HTML in order to provide web content.
• Flash is based on an open specification made by Adobe. Flash Players can interpret SWF in order to provide web content.

The fact that Adobe’s Flash Player is the most spread doesn’t make Flash a “bad” technology.
Some years ago, the Internet Explorer was the most dominant web browser on the web. It was buggy (and still is) and proprietary and all but did anybody blame HTML on that? I’m sure no-one did.
If people say now that the Flash Player should be open: Is every browser manufacturer in the world now supposed to open their browser source as well? – I don’t think so.
It’s the same with Flash. The format is open, the Player is not.
It’s not Adobe’s fault that there are no other competitors which offer versions of Flash Player that can compete with the original one by Adobe.

Flash is not contra-productive to an open web
Don’t get me wrong. I personally don’t like proprietary systems but I can understand companies that don’t want to open their software.
For an open web, this isn’t important though. What needs to be open is the format, not the player/browser which renders/interprets the content.

Just to make things clear

• I am not an Adobe-fanboy.
• I hate the Flash Player, but I love Adobe’s tools to create content of any type.
• I am not an Apple-hater. I own a Macbook myself and I love it.

I want as much control over my devices as possible. Thus, I own an Android phone.
No company in the world should be allowed to tell me what I should install on my phone and what not.
I can’t install Flash on an iPhone? – Won’t buy it. That simple.

• 
• 
• 
• More

Ok, hands down. Sooner or later, Flash will not be relevant to the WWW anymore. Flash videos will be replaced by <video> while animations will use <canvas> and <audio> in HTML5.

There are a few things Flash can do, but HTML5 cannot, like:

• Webcam support
• Binary sockets (not web-sockets!)

But these features will sooner or later be covered by HTML as well, so there is no need for Flash anymore on the web.

But what about the Desktop?

As I already stated, Flash could become the next-gen Java-replacement for Desktop applications.

The reason why I think so is simple:

• Flash/Flex applications are easier and faster to develop than Java (thanks to MXML). This improves workflow and thus reduces costs for software companies.
• There is already a wide range of developers that have experience with Flash development, so there is no new programming language/technology to learn for these people. They can start develop rich desktop applications right away.
• Flash-based desktop-applications simply provide a nicer user-interface and their look ‘n’ feel is “smoother” than Swing.
• The Photoshop/Illustrator-Catalyst-FlashBuilder workflow is great and definitely enhances work of designers and developers. There is nothing compared to that in classic software development.

So, what I want to basically say is:

HTML5/Ajax for Web and Flash/Flex/AIR for the Desktop!

That’s why I think that both are not competitors. Their future lies on two difference battlefields.

If your Flex/Flash Builder has suddenly problems connecting to your Flash debugger, you might be using Google Chrome.

It seems like Google started bundling the Flash Player together with Chrome, which has an automatic updating engine (in the background) and thus you probably didn’t notice the update.

Currently, there are two workarounds for this:

1. Manually replace the Chrome Flash player with the debugger version (Thanks to Josh for the how-to).
2. Use a different browser for testing your Flash applications in.

Workaround #1

Go to chrome://plugins and disable the following entry (on MS Windows):

$HOME/AppData/Local/Google/Chrome/Application/FLASH_VERSION/gcswf32.dll

On MacOS X, the path is:

/Applications/Google Chrome.app/Contents/Versions/FLASH_VERSION/Flash Player Plugin for Chrome.plugin

This will disable the integrated Flash Player bundled with Google Chrome. Watch out not to disable your operating system’s default Flash Player (debugger). You can see the difference in the installation path: The global Flash Player is not installed into a directory associated with Chrome.

workaround #2

In Flex/Flash Builder (or Eclipse), simply go to Preferences -> General -> Web Browser and hit “Use external Web Browser“. Then pick Safari, Firefox or whatever you prefer. This choice will then be your “development test browser”, while you can use Chrome for your daily surfing needs.

Update

In version 6.x beta of Google Chrome the option to explicitly dis-/enable certain (versions of) plugins was removed. Don’t ask me why. Instead, you may only dis-/enable all Flash versions at once.
Since the plugins-page on chrome://plugins shows the path to Chrome’s integrated Flash Player, it would be theoretically possible to remove the plugin manually on the file-system or simply create a link to the debug-version at least on Mac OS and Linux.

Note: This is not a posting about introducing Gordon. This article describes a concept of automatically porting the Flash Player to JavaScript in a generic way, based on the idea of Gordon and Adobe Alchemy.

You might know Gordon, an experimental attempt of implementing the Flash Player runtime environment, completely written in JavaScript (by Tobey Tailor).
Demos have already shown, that this is possible.

The idea itself is great: Create a Flash application as you’re used to and then compile it into a SWF file.
Then, embed it together with Gordon into your website like this:

<html>
	<head>
		<script type="text/javascript" src="/path/to/gordon.js"></script>
	</head>
	<body>
		<div id="your_stage">Replace me</div>
		<script type="text/javascript">
		var movie = new Gordon.Movie("/path/to/your.swf", {id: "your_stage", width: 480, height: 320});
		</script>
	</body>
</html>

The problem here is that I doubt that one person alone can completely re-implement the full Flash engine. This is somewhere close to impossible, since Gordon currently only supports SWF1, while the Flash Player was just released in version 10.1.
Even open-source projects like Gnash, a re-implementation of the Flash Player (written in C++), which already exists since several years, currently only support SWF7 and SWF8 partially.

Now, here comes my idea:

What, if it would be possible to automatically transform existing Flash Player implementations into JavaScript?

I know that this sounds crazy, but read the following first.

Ever heard of Alchemy? It’s a transformation tool, which converts C/C++ code into ActionScript and then build a Flash file from. Yes, you heard right. This is not an April joke. It’s real and it works. There have already been ports using the original (open) Quake2 source, transform it into ActionScript and then run the game inside Flash Player.

Now, since this is nothing new, here comes the big trick: Why not use the source code of Gnash, send it through Alchemy and achieve the ActionScript version of it.
Then, write a transformation tool, which converts ActionScript into JavaScript code. Since both languages share some syntax similarities, this should be possible (Especially if it is possible to transform C/C++ into ActionScript, which would sound even more crazy to me, if I’d hear it in the first place).
After this, the achieved JavaScript code must be cleared of anything that the Flash Player offers, but cannot be handled by JavaScript/HTML5, like for example web-cam support.
Finally, an interface must be written in order to output video and audio. Since HTML5 supports the new <canvas> and <audio> tags, this should be possible. Simply draw the content of the graphical buffer, generated by the Flash Player emulator, onto the canvas element and playback the sound using <audio>. Done.

This way, it would be possible to run (existing) Flash applications without having the Flash Player plugin installed.

I know, this still might sound crazy but it might be possible with enough man-power and the know-how. The only thing that might become a bigger problem is the file size. I wonder how big such a .js file, implementing the full(!) Flash Player, might become. Maybe it would then be necessary to package only required subsets of it.

So what do we get at the end? A JavaScript-version of the Flash Player which supports up to SWF8, thanks to Gnash.
If Adobe ever releases the Flash Player as open source, it would be easy to throw it into our C/C++-to-JavaScript transformator. Sounds great, or not?

Update: It just came to my mind that, if it’s possible to transform C/C++ into ActionScript, why shouldn’t be possible to directly cross-compile C/C++ into JavaScript?
As far as I know, Alchemy is based on LLVM, which should be able to handle this.