subject:"\[gwt\-contrib\] Re\: Business proposition of GWT 3.0 \- what is it good for vs. other solutions out there\?"

@James: I am interested and may be able to help if you open source it. 
However, there are integration issues with respect to GWT 3 noted above, in 
the rest of the thread. Please do read it when you have time.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2aabe623-ca5d-4f52-b4de-b607e458d5ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-24 Thread James Nelson

Have not read the whole thread yet, but just wanted to point out a few
small things.

First, whole-world compilations and transforms are something I've been
working on as a replacement for generator subsystem since I heard it was
dying a couple years ago.
I have a toy implementation working with java 8 javac compiler plugins,
though it looks like that is going away now that java 9 modules exposes the
compiler in a more powerful / official capacity
(I have a commit w/ java 9 support already, btw).

>From these experiments, I can conclude that it is possible to get typesafe
whole-world analysis out of your standard javac process, and do ...anything
you want.
The whole-world part does involve forcing javac to reconsider referenced
types, and so will be slower than standard javac... but it is, indeed
possible.

My main use cases were a GWT.create-like replacement; I have a prototype
able to slurp up the class literals the same (or better) than stock GWT (I
also run a fork of GWT 2.X that does other magic-method-magic),
which can then run replacement rules that generate code (completely
different AST, and no TypeOracle just yet, but all things are possible with
time). I didn't bother w/ gwt.xml support yet, as it was just a toy to see
if it was possible (it is).
My other main use-case was a new ui-templating library to replace the need
for ui binder;
the solution I came up with includes a DSL that generates cross-platform
view components for web and javafx... android and ios will likely get a
kotlin target someday,
but it could easily be stripped down to something that emits artifacts
suitable for webpack et al.

Both of these efforts have prototypes laying around that could be cleaned
off if there was significant community interest,
but it's hard to spend lots of time on these things when I've also got a
day job and an infant at home :-)

So, while I'm not promising I can magically deliver everything that will go
missing overnight, it is possible, and there are other members of the
community who are interested.
However, to get production-ready support and testing, this would likely
need to be a fulltime effort.

*Do ye dissatisfied members of the community think it possible that support
contracts for GWT 2.X and porting of features into GWT 3.X would be viable?*

While I'm currently happily employed,
I would certainly consider working on fulltime support for these
replacements *if* it could occupy my working hours rather than my scant
hours of rest.

If your mission critical applications depend on keeping up to date with
latest GWT versions but need older GWT features,
well... somebody has to put in time, and it's not looking likely that it's
going to come for free from community members' spare time.

In reality though, existing applications can stay on 2.X for a long time,
provided odd compiler bugs get worked out.

While I can find a night here or there to fixup things like sysprops not
generating permutations correctly (took about 5 hours work),
I also have my own projects on top of work and GWT community and family, so
I'm stretched pretty thin.

PS -> I already maintain an open source fork of GWT which includes support
for reflection and arbitrary magic method injection.
I did not even try to get these merged upstream because they move in the
opposite direction of GWT (I was going for more magic, and they for less);
my long term game plan is to get my extra bells and whistles pulled into
the javac plugin system (with my other prototypes in that area), so I can
prefer J2CL as well.

While I will get to this eventually, if there is enough motivation to pay
to get to it in a hurry, I think there is enough willing talent to pull off
...whatever we want. :-)

--
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/9f7563ef-9774-4c86-b620-46bd6259f24a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


On Wednesday, May 24, 2017 at 3:41:13 AM UTC-4, Thomas Broyer wrote:
>
> It indeed does use  and  from gwt.xml files to 
> subset/superset the compilation classpath, but it does *not* take the 
> EntryPoint into consideration; not at that point.
> First generators are run and generate code, then only things are optimized.
> So a pre-compilation analysis would "only" have to possibly subset the 
> compilation classpath (though ideally you'd separate out what's not 
> "translatable" and just not put it in the classpath at all; actually, 
> afaik, j2cl has a similar "interface" as javac where you explicitly list 
> the files to translate, so that's work that'll have to be done anyway, 
> though GWT 3 might do it for you, keeping the gwt.xml files; this is part 
> of the "we don't know what GWT 3 will look like" bucket).
> That being said, if you agree to whitelist classes in annotations on the 
> RemoteService interfaces (similar to the @ExtraTypes of RequestFactory), 
> then this processing step could possibly be an annotation processor rather 
> than a separate pre-processing tool/step.
>

Well, as I noted earlier... to efficiently generate code and not have to 
generate it for the whole world, I need to perform reachability analysis 
before I generate it, which means before J2CL does its thing. Hook would, 
thus, have to be in the appropriate place. As for whitelisting, the goal is 
to do *at least as good as GWT RPC* and better with whitelisting. 
Specifically, no whitelisting would be needed for the apparent, declared 
types of classes that are observed communicated. This can be determined 
with no additional annotations.I can do even better because I can analyze 
code and see which subtypes of those may be possible as well and include 
those automatically. Whitelisting comes in addition to that to state 
possible subtypes from the code that isn't analyzed - e.g. the server code.


> Tooling can help here (you can already do that with GWT 2.x by calling 
> ModuleDefLoader/ModuleDef in your code; and those kind of use-cases might 
> become a good reason to provide a CLI tool producing a list of files or 
> patterns out of a gwt.xml that you could feed to other tools; see however 
> the comment above about "we don't know what GWT 3 will look like")
>
That's GWT 2.x ... I don't know what will survive in GWT 3.0 or in what 
form. I also don't need any of this in 2.x.
 

> IDEs ("on save" actions), build tools (e.g. Gradle continuous build 
> ) or 
> other watchers (watchman, modd, etc.) can help here.
> Though if you change any class that's shared with your server, you'd have 
> to redeploy the webapp too (with current DevMode's embedded server, that 
> means clicking the "reload server" button); so possibly that step would 
> better be manually triggered (YMMV)
>
> Yes, that is what I noted but I also explained what this does to the 
experience. Also what will happen if someone clicks to refresh while the 
code is being regenerated? Not nice.
 

