>
>
> 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.
>
>
>
I openly admitted that the current GWT debugging experience sucks so I'll 
pass on your Java-debugging-is-so-much-better eye opener.
As for GWT "no longer stretching the limits"... while I sympathize your 
emotions, the battle is lost. A single toolkit can't possibly keep up with 
all the innovation on the JavaScript front, so they either need to have a 
very good jsinterop + lightning fast transpiler (ASAP!!), or Java in the 
browser will die.

Now to the concrete topic of GWT debugging:
Unfortunately, Google seems to have other priorities right now so we are on 
our own for anything besides the core compiler (cough, transpiler). 
So as Jens said - screaming out loud won't help. If you really want to make 
a difference - invest your time, swim against the current and prototype the 
gwtromium thing (or help improve the sourcemap debugger - a lost of what 
you mention about native Java debugging is possible to implement with 
enhancements to the sourcemap debugger). 
<rant>This community needs more people *doing* stuff.</rant>

-- 
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/0a0b473b-8fb5-4996-8e2f-2baa0338567a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to