Hi Sanny,

Thanks for your message !

I agree with Jens, once you accept and understand the new SDM+sourcemaps 
workflow, the thing is really powerful, yet of course different than the 
experience with DevMode.

It's even easier to find browsers specific bugs since the code is executed 
in the javascript vm hence it is very very close to the production code 
flow, whereas with the DevMode there were cases you could not reproduce 
because the code was running in the JVM...

I think you also should understand that sourcemaps is not restricted to 
GWT. So any progress made on sourcemaps support in chrome (or other 
browsers) will benefit not only gwt but all languages transpiled to JS or 
CSS. Maybe one day we get live variable inspection through SourceMap and 
this will be a big win for everyone !

Also one disclaimer as you are citing my article on GWT : I am not part of 
the GWT team (sure I'd love to of course ;)) and the opinions and 
statements in this article may be false - although of course I try not to 
say silly or false things in my articles... Anyway, my article is not at 
all the official GWT's voice...

Just one more point, when the GWT team first announced the death of 
DevMode, I had the same reaction as you, but then having practiced the new 
workflow I changed my mind and now find it better on some aspects.

About DevMode performance, the OS uses IPC & memory sharing when doing 
network on the localhost loopback, so the TCP connection shoud have 
practically no impact on the performance.

About conferences and events, the last GWT event was GWTCon in Firenze, 
Italy which happened on 2016 November. Some talks were given by Daniel 
Kurka member of the GWT team, so was not an "official" google event but had 
all the taste of it ;) I hope the videos will soon be uploaded to youtube.

I recently worked for a customer with 60+ developpers working on a very big 
GWT project, and I helped them migrating to the 2.8 version and optimize 
their code base for a faster compilation. I was kind of scary that they 
would emotionnaly refuse the new workflow with SDM+sourcemaps but it turned 
out they were very happy with it and gained a better productivity. So to 
me, that's really something to try...

About the "javascript-transmitted desease", for myself I don't perceive 
things like that. I love GWT, and I love Typescript, and I also love 
Javascript. All those are languages and tools that I choose depending on 
the context. The two worlds (Java and Javascript) have a lot to share and 
should not be - I think - always opposed one to the other. In the past I 
used to code a lot in C, C++ and x86_64 ASM but things have changed... Is 
that better or worse ? I don't know, it's different... and also the same ! 
Java will be dead one day, and Javascript will also be dead one day, that's 
just how it goes, nothing lasts forever.



Arnaud Tournier

Le jeudi 12 janvier 2017 22:43:57 UTC+1, sanny...@gmail.com a écrit :
> 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://blog.lteconsulting.fr/gwt/2016/2016/04/10/gwt-2016-en.html> 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. 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>
> Thanks.

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to