Flash RIAs vs. Javascript RIAs

Javascript RIAs (aka AJAX) don’t come close to the interactivity that developers can implement using technologies like Flash or Java. For example, there is no easy way of integrating with audio and video content, there is no ready-made toolkit of application widgets (tree-views, data-grids, etc). There are undeniable advanatages to the JavaScript RIA approach, however. So how do you decide whether a Javascript RIA (or “AJAX”, if you must) or a Flash RIA is right for the project you’re working on?


Download Size
Clearly DHTML pages will end up being smaller (on average) than Flash SWF files or Java applets (assuming a rich approach that doesn’t repeatedly download the html). If your client may be using a slow internet connection, a JavaScript RIA will have advantages. Similarly, if you’re application is going to be deployed on a very popular site (like google!), reducing downloads will also save you a lot of money on bandwidth.

Politics and Such

XMLHttpRequest is an API that belongs to Microsoft and is not part of the JavaScript standard. Given that Microsoft is NOT interested in open web-based standards becoming more powerful, there is a risk that the next version of IE will break XMLHttpRequest in a subtle or perhaps, not-so-subtle way. They wouldn’t even be guilty of violating a real standard if they did this, just a de-facto standard. And you can bet they would love to break all that cool code that google just finished writing!
Of course, if you do Flash or Java development, you are at the mercy of Macromedia or Sun, and the changes they make to their browser plugins. So which company you trust to “do the right thing” becomes a relevant question. In general, Java and Flash JVMs have been backwards-compatible, and Microsoft has an established history of keeping standards in constant flux to cripple their competition (a tactic that Joel Spolsky aptly calls “cover fire”). Draw your own conclusions.
Staffing
It is definitely easier to hire “vanilla web developers” than people who can do real engineering using Flash. Drew McLellan writes
“It’s hard to find good people who are also prepared to work with tools like Flash. I’m sure they exist, but finding someone who’s a good Flash developer and is also geographically close and available for work is hard.”
I’ve despaired at hiring good Flash engineers, and resorted to hiring Java Developers and retraining them. This approach works if you can keep your Java Developers involved and invested in Flash. But you just don’t face these kinds of staffing issues with JavaScript: there will always be web developers.
Integration with multimedia
One of the big advantages of Flash is that it natively supports streaming audio and video, something that obviously isn’t a part of DHTML. If you’re working with multimedia, Flash is definitely the RIA platform to build your application on.
Availability of UI toolkits
Flash and Java come with UI toolkits for such things as tree views and data grids. These components are absent in the Javascript world (although enterprising companies are moving in to fill the gaps: look for some introductions to the newer players in this space shortly on my blog). If that’s important to you, that either Flash or Java are a much better option comparted to developing a JavaScript RIA.

Maintainable Code

Javascript development in general requires writing code that runs on different browsers and “degrades gracefully”. For example, there is a reasonable chance the XMLHttpRequest object won’t be present in a given browser: your code has to handle this. As jibbering writes:
“Even in IE the XMLHttpRequest object can often be blocked by slightly raised security settings (popular due to the commonly exploited holes of course)”
Writing this kind of code (in order to work on all browsers and degrade gracefully, everything is implemented two or three times) is annoying. Maintaining this kind of code is a real nightmare. When you depend on a plugin like Flash, compatibility problems are all but eliminated: as long as your client has the right plugin, your code should work.
On the other hand, writing maintainable Flash code is no picnic either. Actionscript (unlike JavaScript) is an object-oriented language, so there is the potential for extremely elegant and maintainable code. But unless you abandon the Flash IDE entirely (and good luck finding a Flash designer who can work without it) you will end up with a big binary FLA file that is hard for maintenance programmers to deconstruct and understand (see Flash Better Practices for the gory details). Here I’m going to give Flash the advantage, but it’s not a knockout blow: it’s more of a judgement call.
Conclusion
I hope this article provides a beginning framework for deciding whether to implement your next RIA in JavaScript or Flash. The two technologies have very different profiles, and in many ways compliment each other, so both are likely to be quite important to web developers for the conceivable future. so there should be room for both approaches: no need to be a technology bigot! A nice debate on the topic is currently perolating in the Flash forums, and the discussion continues on Slashdot and elsewhere. As always, the space below is for feedback and discussion.
Update (3/10/2005): more links for ya!

