--
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+unsubscribe@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.
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 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.</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, 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>
--
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+unsubscribe@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.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@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.
--
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-co...@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.
have been pushing for more than a year now to delete it from GWT proper too.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/beafcbb5-8e3e-4fd3-8254-eb279307549a%40googlegroups.com.
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 “inject” it back into newer typescript-like architecture, let alone to maintain the “community fork” of GWT. Community forks (maintained) are not supposed to bring in the missing fundamental parts of original project, it’s too expensive.
Stephen Haberman, this is really good, viable workaround, to abstract browser away, but this approach, among other things, reduces the role of GWT from developing framework to transpiler, and this is exactly what is my whining about. When I’m trying to find out why my presentation layer DOM element didn’t receive some DOM attribute as result of computation, this is bug in the presentation layer, which was abstracted together with browser in your approach. But I want to debug browser issues, I want to develop/debug the app which looks like html app, not generic app! BTW as advance to your approach there are projects that completely eliminate need in GWT your way, such asCodenameOne (they can compile Java to JS using TeaVM (in addition to Android/iOS) and have rich abstraction widget library) or I saw quite impressive efforts to translate Qt Quick applications to JS usingemscripten. As you will see, too big abstraction leads to web app look like, well, too abstracted from browser (they look like mobile apps). This is inevitable cost of abstraction, and your approach inherently drifts towards same (but of course much less noticeable) features.
Taking discussion further to the need of test cases covering the whole code in strongly typed language, this is religious issue, naturally solved to “having it” in your case, and as far as I can see from video demo on the site, the size of test code (excluding declaration and syntax lines) is 5-6 lines, whereas logic being tested is 3 lines, which makes this approach disputable in wide circles of developers, due to need to maintain all these tests, but this debate is behind scope of this
N.B. If I omitted some points, this is either because I missed them or agree with them.
Thank you all.
Sanny.
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.
--
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-co...@googlegroups.com.
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.
When I’m trying to find out why my presentation layer DOM element didn’t receive some DOM attribute as result of computation, this is bug in the presentation layer, which was abstracted together with browser in your approach
I want to develop/debug the app which looks like html app, not generic app!
the size of test code (excluding declaration and syntax lines) is 5-6 lines, whereas logic being tested is 3 lines
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
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.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANnRKuWxn6c2xeCBFu_3S5jhABLrMRT11GcqnEKrM8DO3RkTXg%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
Speaking of j2cl and GWT 3.0 it would be nice if somehow the development did not happen behind closed doors.It would give us a better indication of where it is heading. I feel a bit anxious about the future because of this.
But this is still handwaving for now, as nobody outside Google has seen J2Cl yet (the Steering Committee, and probably select contributors, should have an early access to it in the coming weeks/months, to have a better sense of how GWT 3 could look like, and possibly help in the opensourcing process –particularly about using it outside Google, e.g. with Maven/Gradle)
And please, Gradle ;)