This page is from our blog archive
You may still find this page interesting, but there are more relevant and up-to-date blog posts available. Use search or filter options to find the latest content.
The original HTML specification had no entry for images, let alone interactive graphics. But in the mid nineties two techniques emerged. The first was Java applets. The second was Flash, or FutureSplash Animator as it was first called (we’ll save that story for another post).
Flash achieved greater success as a commercial technology, but was not used by academics interested in visualizing data. Despite the runtime being freely available & widely distributed, the programming environment cost money. And the language (ActionScript) didn’t achieve any sort of respectability until much later, when AS3 introduced classes and other paraphernalia expected by those schooled in class-based statically typed languages.
On the other hand, Java was widely adopted for visualization work – and Java applets continue even now to be the academic visualizer’s tool of choice. The main reason for Java’s popularity was because it was – and still is – one of the main languages used for teaching computer science at universities.
The visualization capabilities the environments are very similar. The difference is not what each platform can do but the ecosystem in which they run.
The user experience of Flash and Java is very different. The main annoyance with Java is lengthy delays while the runtime loads. The runtime never got built natively into browsers. Flash has always had a much smoother experience thanks to commercial distribution arrangements & better design choices.
The security models of both Java and Flash have been an issue over the years. Arguably, Java’s is much worse. Once permission is granted by a generally trusting & unsuspecting user, a (signed) Java applet is free to do pretty much anything it wants on the user’s machine. In Flash’s case, the problems come through security loopholes exposed accidentally – breaking the normally tight security sandbox governed by the flash runtime.
Flash became the runtime of choice for commercial visualization software due to its ubiquity & strong capabilities. Flex helped, by providing well-designed application building blocks. The Flash/Flex combination was very successful in commercial projects requiring visualization, particularly for dashboards and business intelligence applications.
Some commercial organizations used Java too. Fresh graduates out of college knew Java and provided a willing (and cheap) talent pool to draw on. The tools evolved from applets to use techniques like Java Web Start. Companies could then claim their app was web-deployed but really this technique just used the web to download an application and run it like any other native app.
So – enter the newcomer – Silverlight. As usual Microsoft entered late into the fray.
Previous to Silverlight, Microsoft’s line on graphics work was to use ActiveX, which was tricky to develop with, offered no cross-browser compatibility & was another security nightmare.
Silverlight appealed to Microsoft fans, and after version 4 they had every reason to say that it was at least a match for the Flex/Flash combination. They loved writing C# code and see it running in the web browser, even if it meant having to learn the new XAML mark-up language. Silverlight, like Flex/Flash, hit a sweet spot for commercial projects, particularly for folks who love the Microsoft tooling. Outside of that environment though – in the open web – nobody ever cared about Silverlight, and very few visualization projects were ever made in it.
Sadly it comes down to commercial drivers. Flash’s strength – commercial support – ultimately ended up as being its key weakness. Without commercial support from the leading vendor of the day, Apple, it became vulnerable & lacked the loyalty of developers that otherwise could sustain it into the future.
To some extent the same can be said of Silverlight – it may have stronger developer loyalty but has a far weaker distribution.
And Java, with the Oracle acquisition of Sun, is at risk of losing the support of the academic community which provides the new emerging developers who could otherwise maintain its ecosystem.
The future of all of these add-on browser runtimes? They are all doomed. The modern browser has new capabilities which make them utterly redundant. We’ll be talking about these in future posts.