Stop calling it GWT 3.0

[Paul Robinson]

The GWT Meetup 2015 videos are very interesting.

I can see why the proposals for GWT 3.0 have been made. However, we should be clear about the fact that GWT 3.0 is not just going to break a few little things that can easily be fixed, but break things to the point that it's a completely different product and there will be lots of GWT applications that will never be ported to the new system.

It will be confusing to all GWT users to continue to use the name GWT 3.0. It would be much better to use a new name for the new system and treat it as what it is: a new idea about how Java can be used to build modern web applications.

The situation we have now is that GWT will end at 2.8 and a new thing, that is currently vapourware, will be coming that people are expected to use. There's going to be a lot of confusion and those using GWT now, as well as those that will use the new thing when it does exist, will all be served much better if everybody stops calling the new thing "GWT".

Paul

[Thomas Broyer]

While I don't disagree with your arguments, this is not new in software development: Angular 1 vs 2, Dagger 1 vs 2, even HTTP/1.0 vs HTTP/2, OAuth 1 vs 2, etc.

And contrary to those listed above (correct me if I'm wrong), it's expected that you could future-proof your application in GWT 2.8.

[Paul Robinson]

On Saturday, 13 June 2015 12:18:37 UTC+1, Thomas Broyer wrote:

it's expected that you could future-proof your application in GWT 2.8.

 

Yes, except that if you're heavily invested in GWT widgets, then "future-proofing" means switching to a different rendering library and so almost a complete re-write of your UI code. It may not be practical for many widget-based GWT applications.

[Jens]

I kind of agree not calling it GWT 3.0. I would not name it completely different, maybe something along the lines of GWT X1, GWT RST (abbr. of reset) or GWT Next. I am pretty sure we could come up with something more distinct to indicate that this release is a lot different and a reboot of GWT.

I also think that without drop-in replacements for widget code, UiBinder and GWT-RPC a lot of apps will not migrate to the new GWT because it is simply not cost effective. The GWT surveys shows that the majority of apps depend on these features. Maybe with the help of Singular it is possible to incrementally rewrite your UI until its compatible with GWT 3.0 but you still need to rewrite a lot.

I think at the end it boils down to if you want to use the new compiler or if you are fine with the current SDM development speed of the 2.8 release. Because all the rest of GWT 3.0 can also be used with GWT 2.8.

-- J.

[James Horsley]

I think that there's enough branding/momentum/etc. behind the GWT name that to be taken seriously it should stick with the GWT name, even if possibly adjusted slightly like Jens's suggestions.

I'm fully behind the direction the compiler is taking and I believe that the vision put forward in the videos from the GWT meetup is a great one that will resonate well with developers. My big concern is that the "migration" story and timing isn't great right now.

New projects that are starting with GWT 2.8 are somewhat in limbo right now. I think that things are okay for the business logic and presenter side of things, but deciding what to do for the view layer is tricky.

JsInterop doesn't feel complete enough to easily use with libraries like React for the view layer. I've played around with doing this but it seems very painful without some of the JsInterop 2.0 features (per https://goo.gl/sKsBGX) in particular the functionality from the Js class to easily call JS and create JS collections. As such, the best choice seems to be UiBinder with HTML+CSS and my own minimal JsInterop interfaces for DOM types. But even that's not future proof under the current plans to not support UiBinder. If Singular was available it would probably bridge the gap, but it's not available so we're left picking from choices that aren't planned to be in GWT 3.0.

An official JsInterop version of elemental would also be a big help to prevent everyone from creating their own version and having to migrate later.

I would recommend a doc/page/etc. be started which clearly lists things that are definitely going to be in GWT 3.0, those that are under consideration, and those that definitely won't. Also, give trivial examples future proof setups that dev's can follow to make the 3.0 transition easier.

Cheers,

James

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/76cb0c63-a981-4b54-95bf-ebbd8f773311%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Matic Petek]

Hi, 

 I'm also frustrated about which technologies to use on new GWT projects (see https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/_QSayBAmeX8).

But when it comes about the name, GWT should stay. The basic idea around GWT is writing code in Java which is then recompile (or whatever you call it / do it) into JavaScript. And this idea will stick with new GWT 3.0 (it was also very clearly emphasis is one of the talks), so the name should stay.

Regards,

  Matic

[David]

I'm excited that you guys are planning a radical change (really). I hope it becomes more clear on what we should be using to future proof our apps. 

I hope we will get some usable preview of Singular (if that is really going to be a replacement).

Somehow I am not totally concerned that we will need some major rewrites, it will be hard sell to management and it might mean that we need to look to different directions as well.

But I am afraid that if GWT is no longer offering a complete solution like it does now (including a UI library, RPC support, i18n, UI binding, ... etc) that a lot of the advantage will be lost for me.

As for naming, well it seems that non of the three letters still apply to the direction GWT is about to take.

1) no longer in Google hands (or so they clame)

