Flash: what is it good for?

Flash gets a bad rep among programmers. The programming model is very different from typical programming languages, and the uses of the technology have typically been annoying (banner adds, skip-intro splash pages). More recently, AJAX has emerged as an extremely popular way of introducing dynamic behavior into web pages. So why do we even need Flash?


I just finished a HUGE Flash application (MindCanvas) that started out as an AJAX prototype, was developed in Flash, and then had part of the application converted back to AJAX. Whew! At this point, I feel like I can write with some authority on when to use Flash, and when to avoid using it. Flash has specific limitations, but so does AJAX, and it’s important above all to use the right tool for the job.
Capabilities that require Flash
*Audio – As far as I know, no one has figured out a way to make an AJAX application play audio files. This can be important for the little details of an application. It can also be important if you’re making an immersive experience of some kind, as we were. We NEEDED sound.

*Complex animation with arbitrary shapes (i.e. not just rectangles).
You’ll know if you need this or not. MindCanvas is a video-game like survey application, and we definitely needed vector graphics to make it come alive.
*Sockets (“pushing” data from the server. Required for multiplayer games, stock-trading applications, etc). We had no need for this in our initial release, but we have a lot of ideas as to how to use MindCanvas to perform multi-player research exercises. We’d use flash communications server to do this in the flash world. There is no equivalent in the DHTML world.

*Integration with client microphone / webcam.
We didn’t really need this at present (though it’s nice to know it’s there for the future). But many collaboration applications or consumer media sites will absolutely need this in the next few years.
Capabilities that Flash lacks
* Rapid development: if your code needs to change quickly, or if it needs to be ready in a few weeks, Flash is a poor choice. In our case, the management UI for MindCanvas was originally built in Flash. When we had to change it to meet an early customer’s requirements, we realized that Flash really isn’t what you should be using to do rapid application modification. We ended up reimplementing the management UI as a conventional web application, with bits of AJAX folded in after the fact. I’m extremely glad we did, as we’ve had to do extensive customization to this code as our business model evolved, and making the changes to a Flash application would have taken an unacceptable amount of time. (NOTE: It is possible that FLEX is a faster environment for rapid prototyping. But frankly, I doubt it could be as fast as vanilla web application development, which is such a well-understood problem now that it is extremely easy).
* Excellent handling of text. Something you take for granted on the web is that you will be able to display text of varying sizes in a way that is readable for the user. But font sizes that were easily “big enough” to be legible in html were fuzzy and hard-to-read in Flash. We bought several fonts from third-party vendors : these helped, but didn’t completely solve the problem.
It’s not just the rendering, either. Often it’s nice to be able to copy text from an interface you’re using (for example, to tell a developer that a particular label needs to be reworded). This is impossible if the text is part of a flash file. Even copying text from text areas has problems! (notably in Firefox with Windows XP and Flash 7). Flash is vector graphics at heart, and if your application exists primarily to let users read, produce, and manipulate text, Flash is probably not the best choice.
It you look at these abilities and limitations, you see that Flash is excellently positioned as the Web becomes more of a mainstream, visual medium. As the web matures as a platform, it will become a as much about voice communication, visual communication, and virtual collaboration as about reading and writing text. While it’s not the best tool to use for a classic “Web 2.0” applications (that mostly deal with sharing text and links asynchronously), it’s definitely the best thing going for “Web 3.0” applications that are about real-time, synchronous communication. If I was building the “Flickr of video”, for example, there’s no question what I would use flash heavily.
Update: This article has been translated to italian! Cool!

