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