On Thursday, May 18, 2017 at 9:37:58 PM UTC+2, Relja Pcela wrote:
>
> It would be really nice to see some new answers on this kind of questions
> from GWT contributors other than: "We don't know how GWT3 will look like in
> this moment but we know that J2CL will not include this and that" because
> this sentence is almost 2 years old.
>
We don't really know how GWT 3 will look like, but we know we'll base it
upon j2cl, which means no JSNI and GWT.create() magic (no generators, no
deferred-binding configuration in XML files).
We've said repeatedly that we were waiting to actually being able to start
*playing* with j2cl to have a better understanding of what would be
possible or impossible, what would need to be done, etc.
We want to start prototyping things.
And only then we'll be able to form a better image of what GWT 3 could look
like.
Incidentally, you've had 2 years to start planning for it:
- remove as much JSNI as possible, leaving mostly one-liners that could
then easily be replaced with JsInterop (and now that JsInterop is here with
a beta of Elemental 2, that last migration can be started too)
- replace <replace-with> in gwt.xml with System.getProperty("…") and a
switch…case (or if/else for more complex cases); this is relatively
straightforward and can possibly even be (partially) automated (first step:
generate, from the XML, a proxy class whose constructor does the switch on
implementation, and replace the <replace-with> rules with a single one
using the proxy class; second step: generate a static factory with that
same switch code, and use it instead of the GWT.create())
- replace generators with annotation processors (first step: have the
processor generate a *.gwt.xml file with <replace-with> rules; second step:
rpelace the GWT.create() calls) or preprocessors (or a combination of both).
GWT-RPC *is* problematic, but not insurmountable. People (me included)
question whether this is a good idea though, but others disagree.
We haven't seen the community engaging much in any discussion trying to
move things forward though: if I tell you GWT-RPC won't be the same, can
you tell me how you'd like it to be? (a preprocessor? a whitelist of
classes in annotations on the RemoteService interfaces? what if it
generated server-side code too instead of the serialization policy files?)
Fortunately, there have been people trying new things though (autorest for
example).
UiBinder and ClientBundle have their issues, too; but maybe they need to be
replaced with new tools leveraging the new toolchain, along with automated
migration tools?
Regarding ClientBundle, isn't it now seen as a bad practice (with HTTP/2)
to bundle assets inside the JS code?
--
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/7ac23bf2-a9ba-4616-b10e-dd245b0adc72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
