FWIW my answer to "I want a really awesome debugging experience" is that you shouldn't be doing any debugging in the browser in the first place, e.g. whether it's old-school DevMode or SuperDevMode or Typescript etc.
This is what Tessell allowed (apologies for the self-promotion, although I am mentioning it less as "you should go use it" and more as "no really this approach is technically possible and works well") by stubbing out the DOM with pure-Java equivalents. Granted, you're now running against an abstraction level, so without a browser (e.g. in a pure Java unit test) you can't do any pixel calcs or intimate rendering logic, but the majority of your app shouldn't be doing that anyway (or any at all since most munge-pixels-with-JS can be done by adding/removing CSS classes these days). With Tessell (or whatever Tessell equivalent), you can get to the point where 95% of your development time is in pure Java unit tests, running your presenters, your views, whatever, as regular Eclipse-is-none-the-wiser JUnit tests, and making sure "yeah, the DOM 'looks' like I think it should" (where 'look' is not you-see-it-with-your-eyes, but the-markup-matches-what-I-want) . Then the final 5% of your development time is popping open the browser, and tada it will all magically work. If it doesn't, yeah sure, you spend ~5-10 minutes in SuperDevMode/sourcemaps figuring out why, but then as soon as you reproduce it, you usually can reproduce it in a pure-Java unit test against your DOM abstractions, and you're back to an amazingly quick TDD cycle; no sourcemaps, no browser debugger, no waiting for DevMode or SuperDevMode to load. So, that is my answer to "I really want old-school DevMode": you should put the right abstractions in place to where your app is not coupled to the browser in the first place. If you're coupled to the browser, you've already lost IMO. (Granted, if you've already got a large codebase that is not written against this sort of abstraction, it's not going to be easy to move, so this is probably not very helpful to you.) - Stephen On Fri, Jan 13, 2017 at 6:52 AM CodeLess <codelessoluti...@gmail.com> wrote: > 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 <t.bro...@gmail.com> > wrote: > > > > On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, sannysan...@gmail.com > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. > 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 > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFHJR8Wmhks9gLKfBM%3De-%2BDjQf7EM%3DejS%3D0KGFweOPWGSSMBZA%40mail.gmail.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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANnRKuVA8D26zh6tU_0-1LLeSeqjc1arf%3D9-a6Yqc9640ASyuw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