> As said previously, one criticism of Google against the current GWT 2.x 
> architecture is that it "does too much", and part of the j2cl effort is to 
> split things into smaller and simpler tools, replacing some of them by 
> existing tools, and (from Google's point of view) leveraging their build 
> system (that promotes small compilation targets and provides fast 
> incremental builds and continuous rebuilds – the latter is not yet 
> opensourced into Bazel afaict).
>
"Too much" is relative. I agree that it did too much for most, because it 
always did all. But if something saves you time (via reduced development 
effort, resulting manually written code size, etc) or is a downright 
compatibility issue, then it isn't too much. I am not asking it J2CL to do 
it. I repeat, all I need is the ability to have bits and pieces of what 
some need (and others think of too much) pluggable into this externally. 
Some may want to plug in UI binder (I don't), for example. You plug the 
right pieces you need and you get exactly the right amount of stuff - the 
Goldilocks zone :)

 

> One thing that we need to do for GWT 3 is to somehow "package" those 
> separate tools into an easy-to-use product (think polymer-cli and the 
> like), so maybe GWT 3 will introduce its own daemon to monitor source files 
> and trigger some actions before feeding them to the j2cl+closure-compiler 
> toolchain, or maybe not.
>
Yes, something like that. 

-- 
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/575be67e-273b-4bf5-bc78-21548a72e208%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?



On Wednesday, May 24, 2017 at 4:06:25 AM UTC-4, Thomas Broyer wrote:
>
> Open-sourcing j2cl takes time (see 
> https://opensource.google.com/docs/releasing/ , we've been told it's 
> currently in the "getting approval" phase), more time than for 
> jsinterop-generator or elemental2.
> But no work on GWT 3 will happen before j2cl is open sourced (maybe some 
> of us steering-committee members and core contributors will have access to 
> a private repo so we can start thinking about how to build GWT 3 using it; 
> but no open-source work will likely happen before j2cl is itself open 
> source, and this is specifically why we're still in that "we don't know 
> what GWT 3 will look like" situation).
>

Yes, I understand and am afraid precisely of *all* that.
 

> BTW, for now, the only "hook" that has been identified is a way to get 
> access to private fields (others, like Errai CDI, might want access to 
> private constructors and private methods too).
>
At least something but the form of the hook will influence how well things 
can be done otherwise, see my previous post. 
 

> This could possibly come in the form of a "contract" in j2cl in the 
> "shape" of the ES6 classes it produces and how it represents private 
> members there;
>
and then possibly using jsinterop-base, 
>
That would be (4) from my short list of possibilities. While possible, this 
is less desirable approach than (2) as per my explanation.
 

> or creating a dedicated API based on that contract)
>
Yes, something like that is what I would like. I am not asking J2CL to 
perform any analysis including reachability - I must do it. But I need to 
be able to do it as/when needed. 
 

-- 
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/8202e78c-b9f9-488f-bb40-aeaa2b422a71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
>
> My point is simply if the Java->JS compiler is moving to separate 
> compilation, 
>
Well, that is why we are having this discussion.
 

> having hooks in it cannot help you if the things you want require 
> whole-world analysis. 
>
It actually can, as I noted above, saving duplication of configuration 
processing. Otherwise, yes, I could do some global analysis.
 

> If the reachability analysis is done at a later "linking" stage, then 
> clearly that cannot be available at the compilation stage.
>
 Again, that is why we are having this discussion. I need to be able to do 
reachability analysis together with the code generation ne to have any 
chance of this performing well. And the problem is that if code gen must 
happen before J2CL and reachability analysis and optimization later then 
this can't really be done. Now, I am not saying that J2CL has to do the 
reachability analysis - but I need to be able to do it at the right time 
within it.
 

> So I think what you want is fundamentally incompatible with the separate 
> compilation direction.  That means that either GWT3 is not for you or you 
> will have to build an external tool that basically does much of what the 
> existing GWT compiler does now to get what you want.
>
Hence all my comments. Why should GWT3 go into such a direction that it 
makes it incompatible for me, an existing GWT user, or for any existing GWT 
user. Sure, it can split things away, but it can allow things to be done 
externally.

-- 
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/122671f7-1ad6-462e-8c4a-369574362cba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-24 Thread Thomas Broyer

On Tuesday, May 23, 2017 at 9:57:35 PM UTC+2, Learner Evermore wrote:
>
> J2Cl will be a Google project (not a GWT project; actually not dissimilar 
>> to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be 
>> open source and accept external contributions too.
>>
> I didn't think much of this when I read this the first time but I just 
> realized that for J2Cl you say "it*'ll* be open source...", meaning it 
> isn't yet... and it is likely the place where the modifications need to be 
> made to, at the very least, expose necessary hooks to make things possible. 
> That makes it impossible for the community to help (before it is open 
> sourced).
>

Open-sourcing j2cl takes time (see 
https://opensource.google.com/docs/releasing/ , we've been told it's 
currently in the "getting approval" phase), more time than for 
jsinterop-generator or elemental2.
But no work on GWT 3 will happen before j2cl is open sourced (maybe some of 
us steering-committee members and core contributors will have access to a 
private repo so we can start thinking about how to build GWT 3 using it; 
but no open-source work will likely happen before j2cl is itself open 
source, and this is specifically why we're still in that "we don't know 
what GWT 3 will look like" situation).
BTW, for now, the only "hook" that has been identified is a way to get 
access to private fields (others, like Errai CDI, might want access to 
private constructors and private methods too). This could possibly come in 
the form of a "contract" in j2cl in the "shape" of the ES6 classes it 
produces and how it represents private members there; and then possibly 
using jsinterop-base, or creating a dedicated API based on that contract)

-- 
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/2e12d114-d4d5-497f-9dd8-5c487494f18e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-24 Thread Thomas Broyer

On Wednesday, May 24, 2017 at 7:14:52 AM UTC+2, Learner Evermore wrote:
>
> ... continuing the above - there is more. Let's now come back to the 
> analysis part. Yes, it is possible to do the "whole-world analysis" outside 
> the compiler. But what perspective should the analysis take? It is 
> irrelevant if it cannot reduce the number of possible classes - we don't 
> want all of Java runtime library in there, for example. We need to discover 
> which parts are needed from the code that *could* be executed. GWT 
> determines this based on entry points and other configuration in the 
> *.gwt.xml files **and** what it finds in the compilation classpath, as 
> configured, including its own version of the standard library.
>

Actually, no.
It indeed does use  and  from gwt.xml files to 
subset/superset the compilation classpath, but it does *not* take the 
EntryPoint into consideration; not at that point.
First generators are run and generate code, then only things are optimized.
So a pre-compilation analysis would "only" have to possibly subset the 
compilation classpath (though ideally you'd separate out what's not 
"translatable" and just not put it in the classpath at all; actually, 
afaik, j2cl has a similar "interface" as javac where you explicitly list 
the files to translate, so that's work that'll have to be done anyway, 
though GWT 3 might do it for you, keeping the gwt.xml files; this is part 
of the "we don't know what GWT 3 will look like" bucket).
That being said, if you agree to whitelist classes in annotations on the 
RemoteService interfaces (similar to the @ExtraTypes of RequestFactory), 
then this processing step could possibly be an annotation processor rather 
than a separate pre-processing tool/step.

> So, the pre-compilation analysis tool would have to configured exactly the 
> same and process exactly the same configuration as the GWT compilation 
> step. This would have to evolve in lockstep with GWT. It would also be 
> doing the same processing and analysis that GWT already has to do - at 
> least the step of deciding which bits of code to convert to JavaScript 
> before any further optimization.
>

Tooling can help here (you can already do that with GWT 2.x by calling 
ModuleDefLoader/ModuleDef in your code; and those kind of use-cases might 
become a good reason to provide a CLI tool producing a list of files or 
patterns out of a gwt.xml that you could feed to other tools; see however 
the comment above about "we don't know what GWT 3 will look like")

> Are we done with that? Whether or not you think that this still can or 
> should be done outside and with no integration with J2CL, let's move on to 
> the debugging. How about *any* dev mode where the code is to be 
> automatically updated on demand? What event signifies that demand? When can 
> we trigger that analysis and code gen step before, say, the Super Dev Mode 
> of the future gets hold of the code? Again, without any ways to hook into 
> that, we'd be relying on the analysis and code generation already having 
> been done by the time SDM has to do anything with it and that means either 
> manual triggering or something like "on save", if that can be monitored 
> (not reliable). And how would that pre-step be configured by the developer? 
> Duplicating configuration but possibly in a different way?
>

I'd say yes (this is my own opinion, also see "we don't know what GWT 3 
will look like" above).
This is not much different from annotation processors actually.
IDEs ("on save" actions), build tools (e.g. Gradle continuous build 
) or other 
watchers (watchman, modd, etc.) can help here.
Though if you change any class that's shared with your server, you'd have 
to redeploy the webapp too (with current DevMode's embedded server, that 
means clicking the "reload server" button); so possibly that step would 
better be manually triggered (YMMV)

As said previously, one criticism of Google against the current GWT 2.x 
architecture is that it "does too much", and part of the j2cl effort is to 
split things into smaller and simpler tools, replacing some of them by 
existing tools, and (from Google's point of view) leveraging their build 
system (that promotes small compilation targets and provides fast 
incremental builds and continuous rebuilds – the latter is not yet 
opensourced into Bazel afaict).
One thing that we need to do for GWT 3 is to somehow "package" those 
separate tools into an easy-to-use product (think polymer-cli and the 
like), so maybe GWT 3 will introduce its own daemon to monitor source files 
and trigger some actions before feeding them to the j2cl+closure-compiler 
toolchain, or maybe not.

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

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread John A. Tamplin

On Wed, May 24, 2017 at 1:14 AM, Learner Evermore <
learner.everm...@gmail.com> wrote:

> ... continuing the above - there is more. Let's now come back to the
> analysis part. Yes, it is possible to do the "whole-world analysis" outside
> the compiler. But what perspective should the analysis take? It is
> irrelevant if it cannot reduce the number of possible classes - we don't
> want all of Java runtime library in there, for example. We need to discover
> which parts are needed from the code that *could* be executed. GWT
> determines this based on entry points and other configuration in the
> *.gwt.xml files **and** what it finds in the compilation classpath, as
> configured, including its own version of the standard library. So, the
> pre-compilation analysis tool would have to configured exactly the same and
> process exactly the same configuration as the GWT compilation step. This
> would have to evolve in lockstep with GWT. It would also be doing the same
> processing and analysis that GWT already has to do - at least the step of
> deciding which bits of code to convert to JavaScript before any further
> optimization.
>

My point is simply if the Java->JS compiler is moving to separate
compilation, having hooks in it cannot help you if the things you want
require whole-world analysis.  If the reachability analysis is done at a
later "linking" stage, then clearly that cannot be available at the
compilation stage.

So I think what you want is fundamentally incompatible with the separate
compilation direction.  That means that either GWT3 is not for you or you
will have to build an external tool that basically does much of what the
existing GWT compiler does now to get what you want.

-- 
John A. Tamplin

-- 
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/CAM5k6X-4sYX9-_rYTsQhB%2B1O%2Bc44iKyeJTGO84f7rakCmBkitQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

... continuing the above - there is more. Let's now come back to the
analysis part. Yes, it is possible to do the "whole-world analysis" outside
the compiler. But what perspective should the analysis take? It is
irrelevant if it cannot reduce the number of possible classes - we don't
want all of Java runtime library in there, for example. We need to discover
which parts are needed from the code that *could* be executed. GWT
determines this based on entry points and other configuration in the
*.gwt.xml files **and** what it finds in the compilation classpath, as
configured, including its own version of the standard library. So, the
pre-compilation analysis tool would have to configured exactly the same and
process exactly the same configuration as the GWT compilation step. This
would have to evolve in lockstep with GWT. It would also be doing the same
processing and analysis that GWT already has to do - at least the step of
deciding which bits of code to convert to JavaScript before any further
optimization.

Are we done with that? Whether or not you think that this still can or
should be done outside and with no integration with J2CL, let's move on to
the debugging. How about *any* dev mode where the code is to be
automatically updated on demand? What event signifies that demand? When can
we trigger that analysis and code gen step before, say, the Super Dev Mode
of the future gets hold of the code? Again, without any ways to hook into
that, we'd be relying on the analysis and code generation already having
been done by the time SDM has to do anything with it and that means either
manual triggering or something like "on save", if that can be monitored
(not reliable). And how would that pre-step be configured by the developer?
Duplicating configuration but possibly in a different way?

--
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/40f3a455-21db-4c11-94a6-0920f0d6a441%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

On Tuesday, May 23, 2017 at 9:36:45 PM UTC-4, John A. Tamplin wrote:
>
> Why is that so?  Can't you do your own whole-world analysis pass 
> independently of the compiler if that is what you want to do?  It does not 
> seem possible to have whole-world analysis in the compiler (hooks or not) 
> if the goal is to enable separate compilation at the Java layer.  So, if 
> that is important to you, it must necessarily be outside the compiler.
>

Well, think a little bit more about it yourself. Yes, I *can* do the 
analysis. I don't even need the source code for it, in fact. But what then? 
Code needs to be generated to perform (de)serialization as there is no 
reflection in the GWT client side. Fine. I could do that too but there are 
non-public fields without accessor methods (and, these are perfectly valid 
cases, and in fact, a good pattern). So how/where do you generate code that 
can both get/read and set non-public fields of any class? There are 
following ways about this:

   1. Use reflection. But reflection is not available in the GWT 
   client-side.
   2. Generate code / synthetic methods within the classes they 
   (de)serialize. But J2CL does not offer that.
   3. Re-generate ALL code so that the new copy is a superset of the 
   original - it includes both the original and new synthetic methods. 
   Essentially a Java-to-Java compiler. But this would be much slower because 
   it has to regenerate code in a file system somewhere so that J2CL has all 
   of it, including those from imported libraries. Debugging also becomes 
   interesting. You can't just generate new code to be equivalent functionally 
   - you need to actually maintain exact formatting as it was before and add 
   stuff at the end to avoid shifting line numbers. If you have nested classes 
   this becomes impossible.
   4. Like (2) but generating CL / JavaScript code instead and, thus, not 
   having the issues of (3) and even being able to bypass Java visibility 
   rules. As J2CL evolves and possibly changes how it translates Java to 
   JavaScript this would have to evolve equivalently too.

So (1) is not possible, (3) is not feasible or possible / practical and (2) 
or (4) are both OK but require hooks in J2CL to integrate with the process. 
See https://github.com/konsoletyper/teavm/wiki/Metaprogramming for such a 
hook in TeaVM. TeaVM does *not* have RPC like GWT does but it makes it 
possible for it to be implemented externally via this API.

-- 
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/ecb1909a-8789-4da5-812f-f1d27a00ddc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread John A. Tamplin

On Tue, May 23, 2017 at 8:24 PM, Learner Evermore <
learner.everm...@gmail.com> wrote:

> And again, I for one, am not calling for GWT RPC to be resurrected in 3.0.
> I don't need it. But I do need the complete serialization instead of the
> half-baked, mostly-incapable external frameworks
> needing-a-ton-of-extra-code-and-still-can't-do-it in existence today. And
> I can even code that to work much faster than GWT RPC did (I do stuff like
> that all the time) but it isn't possible without dedicated hooks within
> J2CL.
>

Why is that so?  Can't you do your own whole-world analysis pass
independently of the compiler if that is what you want to do?  It does not
seem possible to have whole-world analysis in the compiler (hooks or not)
if the goal is to enable separate compilation at the Java layer.  So, if
that is important to you, it must necessarily be outside the compiler.

-- 
John A. Tamplin

-- 
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/CAM5k6X8PsyPWaL3hHFjbMq5Xgve-7up6QWwX3xbr1jrVMWqhoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
> Yes, the GWT/J2CL Google dev team is a bit behind, or maybe everyone 
> (including GWT team at Google) were a bit too optimistic. But I am 100% 
> sure J2CL will be released and open-sourced soon. And from descriptions 
> about J2CL we have seen so far, it does sound like the right minimal 
> approach. 
>
Well, I am not entirely optimistic. I do agree that J2CL is the right 
minimal approach, I just don't agree that it should do away with things - 
it should at least have sufficient hooks to make compatibility possible (as 
it won't be there "out of box").
 

> Having said that my prediction is that GWT 3.0 plans will be quickly 
> abandoned once the community gets its teeth into J2CL. 
>
Unfortunately, I have the same thoughts.

One last point: I, many other GWTers and Google don't care about UI 
> binders, RPC, bundled Jetty servers and other failed ideas (GWT RPC=Java 
> RMI=cute, but bad idea long term) and will be unhappy if such legacy 
> baggage gets tucked into future releases of a J2CL-based product. That 
> leaves the fraction in the GWT community that has vested interest in the 
> legacy stuff to figure out way forward.
>
> That is a loaded statement and it is NOT the correct perspective of 
thinking for anything. For any large solution there will be many who don't 
care about parts of it. Sure, I do not personally care about UI binder, but 
others may have found it useful. We abandoned bundled Jetty a long time 
ago. Now, you say "and other failed ideas". The idea is NOT "failed" if you 
or someone else thinks so or hasn't found good use for it. If you take that 
approach then *everything* is a failure. People have moved off GWT because 
they no longer need Java (because JavaScript/TypeScript and other 
approaches). Both classic and super dev modes are failures. Code splitting 
is a failure because it can't deal properly with leftovers. 
Java-to-JavaScript translation is a failure because it is not debuggable or 
as fast as just coding straight in JavaScript. GWT Java emulation is a 
failure because it could not be complete. We can go on and on about that. 
Things are failures if they don't achieve their original goals and people 
don't find good uses for them, not if *someone* in isolation thinks they 
are failures. Furthermore, they are failures if they are given up on. 
Java-to-JavaScript isn't a failure because there is so much need for it.

The same is true for GWT RPC. You are just plain wrong to say that it is 
Java RMI. It did take up some things from it but it is nothing like it and 
serves a very different purpose in very different ways. Furthermore, GWT 
RPC is not what the problem is here - if someone needs it, it could be 
reimplemented - but only if another part, the serialization part of it, is 
possible. And that is not legacy baggage. The need for this very much 
exists. Some people are happy with other frameworks that do the *same thing* 
but 
can't handle some cases such as non-public fields. Wther it is RestyGWT or 
anything similar it is all about communicating between the client and the 
server. Some like readable JSON and original GWT RPC did not do it (it did 
unreadable JSON :)). But otherwise they are exactly the same. The 
communication data format was not something that needed to matter in GTW 
RPC but it could have been made to be readable JSON. It could have been 
made even to use JSInterop and map classes to JSON to a point. To me 
personally that does not matter. I don't care whether is is JSON, XML, 
binary or ThingamaWatchaCallit. Show me ONE other framework that I can give 
to it a *cyclic graph* of objects to be sent over such that it requires no 
additional code to be written and that will let me include objects of 
unspecified third party libraries and I will move to it *NOW*. The problem 
is that you *won't find it* (I really hope I am wrong here, but I know that 
I am not). Are these other things better because they use, say JSON? Fine 
with me. Are they better because you can annotate some special behaviour? 
They are not - that could have been done differently with GWT RPC only in a 
different way. Are they better because they *can't do things*? No, quite 
the opposite. Think they are better beause they "force you to think" as 
someone has mentioned? I don't understand how anyone didn't think about 
what they are communicating, whatever they are using. Maybe they got burned 
by not thinking of it first, then had the opportunity to rectify that when 
they switched away and blamed GWT RPC for it. Still think you are right? 
See if developers of RestyGWT or other such frameworks don't desire some 
ways of accomplishing the functionality and ease of GWT RPC *serialization*. 
You may be surprised.

Now, GWT RPC also has the other, ugly side, which is how services and 
methods are exposed. That was only good for minimal size services. We 
realized that early on and only tunneled through a small number of service 
methods to get the benefit of serializati

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread Hristo Stoyanov



On Tuesday, May 23, 2017 at 12:57:35 PM UTC-7, Learner Evermore wrote:
>
> J2Cl will be a Google project (not a GWT project; actually not dissimilar 
>> to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be 
>> open source and accept external contributions too.
>>
> I didn't think much of this when I read this the first time but I just 
> realized that for J2Cl you say "it*'ll* be open source...", meaning it 
> isn't yet... and it is likely the place where the modifications need to be 
> made to, at the very least, expose necessary hooks to make things possible. 
> That makes it impossible for the community to help (before it is open 
> sourced).
>
>
Yes, the GWT/J2CL Google dev team is a bit behind, or maybe everyone 
(including GWT team at Google) were a bit too optimistic. But I am 100% 
sure J2CL will be released and open-sourced soon. And from descriptions 
about J2CL we have seen so far, it does sound like the right minimal 
approach. The GWT/J2CL team at Google already followed through with 
Elemental2 and the code generators, which by the way are shared with J2CL 
(smart!). However, they do have internal customers to win first and secure 
funding, since there are several internal Google web framework teams (Dart, 
AngularJS, Polymer, etc) each one claiming to be the "official Google web 
framework", competing for limited internal funding/resources.

Having said that my prediction is that GWT 3.0 plans will be quickly 
abandoned once the community gets its teeth into J2CL. This may sound 
harsh, but is a lot better than the Cambrian explosion of JS frameworks, 
which left 99% of them as dead corpses over the web landscape.  Google 
already issued DOs and DONTs to make the GWT-->J2CL transition easier.

One last point: I, many other GWTers and Google don't care about UI 
binders, RPC, bundled Jetty servers and other failed ideas (GWT RPC=Java 
RMI=cute, but bad idea long term) and will be unhappy if such legacy 
baggage gets tucked into future releases of a J2CL-based product. That 
leaves the fraction in the GWT community that has vested interest in the 
legacy stuff to figure out way forward.


-- 
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/1fc32081-55a0-4bbe-a418-6e8733560e44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
> J2Cl will be a Google project (not a GWT project; actually not dissimilar 
> to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be 
> open source and accept external contributions too.
>
I didn't think much of this when I read this the first time but I just 
realized that for J2Cl you say "it*'ll* be open source...", meaning it 
isn't yet... and it is likely the place where the modifications need to be 
made to, at the very least, expose necessary hooks to make things possible. 
That makes it impossible for the community to help (before it is open 
sourced).

-- 
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/465435b5-3463-449e-929a-fd471355b8b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
> Just because it wasn't mentioned yet in this thread, and I think it 
> deserves some clarification: "the community" does not necessarily mean 
> "third party projects on top of GWT"; GWT is open source and contributions 
> are welcome.
>
Yes, that is how I took it. But it isn't just "roll up the sleeves and do 
it" - it requires coordination and desire to do this, some sort of common 
guidance.
 

> So, there are trade-offs everywhere.
>
Yes, of course. 

-- 
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/9b20ab16-2a49-4280-af36-e0cb0cf6cc12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread Thomas Broyer



On Tuesday, May 23, 2017 at 5:27:44 PM UTC+2, Learner Evermore wrote:
>
> @Anders Forsell: We were careful to make a good separation between UI 
> concerns in Java from the very beginning. We were very strict about this. 
> So, a "forced opportunity" to redo this isn't a benefit to us.
>
> Otherwise... if community is to help and roll up the sleeves we still need 
> some things in the core of GWT.
>

Just because it wasn't mentioned yet in this thread, and I think it 
deserves some clarification: "the community" does not necessarily mean 
"third party projects on top of GWT"; GWT is open source and contributions 
are welcome.
J2Cl will be a Google project (not a GWT project; actually not dissimilar 
to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be 
open source and accept external contributions too.
 

> Getting back to my original question - the business proposition/value 
> let's consider different reasons I can enumerate why people used GWT in the 
> past and what options they would have today:
>
>
>1. *Just wanted a typed, safe language to work with in the browser.* 
>TypeScript + JavaScript has evolved itself .. and anything below.
>
>2. *Wanted a language in which dangerous undisciplined JavaScript code 
>wasn't possible.*
>It is always possible but it may be hidden under the rug. TypeScript 
>with some validators, Kotlin and others. If you want Java, JSweet, TeaVM, 
>Dragome, Bck2Browser, JavaPoly, ST-JS... are there ... and, yes, GWT.
>
>3. *Wanted Java for sentimental reasons*
>Java, JSweet, TeaVM, Dragome, Bck2Browser, JavaPoly, ST-JS... are 
>there ... and, yes, GWT.
>
>4. *Wanted all/most of Java RE/VM semantics*
>Dragome, not sure of Bck2Browser and others. Not GWT - it may have a 
>good chunk of classes emulated but not all of the semantics.
>
>5. 
> *Wanted to share client-side code between web, mobile devices, etc. Not 
>sharing anything with the server. Will abstract the presentation layer 
>"myself". *Kotlin, TeaVM, Dragome, Bck2Browser, ...and, yes, GWT. You 
>will *not* use the HTML abstraction for all the platforms. *All* present 
>platforms, including web/HTML do widgets. Depending on HTML on all is 
>possible but, then again, it really is just a web app...
>
>6. *Same as above, but expecting that the presentation layer 
>abstraction is already present (i.e. not "Swing" approach)*
>Kotlin?
>
>7. *Sharing code between client and server*
>This gets to be fun. What code do you want to share? Do you care about 
>what language you run on the server? I am very far from being a fan of 
>node.js but many use it, and it can be used with languages that can 
>translate to JavaScript (e.g. TypeScript and others).
>
>If you want Java on the server then what code will you share? If you 
>are only going to share classes that are NOT used for communication (DTOs 
>are excluded here as they are not about code sharing but inherent 
>necessity), then you really can use anything from (4) or (5). If you want 
>to use Java communicate instances of shared classes then you either need 
> to 
>make the communication happen yourself (say via DTOs and 3rd party 
>frameworks) but you become constrained as to what you can and need to do 
>and what libraries you can use - because they need to be compatible in 
>terms of communication. If you don't want to have to worry about this, but 
>only about efficiency of communication and let the framework handle the 
>wire transfers, then there you can use GWT 2.8.1 or older (not 3.0), TeaVM 
>(you have to code a bit but it is possible) and, possibly, Dragome (not 
>sure, but it does reflection too, so it may be possible to add if not 
>already in). 
>
>
> I may have missed some solutions out there and haven't listed all those 
> that do apply in all cases but you get the point. Getting the benefit of 
> Closure optimization will be possible with any JavaScript-based solution, 
> including JSweet, TeaVM and possibly others (not Dragome as far as I know). 
> In terms of controlling UI in the web, you can use whatever fills you heart 
> with warmth if you like JavaScript approaches (Angular, React and many 
> others) with almost any of these, perhaps best with JSweet if you want 
> Java. 
>
> So what are differentiators of GWT? Repating, to an extent, my first post 
> here:
>
>
>- J2CL? Not really. The same can be applied to most other approaches 
>mentioned above.
>- JSInterop? Not really. Other approaches have other, similar and even 
>better integration (or no need for one).
>- Presentation control? Matter of taste, but if one wants to get close 
>to the metal, then there are ways to get closer and better. Widget-based 
>approach is easier/safer to work with if one is to share presentation 
> built 
>on top of them between dif

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

@Anders Forsell: We were careful to make a good separation between UI 
concerns in Java from the very beginning. We were very strict about this. 
So, a "forced opportunity" to redo this isn't a benefit to us.

Otherwise... if community is to help and roll up the sleeves we still need 
some things in the core of GWT. Without it things become essentially 
impossible for all practical purposes. Getting back to my original question 
- the business proposition/value let's consider different reasons I can 
enumerate why people used GWT in the past and what options they would have 
today:


   1. *Just wanted a typed, safe language to work with in the browser.* 
   TypeScript + JavaScript has evolved itself .. and anything below.
   
   2. *Wanted a language in which dangerous undisciplined JavaScript code 
   wasn't possible.*
   It is always possible but it may be hidden under the rug. TypeScript 
   with some validators, Kotlin and others. If you want Java, JSweet, TeaVM, 
   Dragome, Bck2Browser, JavaPoly, ST-JS... are there ... and, yes, GWT.
   
   3. *Wanted Java for sentimental reasons*
   Java, JSweet, TeaVM, Dragome, Bck2Browser, JavaPoly, ST-JS... are there 
   ... and, yes, GWT.
   
   4. *Wanted all/most of Java RE/VM semantics*
   Dragome, not sure of Bck2Browser and others. Not GWT - it may have a 
   good chunk of classes emulated but not all of the semantics.
   
   5. 
*Wanted to share client-side code between web, mobile devices, etc. Not 
   sharing anything with the server. Will abstract the presentation layer 
   "myself". *Kotlin, TeaVM, Dragome, Bck2Browser, ...and, yes, GWT. You 
   will *not* use the HTML abstraction for all the platforms. *All* present 
   platforms, including web/HTML do widgets. Depending on HTML on all is 
   possible but, then again, it really is just a web app...
   
   6. *Same as above, but expecting that the presentation layer abstraction 
   is already present (i.e. not "Swing" approach)*
   Kotlin?
   
   7. *Sharing code between client and server*
   This gets to be fun. What code do you want to share? Do you care about 
   what language you run on the server? I am very far from being a fan of 
   node.js but many use it, and it can be used with languages that can 
   translate to JavaScript (e.g. TypeScript and others).
   
   If you want Java on the server then what code will you share? If you are 
   only going to share classes that are NOT used for communication (DTOs are 
   excluded here as they are not about code sharing but inherent necessity), 
   then you really can use anything from (4) or (5). If you want to use Java 
   communicate instances of shared classes then you either need to make the 
   communication happen yourself (say via DTOs and 3rd party frameworks) but 
   you become constrained as to what you can and need to do and what libraries 
   you can use - because they need to be compatible in terms of communication. 
   If you don't want to have to worry about this, but only about efficiency of 
   communication and let the framework handle the wire transfers, then there 
   you can use GWT 2.8.1 or older (not 3.0), TeaVM (you have to code a bit but 
   it is possible) and, possibly, Dragome (not sure, but it does reflection 
   too, so it may be possible to add if not already in). 


I may have missed some solutions out there and haven't listed all those 
that do apply in all cases but you get the point. Getting the benefit of 
Closure optimization will be possible with any JavaScript-based solution, 
including JSweet, TeaVM and possibly others (not Dragome as far as I know). 
In terms of controlling UI in the web, you can use whatever fills you heart 
with warmth if you like JavaScript approaches (Angular, React and many 
others) with almost any of these, perhaps best with JSweet if you want 
Java. 

So what are differentiators of GWT? Repating, to an extent, my first post 
here:


   - J2CL? Not really. The same can be applied to most other approaches 
   mentioned above.
   - JSInterop? Not really. Other approaches have other, similar and even 
   better integration (or no need for one).
   - Presentation control? Matter of taste, but if one wants to get close 
   to the metal, then there are ways to get closer and better. Widget-based 
   approach is easier/safer to work with if one is to share presentation built 
   on top of them between different devices or of, like we do, wants to 
   abstract the foundation's appearance *and* behaviour from the code built 
   downstream from us. Availability of libraries is questionable as all those 
   that depended on GWT widgets go down the drain and have questionable future 
   support.
   - Size of code? Not really. TeaVM is close and can use the same 
   optimization tool GWT will.
   - Code splitting? Yes, if it survives, but others aren't far behind. 
   With TeaVM this may be *relatively* a simple endeavour even across 
   synchronous calls and without the "leftovers" issue.
   - Permu

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread Anders Forsell

I just want to chime in and let you know that in my case migrating away 
from GWT Material Design with UiBinder, JSNI and bundle resource in favor 
of JsInterop+Elemental 2 and the UI layer with Web Components/Polymer 2.0 
took a couple of months.

There is a growing number of reusable web components at 
https://www.webcomponents.org/, with the Vaadin components like the 
vaadin-grid worth mentioning.
In the end it made my architecture much better with a clear separation 
between the UI layer and the Model/Presenter (business logic) layers in 
Java.

See more info in my G+ post: 
https://plus.google.com/+AndersForsell/posts/NpTm1Ga8eMM

I am now looking forward to the benefits in using J2CL and hope that Google 
continues to be open and share their work with the open-source community.

Anders

On Monday, May 22, 2017 at 9:25:38 PM UTC+2, Learner Evermore wrote:
>
>
> On Monday, May 22, 2017 at 2:55:01 PM UTC-4, stuckagain wrote:
>>
>> But sometimes it is a good moment to reflect on the choices that were 
>> made. With Java 8 support in place I have the tendency to do things 
>> different anyway.
>>
>> That is only possible if:
>
> a) You have complete control over the entire codebase above GWT
> -OR-
> b) You have complete control over the entire codebase above GWT except for 
> some libraries you use but that will address this internally.
> -OR-
> c) You have completely abstracted everything (GWT *and* any 3rd party 
> libraries) from the code you don't control.
>
> Case (a) can be plenty of work but is possible.
> Case (b) could actually be less work than (a) but you may need to wait for 
> 3rd party libraries to catch up. Will GXT catch up, for example? 
> Case (c) does is plenty of work upfront and rarely done .
>
> There are those of us who fall into none of the above. We have built upon 
> GWT and have let others who build their solutions on top of our foundation 
> enjoy it too. Trouble is that, even if we decide to implement the bits 
> to-be-missing in GWT 3.0 ourselves, we can't. It isn't possible without 
> official (but non-existent) hooks into the compiler. That is for GWT RPC. 
> For widgets it is not possible for other reasons in a general case (but 
> does not directly hit me as we haven't allowed anyone else to use JSNI or 
> custom code generators- only foundation code uses a bit of JSNI where there 
> was no other choice and that's it). However, it is a great big challenge as 
> there are many GWT libraries out there that depend on this and that can't 
> work at all without multiple of those bits - some paid, some free. 
>
>

-- 
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/a1e616a1-6c8e-4ab4-a831-f46dcc166061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-23 Thread Anders Forsell

I just want to chime in and let you know that in my case migrating away 
from GWT Material Design with UiBinder, JSNI and bundle resource in favor 
of JSNI and the UI layer with Web Components/Polymer 2.0 took a couple of 
months.

There is a growing number of reusable web components 
at https://www.webcomponents.org/, with the Vaadin components like the 
vaadin-grid worth mentioning.
In the end it made my architecture much better with a clear separation 
between the UI layer and the Model/Presenter (business logic) layers in 
Java.

See more info in my G+ 
post: https://plus.google.com/+AndersForsell/posts/NpTm1Ga8eMM

I am now looking forward to the benefits in using J2CL and hope that Google 
continues to be open and share their work with the open-source community.

Anders

On Monday, May 22, 2017 at 9:25:38 PM UTC+2, Learner Evermore wrote:
>
>
> On Monday, May 22, 2017 at 2:55:01 PM UTC-4, stuckagain wrote:
>>
>> But sometimes it is a good moment to reflect on the choices that were 
>> made. With Java 8 support in place I have the tendency to do things 
>> different anyway.
>>
>> That is only possible if:
>
> a) You have complete control over the entire codebase above GWT
> -OR-
> b) You have complete control over the entire codebase above GWT except for 
> some libraries you use but that will address this internally.
> -OR-
> c) You have completely abstracted everything (GWT *and* any 3rd party 
> libraries) from the code you don't control.
>
> Case (a) can be plenty of work but is possible.
> Case (b) could actually be less work than (a) but you may need to wait for 
> 3rd party libraries to catch up. Will GXT catch up, for example? 
> Case (c) does is plenty of work upfront and rarely done .
>
> There are those of us who fall into none of the above. We have built upon 
> GWT and have let others who build their solutions on top of our foundation 
> enjoy it too. Trouble is that, even if we decide to implement the bits 
> to-be-missing in GWT 3.0 ourselves, we can't. It isn't possible without 
> official (but non-existent) hooks into the compiler. That is for GWT RPC. 
> For widgets it is not possible for other reasons in a general case (but 
> does not directly hit me as we haven't allowed anyone else to use JSNI or 
> custom code generators- only foundation code uses a bit of JSNI where there 
> was no other choice and that's it). However, it is a great big challenge as 
> there are many GWT libraries out there that depend on this and that can't 
> work at all without multiple of those bits - some paid, some free. 
>
>

-- 
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/8f66e8bc-daab-4841-a063-abb1dd430bcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-22 Thread Learner Evermore

On Monday, May 22, 2017 at 2:55:01 PM UTC-4, stuckagain wrote:
>
> But sometimes it is a good moment to reflect on the choices that were 
> made. With Java 8 support in place I have the tendency to do things 
> different anyway.
>
> That is only possible if:

a) You have complete control over the entire codebase above GWT
-OR-
b) You have complete control over the entire codebase above GWT except for 
some libraries you use but that will address this internally.
-OR-
c) You have completely abstracted everything (GWT *and* any 3rd party 
libraries) from the code you don't control.

