I pushed the pruning of some class selectors. There are a few more, but I'm not going to do them right now. Volunteers are welcome to do it though. Along with a few more tweaks, I got HelloWorld from 69K (my earlier report of 62K was incorrect) down to 59K. I'm going to stop there for this release.
When I look at the minified JS, without actually measuring, it appears that what is left is: 1) String table 2) Google's event subsystem 3) FlexJS MouseEvent subsystem 4) Utils Maybe for the next release, I will play around with an option that I'll call '-noexport' that removes all @export jsdoc tokens in the output before passing it to Google Closure Compiler. That might reduce the string table, but it would break code that relies on obj["propName"] access so it might break DataBinding without further work. Volunteers are welcome to take this on instead of me. I keep wondering if we still need Google's event subsystem. We did early on when we were still supporting IE8. IIRC, it is about 6K. I left the mouse event code in HelloWorld because in practice, everybody else's app is probably going to leverage mouse events. Maybe for the next release, we should look into splitting up our Utils classes into package-level functions. StringUtil for example has lots of nice utility functions like trim and restrict, but HelloWorld doesn't use restrict. If StringUtil was a set of package-level functions, it would be more PAYG. Thoughts? I'm off to make sure I didn't break any examples. We need a few more folks to say they've examined the release branch packages before we cut an RC. -Alex On 5/15/17, 8:46 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote: >Hi, > >While waiting for more folks to examine the release branch packages, I try >find time to find easy ways to make HelloWorld smaller. Currently, it is >62K of minified JS. IMO, that's too big! > >I think I can get some classes to drop away via more >@flexjsignorecoercions. The list of interfaces in the output is pretty >large and I'll bet most are not needed at runtime. > >But another sore spot for me is the CSS output. This is true even for >regular Flex: the CSS output contains EVERY class selector. The compiler >knows how to prune out unused type selectors, but it always keeps every >class selector. IOW, if you look at the CSS and see ".DataGridListArea", >that's a class selector. But if you see "DataGrid" (no starting '.') >that’s a type selector and for HelloWorld, which has just a Label, the >DataGrid type selector is not in the output and any dependencies it brings >it are not in the output either. > >But in HelloWorld today, ".DataGridListArea" is in the output for >HelloWorld. In looking at the compiler code, we could somehow mark our >class selectors in a way that they will be removed if the type related to >the name isn't in the output. IOW, we need to know to keep class >selectors like ".myClassSelector", but know to get rid of >.DataGridListArea if DataGrid is not in the output. > >I've worked around this in the past by creating new classes. In this >case, if .DataGridListArea is applied to a Group, then make a subclass of >Group called DataGridListArea and change the class selector to a type >selector. The problem is that the definition of the DataGridListArea >class takes up room in the output, so it would be slightly better to find >a way to prune class selectors. > >Maybe class selectors we want to prune should start with the type name >surrounded by '$", so .$DataGrid$ListArea. Then the compiler could easily >check for two '$' and see if the class in-between is being kept in the >output or not. > >Thoughts? >-Alex >