2) Web not the main concern since the cross compiler is more to share code between web/android/ios apps.

3) Toolkit ... it sounds more like a transpiler to me. Everything that made it a tooltip will be scrapped.

 

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/43ceb941-d8cc-496f-bab3-ab8219c120bf%40googlegroups.com.

[Travis Schmidt]

I have the same concerns as the last comment.  We are a java shop and use enterprise java for our back-end.  We have been using GWT for the last 9 years to write thin front ends for our applications.  Basically GWT RPC and UiBinder are 99% of the code we deploy.  If I need to replace those with Polymer, Angular and some JSON XHR, then I don't see much need to use GWT going forward.  Am I mistaken or just misunderstanding something?

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW0HrjzhwAmGGsSNqzD5YFrPySE7wn%2B_Sp%3Dk-Z1a9ExiMQ%40mail.gmail.com.

[Alain Ekambi]

Also think of people who use GWT for non web based project. 

We use GWT  for example to create native mobile apps with Titanium. And our customers love the  UI Binder support.

Dropping UI Binder means we wont be able to support new version of GWT. 

Such a bad move.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC_RtEZyUauWsQQA%3D8Od0ZeDpgTp%3D3vsvBgLUsTZWcG0Hw5sFw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

[Daniel Kurka]

Hi all,

thanks for sharing your views in this discussion.

Let me add a little background:

Currently we the GWT team have decided to work on a new fast transpiler from Java to Closure (our internal enhanced version of JavaScript). This makes sense for a lot of reasons that I won't go into detail on, but here are a few:

- Our cross platform applications really want a faster and better integration with closure.

- GWT and closure share a lot of work (optimizations) and this is a good way to not reinvent the wheel constantly

So at some point we will open source this new compiler which will have some compatibility with the old compiler, but it will not support everything that GWT used to support.

It is not up to Google to decide if this should be GWT 3.0, but it is up to the steering committee to decide (this is what the steering committee is for).

However this new compiler works out, Google has tons of GWT applications that would need to move from GWT 2.8 to whatever this new effort is, so coming up with a common feature set and a migration plan is on our work list, but we will focus on that once we actually have a new compiler.

However we already know that applications that only use a certain feature set (which might grow, as people put in more work), should be fine on both compilers (we should discuss this after the 2.8 release). We only talked about this so early in the process to give the community the ability to provide feedback on our efforts, but don't panic, nothing is set in stone and we (the steering committee) need your input on this.

-Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGw%3D_tzUMgPMwHw3Un2_NOq%3DZ2jpXr9vHRc1xEFzuChCMkTTyw%40mail.gmail.com.

[James Horsley]

Thanks Daniel.

It's great that the steering committee are discussing the topic this early in the process; in particular, in the context of how GWT dev's can help themselves to be future proof (e.g. your Modernizing GWT talk).

I completely understand how certain GWT generator based libraries that require global knowledge don't fit with APT (e.g. GWT-RPC maybe needing the transportable types explicitly listed). But, at a glance, it seems like other high adoption libraries like UiBinder and the widget library (maybe even just some top level pieces?) can be retrofitted and released as separate projects to work with the transpiler. 

