SecuritySoftware

Flash v. JavaScript: Is One Really Better Than The Other?

Posted on by vansmith

Introduction
A quick search of the forums will reveal a particular unabashed bias towards technologies that leverage anything but Adobe’s Flash. To a certain extent, this is justified but should non-Flash based solutions always be the right method of delivering content? To answer this question, I investigated the efficacy of both Flash and its most often articulated “competitor” JavaScript1 to see how well they work in different situations.

The Tests
Before outlining the tests used to explore each technology, it’s important to note that I do not seek to suggest that one solution is better than the other. In fact, I seek the opposite – I hope to demonstrate that neither is inherently better than the other. Like any good scientist however, I did not create tests to prove this point from the beginning. Instead, as will become clear, the tests happen to reveal what I feel is an obvious point.

The tests chosen include a security test, a memory test and a speed test. Each will be clarified as the article progresses.

Analysis/Results

Security
Admittedly, beginning a discussion around something that is not all that quantifiable seems to contradict my desire to provide objectively true facts. However, there is some evidence to highlight security issues around both. Let’s begin with Flash.

Flash, much like Java, is plagued by security holes. It has earned a reputation as being an unmitigated disaster from a security standpoint and for a good reason. In an article published earlier this month, it’s noted that Flash was responsible for 3 of the top 10 exploits of the third quarter in 2012 (as an aside, it’s worth noting that Apple appears on that list twice). This sad state is a reflection of a trend with a history. For example, Adobe was faced with critical security holes in March, June, August, October and November of this year. Sure, many of those were fixed but the existence of these holes in the first place speaks to an endemic problem with security in Flash. This pattern of security issues is only made worse by companies such as Microsoft who take their time rolling out Flash updates for their browsers (source). Corporations aren’t entirely to blame however. Individuals are notorious for running out of date plugins which subject them to possible security problems. This is why Google includes Flash (source) and why Safari is now blocking out of date plugins.

None of the aforementioned evidence is provided to suggest that Flash is inherently more of a problem than JavaScript. However, the problem with JavaScript is that security issues are browser dependent. Unlike Flash, which is a plugin that operates across browsers, JavaScript support is implemented by each browser independently of the competitors. Even in case where technologies are shared (as is the case with Safari and Chrome which both use the WebKit layout engine), JavaScript is implemented differently (Safari’s JavaScript engine is different from Chrome’s).

As noted in this article, JavaScript vulnerabilities can cripple a webpage. Compounding this problem is the notorious cross site scripting issues that have plagued JavaScript for ages. Combine these and you’ve got a potent source of problems. Problems don’t even have to be as complex as those issues. For example, this recent blog post notes that security flaws in JavaScript can be as simple as one line.

There is no winner or loser in this case (nor did I set out to declare one). The point here is simple: the widespread security issues known to plague Flash, while bad, are complemented by similar issues with JavaScript.

Memory
Measuring the memory proved to be quite tricky. The only browser that made this easy was Chrome since the tools to measure both Flash and JS memory usage are built in. Thus, I can only provide results for Chrome.

Flash/Flex JavaScript
Chrome 36.2 MB (beginning), 36.5 MB (end) 8.89 MB (peak)

This is perhaps not all that surprising – Flash has a reputation for being more memory intensive (albeit not all that bad in this example). However, don’t let the results fool you. JavaScript can use a lot of memory when a browser makes extensive use of it. This might explain why Google emphasizes JavaScript performance – many of its own tools make heavy use of JavaScript.

To highlight the problems with JavaScript memory usage, I provide the starkest example I can think of. Here are the before and after memory usage results when I make Safari run the SunSpider JavaScript benchmark:

Before After
Safari 124.3 MB 3250.58MB

No, that isn’t a typo. That’s a 2515.11% increase. On top of that, not only did the test take a long time but Safari was unable to release this memory afterwards.

Speed: The “Quick Count Test”
To analyze the speed of each respective solution, I wrote up a simple test for each: how long it takes for each to count to 10,000,000. I wrote the Flash version using the Flex framework which is, for all intents and purposes, Flash but for designing applications with buttons and text boxes (and other application UI elements). Since it compiles code to Flash SWF files and because I have a licence for Flash Builder, I used this. The JavaScript code is simply a function executed on the loading of the document’s body. I would have used something like jQuery to do this but I didn’t want to influence execution times by introducing an external library.

The following is the code used (for those interested)2. The first block is the Actionscript (Flash) code and the second block is the JavaScript code. The Actionscript code was measured using a timer and the JavaScript code was measured using each respective browser’s built-in inspection tool:

// Thanks to http://stackoverflow.com/questions/2088514/is-there-a-way-to-time-how-long-a-function-takes and http://stackoverflow.com/questions/7601743/how-to-measure-how-long-the-function-works
 
import flash.utils.getTimer;
 
protected function countNumbers():void
{
    for (var i:int = 0;i<=10000000;i++)
    {
        lblCount.text = "Count: " + new String(i);
    }
}
 
protected function startTest(event:MouseEvent):void
{
    var timeStarted:int = getTimer();
    var timeCompleted:int;
    countNumbers();
    timeCompleted = getTimer();
    lblTime.text = "Time: " + (timeCompleted-timeStarted) + "ms";
}

The JavaScript equivalent is the following:

function count()
{
    for (i=0;i<=10000000;i++)
    {
        document.getElementById("count").innerText = "Count: " + String(i);	
    }
}

The Flex project can be viewed here and the JavaScript one here.

Running those resulted in the following execution times:

Flash/Flex JavaScript
Safari 3.16s 11.54s
Chrome 3.87s 17.76s
Firefox 3.14s N/A*
Opera (Next build) 3.82s 57.12s

* Firefox didn’t seem to like the script and just hung.

A few notes on the results. First, it’s not all that surprising that the Flash example was relatively consistent across platforms. Each browser used the same version of the plugin (except for Chrome) and since much of the ‘number crunching’ was done by an external source (the plugin, not the browser), the consistency was expected. However, the fact that Safari/Firefox had similar times which were different than the Chrome/Opera times is a mystery to me. Second, the JavaScript values vary wildly and this was expected. Each browser does JavaScript differently and the ways in which they work through loops and optimize code will vary depending on the priorities of the developers. Finally, and the most salient point here, the Flash times were consistently lower than the JavaScript times. In some cases (Opera), it wasn’t even close. On the whole, the Flash application ran anywhere from 3.65 – 14.95 times faster than the JavaScript version.

Conclusion
Although this is just a few simple and small tests (or a discussion with regards to the security), it does highlight one thing that I think is important to note. While many of us will happily criticize Flash for being slow as we recommend JavaScript based solutions, many of us forget to acknowledge that there are better tools for particular jobs. In some cases, the lack of speed when it comes to certain functions actually suggests that JavaScript may be a slower solution. Add to this browser based issues (*cough* Safari *cough*) with respect to JavaScript and Flash may be a better tool.

Addendum
This comparison was based on the experience of each on a Mac. If you’re using an iOS device, much of this is of no consequence as Flash is unavailable for that platform.

Notes
1 In so many ways, “competitor” is the wrong word since that fails to recognize how each are tools that were designed with different principles and intentions in mind. However, I lack a better word for the sake of this article.
2 A note: I’m well aware that the code could probably be refactored to be more efficient. As a programmer who writes as a hobby, I lack the expertise to write efficient and consistent code across languages. However, I still feel that the code is close enough in function to be indicative of a general trend.