One of the fun aspects of life here at Cognethos is the number of different languages and environments you can find yourself working in. I’ve had projects in C++, C#, Java, HTML+Javascript, JSP, ASP.NET. Sometimes it feels like each month it is a new language and a new IDE.

Lately, I’ve been working on Craig’s port of the chart to Flash and ActionScript. This has given me a chance to compare the various approaches we’ve taken to making web content update dynamically.

In the products I’ve worked on I’ve seen four approaches so far:

• ‘pure’ javascript
• ActionScript
• Java applets
• Java driving Javascript

‘Pure’ JavaScript

The ‘pure’ javascript approach refers to using AJAX and Comet style javascript to update the pages DOM. I’ve put the inverted commas around pure because, as anyone who tried to do cross browser javascript knows all too well, javascript is rarely pure.

This approach is hampered by needing to code around browser quirks but also by the ‘hand-built’ nature of doing large amounts of programming in javascript. There is no compile-time. You only know you have a bug or a typo in your code if you happen to manage to get your code to pass through that particular path of execution and the bug occurs in a nice enough fashion for you to notice it easily. A simple typo in a variable name can have far reaching consequences. Since javascript variables don’t need to be declared the misspelt variable will have an undefined value. If you’re lucky the bug will manifest itself in the next line or two. If you’re not so lucky it will get passed into another function and show up as a bug somewhere far from the original error. I find that with programming in javascript it is a good idea not to write too much code at once. You write a bit, you test a bit, you write a bit again. If you go off and spend half and hour writing a long screed of script and then come back and expect it to work flawlessly first go you’re going to be in for a very rude shock.

But the advantages of the approach are that it is light-weight and very portable. There are no plug-ins, just a few .html and .js files. Updating the DOM is easy. I find this approach is the best for updating text and tables, but it falls down when it come to charts and graphics. The javascript approaches for graphics aren’t standardised enough (SVG vs VML), and although some people have done great work on producing libraries to cover over the incompatibilities, when it comes to the requirements we meet for financial charting the pure javascript approach doesn’t measure up.

ActionScript

Enter ActionScript. ActionScript is like a typed Javascript. It has a compiler, so the fear of lurking bugs from typos is eliminated.

Since it is the language behind Flash player the graphics capabilities are as good as you’d expect. Have a look at the Cognethos demos for our implementation of a Flash chart.

The ActionScript language has types and the compiler will do type checking on assignments and parameter passing. This makes the code a lot neater.

The code gets compiled down into a Shockwave (swf) file. It seems to be optimised for size to make the download to the client quicker.

However, since we use javascript for our lightweight streaming data we need to be able to push data from javascript into Flash. Adobe provide a bridge that enables that.

Also since this is Flash, we need the Flash plugin, a swf file and an <object> or <embed> tag in our html. From javascript, you cannot begin to access the objects in the swf file until it has finished loading.

All in all, ActiveScript is a good environment for what we want to do. The Flex IDE is an eclipse clone, and it is (in my opinion) a bit clunky, but it is bearable.

Java applets

Which brings me to the next alternative. Why not just use a Java applet? The technology is very similar. You need to compile your java into a jar file, and use an <object> or <embed> tag to load it into your html. The jar file replaces the swf file, and both technologys use the same html tags.

Java is a much more mature language, and the development tools are better too. I use Netbeans for my java work, and find it a lot easier to work with than Eclipse.

The drawback for using Java are the graphics APIs. Java is a much more general language, and you need to do a lot more work when coding the animation, transparency and other effects.

Java is also a much more memory hungry beast. Again, I think because it has been around longer, and is now expected to do more things, the ‘bundle’ or core code that is running when you start your applet is larger than for Flash.

Another downside to both Flash and Java is the VM stability. Both plugins have been around for a while, and you would have thought the bugs would have been ironed out, but you still get things breaking from time to time when the vendor does a new release. We’ve had this happen to us a number of times, and the end result is that you have to do an emergency fix because 1.5.0_07 broke this or version 9 broke that. I’ll write another post on that one shortly.

Java driving Javascript

This is another good technique for doing dynamic updates ito HTML. The trick is to have a ‘hidden’ or 1 pixel x 1 pixel applet that handles the connection back to the host and drives the updates through to the HTML DOM.

This can be good for implementing sophisticated retry or timeout mechanisms. Its a lot easier to write reconnect logic in Java, where you can have a dedicated thread that can loop and retry, than it is in Javascript where everything has to be in a callback, or a timer or in the UI thread. It is also good for multiplexing many updates to the page to a single update from the data feed.

Conclusions

I like to use ‘Pure’ javascript as a first try. If that is good enough for what you want to do, why go further? If the application requires ‘pretty’ graphics go with Flash. If the application requires sophisticated networking go with Java and Javascript.