5

From my understanding, with collapse-all-properties in gwt.xml, the compiler produces one permutation for all browsers. And the resulting files are 15% to 20% larger.

Other than the increased file size, are there other reasons why I shouldn't use collapse-all-properties for production?

For example, does it strip browser-dependent logic and css, thus causing the app to potentially work and/or look differently than when compiled with default permutations?

In my app, I noticed about 100KB size increase in cache.js and combined 50KB increase of all deferredJs files with collapse-all-properties.

But when combined with gzip, code splitting and caching, the benefit of smaller file size seems trivial compared to the significant fast compilation time and general ease of use.

Got me wondering if I could use it for production.

Ivan Yeh
  • 53
  • 5

1 Answers1

9

There is no reason you can't use it in production, aside from the reasons you've already stated, and if you expect most of your users to usually arrive with populated caches (app doesn't change often, and most users bring up the app frequently), then you are correct that the size point is less meaningful. There is still a cost to loading a large JS app into memory and building all of the required methods, but I suspect that it is not meaningful when compared to loading an extra 100kb from the server.

I don't believe that collapse-all-properties by itself disables your split points (deferredJs files), or perhaps I misunderstood and you were saying that the split points grew by around 50kb.

If the performance seems acceptable on the lowest power machine you expect your users to be running the app on, I wouldn't be concerned - no need to optimize for cases that don't really apply to you.

I would be somewhat wary of additional locales (esp when new images are used for different locales), and 'form factor'-based properties (probably want to keep mobile/tablets fast at the cost of build times). I would also look into disabling unused browsers - while most modern browsers are converging on just a handful of required implementations, older browsers are still around which require extra code and additional ways to handle features like clientbundle (can't inline images into a data url). If you are able to remove those browsers from your application, you may recover a large amount of that increase you are seeing.

There has been discussion in the general GWT roadmap of removing permutations entirely, since they are largely a holdover from the time when each browser behaved very differently from others, but while we still have IE8/9 support, it will be difficult. A future modern-browser-only GWT will likely leave permutations behind entirely, and encourage solving problems like locales in a different way.

Colin Alworth
  • 17,801
  • 2
  • 26
  • 39
  • Just so I understand you correctly, there is no information loss with the use of collapse-all-properties. Correct? Extra code and resources needed to support various browsers are simply compiled into one set of files for use on all browsers, hence the increased per-file size (as opposed to several optimized file sets, one per browser/locale/form factor). I think your suggestion to remove older browsers is good enough for my use case. I will look into that. – Ivan Yeh Feb 07 '16 at 02:20
  • Correct - you pay a small runtime fee to check which "soft permutation" you are in each time one of the objects is created that would be different in a distinct permutation, and you also lose any optimizations from assumptions that the compiler used to make about which specific subclass would be used, but that's about it - it should behave the same but slightly larger, and veeery slightly slower. – Colin Alworth Feb 07 '16 at 04:42