Case (a) can be plenty of work but is possible.
Case (b) could actually be less work than (a) but you may need to wait for 
3rd party libraries to catch up. Will GXT catch up, for example? 
Case (c) does is plenty of work upfront and rarely done .

There are those of us who fall into none of the above. We have built upon 
GWT and have let others who build their solutions on top of our foundation 
enjoy it too. Trouble is that, even if we decide to implement the bits 
to-be-missing in GWT 3.0 ourselves, we can't. It isn't possible without 
official (but non-existent) hooks into the compiler. That is for GWT RPC. 
For widgets it is not possible for other reasons in a general case (but 
does not directly hit me as we haven't allowed anyone else to use JSNI or 
custom code generators- only foundation code uses a bit of JSNI where there 
was no other choice and that's it). However, it is a great big challenge as 
there are many GWT libraries out there that depend on this and that can't 
work at all without multiple of those bits - some paid, some free. 

-- 
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/5afc9334-cb0c-4827-b795-c3192d1f24b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-22 Thread David

I guess he is going through the same steps like most devs who relied on
GWT. I recognise the same reactions I initially had. We also have huge
applications build on GWT and we don't like rewriting hings that work.  But
sometimes it is a good moment to reflect on the choices that were made.
With Java 8 support in place I have the tendency to do things different
anyway.

After working iwth JsInterrop and Elemental2 (and the ability to quickly
interface with other js based widgets) I noticed that my code is much
smaller and maintainable.

Right now I still depend on UiBinder and CellWidgets, but I plan to move
too Elemento2 and possibly vaadin grid instead or bootstrap datatable.

Superdevmode is also fine in most cases. Sure sometimes it is a fight to
put a breakpoint in the right location, but with pretty mode the mapping
between js and java is very readable.

Now I just need a replacement for GWTP with annotation processors. If
needed I would even like to help out in getting it done.

On Mon, 22 May 2017 at 14:32, Paul Stockley  wrote:

> You are putting words in my mouth. Try reading my comment again. All I
> said was the approach we took was a lot faster and resulted in smaller code
> size, both of which are true. I said it came with some compromise, which
> for our use case and I suspect many others isn't a big deal. However, it
> also comes with other benefits. For example, we can easily communicate with
> non-java backends and services using the same JSON based approach.
>
> It sounds like your use case isn't applicable to this approach. Google
> have made it pretty clear they don't want to use or support GWT RPC
> anymore. To be honest they are totally in their right to do this. This is
> one of the most one sided open source projects I have seen. Virtually all
> the work has been done by google over the years. Over the last few years
> all I have seen is people complain that their use cases (RPC, UiBinder,
> etc) are being abandoned. Now is the time to step up as a community and
> actually start contributing back. Our company relies on base widgets,
> UiBinder and Resources. If google doesn't offer these going forward, we
> will help to come up with alternatives that will work with J2CL.
>
> I would suggest you gather up support from everyone who still wants RPC
> and start planning to build an alternative. It sounds like you have lots of
> ideas how to make a better version. Talk is cheap, why not make something
> happen.
>
>
> On Sunday, May 21, 2017 at 9:03:55 AM UTC-4, Learner Evermore wrote:
>>
>>
>>
>> On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote:
>>>
>>> I am really interested to hear how you can make a version of GWT RPC as
>>> fast as a pure JSON approach. We take a tree of thousands of objects and
>>> just use one JSON.parse / JSON.stringify call to deserialize / serialize
>>> which happens within the browser in C++ code. No other processing is
>>> required. We use Overlay types to access the data and that is it. In the
>>> future we will switch to JsInteop types instead of overlays, that way we
>>> only have one version of our DTO's that are used on the client / server.
>>>
>>
>> As I suspected, you are comparing apples to oranges...
>>
>>
>>1. You made dumb DTOs for this which means that you have to have the
>>code that copies data into them specifically for this purpose. And while
>>DTOs have followers for some cases they are *downright antipatterns* in
>>other cases. But we don't need to discuss that.
>>2. You either don't have/use polymorphism or have had to code around
>>that as well.
>>3. Any logic you have has to be either outside of the overlay types
>>or not polymorphic and you need to deal with that too.
>>4. You also probably excluded the cost of delayed type conversion.
>>5. How are you communicating long/Long? There are other examples.
>>6. You can't include data of a third party library unless you have
>>the means to make full copies of it and keep in sync with that.
>>7. Enjoy communicating cyclic graphs?
>>
>>
>> Then we come to the point of how much work you spend addressing the
>> above, esp. for complex types. We don't have to spend any of that. None.
>> Zilch. Nada. We have spent that time ensuring that we *never* have to
>> send so many objects even if we have to show millions (literally) and made
>> our product better overall.
>>
>> --
> 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/81724bf2-552d-4461-9f92-b6fc388f4840%40googlegroups.com
>

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-22 Thread Learner Evermore



On Monday, May 22, 2017 at 8:32:34 AM UTC-4, Paul Stockley wrote:
>
> You are putting words in my mouth. Try reading my comment again. All I 
> said was the approach we took was a lot faster and resulted in smaller code 
> size, both of which are true.
>
Where did I do that? I noted that you cannot compare approaches that don't 
yield equal amounts of functionality. I proved that these are apples and 
oranges.
 

> I would suggest you gather up support from everyone who still wants RPC 
> and start planning to build an alternative. It sounds like you have lots of 
> ideas how to make a better version. Talk is cheap, why not make something 
> happen.
>
> Try reading my comments again. I never tried to avoid work. The problems 
are that the effort really should be centralized to maximize benefit and, 
more critically in this case, it is *not possible for anyone* to make RPC 
work without appropriate hooks in the compiler. Quoting myself, excerpts 
from different posts:


   - If you are so hung up on removing GWT RPC, do so, but provide the 
   means to replace all of its functionality externally, especially 
   serialization
   - Community can only do it if the foundation allows it.
   - It isn't so much that this "creates incompatibility" as much that it 
   doesn't even begin to allow it in a remotely reasonable way
   - Yes. So, what we'd need is that this is at least allowed.
   
 

-- 
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/5a6e3d99-90b5-494a-b413-fd2734014246%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-22 Thread Paul Stockley

You are putting words in my mouth. Try reading my comment again. All I said 
was the approach we took was a lot faster and resulted in smaller code 
size, both of which are true. I said it came with some compromise, which 
for our use case and I suspect many others isn't a big deal. However, it 
also comes with other benefits. For example, we can easily communicate with 
non-java backends and services using the same JSON based approach.

It sounds like your use case isn't applicable to this approach. Google have 
made it pretty clear they don't want to use or support GWT RPC anymore. To 
be honest they are totally in their right to do this. This is one of the 
most one sided open source projects I have seen. Virtually all the work has 
been done by google over the years. Over the last few years all I have seen 
is people complain that their use cases (RPC, UiBinder, etc) are being 
abandoned. Now is the time to step up as a community and actually start 
contributing back. Our company relies on base widgets, UiBinder and 
Resources. If google doesn't offer these going forward, we will help to 
come up with alternatives that will work with J2CL.

I would suggest you gather up support from everyone who still wants RPC and 
start planning to build an alternative. It sounds like you have lots of 
ideas how to make a better version. Talk is cheap, why not make something 
happen.

On Sunday, May 21, 2017 at 9:03:55 AM UTC-4, Learner Evermore wrote:
>
>
>
> On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote:
>>
>> I am really interested to hear how you can make a version of GWT RPC as 
>> fast as a pure JSON approach. We take a tree of thousands of objects and 
>> just use one JSON.parse / JSON.stringify call to deserialize / serialize 
>> which happens within the browser in C++ code. No other processing is 
>> required. We use Overlay types to access the data and that is it. In the 
>> future we will switch to JsInteop types instead of overlays, that way we 
>> only have one version of our DTO's that are used on the client / server.
>>
>
> As I suspected, you are comparing apples to oranges...
>
>
>1. You made dumb DTOs for this which means that you have to have the 
>code that copies data into them specifically for this purpose. And while 
>DTOs have followers for some cases they are *downright antipatterns* in 
>other cases. But we don't need to discuss that.
>2. You either don't have/use polymorphism or have had to code around 
>that as well.
>3. Any logic you have has to be either outside of the overlay types or 
>not polymorphic and you need to deal with that too.
>4. You also probably excluded the cost of delayed type conversion.
>5. How are you communicating long/Long? There are other examples.
>6. You can't include data of a third party library unless you have the 
>means to make full copies of it and keep in sync with that.
>7. Enjoy communicating cyclic graphs?
>
>
> Then we come to the point of how much work you spend addressing the above, 
> esp. for complex types. We don't have to spend any of that. None. Zilch. 
> Nada. We have spent that time ensuring that we *never* have to send so 
> many objects even if we have to show millions (literally) and made our 
> product better overall.
>
>

-- 
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/81724bf2-552d-4461-9f92-b6fc388f4840%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-21 Thread Learner Evermore


>
> "Swing approach", as in javax.swing, i.e. build a UI once and run it 
> everywhere, with theming to try to blend it with the platform.
> "native UI" as in Android's android.widget.Button vs. Cocoa's NSButton or 
> UIKit's UIButton, vs. WPF's System.Windows.Controls.Button vs. HTML's 
> , i.e. build the UI with the tools native to the target platform.
>

Well, *we* don't do that. GWT widgets and the UI code that drives them that 
way is only for the web. Underlying code is shared, but not the actual 
presentation. However, the widgets do give us a level of abstraction and 
related freedom with respect to add-ons that others make for our product. 
We can evolve our product and have greater flexibility in changing how it 
looks and behaves when add-ons use our widgets as main building blocks. 
They bring main navigational and other user experience paradigms, not just 
looks which could be handled by CSS. With respect to various forms of 
buttons you mention as an example we would have abstracted that, not taken 
the javax.swing approach of reimplementing them. I do not know what others 
are doing.
 

>  Fwiw, I had started working on it almost 2 years ago, and Daniel (Kurka) 
> told me he went that path too, but eventually abandoned as it was 
> relatively easy to port generators to annotation processors. And that was 
> indeed my experience as well when porting the PlaceHistoryMapper generator 
> over to APT as aprood of concept: https://github.com/tbroyer/gwt-places
>

I like APT better over the other form of generators too. My problem isn't 
about that exactly.In our case the problem is what do we do with 3rd party 
libraries we depend on that need whatever they may and, more directly, the 
fact that we cannot generate additional synthetic (de)serialization methods 
without regenerating the entire type - and we'd need to do that to gain 
access to anything that isn't public. No, not all fields should have 
getters and certainly not setters.
 

> Btw, I'd really like it if for development only j2cl was needed, without 
> the closure-compiler pass (now that most browsers support ...
>
> I'd like the same thing for some other reasons too. I am mostly coming 
from the perspective of efficiently delivering and combining our code with 
add-on code at customer (install-time or run-time).

 

> Furthermore, how do we make the compiler generate code that accesses 
>> private fields? 
>>
>
> This is a very good question, and it seems like it would be the only 
> blocker.
>
> Yes. So, what we'd need is that this is at least allowed.

Thanks for the rest of the info.

-- 
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/c1b7fe7c-a150-4896-a6d8-e36a189e5dfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-21 Thread Thomas Broyer

On Saturday, May 20, 2017 at 2:05:22 AM UTC+2, Learner Evermore wrote:
>
>  
>>
> In our opinion, the "Swing" approach leads to an Uncanny Valley effect, 
>> and the best approach is to use "native" UI for each platform. 
>>
>
> I am not sure what do you mean by "Swing approach". Maybe you are thinking 
> of widgets? Well, the "native UI" boils down to communicating with hardware 
> and populating video memory, etc. Is that the best way? It is the fastest. 
> But it is also a lot of work. 
>

"Swing approach", as in javax.swing, i.e. build a UI once and run it 
everywhere, with theming to try to blend it with the platform.
"native UI" as in Android's android.widget.Button vs. Cocoa's NSButton or 
UIKit's UIButton, vs. WPF's System.Windows.Controls.Button vs. HTML's 
, i.e. build the UI with the tools native to the target platform.

> * Someone could make a harness that makes GWT Generator APIs to APT's APIs,
>>
>
Fwiw, I had started working on it almost 2 years ago, and Daniel (Kurka) 
told me he went that path too, but eventually abandoned as it was 
relatively easy to port generators to annotation processors. And that was 
indeed my experience as well when porting the PlaceHistoryMapper generator 
over to APT as aprood of concept: https://github.com/tbroyer/gwt-places
I haven't deleted my own code though, so I could revive it if there's a 
real demand (but there's still a need to change the "contract" to trigger 
the annotation processor from a GWT.create() call on a 
subclass/subinterface to an annotation on that subclass/subinterface, so 
I'm not sure it's really worth it; possibly as a temporary step for very 
complex generators but even for that I doubt it)

> which could allow GWT generators *that don't depend on global knowledge *to 
>> run as APT. (e.g. the I18N, ResourceBundle, and perhaps UiBinder could run 
>> under the APT environment). *GWT-RPC can't* because it requires all 
>> sources to be present, it depends on global knowledge, so it would *need 
>> a specialized preprocessing step* that depends on the transitive closure 
>> of all of your dependencies. Still doable, but not as an APT.
>>
>
> So, the compiler is going through code once but we need to make a separate 
> pass through all of it instead of interacting with it.
>

In a j2cl+closure-compiler world, the *optimizer* (from many-files-JS to 
optimized-and-bundled-JS; i.e. closure compiler) goes through all the code, 
but not the *translator* (form Java to JS; i.e. j2cl).
>From what I've been told, j2cl works at the file level directly translating 
Java to JS, so it does not (necessarily) see all the code.
The same is true to some extent with javac (though it needs to "see" the 
class dependencies, i.e. if class A uses class B, then it needs B to be 
able to compile A; afaict this wouldn't even be required for j2cl).

Btw, I'd really like it if for development only j2cl was needed, without 
the closure-compiler pass (now that most browsers support ES6 
classes: https://caniuse.com/#feat=es6-class 
/ https://kangax.github.io/compat-table/es6/#test-class ; assuming j2cl 
produces goog.require / goog.provide rather than ES6 modules, though ES6 
modules are supported in all evergreen browsers behind a flag)
That would make debugging even faster (file changes, it's translated to JS 
by j2cl, refresh the browser and you have it) and even easier! (readable 
ES6 class code matching your Java code means you don't even need to use 
source maps, and you navigate inside the code similar to how you navigate 
inside your Java code, rather than through one huge JS file containing 
everything)

Furthermore, how do we make the compiler generate code that accesses 
> private fields? 
>

This is a very good question, and it seems like it would be the only 
blocker.

So, simple questions that truly need to be *answerable* before GWT 3 can 
> have any future for us with complex products... and I think for any future 
> users too:
>
>
>1. How to *reasonably* accomplish compatibility with existing code 
>dependent on widgets (for example Sencha GXT - most should be aware of 
> that)
>
>2. How to *reasonably* accomplish GWT RPC serialization (all of it)?
>
>
> I am sure others will have other questions, like UiBinder, etc. We don't 
> use it so I don't need to ask those...
>

Yes, those are the questions that still have no answer, that *need* to have 
an answer, and that are basically waiting for us to finally get our hands 
on j2cl and start playing with it. To start to grasp how we could build GWT 
3 around it, what kind of toolchain to build (one integrated piece of 
software, or rather build system plugins tying them all together, etc.), 
what actual work would be needed to port widgets, and basically find 
answers to all those open questions.
Until then, GWT 2.x is here to stay for at least a handful years I believe, 
and we'll try (it'll depend on the effort it takes) to provide a smooth 
migration path from GWT 2 to GWT 3.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-21 Thread Learner Evermore

On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote:
>
> I am really interested to hear how you can make a version of GWT RPC as 
> fast as a pure JSON approach. We take a tree of thousands of objects and 
> just use one JSON.parse / JSON.stringify call to deserialize / serialize 
> which happens within the browser in C++ code. No other processing is 
> required. We use Overlay types to access the data and that is it. In the 
> future we will switch to JsInteop types instead of overlays, that way we 
> only have one version of our DTO's that are used on the client / server.
>

As I suspected, you are comparing apples to oranges...

   1. You made dumb DTOs for this which means that you have to have the 
   code that copies data into them specifically for this purpose. And while 
   DTOs have followers for some cases they are *downright antipatterns* in 
   other cases. But we don't need to discuss that.
   2. You either don't have/use polymorphism or have had to code around 
   that as well.
   3. Any logic you have has to be either outside of the overlay types or 
   not polymorphic and you need to deal with that too.
   4. You also probably excluded the cost of delayed type conversion.
   5. How are you communicating long/Long? There are other examples.
   6. You can't include data of a third party library unless you have the 
   means to make full copies of it and keep in sync with that.
   7. Enjoy communicating cyclic graphs?

Then we come to the point of how much work you spend addressing the above, 
esp. for complex types. We don't have to spend any of that. None. Zilch. 
Nada. We have spent that time ensuring that we *never* have to send so many 
objects even if we have to show millions (literally) and made our product 
better overall.

-- 
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/144eac41-ae28-408c-be89-fbe4d02e407e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-21 Thread Paul Stockley

I am really interested to hear how you can make a version of GWT RPC as 
fast as a pure JSON approach. We take a tree of thousands of objects and 
just use one JSON.parse / JSON.stringify call to deserialize / serialize 
which happens within the browser in C++ code. No other processing is 
required. We use Overlay types to access the data and that is it. In the 
future we will switch to JsInteop types instead of overlays, that way we 
only have one version of our DTO's that are used on the client / server.


On Saturday, May 20, 2017 at 1:25:46 PM UTC-4, Learner Evermore wrote:
>
> As a heavy user of GWT-RPC in a large app, I've become disillusioned with 
>> it. That's for three reasons:
>>
>> GWT RPC has its deficiencies. I don't have much to add to 
> https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
> However, the serialization alone (used within GWT RPC) is its own beast 
> with its own deficiencies and benefits. One deficiency I can mention is 
> that it isn't completely compatible with java.io.Serializable contract. 
> Customization is done via separate _CustomFieldSerializers. I understand 
> why it had to be done that way, to handle some special cases but ultimately 
> standard approach was also possible with little loss of efficiency, if any 
> - just using a different underlying stream implementation.
>  
>
>> - I often need to see what data is being sent, and it's just not very 
>> good for that. It makes debugging harder than it could be.
>>
>
> Well, actually, you don't need to see it if it works.You need to see what 
> is sent and received. Second, "seeing" it is not that hard. There are 
> solutions to it and we have our own (very rarely needed). 
>
> - it's not good for communicating from a mobile app.
>>
>> That does not depend on whether the app is mobile but whether it has a 
> matching (de)serializer. If your app is web-based GWT app you can use it, 
> it works no worse (in fact better) than other approaches. If it isn't, then 
> I agree, GWT RPC isn't for you. Never was. That isn't its purpose.
>  
>
>> - it's much too easy to accidentally send much more data than necessary. 
>> Being forced to think about your content on-the-wire would probably make a 
>> better product in the long run.
>>
>> There is *no difference* in thinking you need to do between those. We 
> did put thought of it and we're perfectly fine and didn't have to write as 
> much of ugly glue code and duplicate code to use other frameworks. Being 
> forced to think about anything is good in some cases but not others and 
> does NOT generally make a better product in any run length. Examples:
>
> a) If you think about hardware efficiency you should program in assembly, 
> shouldn't you?
> b) Never use databases, they are an abstraction of the file system. Use 
> files directly, make them best for your need. Better yet, talk to 
> underlying storage hardware.
> c) Always implement your own security checks all over the place. You''ll 
> be sure that it always does exactly what it needs to.
>
> Problem is that this is what happens if you follow logic like that:
>
> 1. Your immediate logic seems to operate faster at the low level.
> 2. You have spent time on low level and not on your business, hence your 
> high level is less optimized.
> 3. You're ignoring the big picture. Yes, it may indeed be faster to take 
> one person from point A to point B in a race car but most of the time we 
> actually want to take dozens. A "slow" bus wins here by a lot.
>
>
> So we're going to pay the price to migrate away from GWT-RPC and I don't 
>> feel too bad about it going away.
>>
>> You can, are willing to do so, and don't care about others because of 
> your personal needs. I don't ignore the needs of those who use things I 
> don't. I may be lucky in some cases but it is a wrong thing to say "I don't 
> have a need for it thus nobody should". Furthermore, you can say that you 
> can migrate. We can't. If we migrate our code that still leaves the code of 
> those that are built on top of our solution. It leaves the joint customer 
> stranded too. Finally, if there isn't ONE framework that rules them all you 
> have the trouble of combining libraries. Library A uses framework P, 
> library B users framework Q, you need to communicate their data (at least) 
> through your framework R and P != Q != R. 
>
>  
>
>> I just hope we don't have to give up widgets too. I don't see that being 
>> practical for us.
>>
>> For us neither abandoning widgets nor RPC is "practical" (possible). How 
> would you feel if someone said "We only used GWT to drive Angular, didn't 
> use widgets at all, don't feel too bad about them going away"?
>
>

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

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

