Building Applications in ActionScript: Promise and Problems

or, "The Trouble With ActionScript"

In my previous posts on my experiences as a developer in the world of ActionScript (here) and (here), I've complained about the difficulties inherent in application development in Flash and ActionScript. I believe we're in uncharted territory; I'm not aware of any other development efforts underway which match the scale of what we're trying to do at Applied Messaging. Therefore, I think my perspective might prove to be valuable to other people who are considering similar projects.

After helping to develop an extremely complex product over the course of the last nine months, I have come to believe that Flash has a future as a real internet application development tool. It's a very difficult and frustrating tool to use at present, however, and it has a lot of growing up to do. On the other hand, I've worked with a lot of tools and environments which were immature, hard to use, and frustrating -- and some of them, over time, were improved to the point of being useful and relatively easy to use. I hope Flash becomes one of them, and on the basis of the conversations we've had with Macromedia, there's a lot of reason to be optimistic. I think on balance there is a good chance that Flash will mature the way it should, and when that happens, it could be very cool.

In the meantime, I have to live with what Flash is, rather than what I hope it will mature into, and here we have a wealth of problems.

ActionScript is a feature-complete language: it provides the necessary infrastructure to perform almost any computing task. There is no formal reason why one cannot build large, complex applications in ActionScript. However, that doesn't mean that ActionScript is a particularly good tool for doing so. In fact, if you are developing a complex application, unless you have a compelling reason to develop in ActionScript, you probably don't want to do so.

ActionScript, as I mentioned before, is well-designed to create simple applications. If you are developing a simple application, then doing so in ActionScript may well save you a great deal of time. However, if you are developing a complex application, then doing so in ActionScript will actually cost a lot more than it would in a more mature environment. Let me digress for a few paragraphs to explain why.

Simple applications and complex applications differ in the number of interfaces which the programmer is required to maintain. An interface exists anywhere where one object or routine is calling another object or routine. Simple applications may only have a handful of objects and their associated routines. Complex applications may have hundreds of objects and thousands of functions. Our current application has over two thousand separate functions.

Simple and complex applications also differ in the stability of the requirements and the design. Simple applications are easy to understand and easily specified. A simple application's requirements do not change much over the (short) course of the application's development and deployment. However, this is not the case for complex applications, where it's a common occurence for the final product to look and behave substantially different from the product which was originally envisaged. There are a number of reasons why this might occur. The problem might turn out to have been incompletely specified (this happens a lot, actually). The customer's needs might change. The original design approach might need to be altered for performance. The server backend might need to be migrated to a different system with a different protocol, necessitating a client change, etc. All these changes need to be propagated through the application's codebase and its associated interfaces. The interfaces consist of function calls within the application, and network requests outside the application.

In the case of simple applications, the time to build the application (i.e. the cost) is dominated by the time required to code the application. However, as an application grows, the number of interfaces to maintains grows roughly as the number of objects squared. Therefore, as an application grows in complexity, the time to build the application soon becomes dominated by the time spent testing and debugging the interfaces. This problem is compounded by the fact that complex applications are subject to the additional stress of changing requirements/designs, as mentioned above.

ActionScript is a typeless language with minimal error-checking and a forgiving compiler. It doesn't require variables to be declared or typed; it has a very simple and flexible object model, and errors such as uninitialized variables and mismatched function signatures do not generate any warnings or exceptions. On the other hand, a language such as C++ is strongly typed, with loads of error checking and a strict compiler. Coding and compiling an application in C++ is difficult and frustrating compared to doing the same in ActionScript, because there are a lot of details which have to be precisely specified, and the compiler generates a lot of errors and warnings. However, the compiler's insistence on rigor from the programmer helps to insulate the program from errors which arise when one part of the program isn't consistent with the other parts. This makes C++ programs relatively robust in the face of design/requirements changes, and makes ActionScript programs, by contrast, relatively brittle. Because of this, it usually takes much longer to change an interface, and to test that change, than it does in a more mature environment. Creating, debugging, and maintaining a complex application in ActionScript therefore takes several times as long with Flash and ActionScript than it would with another tool like Visual Studio.

If your application is straightforward, if it should only require an afternoon to code, ActionScript is a very good tool. It doesn't require a lot of preparation to get an application up and running, and because the compiler is not very strict, it's not intimidating for nonprogrammers. Plus, of course, it's part of Flash, giving you an excellent display layer, as well as access to a good API with components and a set of network interfaces. However, if your application is very complex, you should consider very carefully whether ActionScript is the tool for you. The brittleness of ActionScript applications with respect to design changes is its most serious weakness, but not its only problems. ActionScript applications are also very slow, because they are only compiled down to virtual machine code, to be interpreted within the context of the Flash player. Finally, good debugging facilities for ActionScript applications are practically nonexistent, further adding to the time and cost for building complex applications.

Macromedia claims that many of the current deficiencies in Flash and ActionScript will be largely resolved in the next release of Flash. In fact, what I've seen of the new tool is very promising. However, if you're building an application now, you don't have the luxury of working with next year's tool. Flash 6 (a.k.a. Flash MX) is an enormous improvement over Flash 5, and I expect Flash 7 to be even better. Alas, that doesn't help me now.

Some advice if you've come this far and you still want or need to develop in ActionScript:

Plan Ahead Very Carefully. Because changing your architecture in the middle of your project will be fraught with difficulty, be as complete as you possibly can in your initial design and try to minimize how much the specifications will change while you're in the midst of development. This will reduce the possibilities for introducing bugs as you modify your code.

Shift the Burden as Much as Possible Off Your Flash Client If you're building an application which consists of a Flash client and a server based on some other technology, try to make the server do as much work as possible, and try to make the Flash client do little more than serve as a display and control layer for the user. It's likely that the server can be coded in a more robust fashion.

Don't Expect Much Help From the Flash Debugger. We almost never use the Flash debugger. This is for a number of reasons and some of them are unrelated to the platform itself, but partly this is because the Flash debugger is, in fact, a poor debugger. We have developed a number of in-house tools which do some of the jobs which a real debugger would perform, and we have made do with these.

Build Lots of Instrumentation and Scaffolding. Make sure your program keeps a lot of state information, allowing you to find and diagnose bugs when they occur. Our tools essentially encapsulate a local shared object which maintains a running record of trace-like statements, coupled with interactive runtime expression evaluation. These tools are dependent on a lot of instrumentation in our application.