Thoughts on DevMode

[sanny...@gmail.com]

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>

Thanks.

[CodeLess]

I agree 100% with everything you said. I was thinking exactly about this idea (when I first saw dartium). I was wondering why it's not done in gwt the similar thing long time ago (DevMode with special version of Chromium) ? SDM in Chrome or Eclipse (with sdbg) is nothing comparing to DevMode. It does not really replace DevMode it's just a bad hack that I personally don't find useful at all. It's faster than DevMode, but that is it. It's not really a debugger if you are not able to watch Java expressions and variables, it looks more like some kind of hacking than debugging. I still prefer to use DevMode with Mozilla 26 and IE11 than the latest Chrome and it's source maps (so called) "debugger".

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

[Ivan Markov]

I agree that the debugging experience of GWT can be improved.

That might happen either by trying to resurrect DevMode by hacking on Chromium and the JVM, or by implementing Java watch expressions and conditional breakpoints in Chrome Devtools / Eclipse SDBG.

I think the second approach might be easier, but it will require hacking on GWT itself, because evaluation of Java expressions in the debugger would need support from the compiler. That might be easier to do with J2CL once it is out. Let's see - rumor goes, initial beta or something is expected this quarter...

[Jens]

Sorry but this will very likely never happen unless you do it yourself together with other interested people and manage it on Github as a community project. Google (GWT's main committer) invests in J2CL + Closure Compiler in the future so they won't do it and current contributors will likely favor SDM and don't want to manage a custom chrome build (at least that is my impression).

I think you never really dived into SuperDevMode. Take GWT 2.8, start SDM with -style PRETTY and disable sourcemaps in Chrome to see the real JS. Now search for any method name and take a look how GWT sets up classes and methods in JS. Once you understand that (really easy to understand the basics) you can easily find what you are interested in, use watch expressions and set conditional break points. You can also hover variables to see their content if you do not use sourcemaps. Given that GWT doesn't really optimize the JS code all the Java methods in your project will look pretty similar in JS. If J2CL plays out nicely and GWT 3 will be build around it, then the generated JS will likely even more look like Java as it will use ES6 JavaScript classes. So the need for sourcemaps (and its disadvantages) during development will be questionable.

DevMode had its time, I never really missed it. It's slower than SDM, you can not use it do develop directly on mobile devices (granted with SDM and a certain app size its also not possible because the SDM JS is so large that it crashes the mobile browser), DevMode had executed Java code in JVM which sometimes had different behavior than the compiled JS which could lead to bugs in production you can't reproduce in development unless you compile your app. IMHO SuperDevMode is superior to DevMode once you make yourself comfortable with Chrome and its DevTools.

The only sad thing is that SDM still has some hard to reproduce bugs that every now and then show up during development which require you to cleanup the cache and start fresh.

-- J.

[Arnaud TOURNIER]

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.

Peace,

Thanks

Arnaud Tournier

[Thomas Broyer]

On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, sanny...@gmail.com wrote:

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.

You're right, GWT turns more and more into a TypeScript/Dart-like, with one major difference: the input is Java.

This means it can run in a JVM, i.e. be shared with your server-side code and/or your Android native app, and possibly transpiled to ObjectiveC for use on iOS (which is exactly what Google does: sharing 70% of code between all versions of Inbox, sharing Google Sheets formulas' parsing –and execution?– between client and server –and Android?–, etc.)

With Dart or TypeScript you need to bring a DartVM or JS Engine to run the code.

And that's without talking about the tooling you get with Java too, that has to be rebuilt for all those newer languages (linting, refactoring, code generation by analyzing the AST –annotation processing– etc.)

 

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>

It makes total sense, but as Jens said, it's unlikely to happen unless people organize and make it happen (FWIW, JavaFX, if it ships with a recent/decent-enough version of WebKit, is probably the way to go here).

There are hitches though: Google no longer maintains the DevMode code and JsInterop doesn't work there; they actually already deleted that code internally and have been pushing for more than a year now to delete it from GWT proper too. This means that for DevMode to be "resurrected", someone would have to step up and actively maintain the DevMode code (CompilingClassLoader, with its special logic for super-source and JSNI) and enhance it so it supports JsInterop. So it's not just a "browser/plugin" issue.

(note that in GWT 2.8, GWTTestCases now run in "prod" mode by default, that was one step towards deleting DevMode entirely from the codebase)

[CodeLess]

IMHO @Ivan's second suggested approach would be a perfect solution: "implementing Java watch expressions and conditional breakpoints in Eclipse SDBG".

Hopefully this will be possible to realize and hopefully gwt contributors/maintainers will be willing to cooperate with @Ivan about this idea.

--

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.

[Stephen Haberman]

FWIW my answer to "I want a really awesome debugging experience" is that you shouldn't be doing any debugging in the browser in the first place, e.g. whether it's old-school DevMode or SuperDevMode or Typescript etc.

This is what Tessell allowed (apologies for the self-promotion, although I am mentioning it less as "you should go use it" and more as "no really this approach is technically possible and works well") by stubbing out the DOM with pure-Java equivalents.

Granted, you're now running against an abstraction level, so without a browser (e.g. in a pure Java unit test) you can't do any pixel calcs or intimate rendering logic, but the majority of your app shouldn't be doing that anyway (or any at all since most munge-pixels-with-JS can be done by adding/removing CSS classes these days).

With Tessell (or whatever Tessell equivalent), you can get to the point where 95% of your development time is in pure Java unit tests, running your presenters, your views, whatever, as regular Eclipse-is-none-the-wiser JUnit tests, and making sure "yeah, the DOM 'looks' like I think it should" (where 'look' is not you-see-it-with-your-eyes, but the-markup-matches-what-I-want) . Then the final 5% of your development time is popping open the browser, and tada it will all magically work.

If it doesn't, yeah sure, you spend ~5-10 minutes in SuperDevMode/sourcemaps figuring out why, but then as soon as you reproduce it, you usually can reproduce it in a pure-Java unit test against your DOM abstractions, and you're back to an amazingly quick TDD cycle; no sourcemaps, no browser debugger, no waiting for DevMode or SuperDevMode to load.

So, that is my answer to "I really want old-school DevMode": you should put the right abstractions in place to where your app is not coupled to the browser in the first place. If you're coupled to the browser, you've already lost IMO.

(Granted, if you've already got a large codebase that is not written against this sort of abstraction, it's not going to be easy to move, so this is probably not very helpful to you.)

- Stephen

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.

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

[Kirill Prazdnikov]

have been pushing for more than a year now to delete it from GWT proper too. 

Are there any updates on that ? 

Is there some patch for review ? 

Thanks

[Goktug Gokdogan]

Small correction: Google is not planning to delete dev-mode from GWT proper. That's community's decision based on how the would like to move forward with GWT 3.0.

Wrt. J2CL; pls don't expect a beta release of J2CL this quarter. Also J2CL doesn't even have devmode since transpilation is instant (think java).

--

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.

[sanny...@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 “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.

[Ivan Markov]

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>

[Stephen Haberman]

> <rant>This community needs more people doing stuff.</rant>

Agreed (although I'm calling the kettle black here).

I think historically GWT was really hard to contribute to; as you said, it was a single toolkit, and had a lot of complexity in it (non-trivial optimizations, non-trivial old browser support, etc.).

My hope is that the just-a-transpiler approach of j2cl will also make it easier for a community to spring up around it. (And for separate small communities to spring up around whatever j2cl-based RPC, j2cl-based UI, j2c-based etc. libraries and frameworks come along.)

- Stephen

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

[Stephen Haberman]

I'll try to keep it short...

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

Yes, you can assert/debug against presentation-layer/DOM element values with a Tessell-style approach very easily, as that's the whole point (asserting that when user does X on DOM element Y, then the DOM looks like Z).

Tessell (or similar) does not replace/remove the presentation layer, it just decouples it from the browser, by replacing the C++/whatever DOM impl (that you only get if you boot up Chrome or FF or PhantomJS or what not) with a pure-Java DOM(-ish) impl.

I want to develop/debug the app which looks like html app, not generic app!

Tessell (or other "modern GWT") apps are just HTML apps, they do not use the generic UI widgets like the Qt/mobile things you mention; see the todomvc example which looks like every other todomvc impl. It's all markup + CSS just like Angular/Ember/etc.

the size of test code (excluding declaration and syntax lines) is 5-6 lines, whereas logic being tested is 3 lines

Unit tests in Tessell projects are unusually small/simple from what I've seen (primarily due to using stubs, they don't have a lot of the repetitive when/when/when setup that comes with mocks), but if you're using a "unit tests add too much code to maintain" line of thought, then you're probably not going to be writing tests anyway. Which probably explains why you need such a great debugging experience. :-D

- Stephen

[David]

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.

I do think GWT 2.8 is a great step forward and cutting all the old stuff that no longer makes sense is also very good and the JsInterrop makes it really easy to directly target JS libs.

But we are now more than a year further down the road and we still don't see any public roadmap and concrete presentation on where this is going.

There is not a lot of activity on the public GWT github repo, nor on the eclipse plugin (reported a few issues last year).

Anyway, back to the debugging experience. I switched to SDM some time ago and I like it a lot. It is a very efficient workflow in most case. If you see what people nowadays need to do to do pure JS development, I don't think they are much more light weight than GWT anymore.

I miss some of the debugging features that I am used to in eclipse but in reality I don't really need those features a lot. In Java those features might be more used because we are writing multihreaded applications on it, but in JS those kind of complicated issues do not really exist. So my needs for debugging features are limited.

In the end we are targetting the browser with JS, CSS and HTML as the native language. You cannot expect to stay shielded from those details in all cases.

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 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/CANnRKuWxn6c2xeCBFu_3S5jhABLrMRT11GcqnEKrM8DO3RkTXg%40mail.gmail.com.

[Thomas Broyer]

On Monday, January 16, 2017 at 9:29:30 AM UTC+1, stuckagain wrote:

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.

J2Cl is a Google project.

AFAIK, they don't/didn't want to opensource it too early because they're not ready to deal with external feedback and building a community, etc. First impression matters and they don't just want a "code drop" that nobody outside Google would be able to test or even build. They first didn't want to opensource it before they were sure that it was viable; they're now using it on Docs and Slides (and maybe Inbox too) so they're moving forward.

Because Google (googlers please correct me if I'm wrong) eventually want to move all their projects out of GWT (2.x) and towards J2Cl (it'll take time, maybe 2 years, who knows; and in the mean time, GWT 2 will still have support from Google), and because the GWT Compiler is a complex thing that almost only Google ever touched; the Steering Committee (please other members correct me if I'm wrong) decided that GWT 3 would be (re)built on top of J2Cl, iff that was possible (I don't have much doubts here) and with a good developer experience (Google has specific tools that make their DX much different from what the rest of us can experience).

This is a Steering Committee decision, a "community" decision, not a Google one. Actually, we should expect Google to not even use GWT 3 per se, but only J2Cl and compatible libs; GWT 3 really being a "community" project (and Google still being part of it as providing J2Cl and sharing libs). 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)

So, we all want to see J2Cl, but keep in mind that J2Cl is not (and will not be) a "community project", it will be (and stay) a Google open source project (that GWT will use).

Google decides when it's OK to opensource it (they actually started the process, but it has to go through the legal department, etc.), then the GWT Steering Committee will decide whether and how to use it.

This is all I know as of today¹. I too am eager to see J2Cl, though I already have some ideas on how GWT 3 could use it.

¹ Well, actually, we know that J2Cl is invoked similarly to JavaC, and they there's no notion of "super source": you just put the "emulated sources" in the "source path" in place of the "JVM-only sources". This means we could possibly keep the gwt.xml in GWT 3 and have it "drive" J2Cl by passing the appropriate "source path" (and depending on how it works at the API level, maybe reuse the ResourceOracle). This will have to be decided, later, when we actually see J2Cl and can start playing with it a bit.

[stuckagain]

Thanks for the info Thomas.

[Jens]

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)

That would be great. Not only for GWT to finally start thinking about how GWT 3 tooling on top of J2CL could look like but also for J2CL to get some limited feedback from the outside world. And please, Gradle ;)

