Hard-Core Actionscript

21 packages, 188 classes, 20,000 lines of code
Automatic unit testing , Automatic daily builds,
Does this sound like a Flash program to you? Because it is.

When we started building MindCanvas, we looked around for what the best practices were for developing rich web-based software. We didn’t find anyone else doing it, so we rolled our own best practices for Flash development together (see this article from last year). We refer to it internally as “java-style” flash development. It is shamelessly copied from the best practices in “traditional” (web-based / client-server) software development.
Besides copying standard practices from traditional software development, we also avoid doing anything that would seem weird to a Java developer. That means we never use the “timeline” that Flash designers love to use so much, and that we don’t have any layers in our initial Flash file. The only thing we use the Flash authoring tool for is
1)developing graphic elements (here the vector graphics capabilities of Flash are a major win)
2)compiling Actionscript.
Avoiding Flash-specific programming methods keeps our programming model as similar to “regular” programming as possible.
Doing “java-style” flash development, with an emphasis on inheritance, design patterns, package structures, and maintainable code, is really quite similar to developing in Java or any other object-oriented language. The benefits include highly maintainable software that new employees can easily learn their way around. The disadvantages include increased development time for the initial release, a temptation to geek out on design patterns instead of doing real work, and a risk of creating an over-architected, static system that is hard to change.
We believe that the first-generation web, where every user action required a trip back to the server, was sub-optimal. The pendulum is swinging back towards putting more and more logic on the client. And as that happens, the code that is supposed to run on the client side will get larger and larger (Note: this applies to AJAX as well as Flash). Whatever technology you’re using, there are some basic things that you need to do once a body of code gets beyond a certain size and complexity. Client-side code is now reaching that stage.
Design Patterns: Design patterns are stereotypical ways of solving engineering problems. Design patterns are language-agnostic, and so can be directly used in Flash Programming. For example, we use the “Model-View-Controller” design pattern throughout our code to separate the code that controls the application logic from the code the controls the display..
Packages: packages are important for two reasons.
1) They allow you to segregate your code into collections of files that are dedicated to specific purposes. This reduces the amount of code that an engineer has to read or think about when working on a particular problem.
Second, packages are a way of avoiding “name-space collisions”, where a common class name or function name (say “Controller”, or “validate()”) is used twice by two different engineers.
This is becoming a MAJOR issue in the AJAX world, where there is no clear model provided by the language itself for creating packages. Some of the pioneering libraries (like Prototype) are written in the default namespace, which risks collision with code written by other developers. On the prototype mailing list, Martin Marinschek wrote: “The critics of prototype argue that the prototype objects are not namespaced – and that prototype extends basic javascript-objects withmethod names that could easily be duplicated by another framework.”

Automatic evaluation of code

One major advantage that strongly typed languages have over scripting languages is that they must go through a compilation process. While this adds overhead between development and deployment, it has the advantage of identifying programming errors at “compile-time” rather than “run-time”, when troubleshooting will be harder. We write our actionscript so that it is as strongly typed as possible, to facilitate catching as many errors as possible at complile-time.
Automatic deployment of code
It’s important to have a reproducible procedure for deploying your software to a server: otherwise, it’s hard to know (when you encounter a problem) whether the problem was caused by a deployment mistake or by a bug in the code. We build and deploy our code using customized ANT script, so that every step is embedded in code and can be reproduced by anyone.
What’s different about writing a large application in Flash, compared to Java?
The first observation I have is that we haven’t been able to get as much code re-use as we’d like. Good third-party libraries aren’t as available in ActionScript as they are in Java, so we aren’t able to “stand on the shoulders of giants”. But even within our own team we haven’t succeeded in reusing code as frequently as I would like. Of course, code reuse is often hard to achieve, even doing java development. I’m not able to put my finger on why this has happened, and whether it’s something specific to my team / project or something generic to ActionScript development.
Another observation is that compilation is really slow. This means developers HAVE to have the latest and greatest desktop machines, and that developing on a slower machine (like my laptop) is a pain.
One pleasing side-effect of the RIA architecture is how simple our back-end code has become. With display and business logic being mostly handled by the client-side, our java code is barely a thousand lines of code, responsible mostly for serving up xml from the database, and writing xml back into the database.
All in all, it’s been a reasonably positive experience. You can build reasonably-sized software using Flash, as long as you are as disciplined as you would be using other technologies.

