Update: moving the session to Tue, Apr 4 @ the same time as originally planned. Regards, ​V​ ojtech PS: Greg sent me a link to SDBG project [1] which allows you to debug GWT application via Super Dev Mode from within Java Eclipse IDE. I'm going to cover this in the presentation as well. [1] http://sdbg.github.io/ On Mon, Mar 27, 2017 at 8:09 PM, Vojtech Szocs <vszocs(a)redhat.com&gt; wrote:

Hi, I've shifted the meeting to 4pm CET to make it easier for TLV folks to join. We can still change the time if needed. Vojtech On Fri, Mar 31, 2017 at 3:48 PM, Vojtech Szocs <vszocs(a)redhat.com&gt; wrote:

Hello everyone, for those who missed my session, please find the recording at https://bluejeans.com/s/zij35/ (there are two chapters, because I've accidentally clicked "stop recording" during the session) slides are available at http://redhat.slides.com/vszocs/debugging-ovirt-gwt-applications?token=br... As for the questions - let me post some answers here: experience with it? Yes, IntelliJ has built-in GWT support, see https://blog.jetbrains.com/idea/2014/09/intellij-idea-14-brings-better-gw... But I wasn't able to make it work on my local dev. env. as it attempts to start SDM code server on its own, whereas in oVirt we have a dedicated command to start the code server, `make gwt-debug`. And that's partially because we use ${foo} placeholders in our *.gwt.xml files (to be substituted during Maven build) which causes IntelliJ to fail with messages like Invalid property value '${gwt.runtimeLogLevel}' which comes from WebAdmin.gwt.xml file. TL;DR it works for HelloWorld-style GWT webapps, but unless we can tell IntelliJ to reuse existing SDM code server, it won't work for us. There are two things to consider, asm.js [1] and WebAssembly spec [2]. [1] http://asmjs.org/ [2] http://webassembly.org/ asm.js is about having a subset of JavaScript which is easily optimizable by the runtime platform (e.g. browser's JavaScript engine) but this platform obviously needs to be aware of the asm.js spec to do the optimizations. Latest working draft of asm.js is from Aug 2014. WebAssembly seems to be the next step, defining a binary format that is size- and load-time-efficient but working with low level structures like some basic types, table of types, linear memory, functions and local/global variables - everything wrapped as a "module". The runtime platform also needs to support WebAssembly spec, which is currently being standardized, see http://webassembly.org/docs/mvp/ I found some GWT discussions about WebAssembly and it eventually comes down to GC (garbage collection) support, since WebAssembly code runs in its own context, possibly outside (next to) JavaScript VM. Plus, given the fact that lots of performance depends on how much DOM (or other browser-specific) operations a webapp performs, the gain of using WebAssembly in webapps might not be that big, compared to e.g. games or scientific applications that leverage the power of native code on given OS platform. Good news is that WebAssembly has plans for GC - https://github.com/WebAssembly/design/blob/master/GC.md So once/if WebAssembly adds GC support and tightens integration with web APIs, it might be a feasible compilation target for GWT. ​Regards, Vojtech​ On Sun, Apr 2, 2017 at 11:24 AM, Roy Golan <rgolan(a)redhat.com&gt; wrote: