Zach Graves and I are finishing up the demo app we’ll present at ApolloCamp Friday. As I review the code, my web app developer instincts kick in… What further efficiencies can we make? Is it OK to use the large DataGrid component? Is the XML loading fast enough? What’s the final application size?… And then I pinch myself. This is a desktop application. Size is no longer that big a deal. Or is it?
For so long, as web developers, we have been trained to cut as much fat as possible off our applications. We know that the user should never have to wait too long to view and interact with our apps. We know to use as lightweight components that we can find. Factors like these have long challenged the speedy delivery of Flash/Flex and web apps as a whole. Typically, the components included with the Flash IDE were always bulky. And a characteristic of Flex apps is that, due to the framework inclusion, you were always going to get a bigger .swf than if you coded it straight out in Flash.
However, the game is changing. In the desktop world, size considerations are seldom made, or so it seems. Desktop applications have long been distributed on CD (or DVD). Usually weighing in at hundreds of MB’s (apps like Microsoft Word and Outlook are huge); these apps usually take minutes (as in 20-30) to install. Have desktop app developers always coded with a disregard for size? It seems they are bound by a different covenant, one that requires them to develop as functional and as all-things-to-all people of an app as possible?
The only real factor for size lies with distribution. We already know that the Apollo runtime size will be larger than say Flash Player. This of course is due to the inclusion of HTML support and new APIs. Seeing as most Apollo apps will be distributed online, maybe paired with the runtime, developers should still be certain not to code to too great a size. Not that we’ll see apps in the hundreds of MB’s (I’ve yet to see a demo Apollo App in the dozens of MB’s), but we can’t forget our dial-up users either.
My conclusion is that the size factor for desktop apps most likely benefits only as a bi-product of efficiency. In other words, the practice of a developer to code their desktop app most efficiently, for performance and scalability, probably has the most effect on reducing size. As Apollo continues to roll out, we should see developers’ instincts change a bit.
Awareness for size will lighten and make way for more functional and robust application development. With such a conversion about to happen, web developers to would-be desktop developers, we should see the most lightweight, yet highly functional desktop applications ever – thanks to Apollo! Size matters not, and like the old adage says, may not even be a factor.