On Friday, August 4, 2017 at 9:37:12 AM UTC+2, Geoffrey De Smet wrote: > > Currently we suffer a lot from time-consuming and memory-hungry GWT > compilation on a big project, especially during a "mvn clean install", the > GWT compilation takes several minutes. > GWT super dev mode does alleviate some of these problems sometimes, but > when backend code changes, often the only reliable action is to restart the > entire server. >
That shouldn't necessarily mean recompiling the GWT app though. > Will J2CL and GWT 3 make GWT compilation scale better (faster and/or less > memory-hungry for big projects)? > J2Cl should be really fast, but the Closure Compiler phase is likely to be the bottleneck. I don't have numbers though as I haven't experimented with it yet. > Is any active progress being made on these technologies? > Yes (on the J2Cl side; not GWT 3 yet, it's actually yet to be defined what exactly will be GWT 3: encapsulate J2Cl and Closure Compiler into a "monolithic" tool? or mostly just libraries to be used with J2Cl and Closure Compiler, probably along with Maven/Gradle/etc. plugins tying things together) > Are there any examples out there with a big codebase so we can see the > compilation performance difference in action? > Can we experiment with it on ours? > No yet, but if you want an idea of compilation performance, find a JS project with an equivalent number of files and classes (actually, J2Cl produces at least two JS files per Java file, but one ES6 class per Java class) and run the Closure Compiler on it. One thing we don't know yet how it'd work is "permutations": hopefully there shouldn't be "permutations" per browser anymore, but how about i18n? and then how to select the appropriate "permutation" at runtime? Also, for development, there should hopefully be an equivalent to "draft mode" / "super dev mode" where generated sources are simply concatenated, without further processing (except maybe some basic minification). AFAIK, this is something they have in Closure Compiler that should be open sourced soonish. That said, J2Cl / GWT 3 might require some specific project layout (it might become impossible to mix client and server code in the same Maven module; hopefully a split layout like in https://github.com/tbroyer/gwt-maven-archetypes will continue to work with minimal changes to the POMs) so the first thing in any case is to "clean up" existing codebases; and this hopefully could make your build more incremental, so you wouldn't need to recompile your GWT client code when you only changed server-side code. For now, make sure you take full advantage of GWT incremental compilation and your build tool's incremental build support (Maven is "broken by design" on that front, but should work quite well nonetheless with recent plugin versions; but what I mean primarily is "don't 'clean'") -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/f1a24190-e8a0-41cd-ad95-2dbe95a7ed3b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