16 thoughts on “Flash RIAs vs. Javascript RIAs

  1. John Dowdell March 3, 2005 / 9:10 am

    Thanks for continuing this conversation, and particularly this attempt at setting out a series of metrics for comparing two technologies for a job. I’m still waiting for the morning coffee to do its work and want to print this page out for closer study. One thing caught my eye at this stage, though:
    “Clearly DHTML pages will end up being smaller (on average) than Flash SWF files or Java applets” I would have assumed the opposite (single instructions vs multiple branches, binary vs text). What evidence were you considering…?
    (For total download time, the sheer number of HTTP requests is also signficiant. I don’t think we’ve seen “SWF vs DHTML” stats because it has been a non-issue for so many years, and these “AJAX” projects seem to avoid discussing production or distribution costs.)
    tx, jd/mm

  2. jon March 3, 2005 / 10:13 am

    Hey John!
    My evidence for flash download size being bigger is as follows:
    I’ve never seen a “preloader” for a dhtml page.
    I’ve never seen a thriving market for expensive dhtml compression tools, the way that there is a market for swf compression tools.
    http://www.eltima.com/products/flashoptimizer/
    http://www.swishsoft.com/optimizer_new.htm
    The RIA I’m working on right now has a swf download of half a meg. I’ve never seen an html page that big.
    Theoretically, a binary format should reduce bloat (and boy, html has a lot of redundancies: even a custom text format would cut out a lot of fat). Why this doesn’t seem to happen in practice is a bit mysterious to me.
    re: httprequests: JavaScript and Flash RIAs would both request data asynchonously when the client-side engine requested it, so I don’t see how the number of httprequests would be very different in the two cases.

  3. Fraser Campbell March 3, 2005 / 10:34 am

    Whilst Flash does an amazing compression job with internal images, once a dynamic Flash piece picks up external .jpgs any real advantage is lost.
    Also, components in a Flash piece instantly increase fileize, from 25k+, dependent upon the type and number of components. Whilst this is becoming less of an issue with increased download speeds it is still a factor when choosing the technologies to use in a RIA.

  4. Jed Wood March 3, 2005 / 11:03 am

    re: re: httprequests: I think it matters because the majority of Flash files you see that are bloated are ones that have all the data (heck, maybe an entire site) built right into them. In cases where they both make the same number of requests, file sizes are likely smaller, in which case that argument changes.
    Can anyone speak on the size difference in a standar “AJAX” request (especially one with lots of XML) versus remoting? Joey Lott and others have pointed out that the binary Remoting data transfers can be significantly smaller. Just curious as to the real numbers here.

  5. jon March 3, 2005 / 12:22 pm

    Jed,
    Thanks for stopping by.
    Agreed, often you’re doing a big download in the beginning to avoid downloads later. This is dumb, especially if resources can be downloaded in the background.
    Flash in general DOES often tend to be a big download (subjectively: I have no data on this). Maybe it’s because swf is a vector graphics format: there tends to be much more geometry in your average swf than in a dhtml app (which really only has rectangles to play with)? I’m not sure.
    Fraser, excellent point on components. I think that’s another component (sorry for the pun) of the “big download” problem.

  6. ben March 3, 2005 / 1:08 pm

    Actually…
    Last I checked JavaScript had fairly robust object support. Either that, or constructors and the protoype property are just figments of my imagination.
    Going point-by-point:
    Download time: depends on what you’re trying to do. The advantage goes to Flash for animation or video, of course. Outside of those realms – even for image-intensive apps like Google Maps – I would say that JavaScript’s lower barriers to entry give it the advantage; it will take less training for a web developer to optimize something in JavaScript/”Ajax” as well as could be done in Flash.
    Politics/survivability: XMLHttpRequest is indeed at Microsoft’s mercy, and its status as an ActiveX widget complicates things even further. But you have the iframe approach, which I first used almost five years ago (for an internal project management app, sans XML), which is much less likely to be broken by any moves that Microsoft makes. I dunno why, but it’s always mentioned as an afterthought, I’m guessing because of developer biases (frames are evil, XML is sexy).
    [For these same reason I PREFER the iframe approach to “Ajax” implementation.]
    Staffing: what you said.
    X-media integration: This is a nightmare non pareil without Flash.
    Tool availability: Tools? JavaScript? If such things exist elsewhere, I want a ticket to that elsewhere. ..
    Maintainability: reusable DOM code requires crazy skillz to write, and even then is rarely lightweight. But if I’m willing to tailor my code to the architecture of a single site or app, things get a lot easier because I can rely on native methods (especially getElementById). The whole x-platform issue is unavoidable, though. If sponsor expectations of platform support verge on the unreasonable, then Flash is (perhaps unfortunately) the winner.
    In short: the more interactivity you’ve got, the better off you are using Flash. If, however, your application is focused on data easily expressed as XML, then “Ajax” looks steadily more attractive.
    jon b: compression makes bloated markup less painful. application/x-gzip-compressed, anyone?
    John D: “distribution” costs? Ambiguous. As for production costs, man hours are managed just as well or as badly as sponsor expectations.

  7. Adedeji Olowe March 3, 2005 / 9:35 pm

    Is anyone talking about time to market?
    Given a particular RIA project, the Flash guys must have finished and gone home before the AJAX guys gets to the middle.
    And writing different codes (the types that degrade gracefully) is no fun. The advantage Flash has is that it has a platform that is same across all OS. As long as you keep away from fancy OS dependent client objects, you dont care whether target client is Win, linux, Mac ét al.
    And for code protection, Flash is nicer. You dont want your competitor to easily rip your code apart (AJAX) and come up with something better. Not that ActionScript are that safe (I know software that could rip that apart too) but it is not rampant.

  8. jon March 4, 2005 / 11:24 am

    Great point-by-point ben! Really like your point about the iframe approach. Can you post some links with good tutorials on it (or write one if there aren’t any ;->). I learned that frames were evil and never looked back. It certainly sounds like a hack (i.e. it’s obviously not what frames were intended for), and that may be why devs stay away from it.
    Adedeji, the problem is that we’re lacking hard evidence about time to market. Probably because the Flash people and the AJAX people don’t talk, which is why I wrote this posting. It certainly seems to me that writing a real application (talking to database, using datagrid and treeview in non-trivial ways) in Flash takes a lot longer than it should (maybe it’s just me).
    re: Code Protection: the same companies that are in the flash compression business have flash decompilers that can show anyone your code.
    http://www.eltima.com/products/flashdecompiler/
    If anyone knows a good FLA / Actionscript obfusticator I’m actually looking for one right now.
    administrivia: I’ve opened up this thread so that people can post without me being a gatekeeper. Hopefully we won’t get too much comment spam.

  9. Steve Yen March 5, 2005 / 12:47 am

    re: Code Protection, yes, JS RIA AJAX forces you to be open source. Google Maps/Suggest/Gmail workings were deconstructed and described in like 2 internet days.
    But, from a technology platform adoption standpoint, that’s actually a feature. HTML took over the world because it enabled everyone to learn, rip, mix and tweak from everbody else’s interesting web tricks. “How did they do that?” Just View Source for free for the answer.
    View Source means JS RIA victory is inevitable even though it technically lags compared to Flash.
    http://www.shirky.com/writings/evolve.html

  10. ben March 5, 2005 / 8:11 am

    Great point-by-point ben! Really like your point about the iframe approach. Can you post some links with good tutorials on it (or write one if there aren’t any ;->). I learned that frames were evil and never looked back. It certainly sounds like a hack (i.e. it’s obviously not what frames were intended for), and that may be why devs stay away from it.
    Tutorials? They ain’t no steenkin’ tutorials. There is in general a need for accessible documentation on closures, DOM scripting, and Ajax, and I’ve been wanting for the past six weeks to devote some serious time to the task, but don’t know to whom to pitch the copy. ALA’s already covered it as much as they’re likely to, SitePoint’s and ORA’s editorial policies are at odds with my style (‘sides which I’ve no contacts at ORA), and while I’ve got carte blanche at WaSP I would be constrained by the need to do everything in a compliant context – atop the fact that we’re in the early stages of a redesign, so I don’t want to get my ambition on there ’til the redesign’s done. I could approach Lockergnome, but their audience isn’t the one that really needs it IMO. (If you have any ideas, e-mail me.)
    If we think of iframes and framesets as a way of opening up separate documents in the same viewport, no more no less, then yes, applying them to Ajax is a hack… but x-frame scripting has had arguably excellent support since the 3.x browsers shipped. (One of my earliest scripts imitated layer swaps by abusing document.write() in a sibling frame.) That level of support implies rather strongly an early consensus that this technology ought to be available.
    Abedeji: maybe yes, maybe no on time-to-market. Each API has strengths and weaknesses. Further, if leveraging Flash’s rich media strengths becomes a required objective in a Flash RIA project, Flash has just lost most of its time-to-market advantage hands-down.
    And, uh, source protection? MWAHAHAHA!!! These are all just ideas, people. Given enough resolve, they can and will be reverse engineered.

  11. Derek March 8, 2005 / 1:09 pm

    the main difference I see between the different approaches is this:
    flash is a vitual machine and fails to achieve perfect emulation of operating system level widgets while
    the browser is able to use the native forms and text rendering of the operating system. While it may seem like a small issue the “feel” of flash applications is somewhat lacking

  12. Jacques Surveyer March 9, 2005 / 7:00 pm

    Three quick comments:
    First ActionScript is converging on JavaScript 2.0 compliance – so the two have roughly comparable object development capabilities – assuming ECMA finally gets JavaScript to 2.0 status. Admittedly ActionScript has many more prebuilt objects. But watchout on XML – E4X recommended ECMA standard extension from BEA is a real boon, but slow being adopted by major JavaScript players like MS, Adobe, Macromedia, etc.
    Second, there are some great JavaScript UI toolmakers out there right now:
    Dynamic Drive – calendars, tabs, menus
    dynarch.com – very good open source calendar
    softcomplex.com – treeview, menu, scroller, tabs, etc
    navsoft.com – menus, scrollers, etc
    activewidgets.com – data grid
    codethat.com – grid, table, sidebar, treeview, etc
    Check out http://www.theopensourcery.com/ostutor.htm for
    the pick of the JavaScript UI litter and
    hotscripts.com for 1600 free JavaScripts.
    Third:, regarding security of code there are some useful JavaScript obfuscators but Flash allows for code encryption.

  13. jon March 9, 2005 / 7:11 pm

    Jacques,
    1)Standards don’t matter unless they’re implemented by the browser vendors. Just sayin’.
    2)Thanks for the heads-up on the JavaScript UI toolkits.Seperating the signal from the noise is one of the hardest tasks when shopping APIs: you’ve probably saved dozens of people hours of work just by posting that list.
    3)I had no idea you could encrypt your actionscript code. How?

  14. jon March 13, 2005 / 2:48 pm

    AJAX: promise or hype is a nice meta-blog posting that sythesizes a lot of the current debate. The author doesn’t know what RIAs are (or what Ruby on Rails is, for that that matter), but it’s not a bad summary and provides some excellent links…

  15. Sean Corfield March 23, 2005 / 10:48 am

    I was just looking at a JavaScript library that provide AJAX-style functionality as well as rich widgets etc – the sort of things you’d need to ‘compete’ with Flash and it’s just under 370Kb. I think I read somewhere that Google Maps is a 300Kb download (or maybe that was Gmail?). Given that, I’m not sure that you can assert “Clearly DHTML pages will end up being smaller (on average) than Flash SWF files”.
    There are certainly a large number of factors involved in these sorts of decisions tho’ and I think that overall it’s very healthy to see a broader debate about the great experiences that Rich Internet Applications can offer.

  16. jon March 23, 2005 / 11:00 am

    Good point Sean,
    There’s a little bit of a mismatch in this debate about file size. Comparing applications of equivalent functionality / interactivity is the only was to get a true read on whether initial file sizes are smaller in javascript.
    Does anyone know how the Laszlo (flash-based) email client compares to gmail’s/oddposts download size? That would seem the clearest one-to-one comparison in this space.

Comments are closed.