Don't Package on Every Single Compile, Flex Compiler!!
One of the problems I have with Adobe's Flex technology is that Flex compile times are very slow. Yes, I know, Gumbo is going to make compiles somewhat faster. I also know about the Flex Compiler Shell, and other projects to distribute compilation. Yes, I've also tried incremental compilation. All of these things really miss the true problem with the Flex compiler. And it is really at the heart of the Flash technology itself.
The problem really lies in granularity of a compilation unit that Flash and the Flex compiler produce. Basically the output of a compile is a SWC or SWF which is fully ready to be deployed. I think the scope of compilation unit that the compiler uses is way too big. The Flex compiler should be producing an intermediate level compilation unit tied to the source file level, or at least some smaller scope.
I'm just a dumb Java guy, but SWCs and SWFs look a lot like JAR files to me. They include all the bytecode and embedded resources needed for a deployment. So what the Flex compiler is basically doing is saying "I'm going to compile all your source files _and_ put them into an archive for deployment every single time!"
If the compiler would just produce intermediary units of smaller size (like .o files with C, or .class files with Java), and then make packaging a separate step in the build process, then I'm almost certain that compile times would be better.
I also think that tool support would improve. For instance, if the compiler could produce these smaller units, then Flex Builder could do more immediate syntax checking like we're used to having with Java code. Instead of waiting on the compiler to fully package everything up, I could see coding errors much faster. Plus, unnecessary additional scanning of unchanged sources would be eliminated since the compiler would be able to examine one (or at least a smaller set of) source file.
Sure, I need that SWC/SWF when I want to push the app out to a server, but why should I pay the cost to package it up for deployment each compile? This severely limits the size that a Flex application can get, or it at least causes you to create a lot more sub-projects for your app much earlier on in that app's lifecycle.
The problem really lies in granularity of a compilation unit that Flash and the Flex compiler produce. Basically the output of a compile is a SWC or SWF which is fully ready to be deployed. I think the scope of compilation unit that the compiler uses is way too big. The Flex compiler should be producing an intermediate level compilation unit tied to the source file level, or at least some smaller scope.
I'm just a dumb Java guy, but SWCs and SWFs look a lot like JAR files to me. They include all the bytecode and embedded resources needed for a deployment. So what the Flex compiler is basically doing is saying "I'm going to compile all your source files _and_ put them into an archive for deployment every single time!"
If the compiler would just produce intermediary units of smaller size (like .o files with C, or .class files with Java), and then make packaging a separate step in the build process, then I'm almost certain that compile times would be better.
I also think that tool support would improve. For instance, if the compiler could produce these smaller units, then Flex Builder could do more immediate syntax checking like we're used to having with Java code. Instead of waiting on the compiler to fully package everything up, I could see coding errors much faster. Plus, unnecessary additional scanning of unchanged sources would be eliminated since the compiler would be able to examine one (or at least a smaller set of) source file.
Sure, I need that SWC/SWF when I want to push the app out to a server, but why should I pay the cost to package it up for deployment each compile? This severely limits the size that a Flex application can get, or it at least causes you to create a lot more sub-projects for your app much earlier on in that app's lifecycle.
Comments