Hopefully we can leverage the opinions and contributions of the GWT community to determine what are "essential" libraries to carry forward and implement plans to make this happen. A few big helping points here would be:

1) Clearly documented ways to future proof new development. What to use, what to avoid, examples, etc.

2) Early access to the transpiler when you have a basic API settled, so that we can start working on converting our favourite libraries that the steering committee don't have time for.

3) Access to Singular. This gives people a future proof view layer to work with and I think it will boost confidence/morale for those concerned about the 3.0 transition.

Cheers,

James

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/43ceb941-d8cc-496f-bab3-ab8219c120bf%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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW0HrjzhwAmGGsSNqzD5YFrPySE7wn%2B_Sp%3Dk-Z1a9ExiMQ%40mail.gmail.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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC_RtEZyUauWsQQA%3D8Od0ZeDpgTp%3D3vsvBgLUsTZWcG0Hw5sFw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

--
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+unsubscribe@googlegroups.com.

[David]

Daniel,

Thanks for the background info. 

In my applications (non public web apps for banking purposes)  I tend to use GIN, Guava, UiBinder + Widgets + GWT-RPC. 

- GWT-RPC has been a limitation (I filled several issues in the passed) and I was looking for a REST/JSON replacement but it was not available at the time (now it is). So I can already move away from GWT-RPC.

- UiBinder is really fundamental, but if we need to switch to pure HTML then it should not be that hard to do, UiBinder files are already 80% pure HTML anyway. CssResources and such might be a bit more work... we were planning to move to GssResources ... will those remain ? probably not...