On Saturday, May 20, 2017 at 1:06:40 PM UTC-4, Paul Stockley wrote:
>
> I have to agree. A long time ago we moved away from GWT RPC to an approach 
> that used straight JSON. This forced on us by the poor performance on 
> mobile devices. Right away we saw 3 to 5x speed improvement and significant 
> code size reduction. Sure the developer experience wasn't quite as nice. 
> However we, could hardly measure an actual hit in overall productivity. To 
> be honest, our user experience will always take priority over developer UX. 
>

There *is no runtime performance difference* between GWT RPC and JSON if 
you do your homework that you were forced to do when you moved to JSON.  It 
does not exist. We can confirm that, given same functionality. You can't 
compare apples to oranges here. 

Yes, there is a difference in compilation time, but for that I entirely 
blame the inefficient GWT compiler implementation. It can, actually, be 
super fast, *faster* than using *any* other framework for the equivalent 
case. How/why? We can talk about that if there are interested parties, in a 
proper place. I have exactly the same comment for code size. Yes, that code 
size, affects loading time, so it makes things worse. But, again, it 
actually can be fixed, and if you did your homework right, it should not 
have been an issue unless, again, you are comparing apples to oranges in 
terms of functionality.

-- 
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/cdee4f39-7775-446c-82e1-df54238244d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
> As a heavy user of GWT-RPC in a large app, I've become disillusioned with 
> it. That's for three reasons:
>
> GWT RPC has its deficiencies. I don't have much to add to 
https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
However, the serialization alone (used within GWT RPC) is its own beast 
with its own deficiencies and benefits. One deficiency I can mention is 
that it isn't completely compatible with java.io.Serializable contract. 
Customization is done via separate _CustomFieldSerializers. I understand 
why it had to be done that way, to handle some special cases but ultimately 
standard approach was also possible with little loss of efficiency, if any 
- just using a different underlying stream implementation.
 

