[gwt-contrib] Thoughts on DevMode

[sannysan...@gmail.com]

Hello, GWT people.



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 
 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 

 
"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.



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 
, 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? Or javascript-transmitted disease 
finally won?

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 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/dacbb95e-7e2d-4297-af25-74133caf2073%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Thoughts on DevMode

[sannysan...@gmail.com]

Thank you, GWT people, for spending your time answering my thoughts.


To summarize (and TLDR), these were responses in the thread:


Ivan Markov: We should improve javascript-side debugging to match DevMode.

Jens: Google is busy doing other things, so no hope with gwtromium.

Jens: Change your attitude towards SuperDevMode. Also, DevMode was not so 
cool.

Arnaud: Don’t believe what I said in article! // thanks Arnaud, I’m better 
now ;)

Arnaud: TCP via localhost is fast enough

Thomas Broyer: Even moving towards Typescript in GWT architecture, there’s 
still big value of Java as language due to code reuse.

Thomas Broyer: js-java glue that was related to codeserver for DevMode is 
already in rotten state.

Stephen Haberman: Abstract away browser and debug in JVM without browser.


I will respond here in one message to each of these points:


Ivan Markov and Jens, there’s a lot more to JVM debugging that stepping and 
seeing the source. This is "drop frame", hot code reload, evaluate Java 
expression (before deciding whether I should step into or over function 
“verifyCondition(x1.var1, x2.var2)” I evaluate it in expression evaluator 
first to check whether it’s valid – not working with java code in front of 
me in IDE, when JS being evaluated). Also: breakpoint skip count and 
specified exception breakpoint; field access breakpoint; something else 
obvious so much that I even can’t specially recall. I code in java since 
long ago, and these features are just common tools for me, hardwired into 
the muscles, and this makes SuperDevMode looking like a toy. Last time I 
checked, source maps do not map even variables names (not mentioning 
scopes), and, knowing the pace of its development, I don’t give much hope 
to that. Integration of JS debugging into IDEs can't help much with all 
this. Saying all above, I see your (and similar people) favorable attitude 
towards SuperDevMode coming from both low expectations [1] of what good 
debugging is and maybe (sorry!) from excessive self-convincing that 
SuperDevMode is super, due to apparent lack of alternative (which I try to 
change by idea of gwtromium).


[1] I’m aware of two opposing attitudes toward debugging, best illustrated 
by systems-level embedded programmers which usually can afford only 
printf() and must put most effort in writing code that works correct in 
first place (this influences their thought process and attitude even after 
they move to upper levels), as opposed to high-level programmers which can 
literally edit-and-continue most of their time.


Arnaud, TCP to localhost via loopback is indeed faster then over network, 
but, in GWT, different aspect of it contributes to slowness. Let’s see for 
example large grid creation, where there are multiple calls forth and back 
(DOM creation, attributes setting etc), inside java FOR-loop. Main problem 
here is latency of single JS<-->java call, which is coming from the need to 
pass data to OS kernel during tcp transmission, here context switch occurs, 
then context switch occurs on reception of this data, and also 2 context 
switches occur on the way back. This is what contributes to the bad 
latencies, multiply by number of iterations, but same-process would speed 
this up greatly.


Thomas Broyer, about the importance of Java language value even when GWT is 
turning into Typescript. I also thought that this is cool (code reuse), 
only before I honestly checked the amount of code which is common in 
server-side and client-side gwt project. The amount of shared code in 
projects I was taking part is close to 0%, and even if some, say, 
validation rules could be reused, these are simple validations which must 
be abstracted away in higher-level declarative constructs. Yes, there are 
specific areas with clever ideas, like google spreadsheets where 
spreadsheet evaluation can occur on both sides of the network, but this is 
rare (I would like to hear more examples) in the field where GWT is used to 
build complex single-page apps for back-office needs, for example. But even 
in spreadsheets, compare the size of UI-related code with size of code 
around its model. I’m sure it will be 95% to 5% ratio. Also, I used to use 
POJO in both sides of GWT code, which contributed to “code reuse”. But when 
I moved to protocol buffers (protobuf), the domain objects became generated 
in any language, together with serialization, so code reuse dropped to 0. I 
understand, this all is MY experience, and other people have 30% code reuse 
in 800KLOC applications, but honestly, what is your percentage of code 
reuse?


Thomas, the information that DevMode code is deprecated and is being 
removed from the code base is pitiful and shows that steering board doesn’t 
understand the value of it, took the wrong direction, and GWT is heading 
into oblivion because of wrong decision. The initial DevMode code is/was 
deeply integrated throughout all GWT code up to the GWT.isScript(), so it 
will be quite difficult to “inj