> > >> >> (a) Javascript hot-swapping >> One disadvantage of the current SDM recompilation is that it triggers >> page reload in the browser. >> If the application being debugged is a stateful, single-paged one, this >> means that even for a very small change, the developer essentially >> starts-over the debugging, as the application state is lost. >> >> Now, the debugging protocol of Blink allows the debugger to hot-swap a >> piece of JavaScript with a newer version, right? >> If the incremental compiler preserves the names of the generated >> Javascript types/functions, then a debugger like SDBG can detect the SDM >> recompilation and can pro-actively push the newly generated JavaScript into >> the browser. Imagine how cool is this: you stay on the page, spot a bug >> (say, in an onclick event handler), fix the bug in the Java code, hit the >> Recompile button (or Eclipse/SDBG does it for you behind the scenes when >> you save your Java file!) and there you have it - you can click again and >> now the correct, recompiled event handler will be triggered. All of this >> without leaving the application page and starting over. >> >> Of course, for the above to work, additional changes may be necessary. >> For example, contrary to production, the generated javascript file should >> probably always be named the same way. Perhaps, it should also not contain >> one big "eval" statement. Finally, for big changes, the above hot-swapping >> will likely not work, but the idea is not to make it work in all cases, but >> for the majority of the small, incremental changes. >> > It does sound like an interesting idea. If at some point the browser > reload time (as opposed to the compile time) is the longest part then we > will start looking at ways to speed that up. One similarish idea we've > discussed is to change the linkers so that the output JS exists as > separates files. This would allow the browser to hold on to it's > precompiled javascript cache for parts of the application that haven't > changed (thus reload much faster). But as Ray mentions, we're pretty heads > down on an earlier stage of development right now. So I probably won't be > looking at something like this any time soon, but patches welcome. >
The javascript hot swapping is not (only) addressing the browser page reload time. Rather, it is addressing the frustration of the user that he has lost the state of the app due to the page reload, and now she has to potentially do lots of manual clicks and types *inside* the app until it is brought again to the state where the bug happens. But for sure this is a much lower priority than having a very fast incremental recompilation and relinking. Once I have some time myself, I may start looking into hot swapping in the context of SDBG. (BTW, If outputting the 30+ MB javascript file does take some time then looking into outputting instead a "delta" javascript file as you hint is probably worth it even if we put aside my dreams for hot-code swapping via the debugger... but then I'm only speculating here...) What I am working on is trying to flesh out the "maturity" of this current > approach. At the moment we do not notice when you change the content of > resource files which were inputs to Generators and so as a result we fail > to rerun those Generators when we should. Once this is corrected there will > be a while spent on general bug finding. > > After that we will probably start looking at remaining performance > bottlenecks. Roberto is already looking at Linkers and we think that the > next big opportunity after that will be in improving the TypeOracle > construction time (see > https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/javac/CompilationUnitTypeOracleUpdater.java > > and related classes). But there will probably be other opportunities as > well. > Sounds great. I am already happy with the current 7 seconds recompile (as long as the 18 seconds of relinking go down to 2 or so :-) ), but faster is always better. -- 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/1132c1d4-0ac7-4d1e-a1ad-7575e6dadab5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