> - I often need to see what data is being sent, and it's just not very good 
> for that. It makes debugging harder than it could be.
>

Well, actually, you don't need to see it if it works.You need to see what 
is sent and received. Second, "seeing" it is not that hard. There are 
solutions to it and we have our own (very rarely needed). 

- it's not good for communicating from a mobile app.
>
> That does not depend on whether the app is mobile but whether it has a 
matching (de)serializer. If your app is web-based GWT app you can use it, 
it works no worse (in fact better) than other approaches. If it isn't, then 
I agree, GWT RPC isn't for you. Never was. That isn't its purpose.
 

> - it's much too easy to accidentally send much more data than necessary. 
> Being forced to think about your content on-the-wire would probably make a 
> better product in the long run.
>
> There is *no difference* in thinking you need to do between those. We did 
put thought of it and we're perfectly fine and didn't have to write as much 
of ugly glue code and duplicate code to use other frameworks. Being forced 
to think about anything is good in some cases but not others and does NOT 
generally make a better product in any run length. Examples:

a) If you think about hardware efficiency you should program in assembly, 
shouldn't you?
b) Never use databases, they are an abstraction of the file system. Use 
files directly, make them best for your need. Better yet, talk to 
underlying storage hardware.
c) Always implement your own security checks all over the place. You''ll be 
sure that it always does exactly what it needs to.

Problem is that this is what happens if you follow logic like that:

1. Your immediate logic seems to operate faster at the low level.
2. You have spent time on low level and not on your business, hence your 
high level is less optimized.
3. You're ignoring the big picture. Yes, it may indeed be faster to take 
one person from point A to point B in a race car but most of the time we 
actually want to take dozens. A "slow" bus wins here by a lot.


So we're going to pay the price to migrate away from GWT-RPC and I don't 
> feel too bad about it going away.
>
> You can, are willing to do so, and don't care about others because of your 
personal needs. I don't ignore the needs of those who use things I don't. I 
may be lucky in some cases but it is a wrong thing to say "I don't have a 
need for it thus nobody should". Furthermore, you can say that you can 
migrate. We can't. If we migrate our code that still leaves the code of 
those that are built on top of our solution. It leaves the joint customer 
stranded too. Finally, if there isn't ONE framework that rules them all you 
have the trouble of combining libraries. Library A uses framework P, 
library B users framework Q, you need to communicate their data (at least) 
through your framework R and P != Q != R. 

 

> I just hope we don't have to give up widgets too. I don't see that being 
> practical for us.
>
> For us neither abandoning widgets nor RPC is "practical" (possible). How 
would you feel if someone said "We only used GWT to drive Angular, didn't 
use widgets at all, don't feel too bad about them going away"?

-- 
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/06ff19f1-7c34-442c-b4c7-a100f17a79f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-20 Thread Paul Stockley

I have to agree. A long time ago we moved away from GWT RPC to an approach 
that used straight JSON. This forced on us by the poor performance on 
mobile devices. Right away we saw 3 to 5x speed improvement and significant 
code size reduction. Sure the developer experience wasn't quite as nice. 
However we, could hardly measure an actual hit in overall productivity. To 
be honest, our user experience will always take priority over developer UX. 


On Saturday, May 20, 2017 at 11:07:33 AM UTC-4, Paul Robinson wrote:
>
> As a heavy user of GWT-RPC in a large app, I've become disillusioned with 
> it. That's for three reasons:
>
> - I often need to see what data is being sent, and it's just not very good 
> for that. It makes debugging harder than it could be.
>
> - it's not good for communicating from a mobile app.
>
> - it's much too easy to accidentally send much more data than necessary. 
> Being forced to think about your content on-the-wire would probably make a 
> better product in the long run.
>
> So we're going to pay the price to migrate away from GWT-RPC and I don't 
> feel too bad about it going away.
>
> I just hope we don't have to give up widgets too. I don't see that being 
> practical for us.
>
> Paul
>
> On 20 May 2017 2:56 pm, "Learner Evermore"  > wrote:
>
>> ... and before someone mentions version/compatibility issues with 
>> serialization (using any framework) not that NO framework solves this, they 
>> just have different ways of not solving it. And all frameworks expose 
>> *exactly* equal ways of dealing with it should one be interested. Including 
>> java.io.Serializable. And if you happen to not care and change things, it 
>> always results in errors (default cases excepted) only with 
>> java.io.Serializable you get that error immediately and with some other 
>> popular frameworks you get the error at the time of first use - hence less 
>> detectable.
>>
>>
>> -- 
>> 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/1eaced67-96f6-4ea0-9ef7-5bbabb2cf569%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/c4b7f9fe-7fa2-4493-a788-0b49e6c31868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-20 Thread Paul Robinson

As a heavy user of GWT-RPC in a large app, I've become disillusioned with
it. That's for three reasons:

- I often need to see what data is being sent, and it's just not very good
for that. It makes debugging harder than it could be.

- it's not good for communicating from a mobile app.

- it's much too easy to accidentally send much more data than necessary.
Being forced to think about your content on-the-wire would probably make a
better product in the long run.

So we're going to pay the price to migrate away from GWT-RPC and I don't
feel too bad about it going away.

I just hope we don't have to give up widgets too. I don't see that being
practical for us.

Paul

On 20 May 2017 2:56 pm, "Learner Evermore" 
wrote:

> ... and before someone mentions version/compatibility issues with
> serialization (using any framework) not that NO framework solves this, they
> just have different ways of not solving it. And all frameworks expose
> *exactly* equal ways of dealing with it should one be interested. Including
> java.io.Serializable. And if you happen to not care and change things, it
> always results in errors (default cases excepted) only with
> java.io.Serializable you get that error immediately and with some other
> popular frameworks you get the error at the time of first use - hence less
> detectable.
>
>
> --
> 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/1eaced67-96f6-
> 4ea0-9ef7-5bbabb2cf569%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/CAGHNWNLr2jT1WKHs7qnYdG1K_LpT1WdB3TQJ5X26ucKLCROdqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

... and before someone mentions version/compatibility issues with 
serialization (using any framework) not that NO framework solves this, they 
just have different ways of not solving it. And all frameworks expose 
*exactly* equal ways of dealing with it should one be interested. Including 
java.io.Serializable. And if you happen to not care and change things, it 
always results in errors (default cases excepted) only with 
java.io.Serializable you get that error immediately and with some other 
popular frameworks you get the error at the time of first use - hence less 
detectable.


-- 
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/1eaced67-96f6-4ea0-9ef7-5bbabb2cf569%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


Well..


> We looked at this and it seems reasonably simple to get the Widgets 
> working under a pure jsinterop+System.getProperty world. Simple but 
> labour intensive. You could do it now if you wanted to prepare for 
> GWT3. 
>
>
Everything is possible if we do not. Fork GWT or any part of it and make it 
our own. The problem is that then it has no common direction of evolution 
and it becomes proprietary. Even if we open-source that we're still 
disconnected from the main development and may stop working at any time.
 

