Hi, I promised some feedback on Greg's PAYG page. After thinking about it some more, I'm proposing my take on it below. I know past discussion tried to break off component set definitions from PAYG, but I think PAYG is always going to be subjective enough that the goals of the various component sets will affect decisions about what goes in the default beads. I can't say this often enough though: one main goal of beads is to avoid spending energy on what is the one right way, and also, on exactly what PAYG means. If you don't agree with what PAYG means to the others working on a component set, go start a new component set.
So, I am going to try to discuss all of the related factors in one place below. Thanks, -Alex --- Pay-as-you-go (PAYG) --- PAYG means that Download Size, Startup Time, Memory Usage, Line of Code goes up and Performance goes down as new features are added to the Application. PAYG leverages well-known computer science principles: Re-usable code, Separation of Concerns, Modularity, Abstraction. PAYG cannot be defined objectively. You can be too granular or not granular enough. Too Much: Put a for loop in a re-usable function. Everybody must call this function. Too Little: Regular Flex SDK. 13,000 line base classes. Just Right: Make it possible that an application has no unused code paths in the framework code it uses. IOW, no just-in-case code. FlexJS uses modules called "Beads" to implement features in a PAYG fashion. Beads are placed on Strands so composition is primary pattern. PAYG has no required implementation patterns. There is no one right way. Subclassing, sharing utility functions, beads sharing other beads are all valid implementations. The key is to see how it measures up against the metrics of Download Size, Startup Time, Memory Usage, etc. Other computer-science principles like DRY should be considered as well. There doesn't have to be only one version of a bead. There can be beads with different implementations and tradeoffs on those metrics. ---Additional Guidelines for FlexJS--- Naming: Pick a relatively small/simple set of features that are likely to be used in several applications. Give it a name starting with Simple, or something descriptive and well-known like Panel. Additional features expand the name with prefixes (DropDownList instead of ListForDropDown) or suffixes like PanelWithControlBar. Reduced/inlined versions will also get expanded names. Defensive Code: Rarely needed. Bad inputs should be found and fixed before deploying the app. Folks who take the time to do that should be rewarded with smaller code and faster performance. Use of goog.DEBUG to have debug-time input checking is allowed. There is a trade-off between any performance hit of debug-time checking vs the developer productivity of having those errors caught early. Bead Removal: We may someday decide that beads should almost never be removed. Implementing a flag to disable a bead might be cheaper than removing it. Component Sets: Different component sets have different goals. Basic: smallest SWF-equivalent implementations Express: Pre-package Basic beads and thus SWF-equivalent MDL: No interest in SWF equivalence. JS metrics are more important than SWF metrics.
