IMHO @Ivan's second suggested approach would be a perfect solution: "implementing Java watch expressions and conditional breakpoints in Eclipse SDBG". Hopefully this will be possible to realize and hopefully gwt contributors/maintainers will be willing to cooperate with @Ivan about this idea.
On Fri, Jan 13, 2017 at 12:36 PM, Thomas Broyer <[email protected]> wrote: > > > On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, [email protected] > wrote: >> >> Hello, GWT people. >> >> <rant> >> >> GWT got its popularity because it allowed DevMode in the browser (run >> java in VM in browser, manipulate DOM, use your IDE!). In fact, the GWT >> project appeared as clever hack on hack on hack to stretch limits of >> possible, to be ahead of its time, and that was cool. Nobody did that >> before. Now GWT turns into much like... i don't know, more like typescript >> compiler. No, really, with announcements like those "Let’s examine >> <http://www.google.com/url?q=http%3A%2F%2Fblog.lteconsulting.fr%2Fgwt%2F2016%2F2016%2F04%2F10%2Fgwt-2016-en.html&sa=D&sntz=1&usg=AFQjCNFu7UPp65EVtrgMjOqfgOaxsI5b-Q> >> the parts of GWT doomed to extinction: generators, Widgets, GWT-RPC, >> UiBinder …" it's just another typescript. Typescript also looks like >> Java! Its transpiler is and will always be faster than GWT. There's no >> reason for GWT to be anymore. >> > > You're right, GWT turns more and more into a TypeScript/Dart-like, with > one major difference: the input is Java. > This means it can run in a JVM, i.e. be shared with your server-side code > and/or your Android native app, and possibly transpiled to ObjectiveC for > use on iOS (which is exactly what Google does: sharing 70% of code between > all versions of Inbox, sharing Google Sheets formulas' parsing –and > execution?– between client and server –and Android?–, etc.) > With Dart or TypeScript you need to bring a DartVM or JS Engine to run the > code. > And that's without talking about the tooling you get with Java too, that > has to be rebuilt for all those newer languages (linting, refactoring, code > generation by analyzing the AST –annotation processing– etc.) > > >> And there's no GWT events, reddit comments on its announcement are like >> <https://www.reddit.com/r/programming/comments/593c3w/gwt_280_released/d95k7go/> >> "oh, it's still alive?". >> >> So while GWT is essentially already dead for me with removal of DevMode >> (I understand this removal happens because of browsers architectural >> changes, not because the idea failed), I still think about various >> workarounds. >> >> </rant> >> >> I remember, in GWT 1.0 special mozilla-based internal browser was shipped >> with GWT. It was long before GWT DevMode plugins for all browsers. And >> nobody thought it's bad option, although it didn't support SVG which was >> already in firefox, canvas, etc. It was the way to go. IT WAS the cool part. >> >> With removal of NPAPI and devmode plugins, maybe it would be feasible to >> take chromium, maintain one (1) patchset that allows it to run alongside >> with JVM (maybe even same process!) on all platforms, allowing DevMode via >> direct calls, and distribute it on manner they do it with dartium? >> gwtromium? >> >> You ask "what about other browsers"? You don't need other browsers. >> Citing same source: "modern browsers are now more standard and compatible >> <http://blog.lteconsulting.fr/gwt/2016/2016/04/10/gwt-2016-en.html>, and >> we no longer need to have the homogenization layer that GWT gives", and >> this is in fact true. For other browsers, use SuperDevMode, it's useful >> enough to catch browser-related issues. But main program logic should be >> allowed to be developed (and debugged!) in Java. Because GWT is... Java. >> >> By introducing more strong ties and even sharing process with JVM it >> would be possible to speed up roundtrips java<->browser due to absence of >> TCP connection and serialization, so it will be even noticeably faster than >> before. >> >> So, does this idea make sense? <rant>Or javascript-transmitted disease >> finally won?</rant> >> > > It makes total sense, but as Jens said, it's unlikely to happen unless > people organize and make it happen (FWIW, JavaFX, if it ships with a > recent/decent-enough version of WebKit, is probably the way to go here). > There are hitches though: Google no longer maintains the DevMode code and > JsInterop doesn't work there; they actually already deleted that code > internally and have been pushing for more than a year now to delete it from > GWT proper too. This means that for DevMode to be "resurrected", someone > would have to step up and actively maintain the DevMode code > (CompilingClassLoader, with its special logic for super-source and JSNI) > and enhance it so it supports JsInterop. So it's not just a > "browser/plugin" issue. > (note that in GWT 2.8, GWTTestCases now run in "prod" mode by default, > that was one step towards deleting DevMode entirely from the codebase) > > -- > 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/45aa1f15-c3be- > 407f-951e-56793bd5ddb7%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/45aa1f15-c3be-407f-951e-56793bd5ddb7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFHJR8Wmhks9gLKfBM%3De-%2BDjQf7EM%3DejS%3D0KGFweOPWGSSMBZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
