I fully agree about the development pattern! That's why I started by writing the CodeSplitting wiki page as if SOYC already supported the use cases I was thinking about. The design doc was therefore a user manual. As an aside, the code splitting document might sound like a weird home for SOYC development, but in this case the use cases are the same. If we add more kinds of information to SOYC, then that will change.
At the risk of being redundant, here are those two use cases I thought about: 1. Size breakdowns of different parts of your code, so you know what parts to work most on shrinking and/or splitting out. 2. Dependency information related to code splitting, so you can debug what is happening when splitting doesn't go as expected. For this scope, my remaining task list to get information complete is: 1. Dependency information for strings. 2. Depict the initial load sequence. 3. Deal with the divide between pre-optimization size breakdowns and after-optimization dependencies. If we go with the "Soy Lite" size breakdowns, then this issue will disappear. For the UI itself, doubtless it can be improved. I only went so far as to think about the work flow for common debugging tasks, which I documented in the CodeSplitting page. However, the UI is still sparse, and it could doubtless use more guidance and cross-linking. In particular, the current implementation makes it nearly impossible to re-sort the output. Additionally, it takes a lot of time to generate even the relatively limited set of HTML files that are currently supported. Both of these could be remedied by making it a GWT app plus a servlet. Finally, I like the idea of supporting more detailed queries. I haven't looked into it because it's exhausted more than my available time just to cover the basics. A good start would be... use cases that aren't already covered. :) Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