> We use UIBinder extensively and that is probably easy enough to get 
> 95% converted to APT. However I do recall there being a bunch of 
> scenarios where it becomes harder - although what they were slips my 
> mind atm. In that case we are likely to just implement the subset and 
> generate errors if there is any of those scenarios in our code. 
>
> Good for you. May not be good for someone else (we do not use UiBinder). 
The problem we have is that we are not the last in line of dependencies. 
While, with some large effort, it is possible to migrate any code you own 
entirely to anything else, this isn't the case if you have downstream 
dependents in form of external customers and partners. We do.
 

> I have no idea what shape the client bundles would end up in but I 
> suspect  we would move to using wrappers for whatever tool bundled the 
> javascript be it webpack or closure (does it have a bundling tool?) or 
> whatever. I love some of the css-in-js stuff happening in javascript 
> land - (See 
> https://markdalgleish.github.io/presentation-a-unified-styling-language 
> for an overview). I certainly see some significant advantages about 
> changing the way we do stuff here. 
>
> Going forward this may be good for some. My previous comment applies here 
too. Even if we could "move", we cannot force others to.

 

> > How to reasonably accomplish GWT RPC serialization (all of it)? 
>
> It is unfortunate that you have used this feature but I can't see it 
> ever being implemented by google or the community at large. 


Why is it unfortunate? It works. It is efficient (code). It requires the 
least effort to use. It is NOT for the API but for internal communication.
 

> Most frameworks based on language/framework specific serialization 
> strategies tend to fail, often due to the difficulty of interacting 
> from other platforms or difficult evolving code on the same platform. 
> Java RMI is largely unused these days. Maybe now is the time to move 
> to something different*. 
>

Who says there is a need to interact with other platforms or languages? We 
do have other solutions for that. But we have/had a better approach for our 
internal Java-to-Java communication. We don't use Java RMI for the same 
reason we don't want the outer part of GWT RPC. That is, for us, 
replaceable. It is the serialization that is important. And, arguably, Java 
serialization is NO different than any other except:


   - It encapsulates control of serialization in a common way for all 
   classes and in the language syntax 
   - Its wire format is (somewhat) flexible by using an appropriate 
   (sub)type of object stream
   - It works without having to code special access to 
   default/private/protected fields or resorting to hacks that work around it
   - It completely and safely matches the language semantics w.r.t. 
   primitive and complex types and null (or undefined), etc.
   - It works whatever frameworks different libraries you use use themselves

Sure, it does not put field names into the stream but that would be an 
inefficiency and not desirable in many cases. It is important for public 
APIs, but not for internal communication. Do NOT confuse GWT RPC with 
public API exposure framework. We all agree that it isn't for that, never 
meant for that.

>
>

-- 
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/827e32db-2838-46fa-8c8c-2940511b1359%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-20 Thread Peter Donald

On Sat, May 20, 2017 at 10:05 AM, Learner Evermore
wrote:
> So, simple questions that truly need to be answerable before GWT 3 can have
> any future for us with complex products... and I think for any future users
> too:

As context: We have several largish code bases probably totalling just
over a million lines of client code in total although some of that is
generated. However our single largest codebase is only 338K LOC but it
does support a bunch of complex scenarios.

And from what we have heard so far GWT 3 will make our lives a lot
easier. On the basis of this we are looking at building the next
version of our suite in GWT3 which is likely to have at least a 15
year lifespan.

I do not disagree that there will be some period of adjustment and
some growing pain but the future looks brighter now than it has in a
while for the GWT project. I also will be first to admit the GWT
projects communication is not always the greatest ;)

> How to reasonably accomplish compatibility with existing code dependent on
> widgets (for example Sencha GXT - most should be aware of that)

We looked at this and it seems reasonably simple to get the Widgets
working under a pure jsinterop+System.getProperty world. Simple but
labour intensive. You could do it now if you wanted to prepare for
GWT3.

We use UIBinder extensively and that is probably easy enough to get
95% converted to APT. However I do recall there being a bunch of
scenarios where it becomes harder - although what they were slips my
mind atm. In that case we are likely to just implement the subset and
generate errors if there is any of those scenarios in our code.

I have no idea what shape the client bundles would end up in but I
suspect we would move to using wrappers for whatever tool bundled the
javascript be it webpack or closure (does it have a bundling tool?) or
whatever. I love some of the css-in-js stuff happening in javascript
land - (See
https://markdalgleish.github.io/presentation-a-unified-styling-language
for an overview). I certainly see some significant advantages about
changing the way we do stuff here.

> How to reasonably accomplish GWT RPC serialization (all of it)?

It is unfortunate that you have used this feature but I can't see it
ever being implemented by google or the community at large. It is
likely that this is something you will need to do and it will be hard,
particularly arbitrary exceptions which we have found difficult to
whitelist.

Most frameworks based on language/framework specific serialization
strategies tend to fail, often due to the difficulty of interacting
from other platforms or difficult evolving code on the same platform.
Java RMI is largely unused these days. Maybe now is the time to move
to something different*.

Failing that you can stick with GWT 2.X if it fits your current needs.

* A few years ago "grpc" (another google project IIRC? based on
protocol buffers?) came about which looked like it may be a good rpc
solution but it never had a javascript client.

--
Cheers,

Peter Donald

--
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/CACiKNc6ES5V%2BSt378Lnz032%2BFzb%2BVK7QoUhB5%3DJWZFHB%3DeDvHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
>
> No, Google is not converting all Java to JS to abandon Java, it's the 
> exact opposite. Google needs to support 4 platforms with it's code
>
>
OK, that is almost calming.
 

> But the Gmail team is 12 years old, we have a vast codebase that includes 
> a lot of JS...
>

That is fine. I understand and respect that.
 

> In our opinion, the "Swing" approach leads to an Uncanny Valley effect, 
> and the best approach is to use "native" UI for each platform. 
>

I am not sure what do you mean by "Swing approach". Maybe you are thinking 
of widgets? Well, the "native UI" boils down to communicating with hardware 
and populating video memory, etc. Is that the best way? It is the fastest. 
But it is also a lot of work. And zero abstraction. If your platform 
changes the look and feel, your product running inside it won't. As I 
mentioned before, it isn't just about CSS. It is about behaviour and UX 
paradigms as well. Widgets are a great abstraction that allows complete 
separation of concerns. Maybe they don't perform the fastest but that may 
be more important for games. And even though there was GWT Quake a while 
ago, it isn't GGT but GWT, with slightly different implications. In any 
case, my opinion is that both approaches should be possible. We are staying 
away from direct HTML DOM manipulation and have abstracted wherever 
possible, with no user-discernible performance difference, yet it allowed 
us to evolve very quickly and very compatibly. 

 

> So for our hybrid apps, the business logic is Java, and the UI layer is a 
> mix of JS and Java, Objective-C and Java (iOS), or just Java (Android).
>
> In our apps we are 99.9% Java, with some JS where we had no choice. 
 

> For this to work, we need very low impedance JsInterop, hence we created 
> the JsInterop spec, and added -XclosureFormattedOutput to GWT, so that we 
> could feed the output of GWT into Closure compiler along with JS libraries 
> and get a single, statically linked and optimized, output. This saved well 
> over 500k out of a 2mb JS when first implemented. It also yields 
> type-checking between JS code and Java, so if you make a typo or pass in a 
> wrong argument from JS or vice versa.
>
> I understand and appreciate that. But brute force compaction will only get 
you so far. At some point you come to a situation where this no longer 
works and you have to split code. And that isn't a bad thing. Users access 
different area of application at different times, not all of it at once. 
Having a little code loading as they enter an "area" of the app for the 
first time isn't so bad. But the approach *can* scale very well. Will there 
be a small performance hit? Yes, but only the first time they click and 
only a little. There has to be no (none, zilch, nada, zero) performance 
difference thereafter, not even a little.
 

> But GWT had three pitfalls:
> ...
>
J2CL addresses all of these...
>

That is good, I understand, respect and have nothing against that.

>
> GWT does too much, conceptially it is
> ...
> We have decided to break this apart into lots of module pieces and replace 
> what we're duplicating from existing ecosystems
>
> That too is good. That isn't the problem.
 

>
> We've done what you're asking in effect, which is to break GWT up into 
> modular pieces, you just don't like the fact that this creates 
> incompatibility. But the foundational pieces, when they land, can be used 
> by the community to reconstruct a GWT 3.0 that is much simpler to 
> understand. 
>

Well, there we go. It isn't so much that this "creates incompatibility" as 
much that it doesn't even begin to allow it in a remotely reasonable way, 
the way I see ... as you say yourself:


> * Someone could make a harness that makes GWT Generator APIs to APT's 
> APIs, which could allow GWT generators *that don't depend on global 
> knowledge *to run as APT. (e.g. the I18N, ResourceBundle, and perhaps 
> UiBinder could run under the APT environment). *GWT-RPC can't* because it 
> requires all sources to be present, it depends on global knowledge, so it 
> would *need a specialized preprocessing step* that depends on the 
> transitive closure of all of your dependencies. Still doable, but not as an 
> APT.
>

So, the compiler is going through code once but we need to make a separate 
pass through all of it instead of interacting with it. Furthermore, how do 
we make the compiler generate code that accesses private fields? As it is I 
see only three horrible ways:


   1. Preprocess all *.java code and generate new *.java code with 
   synthetic methods, then pass that new code to J2CL.
   2. Generate "CL" code that can bypass Java visibility restrictions, hope 
   J2CL doesn't change its code generation style.
   3. Make our own J2CL.

Again, see TeaVM metaprogramming API Wiki, for example: 
https://github.com/konsoletyper/teavm/wiki/Metaprogramming for ONE 
reasonable alternative to this. We may still have to do separate discovery 
passes, but it it

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-19 Thread 'Ray Cromwell' via GWT Contributors

On Fri, May 19, 2017 at 5:45 AM, Learner Evermore <
learner.everm...@gmail.com> wrote:

> So... If I read this correctly... Google has discovered that GWT is not
> good enough (is bad) to continue using it. It is creating a J2CL that
> produces readable code so that it can completely abandon its original Java
> source and continue without it. The already slow involvement will turn into
> no involvement at all. In fact, there may be no incentive at all to release
> that J2CL ever - as soon as it becomes good enough for Google to have a bit
> manual work left on the generated code it won't need it any more. If we
> exclude Google, who does not plan any future with GWT, steering committee
> is composed of representatives from Vaadin, RedCurrent, RedHat, Bizo and
> JetBrains. I truly may be mistaken but, other than perhaps Vaadin, I don't
> see any company (that I am familar with) that does anything of large scale
> with GWT. and may not have too much interest in particular GWT future
> either.
>
>
No, Google is not converting all Java to JS to abandon Java, it's the exact
opposite. Google needs to support 4 platforms with it's code: Web, Android,
iOS, and Server. We share code by using Java. 60-70% of our code base is
Java, which we transpile to Objective-C with J2ObjC, run natively on
Android and the Server, and compile to the Web with GWT, and now J2CL.

But the Gmail team is 12 years old, we have a vast codebase that includes a
lot of JS. We did not want to reimplement all of our existing Gmail code in
Java and port all the widgets, nor did we want to recreate some kind of
portable UI between Android, iOS, and Web like React-Native. In our
opinion, the "Swing" approach leads to an Uncanny Valley effect, and the
best approach is to use "native" UI for each platform.

So for our hybrid apps, the business logic is Java, and the UI layer is a
mix of JS and Java, Objective-C and Java (iOS), or just Java (Android).

For this to work, we need very low impedance JsInterop, hence we created
the JsInterop spec, and added -XclosureFormattedOutput to GWT, so that we
could feed the output of GWT into Closure compiler along with JS libraries
and get a single, statically linked and optimized, output. This saved well
over 500k out of a 2mb JS when first implemented. It also yields
type-checking between JS code and Java, so if you make a typo or pass in a
wrong argument from JS or vice versa.

But GWT had three pitfalls:

1) It optimizes twice in this scenario, once during GWT compilation, and
again with Closure Compiler.
2) It creates a monolithic target. We don't want monolithic targets, we
want compose.js to only have to depend on a few Java files like
Compose.java. GWT code splitting does not offer deterministic fine grained
control over what lands in a JS module.
3) GWT "closure formatted output" is still very unfriendly to Closure, it
doesn't output interfaces, doesn't output any JsDoc, has weird conventions
around class setup and the way cast checks work.