- Widgets ... by switching to GQuery we can avoid widgets for most cases (although I will have a dependency on Element. But here again, I am sure there will be a replacement for Element using Elemental (and hopefully a GQuery update to moves to something else ?)

- CellWidgets. We depend and enhance the various cellWidgets a lot (adding resizing, filtering, dynamic loading, custom generators to generate the columns, ...). These will be hard to replace at this point (I do like the Vaadin Grid ... who knows).

Is Singular planned to be a replacement for UiBinder or is it too early to ask that question ?

Greets,

David

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/43ceb941-d8cc-496f-bab3-ab8219c120bf%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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW0HrjzhwAmGGsSNqzD5YFrPySE7wn%2B_Sp%3Dk-Z1a9ExiMQ%40mail.gmail.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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC_RtEZyUauWsQQA%3D8Od0ZeDpgTp%3D3vsvBgLUsTZWcG0Hw5sFw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGw%3D_tzUMgPMwHw3Un2_NOq%3DZ2jpXr9vHRc1xEFzuChCMkTTyw%40mail.gmail.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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/beab0cd4-e9e6-4a9d-bd09-be304a61eb51%40googlegroups.com.

[Julien Dramaix]

> CssResources and such might be a bit more work... we were planning to move to GssResources ... will those remain ? probably not...

CssResources will continue to work, the generator can be adapted to use APT api instead of GWT generators.

> Widgets ... by switching to GQuery we can avoid widgets for most cases (although I will have a dependency on Element. But here again, I am sure there will be a replacement for Element using Elemental (and hopefully a GQuery update to moves to something else ?)

GQuery is now supported by Arcbees and it should not be too hard to use elemental if needed.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW0Z5NLcaoq8szjh-dq2Vnge2QcOP5FkmD3mppm-QN%2B5OQ%40mail.gmail.com.

[Frank Hossfeld]

Hi Daniel,

it would be nice, if the team can provide early access to the new compiler. As the owner of mvp4g I would like to do the necessary changes to get mvp4g running with the new version.

Also I like the idea that the new version contains the basic classes, to write old school widgets. May be the community can to do this working as a seperate modul.

Frank  

[stefan....@gmail.com]

Features that I hope will still be supported (or have replacements) in GWT 3.0:

* The core parts of the widget library, i.e. the base widgets, composites, cell widgets (e.g. CellTable, DataGrid), and layout panels. However, I will not miss the old-style table-based panels and all deprecated APIs.

* UiBinder

* i18n

* Event bus

* History support

* Eclipse IDE integration

/Stefan

[Stephen Haberman]

Sounds like I'm late to party; I missed the 2015 meetup videos, does someone have a link? (That will teach me to not login to G+ very often...well played, Google...)

Not that my opinion matters very much (vs. the GWT team who's doing all the actual work), but I'll +100 any plans for large/breaking changes/rewrite for GWT 3.0/j2cl.

Everyone that is concerned about backwards compatibility, you can stay on GWT 2.x. What we need is foundations for a GWT that will be awesome 5 years from now. For the next generation of applications. That's who we need to be worried about.

Yes, that means pain/being left out for the current generation of applications, but that's how technology works. GWT 2.x will not suddenly be taken off Maven central. Plenty of enterprise applications rely on older/mature technology, e.g. jars/projects that aren't pushing out new releases every 2 months with amazing new features. That's fine. If it's too expensive to switch, then don't.

Sounds like a great opportunity for other companies to step-in and provide enterprise support for 2.x as well. Google has never been interested in that game anyway.

Someone mentioned early access to j2cl for framework authors to start porting; I'd throw my hat into that ring. It would be interesting to see what Tessell looks like with it.

Tessell very heavily uses UiBinder to drive its MVP codegen, so I'll have to either port Tessell to the next-generation of templates, or (more likely) port UiBinder to j2cl (using APT/something; maybe not 100% backwards compatible, but at least something that is not "throw away all your templates and start from scratch").

- Stephen

[Thomas Broyer]

On Monday, July 6, 2015 at 2:42:04 PM UTC+2, Stephen Haberman wrote:

Sounds like I'm late to party; I missed the 2015 meetup videos, does someone have a link? (That will teach me to not login to G+ very often...well played, Google...)

https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

(link to the slides is in the playlist description)

 

Not that my opinion matters very much (vs. the GWT team who's doing all the actual work), but I'll +100 any plans for large/breaking changes/rewrite for GWT 3.0/j2cl.

Everyone that is concerned about backwards compatibility, you can stay on GWT 2.x. What we need is foundations for a GWT that will be awesome 5 years from now. For the next generation of applications. That's who we need to be worried about.

Yes, that means pain/being left out for the current generation of applications, but that's how technology works. GWT 2.x will not suddenly be taken off Maven central. Plenty of enterprise applications rely on older/mature technology, e.g. jars/projects that aren't pushing out new releases every 2 months with amazing new features. That's fine. If it's too expensive to switch, then don't.

…with the caveat that “The web is not a platform. It's a continuum.”, which in terms of browser bugs and browser sniffing means that libraries/frameworks have to be maintained if you expect them to continue to work with newer/future browsers and/or browser versions (remember the mess with every new IE version, requiring changes in GWT? has anyone tried GWT in MS Edge?) Hopefully this is going to stabilize with evergreen browsers, but there's still a limit in time before GWT 2.x "explodes" and everyone has no choice but migrating to something else (a newer version of GWT, or something else entirely).

So saying "GWT 2.x is here to stay" really would depend on someone maintaining it:

Sounds like a great opportunity for other companies to step-in and provide enterprise support for 2.x as well. Google has never been interested in that game anyway.

Someone mentioned early access to j2cl for framework authors to start porting; I'd throw my hat into that ring. It would be interesting to see what Tessell looks like with it.

As I said elsewhere, you don't have to wait for an early access to j2cl to start porting. Proof (admittedly a simple/limited one): https://github.com/tbroyer/gwt-places

 

Tessell very heavily uses UiBinder to drive its MVP codegen, so I'll have to either port Tessell to the next-generation of templates, or (more likely) port UiBinder to j2cl (using APT/something; maybe not 100% backwards compatible, but at least something that is not "throw away all your templates and start from scratch").

Re. UiBinder, maybe it could have a first generator pass creating Java source for the *.ui.xml, that could later be reused by an annotation processor working from the "owner Java class": what's specific to the *.ui.xml is generated by a first pass (before JavaC) –just like you do with Protocol Buffer and the like–, and the annotation processor (during JavaC) does only what's specific to the owner class (@UiField, @UiHandler, @UiFactory), calling into the previously-generated class for the *.ui.xml-specific things (that class could possibly be subclassed to override methods when the owner class has @UiField(provided=true) or @UiFactory vs. a simple @UiField, for instance)

That unfortunately would call for a complete rewrite, and UiBinder is quite complex… But if the alternative is to write something else from scratch, then reusing the *.ui.xml and @UiField "contract" probably wouldn't be a bad starting point (and ease porting existsing code).

But I think we should just stop speculating, wait a bit for Google to continue their experiment with j2cl and have a clearer view of how they want to migrate their existing apps, and then see which features Google would like to port themselves (because they need them anyway) and which ones they'd "abandon", and whether they'll be replaced or not.

[Stephen Haberman]

https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

Thanks!

I feel dumb, as the gwt-contrib posts were going under the Forums tab in my gmail account, and so I missed the original email/thread go buy. I only stumbled across this thread later via the web.

I'll start catching up on the videos.

So saying "GWT 2.x is here to stay" really would depend on someone maintaining it:

That is a good point.

 

But I think we should just stop speculating, wait a bit for Google to continue their experiment with j2cl and have a clearer view of how they want to migrate their existing apps, and then see which features Google would like to port themselves (because they need them anyway) and which ones they'd "abandon", and whether they'll be replaced or not.

That's also very reasonable. Sounds fun!

- Stephen

[Goktug Gokdogan]

Just FYI, we don't have any plans to port anything from GWT libraries at this moment other than maybe some Resource support. Our only goal in terms of compatibility is basically having a simple compatibility layer composed of 'java emulation', JsInterop and Elemental. That layer intends to provide an option for third party libraries who wants to support both compilers (i.e. if you write a library that only uses these pieces, it will very likely work fine in both compilers).

 

- Stephen

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANnRKuWXhvbo5MaVpVDkoEwidYWyzkB-HrtKYWuQ-ux86gCZYQ%40mail.gmail.com.

[Lars]

Will the new transpiler support the following features and fixes the linked issues:

 

- "Good" SourceMaps including SuperDebug (see Brians speech at gwt.create) and debugger support within the IDE (like sdbg for eclipse)

- StackTraces including emulation mode (for browsers without - like Safari), StackTraceDeobfuscator and closure support (the current one is still broken - see https://github.com/gwtproject/gwt/issues/7800)

- "Story of Your Compile" or something similar to optimize and analyze the results of the transpiler

[Mark Proctor]

On Sunday, June 14, 2015 at 12:31:15 PM UTC+1, stuckagain wrote:

I'm excited that you guys are planning a radical change (really). I hope it becomes more clear on what we should be using to future proof our apps. 

I hope we will get some usable preview of Singular (if that is really going to be a replacement).

Somehow I am not totally concerned that we will need some major rewrites, it will be hard sell to management and it might mean that we need to look to different directions as well.

But I am afraid that if GWT is no longer offering a complete solution like it does now (including a UI library, RPC support, i18n, UI binding, ... etc) that a lot of the advantage will be lost for me.

Other libraries now offer excellent alternatives, that are probably now superior (imho) for RPC, i18n,  UI Binding - such as Errai.

The programmatic user UI api can be forked and maintained under a different name, for those that continue to need the programmatic UI api. It hasn't been developed much in years now anyway, so freeing it may allow it to progress better.

[Ali Akhtar]

I searched for the modernizing GWT talk but didn't find it on youtube - is there any other talk / article that we can refer to, on how to write future proof gwt code?

[Ali Akhtar]

Nevermind, found it.

[sameeps...@drishti-soft.com]

I am not much concerned about name, but would like to know when the GWT 3.0 will be released??

[Thomas Broyer]

On Monday, October 3, 2016 at 3:12:08 PM UTC+2, sameeps...@drishti-soft.com wrote:

I am not much concerned about name, but would like to know when the GWT 3.0 will be released??

Nobody knows. (and this is an official answer)

(a little birdie told me that “j2cl is working out really well”, so we may have more info on the roadmap “soon”; but I have no idea how much “soon” is)