-- J.

[Thomas Broyer]

On Monday, January 16, 2017 at 10:29:01 AM UTC+1, Jens wrote:

And please, Gradle ;)

J2Cl itself will likely be built with Bazel (given that even Dagger et al. are moving from Maven to Bazel, I don't think we want to invest in maintaining a non-Bazel build –contributed by "the community"– in parallel to Bazel –contributed by Google–), and our goal as a community will be to help Google distribute it on Central.

Calling J2Cl from Gradle should be a no-brainer.

As for GWT 3, if you ask me, it'd be a "rebuild", using either Bazel or Gradle, rather than an evolution of the current repo.

I'll probably leave it to someone else to build a Maven plugin for using GWT 3, unless my existing plugin works out-of-the-box (depends what tooling GWT 3 will provide), but would happily contribute to a Gradle plugin (the hardest part actually is deciding on a "standard" project layout; this should be done by a specific "working group", not unilaterally by an individual).

[Jens]

Yeah I meant GWT 3 with Gradle, not so much J2CL. And yes I would definitely start with a new repository for GWT 3 and a separate repository for Java emulation that can be used with J2CL without GWT tooling on top of it. Given that 2.8 will live pretty long I think it's better to fork the emulation into a separate repository because GWT3 / J2CL should not be hold back from moving forward integrating new emulation which might require new syntax in the future. Yes that would possibly mean back porting emulation for 2.8.x if someone needs it but I think that is fine (if it ever happens)

Not sure how comfortable you can import a Bazel project into any IDE these days, I guess Gradle is still far ahead. Also conventions help you keep the repo clean and consistent.

-- J.