J2CL addresses all of these, it stands for Java-to-Closure, like J2ObjC
stands for "Java to Objective C"
1) It works like Javac, it translates a file at a time, very fast, can
recompile as soon as you hit save in your IDE
2) It produces standard ES6/Closure modules, and fully typed, fully
conformant Closure inputs
3) It relies on standard Java mechanisms for generators and permutations
(System.getProperty()/@define in Closure and APT)
4) It uses the build system to define split points. If you say target ABC
in your build has Foo.java and Bar.java, then that JS target has those
outputs (unless Closure moves them for being unused)
5) It can interop with the entire JS ecosystem with little effort, you
could make Node JS modules from Java and deploy them via NPM if you were
inclined (it would take a little bit of hacking to remove the Closure
library dependencies tho). You could put Java into ReactJS/Native projects
if you want.

GWT does too much, conceptially it is

1) a build system that tries to manage dependencies and run code generators
2) a linking system for assembling deployable JS to serve
3) a Java to JS translator
4) a Java optimizer
5) a JS optimizing compiler
6) a giant SDK runtime

We have decided to break this apart into lots of module pieces and replace
what we're duplicating from existing ecosystems

1) use existing build systems to do what GWT is doing internally with it's
module system and dependency checking
2) A standalone Java to JS translator as a separate build step (J2CL)
3) A standalone JS optimizing compiler as a separate build step (Closure
Compiler)
4) a small runtime (JRE, Elemental2)
5) A good interop layer for tying this to any SDK runtimes you want
(Polymer, Angular, React, Ember, GWT SDK, etc)

We've done what you're asking in effect, which is to break GWT up into
modular pieces, you just don't like the fact that this creates
incompatibility. But the foundational pieces, when they land, can be used
by the community to reconstruct a G

[gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

Is there a way I can access J2CL code? Not open source? 

-- 
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/1c7dac76-ae2c-4880-a840-5624ff18dbba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?


>
>
> Google didn't have any incentive to release GWT 10 years ago, or to 
> continue maintaining it in the open source. They've always been the main 
> drivers and main contributors so they could have stopped sync'ing their 
> internal repository to the outside work long ago; but they did just the 
> opposite 4 years ago, with the opensource repository being the source of 
> truth and them sync'ing it into their internal repository (they have a few 
> internal patches, such as completely removing the legacy devmode).
> You're just being pessimistic here.
>

I did't expect GWT 10 from Google. I understand that. But if you decide to 
expose something to the market at least clearly communicate the intent once 
you want to stop it. We haven't had that.
 

> RedHat publishes the Errai framework, and has several tools built using 
> GWT (including their JBoss/Wildfly admin console if I'm not mistaken)
> RedCurrent is actively using GWT (no idea how and where), and employs (at 
> least) 2 of the most productive contributors.
> ArcBees (which you didn't cite) maintains the GWT-P framework.
> There once was representatives from Sencha (Colin, then Justin), but 
> they're apparently putting an halt to GXT (no new development at least), 
> and the representatives have left the company.
>

RedHat/Errai seems to use GWT internally only, not expose it directly, but 
I may be wrong.
RedCurrent - I have no idea.
ArcBees GWT-P is only about the client-side. There are many alternatives to 
that.
Sencha - I actually saw that as we are using GXT too. They also communicate 
vague but different picture. If GXT is truly out (and indications are that 
it probably is) that only means *worse*, whether GXT is of interest to 
someone or not - it means that they could not influence GWT on behalf of 
its customers.

Who is there using GWT fully, exposing it downstream and not limiting it to 
own codebase?

 

> The Closure Compiler is doing a better job at optimizing JavaScript. Even 
> if it were doing a slightly worse job, using it means freeing development 
> resources to work on something else.
> Closure is only a part of the whole (future) toolchain though.
>

I don't have a problem with Closure. That is fine. It may even be a great 
idea to leverage it do Java to JavaScript (or other target) conversion. But 
that too was vague and, it seems, will be a one-shot deal - to get off the 
Java code. It will address the client only and not nearly as efficiently as 
we know is possible.
 

>  Why would it necessarily require a ton of boilerplate code?
> Also, "handing all the magic in between" makes it way too easy to produce 
> inefficient code in terms of network usage.
>  
>
For every class that was made GWT-serializable by someone else we have to 
write code to wrap it in our own/new serialization frameworks. That may not 
be possible because we may not have sufficient access to their code and 
data and because we may not even be aware of their code. We'd have to 
introduce additional requirements to them and standard that they would have 
to follow and our compatibility with what they have written already goes 
down the drain. Joint customers don't have a path forward. We may not be 
able to communicate our and their objects together, in single 
request/responses roundtrips and may need to split them. That split 
introduces inefficiency. So instead of using optimized, *efficient* code 
created by everyone for this purpose, we are forced to eliminate that 
efficiency and break encapsulation and write more boilerplate code that 
runs slower. This is making it easier to translate code to JavaScript *but 
has nothing GOOD to do with efficiency.* If something is needed, it is 
needed. You can't just write it off and say that it is more efficient 
without it. Without it it does not work and would need to be replaced with 
something else. You think that something else will be more efficient? Think 
again. You think that developer time is cheaper than tool time? I know you 
don't. But this perspective may have been missed in GWT future planning.

I wonder if there is a way to identify other heavy GWT users that actually 
have a vested interest in its future... The approach can be better than 
anything else on the market, but the ball is being dropped. I realize it 
may be too late to pick it up. Just thinking.

-- 
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/ef0b6c62-c717-40e9-949f-261584ae926e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

2017-05-19 Thread Thomas Broyer

On Friday, May 19, 2017 at 2:45:37 PM UTC+2, Learner Evermore wrote:
>
> So... If I read this correctly... Google has discovered that GWT is not 
> good enough (is bad) to continue using it. It is creating a J2CL that 
> produces readable code so that it can completely abandon its original Java 
> source and continue without it. The already slow involvement will turn into 
> no involvement at all. In fact, there may be no incentive at all to release 
> that J2CL ever - as soon as it becomes good enough for Google to have a bit 
> manual work left on the generated code it won't need it any more.
>

Google didn't have any incentive to release GWT 10 years ago, or to 
continue maintaining it in the open source. They've always been the main 
drivers and main contributors so they could have stopped sync'ing their 
internal repository to the outside work long ago; but they did just the 
opposite 4 years ago, with the opensource repository being the source of 
truth and them sync'ing it into their internal repository (they have a few 
internal patches, such as completely removing the legacy devmode).
You're just being pessimistic here.

> If we exclude Google, who does not plan any future with GWT, steering 
> committee is composed of representatives from Vaadin, RedCurrent, RedHat, 
> Bizo and JetBrains. I truly may be mistaken but, other than perhaps Vaadin, 
> I don't see any company (that I am familar with) that does anything of 
> large scale with GWT. and may not have too much interest in particular GWT 
> future either.
>

RedHat publishes the Errai framework, and has several tools built using GWT 
(including their JBoss/Wildfly admin console if I'm not mistaken)
RedCurrent is actively using GWT (no idea how and where), and employs (at 
least) 2 of the most productive contributors.
ArcBees (which you didn't cite) maintains the GWT-P framework.
There once was representatives from Sencha (Colin, then Justin), but 
they're apparently putting an halt to GXT (no new development at least), 
and the representatives have left the company.

> Google's Closure is effectively saying "Closure is "better" than GWT".
>

The Closure Compiler is doing a better job at optimizing JavaScript. Even 
if it were doing a slightly worse job, using it means freeing development 
resources to work on something else.
Closure is only a part of the whole (future) toolchain though.

> Other technologies that are already available may also be better for 
> focused needs - some of which I mentioned in my posts above. Coupled with 
> the steering committee composition, it paints a very bleak picture of GWT 3 
> future, if any, ever. 
>
> I will say that the appeal of GWT wasn't writing Java in the browser. That 
> was only a part of it (and most of the complexity). It is about being able 
> to share a lot of code between the client and the server with all the magic 
> in between handled. No other existing solution handles that, including the 
> GWT 3 with any RPC replacement addons. Why? Because it requires writing a 
> ton of boilerplate code and annotations to turn one set of objects into 
> another and back and does not allow reusability.
>

Why would it necessarily require a ton of boilerplate code?
Also, "handing all the magic in between" makes it way too easy to produce 
inefficient code in terms of network usage.

> Making GWT better is possible. I am truly sorry that people haven't 
> realized how and decided to, instead, focus on efforts to migrate away from 
> it. That is what GWT 3 seems to be - a migration away tool (to Closure). 
> This late in the game and without organized efforts it will be very hard to 
> organize "the community" to do something about this, even if willing to 
> pay. And it is not a good investment for any one company to pay for 
> development of own framework here, so that won't happen either - it would 
> be more work than to move away likely.
>
> I am truly and utterly disappointed.
>
>
>

-- 
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/4e1879be-fb0d-4084-a530-6be6bd4034bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

My responses to specific points:

Removing JSNI, , generators... we ourselves were careful
enough to either never use some of these and/or to abstract and encapsulate
their use. However everyone here seems to take the perspective of "it is
just one product of one company that is affected". It isn't. Some of us
have our customers who develop additions too. Even if we have code to clean
up and clean it up, it still renders the solution incompatible with add-ons
created by others. There is *no* migration here. Customer buys a foundation
(A) from one company and add-ons (B) and (C) from two other companies. They
then upgrade (A) to (A2) and suddenly (B) and (C) don't work. They cannot
and won't just ask for new (B) and (C) - this may not be possible for
business or technical reasons. Migration is not a model at all. It is a
complete breakage.

GWT RPC itself has a lot of problems but the central part of it that cannot
be done efficiently outside the core compiler without hooks made
specifically for this is the serialization of restricted-visibility fields
of classes made by third parties. Yes, it could be addressed by uet another
preprocessor but why-oh-why do this? TeaVM does not do this but allows for
it to be made using Metaprogramming API. Otherwise, serialization-related
analysis of GWT is presently horribly inefficient and *can* be done really
well - it does NOT need to be slow like some were saying., It is slow with
the current design - that much is certainly true. Whitelisting (yes) and
annotations are valid approaches. For example, w/o better approaches one
could use *.gwt.xml to whitelist if not do it from annotations (which would
be better). This really does not need to take significant time at all.

I am a little thin on UiBinder... can't talk much about it other than,
perhaps, also provide ways for this to be optional and a separate module
during compilation.

ClientBundle - whatever it is or isn't, it was a way to encapsulate styles
in widgets and do other things. See my comment on migration not being a
model for large cases. Being able to access resources is a part of Java,
one way or another ... and this would form yet another thing that wasn't
quite Java but is close... and is getting lost too.

Re: "First, GWT 2.x is not dead yet or for the foreseeable future."...
How's that? Maybe it isn't dead but it seems to be on deathbed, with very
little life support and no (communicated) vision of future at all. All we
have is that it isn't GWT 3 and that GWT 3 is significantly less than GWT 2
but with J2CL and somewhat better JavaScript interop that may or not be
important.

Re: "Do you have the slightest idea what amount of work that represents?!
Given that Google won't do it (on their own dime), it'd be highly unlikely
that it'd be free or even opensource." ... Yes, I actually do. Do you have
any idea how much work that would save? I don't need a solution that does
not reduce my work. GWT 3 increases that work. With respect to
free/opensource - I can't comment on that as I can't predict future but I
tend to agree for other reasons. Otherwise, there are much more complex
open source and free solutions oht there. Some are funded by the sponsor
companies who they benefit, some aren't but there is a set up guidance. You
say "Incidentally, you've had 2 years to start planning for it..." but that
is not really the case as there was this illusion that there existed a body
that actually cares about what happens to existing users *OR* GWT 3 in
general. At the same time there were announcements that 2.x will continue
and that there is a steering committee, so there were hopes that it will
realize the importance of things being dropped. Incomplete, unclear and
downright misleading communication and ignorance of current users brought
us here. Sure enough, I agree that Google does not need to foot the bill
for this if it doesn't care, but I would have appreciated some more honesty.

--
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/53de52e6-5bf0-4d9e-8cdd-a73b39631bb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?