Re: [gwt-contrib] Re: Thoughts on DevMode

[Jens]

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

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.

-- 
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/2d70ebf2-90e3-4b78-964a-01cb862af57e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

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

-- 
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/7f03d2b8-d4ba-4a89-9443-a69df148d121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

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

-- 
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/03a35ba4-8ae1-4ae0-93fd-0a1e72f3ea48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

[stuckagain]

Thanks for the info Thomas.

On Monday, January 16, 2017 at 10:01:08 AM UTC+1, Thomas Broyer wrote:
>
>
>
> 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.
>

-- 
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/b1afd130-8829-49c8-a259-e4fb3577b2ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

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

-- 
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/d4e72a8f-b446-4d9e-9ebb-234b995949d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

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

On Sun, Jan 15, 2017 at 8:28 PM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:

> > This community needs more people *doing* stuff.
>
> 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
>
>
>
>
>
> On Sun, Jan 15, 2017 at 8:51 AM Ivan Markov  wrote:
>
>>
>> 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 

[gwt-contrib] Re: Thoughts on DevMode

[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). 
This community needs more people *doing* stuff.

-- 
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/0a0b473b-8fb5-4996-8e2f-2baa0338567a%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 

Re: [gwt-contrib] Re: Thoughts on DevMode

['Goktug Gokdogan' via GWT Contributors]

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

On Fri, Jan 13, 2017 at 7:34 AM, Kirill Prazdnikov 
wrote:

> 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
>
> --
> 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/beafcbb5-8e3e-
> 4fd3-8254-eb279307549a%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0xEfS4pnKo90zBvpdfV77irnMY6pEmfic71T3fyaQVjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Thoughts on DevMode

[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

-- 
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/beafcbb5-8e3e-4fd3-8254-eb279307549a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Thoughts on DevMode

[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







On Fri, Jan 13, 2017 at 6:52 AM CodeLess  wrote:

> 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.
>
>
>
> On Fri, Jan 13, 2017 at 12:36 PM, Thomas Broyer 
> wrote:
>
>
>
> On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, sannysan...@gmail.com
> wrote:
>
> 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.
>
>
> 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.
>
> 
>
> 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 

Re: [gwt-contrib] Re: Thoughts on DevMode

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



On Fri, Jan 13, 2017 at 12:36 PM, Thomas Broyer  wrote:

>
>
> On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, sannysan...@gmail.com
> wrote:
>>
>> 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.
>>
>
> 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.
>>
>> 
>>
>> 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?
>>
>
> 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)
>
> --
> You received this message because you are 

[gwt-contrib] Re: Thoughts on DevMode

[Thomas Broyer]

On Thursday, January 12, 2017 at 10:43:57 PM UTC+1, sannysan...@gmail.com 
wrote:
>
> 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.
>

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

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)

-- 
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/45aa1f15-c3be-407f-951e-56793bd5ddb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Thoughts on DevMode

[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



Le jeudi 12 janvier 2017 22:43:57 UTC+1, sanny...@gmail.com a écrit :
>
> 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 
> 

[gwt-contrib] Re: Thoughts on DevMode

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

-- 
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/0df0b925-befe-4b5a-ba77-702169aa5d61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.