Hi,
On Thursday, May 18, 2017 at 6:29:29 PM UTC+2, Learner Evermore wrote:
>
> Hi there!
>
> I am faced with having to re-think what we are doing in the company I work
> for with respect to GWT, existing and new projects and I am struggling, to
> say the least. We've been very much a GWT shop for years now and have used
> it to expedite the development of very large solutions and improve the end
> user experience. We did this and this was possible because:
>
>
> 1. There is (was?) a *visible* big name behind the technology -
> Google. There were regular updates and a lively community.
>
> 2. It allowed us to share a lot of code between the client and the
> server properly and use a programming language suitable for very large
> software - strong typing, encapsulation/visibility control and all the
> works. JavaScript just isn't an option - it isn;t even a thought with all
> the enhancements they are making.
>
> 3. It allowed us to cleanly and efficiently segregate and encapsulate
> functional responsibilities of both business and representation code. We
> were able to create a foundation with clean APIs that other teams build
> their modules on top - and we bring those modules together. We can evolve
> that foundation and dramatically change it looks beyond just CSS because
> we
> encapsulated units of UI into widgets and we came up with the means to
> aggregate client-server communication from all modules into single
> requests/responses via serialization (we otherwise used GWT RPC very
> little
> - there is a single service with a single method in there).
>
> 4. It offered integrated code optimization and debugging tools with
> what seemed to be a promising future vision and dedication.
>
>
> We've been following what is going on with GWT 3.0 and, admittedly, didn't
> like it. However, we were hoping that our problems are common and that it
> will become apparent that GWT 3.0 vision needs some adjustments. We've
> observed other people communicating similar perspectives to ours.
> Unfortunately, we've also seen little acceptance of these comments, little
> action and, essentially, no direction with respect to those beyond "waiting
> to see what happens with GWT 3.0". We believe that this effective limbo is,
> at least, a big part of the reason for frequent statements like "GWT is
> dead, past its time" and abandoning the technology simple because they have
> to move forward but are left behind.
>
> I/we perfectly *understand *the reasons why one would want to do things
> planned for GWT 3.0. Removals of GWT RPC and widgets can simplify some code
> and increase the performance of the tools, among other things. At the same
> time, I believe that the perspective taken to decide what to do is wrong.
> Instead of finding ways to simplify GWT at the expense of making GWT-based
> products more complex and loosing any chance of being compatible with
> pre-3.0 code, efforts should have been focused on solving the problems.
>
Here's the thing:
- Google is the main contributor to the Compiler, by a very very wide
margin (~99.9% of the code has been written by Googlers)
- Google is (*slowly*) moving away from GWT towards j2cl; they *will*
disengage
from maintaining the GWT Compiler (as we know it) in the coming *years*.
- This means either the community (as a whole, and this includes you)
rolls up its sleeves and steps up to maintain the GWT Compiler; or GWT
moves to using j2cl.
- Google moving from GWT to j2cl is due to several issues with the
current design, and a shift in how they build webapps. The crux is to
leverage JS developers' knowledge of browsers, and existing JS libraries
and tooling (to avoid duplicating efforts); relegating Java (inside Google;
though this is from an outsider's point of view, so I might be wrong) to
those parts of the apps that you want to share between platforms.
- They tried to replace the JS-optimization pass of GWT with Closure
Compiler (i.e. integrating the Closure Compiler into the GWT Compiler;
the
-XenableClosureCompiler flag, removed in GWT 2.8), but it was abandoned
(I
believe relying on internal APIs of the Closure Compiler made it
difficult
for updates; even within Google's monorepo as it involves different
teams,
but exacerbated in the opensource world, particularly with different
release cycles). So instead they decided to split the GWT Compiler into
different parts, first a Java to Closure-annotated-JS transpiler (j2cl),
then using the Closure Compiler as-is.
- Interop with JS had to be better: people want to use existing JS
libs (including, from Google's point of view, Google's own libs: maps,
protobuf, libphonenumber, etc.) with minimal friction, people want to
create JS libs out of Java code (from Google's point of view: share code
with JS devs so they can leverage the Closure Library to build the UI for
example, rather then reimplementing the Google UI style in both Closure
Library and GWT widgets, like they had to do for Google Groups and Google
Flights for example, but that doesn't scale), and everything should
ideally
be compilable in a single optimized bundled (with code-splitting).
They introduced JsInterop 3 years ago, as a mean to both consume
existing JavaScript (those interfaces could be generated from
Closure-annotated JS) and to export Java to JS APIs, then they rewrote it
1.5 years ago.
They tried to produce JS code that could be fed as input to the
Closure Compiler along with other code (the -XjsInteropMode CLOSURE
first,
3 years ago, then the -XclosureFormattedOutput introduced 2.5 years ago).
- They spent a whole lot of time trying to optimize the compilation
process to be as incremental as possible (to speed up SDM): they first
made
generators incremental, but it has to be an opt-in and is not
straightforward to implement, they however try to infer which files are
needed by a given generator for a given input class, but this means
accessing resource (non-Java) files using specific APIs rather than from
the classloader; they introduced the concept of "libraries" (gwtlib) 3.5
years ago, to finally abandon them 2 years ago; then they tried a
"compile
per file" approach 3 years ago which I believe is the basis of the
current
incremental compilation; and they tweaked the various optimizations
passed
to be run in SDM to make it faster and faster.
In the end, j2cl doesn't have generators, first because it translates
one file at a time (afaik) with no "full world view", and because the
Java
ecosystem already has a tool for code generation: annotation processing
(and most –if not all– other usages can be turned into preprocessors,
that
you run explicitly ahead of time). This leaves "caching" and staleness
checks to something that should already be good at it: the build system
(and Google's build system is really good at it; but for most developers
outside Google, there's also Gradle which is really good at it).
- Wrt code-splitting; Google has completely rewritten it 5 years ago
(GWT 2.5), and added many flags to help tune it, but as Ray explained,
it's
still not ideal. This is however an area that has seen tremendous work by
the JS community, with great results (webpack comes to mind; making it
relatively easy to use the PRPL pattern, something that's not possible
with
GWT; the Closure Compiler also has means to modularize its output, but
afaik it's not as easy to use). I think it's a good idea to try to
leverage
those existing tools; I have no idea what that could look like though.
- Wrt GWT-RPC and Widgets, afaik, Google don't use them on new projects,
and are slowly moving away from them on older projects. Speaking of Google
Groups for example, it wouldn't surprise me if it were being rewritten in
Angular as we speak, given the similarities in UI with the Google Issue
Tracker (https://issuetracker.google.com/), and it might be one of the last
Google asset still using GWT-RPC.
What that means is that Google no longer contributes to them, which
means that we, the community, have to decide what to do with them.
GWT-RPC is still very-much achievable with j2cl, either with some
changes to move to an annotation processor, or with a preprocessor that
would scan the whole classpath (and source code?), to generate the
appropriate Java code. The questions are who will do this work and maintain
it? There are people in the steering committee who love GWT-RPC and don't
want it to die (hi Colin ;-) ), so there's still hope that there will be
some form of GWT-RPC in GWT 3.0.
As for widgets, it might very-well be possible to port them to
JsInterop; one question is how to do it (switch to elemental2-dom? or port
com.google.gwt.dom to JsInterop?).
- Then there are permutations. We decided a long time ago that it would
be great to remove the user.agent-based permutation, or limit it to 2
permutations (modern browsers and oldIE; though with Microsoft finally
abandoning oldIE –yay!– we could possibly go with only a "modern browsers"
thing), but again it's a lot of work; and it might actually the main
"blocker" for porting widgets. Ideally, the only "permutations" left should
be i18n. But even without "removing" permutations, it should still be
possible for GWT 3; for that, we need to *experiment*, which means we
need to get our hands on a (preversion of) j2cl. Hopefully this will be the
case by the end of the quarter.
- Finally, there are linkers. Linkers will likely have to be rethought
out from scratch, but are likely to still be there in some form or another
(there will still be i18n-permutations to choose from).
> I know that these problems are hard, but they are also *possible* to
> solve. I know because I made solutions to similar problems. Yes, new GWT
> may produce code faster and it may produce faster code and it may
> interoperate better with the browser and JavaScript. But consider the
> following:
>
>
> 1. For perfect interoperability with JavaScript one can use JavaScript
> or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
>
> 2. For sharing code with the server, some people use node.js (I do not
> subscribe to this) but there are other options - JSweet, TeaVM, possibly
> Dragome and others.
>
> 3. For runtime performance of the code written in Java (via
> optimizations and otherwise), TeaVM seems to yield better performance than
> GWT with JavaScript output and also has experimental support for
> WebAssembly, which yields about double the performance on some tests I've
> seen. One could offer both options, to support browsers that can't do
> WebAssembly.
>
> 4. If one is forced to use external frameworks for serialization they
> don't get any benefits from GWT that other alternatives don't also get.
>
> 5. In terms of tooling - GWT seems to, now, be the worst. Super Dev
> Mode proved to be essentially a failure because one does not really see
> the
> data that matches the code. Runtime performance still suffers and debugger
> often freezes for long periods of time doing who-knows-what if/when
> breakpoints are set or we're stepping through code. Coding in JavaScript
> directly means what-you-see-is-what you get and no wait times. Other
> solutions offer their custom tooling which seem to be possibly better, at
> least on paper (did not check, so cannot verify yet). JSweet and TeaVM
> translation is much faster than GWT is, even without GWT RPC. TeaVM does
> not require source code, which is better for companies who need to deliver
> a module but keep the source closed. GWT needs *both* source and
> binaries...
>
> 6. If we're to work directly with the metal, similar to how JavaScript
> frameworks do things, then again - JSweet may be a better fit, possibly
> TeaVM. Neither has widgets in a sense GWT does/did.
>
>
> Put it simply, GWT 3.0 does not seem offer a path for existing users,
>
Who said that?
> does not have much novel for brand new users that isn't already available
> othewise *and better*, takes more time to do whatever it does and slows
> down the development and is losing trustworthiness - what guarantees that,
> if I start with GWT 3, I won't be left stranded when GWT 4 comes out... if
> it ever will?
>
Nobody can guarantee anything (did you see a contract somewhere?). Tell me
about Silverlight, Adobe AIR, Flash(?) All backed by big companies in their
time.
When it comes to opensource software, one way is to contribute.
If it's critical to your business, one way of contributing is to actually
pay developers to work on it.
> So, who is GWT 3.0 for? Who will use it?
>
Google won't be using GWT proper, they'll be making j2cl,
jsinterop-generator, jsinterop-base and elemental2, and will contribute to
the Java Runtime Emulation library (it is still in discussion where this
code will live).
GWT 3 will have to bring j2cl+jremul+closure-compiler together into a
coherent tool, resembling GWT 2, with a similar (but hopefully better) way
of compiling and debugging the code (people who want more control could use
the parts separately, like Google will).
I really hope the biggest change from GWT 2 will be the removal of
generators (and linkers?) and GWT.create()-driven permutations.
Does this mean that there really is no vision about how GWT can truly
> evolve and grow? If so, let me offer some of my challenges that would be
> best solved or need to be solved in GWT, in no particular order.
>
>
> 1. Simulate synchronicity even for what would be, under the hood,
> asynchronous calls. See TeaVM for how multithreading is supported in it,
> Thread.yield() and related. We know why things must be asynchronous in
> JavaScript, but that does not mean that this has to be exposed as such in
> the Java world - a Java method could "block" at a call only to continue
> when a relevant event is triggered. This would go a long way to
> simplifying
> the code and increasing how much code can be shared between the client and
> the server without exposing the server to unnecessary asynchronicity or
> the
> client with synchronous methods that may/will not work.
>
>
> 2. Doing the above will let you improve code splitting as you will be
> able to load code at any point, not just at GWT.runAsync() points. It will
> open up other possibilities of driving how the code is split - e.g.
> perhaps
> per module, project or package.
>
> 3. Separate widgets into an optional module but definitely keep them
> going. They are important. They are used, both directly and via 3rd party
> libraries.
>
> 4. 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. This is possible in TeaVM with its "Metaprogramming API".
> Arguments that "it is hard" are not helpful and "I don't need it" may
> apply
> to a class of users who really don't need GWT at all or are not creating
> very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but
> allowing matching OWN client and server code to communicate. Do include
> the
> means to store discovered relationships so that they don't have to be
> discovered again. Allow polymorphic serialization one way or another via
> specific annotations. Whether done internally or externally, rethink RPC
> with respect to (1) - synchronicity emulation and what plumbing code needs
> to be written. There is a discussion about these things in
>
> https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
>
>
> 5. Bring back (something like) *.gwtar files. Even better, replace
> them with something that will be self-sufficient and *not* have the
> original source code in it. This would be very useful for both increasing
> the compilation performance and for delivering closed-source modules.
>
>
> 1.
> 2. Deferred binding and code generators are something we do not use
> *directly *as we tried to be as "clean" as possible. As I am
> propagating compatibility, you should not remove this but do provide means
> to not depend on it. That may have a significant performance impact too.
>
> 3. JSNI methods in comments were nice but are the *only thing* that
> truly *requires* the source code. Find other ways of doing this, such
> as via annotations or separate files, e.g. for each Foo.java there may be
> Foo.jsni
>
> 4. Think about how would one support post-development (e.g.
> install-time or run-time) linking of multiple modules. For example, we
> build our foundation product, but our partners build plugins for it.
> Customer chooses and installs plugins they want. Right now this forces us
> to do a GWT compilation step at that time and it is painfully long. (from
> the customer perspective). We are trying to hide this cost in various
> ways
> (store results, reuse them across nodes, etc.) but I am sure you can
> figure
> out the challenges. Since these modules only communicate via dedicated
> APIs, obfuscation can be limited to the implementation only and/or there
> can be an overlay of "exported" symbol maps for cross-module calls. This
> is
> a very similar "problem" to Java class file obfuscation so nothing new.
>
> One idea: export your public API with JsInterop, generate stubs to consume
the API using JsInterop, provide both a JAR with bytecode and sources for
the stubs (standard GWT library), and the compiled JS for the lib (minified
and partially obfuscated if you want it closed-source)
>
> 1.
> 2. Clean up the tooling. Stop embedding everything in a single
> monolithic jar, update code coverage tool support. Rethink debugging -
> perhaps leverage existing work done outside GWT for this? Separate the
> classpath of the compiler from what it is supposed to compile. These are
> not the same thing and cause grief.
>
>
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.
As a business, you can choose to put your money on a commercial product, or
on people to contribute to opensource projects (either dedicating employee
time to such contributions, hiring people to work fulltime on it, or giving
money to developers who would like to do it on their own but need to be
supported).
> Without the above, what seems to be a closer alternative to existing GWT
> 2.x users is a separate fork of GWT (that may not be coming any time soon)
> or a TeaVM enriched with a fork of GWT widgets and a module doing GWT RPC
> (possible!). It does not have code splitting support (yet) and, likely, no
> desire (or need) for "permutations" and related concepts. That would
> require widget libraries to be rewritten with that in mind, but that would
> be *possible* and would, it seems, yield a better dev environment with a
> better performing end result.
>
> I don't want to see GWT fail. We have our future depending on it and, if
> we can't use it, I presently don't know what we can do. But we cannot use
> GWT 3.0. Remember - "I don't need it" is not the same as "Nobody needs it"
> and "shouldn't need it" is a matter of perspective typically uttered by
> those who don't create projects as complex as many of us others do.
>
First, GWT 2.x is not dead yet or for the foreseeable future.
So, what would you *need* (must-have, not nice-to-have) in GWT 3? A clear
migration path (hopefully as automated as possible) from GWT 2?
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/7e89197f-db7b-4348-ab14-f3a27b6d3638%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
