Earlier this year, I led a consulting team which ported a large Windows client app (similar to a member of the Microsoft Office family; think something like Visio but with different functionality) to run in the Flash 9 runtime, using Flex 2 and Flex 3 Beta, in under 6 months.
I was invited to present a (very!) quick talk on some of our "lessons learned," as part of O'Reilly Ignite at Adobe MAX in October. Alas, schedule issues made it impossible to present at MAX. So here, in Ignite style (15 seconds per slide), are the key lessons from the project:
- The learning curve for Flex/ActionScript 3 is very shallow for experienced software engineers, so a strong team can jump right in and be productive even without any Flex/Flash experience. Only two of our five developers had done any Flex or ActionScript work before at all. That said, Flex is still a “leaky abstraction” – some aspects (e.g., deferring an operation to a subsequent frame) of Flash Player still bubble up – so it’s useful to have at least one engineer who is familiar with coding for Flash.
- There is no need to think about a Flex app as a Flash movie on steroids – simply think of it as a VM-based app (like a C# or Java app) from day one. Bringing standard OO pattern experience is very helpful. UML/Code generation tools for AS3 may be helpful too depending on your dev process.
- Premature optimization is still the root of all evil. Most optimizations are a non-issue with the performance levels of Flash 9, and we found that a small number of relevant optimizations could be easily done toward the end of the project without significant pain in refactoring. Network operations, which were outside of our scope, were the only cause of performance issues. Nor did we compromise in terms of space: We had tens of thousands of lines of code, hundreds of features, and most of our display via custom code (the app is partly a diagramming app) … and it compiled to a .swf in the 670 KB range.
- ECMAScript 4, JavaScript 2, ActionScript 3: whatever you want to call it, throwing static typing into the mix (without requiring it everywhere) rocks! Our unscientific feeling is that we enjoyed a 2-4x productivity improvement over a similar language (e.g., JavaScript) because of static analysis capabilities and compile-time error checking.
- E4X on a large scale is a beautiful and terrible thing.
- The beautiful part is: It did not lead us to make a mess of our application with snippets of XML processing scattered everywhere (something we worried about at first), and the performance is amazing. We were doing a ton of XML for integration to existing systems so we worried at first. We measured it, and benchmarks of XML processing speed with E4X were far and away more than adequate.
- The terrible part is: the E4X API has some quirks and inconsistencies that are not documented, and in a number of cases we needed to cook up some ripe hacks to work around them. These issues can and should be cleaned up. E4X also misses a couple of (admittedly rarely used) aspects of the XML schema spec around attribute namespace scoping, that just happened to cause us some difficulty.
- The Flex framework is in serious need of a native AS3 rich text, full [X]HTML editing widget. Workarounds currently include AJAX in the browser, or AS2-based components that can’t run immediately in an AS3 app's VM space.
- For building some applications, the async-callback approach can create substantially more chaos than it eliminates. To address this, Flash/Flex needs threads, or at least continuations. In fact, this is the first time in my career I’ve really seen a problem (handling certain callbacks) where continuations would be an ideal solution and not just a clever one.
- It is easy to mix open source Flash tools and commercial Adobe tools – my team did, and it worked well all the way around.
Since Flex/Flash are likely to stay key contenders for any RIA implementation project, I hope these learnings are helpful when embarking on that sort of work!
No comments:
Post a Comment