13 thoughts on “Hard-Core Actionscript

  1. JesterXL January 3, 2006 / 11:10 pm

    If you are using ANT, then use MTASC, the open-source SWF compiler. It is for the commandline, and supports script injection. So, rather than changing 1 line of code and having to wait 2 minutes in Flash, you only wait milliseconds in MTASC.
    More info:
    More context:

  2. Brajeshwar January 3, 2006 / 11:52 pm

    For AS 2.0 Compile time Speed, MTASC, http://mtasc.org/ is a tool to be seriously considered.
    Not comparable to yours as our was like a one-man job but have done coupla applications in AS 2.0 which cross well over 15,000 lines of code and well above 100 odd classes.

  3. Svetoslav Sotirov January 4, 2006 / 12:34 am

    “The first observation I have is that we haven’t been able to get as much code re-use as we’d like…”
    Well in our experience it took us 2 years and a lor of dedication and spanking to stabilize something that looks like a framework(use of paterns offcourse) that can be reused, with abstract enough architecture so that from version to version of flash we usually have to change just the implementation(will see how major the change will be for AS 3.0) 🙂
    We plan to release soon the framework it will be more towards rich interactive web sites then applications but we have already a very positive experience in using it in a large scale enterprice level project.
    So I guess the it just requires a lot of discipline to seek and enforce reuse and push the development team to think reuse

  4. Leif Wells January 4, 2006 / 7:52 am

    1) You said: “The first observation I have is that we haven’t been able to get as much code re-use as we’d like.”
    Are you using a framework like ARP? (http://www.osflash.org/arp) We love the way that ARP lets us code only what we need for the our RIA.
    2) You said: “Another observation is that compilation is really slow.”
    Are you using the Flash IDE for all your development? We are doing all of our development using Eclipse with the Actionscript Development Tool (ASDT) and the open-source compiler MTASC.
    MTASC compiles super fast because MTASC only recompiles the code that you changed. We went from 2 minute compiles down to 10 second compiles (and much shorter days and fewer “coffee” breaks).
    Of course, you can just wait a while and just use Flex Builder 2 to do all your development.

  5. Jensa January 4, 2006 / 11:58 am

    Curious: Any of you guys uses CVS or Subversion for Flash projects? How do you organize repositories and do you store binary files such as FLA’s in CVS as well?

  6. David Mendels January 4, 2006 / 12:00 pm

    “21 packages, 188 classes, 20,000 lines of code
    Automatic unit testing , Automatic daily builds,
    Does this sound like a Flash program to you? ”
    Hi Jonathan,
    Actually it sounds more like a Flex application but it is by no means atypical in 2005/6–I can think of hundreds of apps that would fit that profile. I think that would be pretty typical in nature (including the “Java style” development you describe”) of a Flex app,. I know of ISVs with Flex apps with a year and a half of development by a team and over 1M lines of code.
    Starting 4 years ago we realized that the Flash authoring style metaphors (timeline, etc) were both innapropriate for most folks with a more traditional application development background and do not scale to team development well or long term maintanence of an application. We set out to address this with a fundamentally different development model that would fit in neatly with the tools, design patterns and workflow of a Java development team. I think we have succeeded fairly well with ~500+ customers of the 1.0 product and many thousands of developers; and now with 2.0 (and a much more approachable licensing model for the masses of developers) we have tens of thousands of developers using the public alpha and the Java-style development would be pretty typical for them. Check it out at labs.adobe.com if interested.
    In terms of code reuse, I think you will also find the ability to build MXML components and reuse them with just a simple tag to be a very simple model to promote code-reuse.

  7. Jon January 4, 2006 / 12:20 pm

    Jensa: we use subversion. We store binary files (gifs, flas, etc) in it. One reason we extract as much logic and completixty into the actionscript is to keep it in text format.
    The repository is organized like this
    root->src-flash->as->{package structure}. FLA files go in src->flash. HTML files go in src->html. The whole thing gets built and copied over to root->deployment as a war file.
    Thanks to everybody for pointing out MTASC. We will try to move to using it immediately!
    We aren’t using any frameworks (ARP, etc), but are definitely interested in hearing about other’s experience with same.

  8. Christian Cantrell January 4, 2006 / 3:51 pm

    Jonathan, I’m very interested in your code reuse observations. I hope you’ll post when you know more, or ping me directly.

  9. Jon January 4, 2006 / 4:15 pm

    Hey Macromedia / Adobe guys!
    David: It might be a stretch to call declarative XML programming “java style”. But it’s certainly more developer centric than the timeline, and clearly the eventual path towards authoring front-end code. But it’s a little cutting-edge, no?
    Christian: will be happy to ping you once I figure out the answer to the code reuse question.

  10. David Mendels January 4, 2006 / 8:18 pm

    Hi Jon,
    “It might be a stretch to call declarative XML programming “java style”.”
    Well, you will find AS3 to be very Java-like. And JSP tag libs are very common in Java app developement.
    But I was referring more to the points you made above that I think do fit the development model nicely: No timeline and “an emphasis on inheritance, design patterns, package structures, and maintainable code, is really quite similar to developing in Java or any other object-oriented language.”
    “But it’s a little cutting-edge, no?” Depends on your taste I guess. Flex is 21 months old now, and has many thousands of developers and some very large and mission critical uses. (Yahoo uses it for Yahoo Maps, SAP uses it for their analytics package, Fidelity uses it for retirement planning applications, Harley Davidson uses it for motorcycle configurators, etc). Declarative XML mark-up for UI pre-dates us with XUL as well. But MXML is just an abstraction on top of ActionScript–you can use it as much or as little as you like. But the development model–text based, code centric, tool agnostic, command line compiler or server side compiler , component oriented, profiling, debugging, easy to implement MVC and other design patterns, promotes code reuse, etc is why I thought you would be interested.

  11. jon January 4, 2006 / 8:57 pm

    We agree that MXML / LZX / etc is a programming approach with “an emphasis on inheritance, design patterns, package structures, and maintainable code”.
    It’s just not as familiar a paradigm as 3GL+UI toolkit, that’s all I’m saying.

  12. Austin Govella January 4, 2006 / 9:22 pm

    I’m not as familiar with ActionScript as I should be, but are you referring to your backend Java here, or the front-end ActionScript?

  13. Jon January 4, 2006 / 10:28 pm

    We’re talking about the front end here. Actionscript which gets compiled into a swf, downloaded and run in a browser.

Comments are closed.