My friend, former co-worker, current co-author, and Yahoo! Maps genius, Chuck Freedman, made an interesting observation about the size of Apollo apps today.
As Flash developers over the years, we’ve had it beaten into our heads to keep apps small. Embed small assets in the swf, load in larger things at run time. Keep things that might change outside the main app.
This is something I’ve been thinking about with Apollo as well. I’m not saying to throw these things out the window, but you really need to rethink them. I was writing up something about embedding vs. loading the other day and realized that what I was saying really didn’t have the importance in Apollo that it does in a traditional app.
Normally, you’d embed smaller things that are less likely to change, and load in larger things or things that are more volatile.
As Chuck points out, file size is largely a moot point. At least to a degree. But even the dynamic nature of application pieces needs some thought. Say you build an app and you distribute it with some skins or other assets. You think, I’ll keep these outside the app, in case I want to change them, I won’t have to recompile the whole thing. But how relevant is that argument in an Apollo app? If the assets are distributed with the app, you’re going to need the user to go through an upgrade anyway – download and reinstall something. So does it really matter if they are are in the app or in a folder next to it?
Note, I’m not saying the answer is a definitive, “no it doesn’t matter.” I’m just saying think about it freshly. You might want to have the assets on a server somewhere and be truly dynamic. Or you might want to be able to just distribute a new set of skins only, or even allow the user to make his own skins. It might even be a better development flow to keep the assets external.
All I’m saying is that a lot of us long time Flash developers are going at things from a web-based development viewpoint, and desktop app building is a different story. Don’t take old habits for granted.