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 “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 <https://www.codenameone.com/demos/Pheonix/> (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 <http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos>. 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. -- 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/e104b24d-6bc0-433e-8998-e5faae100efb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