11 thoughts on “Flash: what is it good for?

  1. JesterXL November 15, 2005 / 9:39 am

    Dude, thank you so much for sharing your experiences. I’m extremely confused in why someone would want to use AJAX & Flash together vs. usign them both from a developement (not design) perspective, so these kind of articles are great! Additionally, sharing your experiences is really cool to read as well, thanks a ton!
    I’ve got some counter points, mainly on alternative sockets, a different perspective on RAD, and text handling. Trivial stuff, though, you rock!
    http://www.jessewarden.com/archives/2005/11/jonathan_boutel.html

  2. Paul Colton November 15, 2005 / 9:48 am

    Jon,
    You may want to check out http://www.aflax.org , I’ve expose most of the capabilities you mentioned in your article in JavaScript. Check out the demos on the site, which include audio, video, drawing, and socket ‘push’.
    -Paul Colton

  3. Crucial November 15, 2005 / 10:37 am

    Nice article! I would note one small exception to your bullet point about Rapid development. I think that would completely depend on the skillset of the shop/developer doing the work. A Flash/Flex developer working in that environment daily might find the opposite to hold true, they may be able to develop/change/adapt much faster using Flash/Flex v.s. DHTML. But I also think that goes to your comment “above all to use the right tool for the job” and would build on that to say “above all to use the right tool for the job and skillset of your team“.
    All in all though, great article…printing it out now 🙂

  4. rashmi November 15, 2005 / 9:23 pm

    Browser compatibility was an issue we considered as well. You might want to add that to the list of Flash pros that we took into account.

  5. amit ranjan November 16, 2005 / 12:44 am

    Th kind of Flash animations you see on the web would make you believe that Flash must be excellent for animated transitions, which are used very fequently in RIA applications ( with its emphasis of single page interactivity throught the use of accordians, sliders, drop menus etc ).
    But while working on MindCanvas, we realized that while these transitons look good in small sized swfs (say, 200X150) , they start looking way too ugly on larger sized swfs (say, 800X600). The animations are jerky and look totally unprofessional. We tried for weeks to tame those but in the end simply gave up and discarded those animated transitions from our application.
    Maybe the problem was not with Flash but in our expectation of its abilities.

  6. kMonsees November 16, 2005 / 12:39 pm

    You actually can change labels very quickly in flash, it just depends on how you developed the app/site. If you made all of the labels dynamic text fields, then it would be only a matter of updating text. But, if it was a really complex graphic, then, really, that is no different than the pain of editing an image in photoshop/image ready.

  7. firehttp November 17, 2005 / 7:21 pm

    The best tool for the job… indeed. It’s important to think about what you’re trying to accomplish and not just what tool is at your disposal. Good article.

  8. David Temkin November 19, 2005 / 10:00 am

    Jonathan — excellent and helpful article. As far as Flash authoring goes I completely agree.
    But it’s worh distinguising between development platform or tool capabilities/limitations (Flash MX, etc) versus runtime capabilities/limitations (Flash Player). This article mixes the two categories; in fact, Flash is really two separable pieces: the authoring tool, and the Flash Player (browser plug-in). The points that you make that are specific to the authoring experience (in particular, rapid development/modification) don’t necessarily apply to OpenLaszlo, which while producing SWFs, completely sidesteps Flash authoring and ActionScript concepts such as movieclips, etc.
    One consistent piece of feedback we get about OpenLaszlo development is about how rapid (and malleable) it can be, even relative to conventional Web development. But this has very little to do with the characteristics of the Flash runtime, and absolutely nothing to do with Flash MX as a development tool.
    Down the road, I think we’re going to see a lot more separation of development platform and runtime, in the Java, .NET and now Flash worlds. You can write Python code and run it in the Java VM; many such possibilities are open to .NET where the most common development language is C#, but many others are possible, all compiled to run in the same execution environment. With Flash 8.5 and its higher-performing VM, it’s possible that we’ll see the ability to create Flash content in languages that have nothing to do with Flash as currently conceived.
    David Temkin
    Laszlo Systems

  9. Jon Boutelle November 19, 2005 / 12:12 pm

    David,
    You’re echoing the conversation happening on the ajax_and_ria yahoo group! Here’s what I wrote (riffing on the same topic with David Medels from MACR):
    I agree that this conversation ends up having “apples to oranges” problems.
    There are at least two dimensions to the decision:
    1)The underlying capabilities of the client-side enabling technology. In the case of Flash, this is whatever version of the Flash plugin is
    currently at 50%+ adoption. In the case of AJAX, this is the DOM, and javascript objects, and html rendering capabilities supported by the major browser vendors.
    2)The engineering framework used to build software that uses this client-side technology. In the case of Flash, this is FLEX 2 and the
    latest version of the Flash IDE. In the case of AJAX this is the unruly but rapidly improving open-source frameworks (RICO, DOJO, MOCHI, et al), and the more mature but proprietary commercial frameworks (hi Jep!).
    As application developers, we live in the world of (2). We install the IDEs and learn the APIs, and improvements in these make our lives
    dramatically easier over time. But (1) is where the longer-lasting constraints are. (2) gets rapidly better over time, while (1) has a potentially greater impact on the core nature of the application.
    For example, FLEX 2 may (hypothetically) bring rapid application development nirvana. But if the Flash plugin is a weak way to display or work with text, FLEX 2 won’t change that. If browsers don’t provide a javascript API that gives native access to client microphones and webcams, that’s also unlikely to change in the next several years.
    I’m more interested in (1) than (2), because I think it forms the basis for decisions that will hold up over time.

Comments are closed.