...

• Preloaders. Hopefully an application and its dependencies are so small you won't need a preloader. Now, you may need to use a sequence of states to stage how your application appears on screen so there isn't dead air, but you will be able to use the same set of components (although they should be the lighter ones) to create the initial visuals. No need to avoid the use of components in the preloaders like you have to do in Flex today.
• Marshall Plan. Hopefully interfaces will not depend on complex classes, and as new APIs are needed, new interfaces will be created instead of changing existing ones. Then the Marshall Plan should not be needed, although you may need to create "smart" beads that can handle legacy vs current code paths.
• Versioning API/Conditional Compilation By Version. If we decide to change the behavior of an API, that should be implemented via a new default bead. You can use an old bead to get old behavior. Or write a new bead that knows how to switch behavior, but keeping multiple code paths around will not be a recommended practice.

Try not to use Flash classes in your beads

If you do, you probably need to write the JS equivalent

The Last Mile

As Mike Labriola claims in his Randori presentation, most of the work in finishing HTML apps is in tweaking the UI for the various browsers. This will likely be true for FlexJS apps as well, although my prototype is using absolute positioning as much as possible.

...