GWTCon 2015 keynote question

[stuckagain]

This points to the GWTCon keynote done by Julien Dramaix.

https://drive.google.com/a/vaadin.com/file/d/0BwVGJUurq6uVa2tpaTRLSzlBMDQ/view?pli=1

I was not able to attend the meeting but I wondered what was said about the last slide:

Use modern framework instead of classic GWT libs

In the same conference Julien also showed how you can use JsInterop to use AngularJS from GWT.

This looked really nice, but does that mean that we need to start looking at AngularJS for any GUI work ?

I'm just trying to get a clearer picture to decide what way to go for implementing a new application and I 

want to be as much future proof as possible.

Should I use:

- UiBinder

- GQuery

- AngularJS

- Singular

- GXT

- Vaadin

This application will have a extensive GUI and will need to be maintained for at least 10 years. Rewriting large parts is not something we want to do too often if not needed.

[Alain Ekambi]

I think to be future proof you should use anything that is not based on the widget system. Since that will be gone in GWT 3.0

We are using Ext JS fpr example on top of GWT.

--
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/3a7092a8-a24c-4e5a-925d-ea426566561d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

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

[Frank Hossfeld]

David Chandler made a statement regarding Sencha GXT:

https://www.sencha.com/forum/showthread.php?306057-GWT-3.0-Sencha-GXT-and-the-future-of-the-widget-eco-system-....

[Jens]

Well if you want to switch to J2CL in the future and you want to be absolutely sure that you actually can switch then you should not use any GWT library/framework and GWT SDK features that can not guarantee to work with J2CL. 

GXT/Vaadin: You should ask them about their plans regarding J2CL since Widget/Elements do not work with J2CL out of the box. Maybe they will provide very long GWT 2.x (paid) support so you can just use GWT 2.x for the next 10 years.

UiBinder: Would need a rewrite to use APT. I guess no one has looked into it yet. One main issue is that APT won't get triggered when updating resources (*.ui.xml)

Singular: isn't released yet and no one knows when it will be released. Also it might cost you time/work if early versions are missing features

GQuery: Based on Element but can probably release a JsInterop/Elemental 2.0 based version easily which would make it J2CL compatible. Not sure if it uses GWT.create() though.

Elemento: Uses HTML as templates, Elemental 1 and is based on APT. So generally compatible with J2CL once it upgrades to Elemental 2. It also has the same issue as UiBinder so you would need to rerun its maven plugin when you change template files since APT won't be triggered automatically.

Angular: Should just work when consumed using JsInterop as shown in the slides since you are effectively writing an Angular application using Java through GWT/J2CL.

So the absolute safest solution is to use JsInterop + any JavaScript framework. If that framework uses HTML templates then you still have that UiBinder feeling. You are not required to use Angular, but its a nice fit. The next best solution is probably GQuery and/or Elemento but you should expect some refactor work.

-- J.

[Brian Pedersen]

I was at GWTcon, and my perception of Juliens keynote and his presentation on JSInterop was, that he used AngularJS to demonstrate that it is now possible to use a JS based framework with GWT 2.8 through JSInterop, and to show solutions to common issues you might run into while doing so.

Which framework you choose if you take this route, depends entirely on your requirements and personal preference. It could be AngularJS or something else, as long as it is javascript based.

This approach should make our applications J2CL compatible.

I also took the following note during the conference: 'J2CL != GWT3'.

This again is my own personal perception. 

While the GWT team seems focused on doing the J2CL transpiler, and there appear to be a clear expectation that the next major version of GWT will be based on J2CL, the future of GWT seems unclear.

/Brian

[Goktug Gokdogan]

I think you get it all correct; in particular J2CL != GWT3.

J2CL is a separate/unbundled "Java to Closure style ES6" transpiler that Google works on and only shares the JRE emulation and JsInterop from GWT-SDK. There is an intention to open-source it when it is ready and J2CL+JsCompiler together 'may' replace the old compiler stack in GWT-SDK in GWT 3.0. That part is a decision that will be made by the open source community and steering committee.

--
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/54a3ffe7-6766-4741-8f8c-9f945c46d305%40googlegroups.com.

[Stephen Haberman]

This is an interesting question (what to use for a greenfield GWT project)...

 

UiBinder: Would need a rewrite to use APT. I guess no one has looked into it yet. One main issue is that APT won't get triggered when updating resources (*.ui.xml)

Yeah, I would probably skip APT and just use an old-school "invoke it before you run javac" code generator for ui.xml files (and hooked into run-on-save with an Eclipse builder).

Given how egregiously statically typed UiBinder files are (in a good way), ideally you wouldn't need much/any reflection/type oracle-type information (which is where being in an APT environment is nice).

I might eventually prototype something like this, for migrating our Tessell-based app off widgets...

So the absolute safest solution is to use JsInterop + any JavaScript framework. If that framework uses HTML templates then you still have that UiBinder feeling. You are not required to use Angular, but its a nice fit. The next best solution is probably GQuery and/or Elemento but you should expect some refactor work.

Yeah. The conundrum for me is that I'm addicted to the pure-JVM unit testing/debugging that MVP gives you.

So, I guess you could still do MVP, with a view interface, and then have the view implementation use Angular/JSInterop? That would be interesting...not sure how it'd work in practice though, as it seems like none of the watch/scope/etc. logic that you see in Angular controllers would work in a pure-JVM unit test?

My worry about "just pick a mainstream JS framework and use it via JSInterop" is that if you're a) coupled to a JS environment for unit testing and b) interfacing with a framework that is inherently dynamic/untyped, what's the benefit of using GWT in the first place?

Perhaps this is a naive question, and some GWT+JSInterop+JS framework examples would (already?) show that you can leverage static typing enough to make GWT worthwhile in a traditionally non-GWT/JS framework.

It will be interesting to see what Singular looks like. Personally, I think there is definitely a space to be filled for a next-gen/J2CL-compatible GWT framework, but I think it'll be ~6-12 months before we really know if a solid choice materializes. And hopefully we'll have a few choices by then as well.

Granted, that is not great advice for what to do right now...

- Stephen

 

-- J.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d92e7eec-fe04-48fa-ba9a-bcf4c5ed5620%40googlegroups.com.

[Brian Pedersen]

Yeah. The conundrum for me is that I'm addicted to the pure-JVM unit testing/debugging that MVP gives you.

I believe Angular controllers, Flux Stores etc. can be just as JUnit-testable as MVP, when implemented in Java and exposed through JsInterop.

There is a lot of pioneering to do, and I can imagine future best practices varying based on the JS framework of choice, as well as other parameters.

The important thing is to keep an open mind, not trying to force JS frameworks into our current best practices, and willingness to be inspired by the best practices of the chosen JS framework.

Our best practices has emerged from the constraints of GWT, and those constraints has just changed.

At least that is my point of view :)

[Stephen Haberman]

The important thing is to keep an open mind, not trying to force JS frameworks into our current best practices, and willingness to be inspired by the best practices of the chosen JS framework.

Our best practices has emerged from the constraints of GWT, and those constraints has just changed.

Good points. :-) 

- Stephen

[Robert Stone]

On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:

My worry about "just pick a mainstream JS framework and use it via JSInterop" is that if you're a) coupled to a JS environment for unit testing and b) interfacing with a framework that is inherently dynamic/untyped, what's the benefit of using GWT in the first place?

 

And this for me sums up GWTs main issues going forward. The benefit before was that existing Java devs could use GWT to work on all the layers of an application. GWT 3 will force (not a bad thing) Java devs to use JavaScript for their views and will also force them to deal with integrating JS and Java code. At this point, you have to ask 'Why bother with Java/GWT at all' - switch the full application to pure JS.

For existing large projects, switching to GWT 3 is almost a non-starter as there will be far too much existing view code to convert over so they will have to stick with the GWT 2 stream and hope that it remains well supported. This is the situation my company face with one of our products.

So GWT 3 is not ideal for new projects and doesn't help with existing projects. Where is it's market?

[Alain Ekambi]

Well the hope is that someone will step in and port existing js libraries to gwt 3 or create new one ? See vaadin sencha etc .. We will def port our ext js wrapper to gwt3

--

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/342561ff-64da-4e7a-aec4-6e9b84846f09%40googlegroups.com.

[Frank Hossfeld]

David Chandler from Sencha answered a question about widgets and GWT 3.0:

https://www.sencha.com/forum/showthread.php?306057-GWT-3.0-Sencha-GXT-and-the-future-of-the-widget-eco-system-....

"Thanks for the kinds words about GXT. We still don't have any more info on GWT 3 than what has been publicly shared at GWT.create in January and the subsequent meetup in May, but we definitely plan to support GWT 3 one way or another. When Google speaks of "removing widgets," I think their first concern is to reduce the support burden of all the individual Widgets currently in GWT, which few Google projects actually use. However, even if they remove the Widget and Cell base classes altogether, it should still be possible to write new base classes using the new DOM impl in GWT 3 as you point out, and this would indeed make a nice open source project. GXT widgets already extend our own base class (Component) which extends Widget, so it is theoretically straightforward to rebase our widgets to use a new DOM implementation. We are still evaluating alternatives at this point, but it is always our goal to make it as easy as possible for GXT customers to keep up with the latest versions of GWT.Given my understanding of the motivation for the proposed removal of Widget in GWT 3, I would hope that Google would be open to leaving some Widget base classes in GWT itself, but if not, I think a separate project is a great idea. If I were you, though, I would probably wait to see what GWT 3 actually brings. We're still waiting for 2.8, after all."

[David]

Thanks for all the feedback. But it does not put my mind at rest right now.

 

It would have been much better if GWT 2.8 would have provided at least the basis for the future of GUI development - because that was one of its main selling points for me.

 

I understand why element/widget/uibinder are going away, but right now there is no low-level alternative that would allow a less painful migration later on.

 

I am not expecting a 100% backward compatibility with 3.0, but at least some certainty that the code rewrites will be limited or easy, if we restrain from using certain technologies. The only certainty we have right now is that GWT 3.0 will compile Java into JavaScript, and all the rest will change or will just disappear assuming that there will be 3rd party extensions.

 

If GWT does not offer a basis for widget and UI development then there will be multiple incompatible GUI libraries or frameworks that will make it difficult to mix.

 

I could take the approach of JsInterop with AngularJS, but Angular 2,x is also not going to offer backward compatibility. So I solve one problem and end up with another one.

 

I guess I will be trying UiBinder with GQuery and not rely on Widget for my project. The UiBinder might disappear, but we are using mostly plain HTML and Bootstrap styles. So we are only interested in binding events. The UiBinder templates will be easy to migrate later on.

 

Any idea what is going on with Singular ? Is it also abandoned or will it finally appear after GWT 2.8 is final ?

 

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

[Thomas Broyer]

On Monday, November 16, 2015 at 11:29:14 AM UTC+1, Robert Stone wrote:

On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:

My worry about "just pick a mainstream JS framework and use it via JSInterop" is that if you're a) coupled to a JS environment for unit testing and b) interfacing with a framework that is inherently dynamic/untyped, what's the benefit of using GWT in the first place?

 

And this for me sums up GWTs main issues going forward. The benefit before was that existing Java devs could use GWT to work on all the layers of an application. GWT 3 will force (not a bad thing) Java devs to use JavaScript for their views and will also force them to deal with integrating JS and Java code.

I think Vaadin and Julien Dramaix showed during the last months how you can use GWT to create Web Components (through Polymer), so no J2CL or GWT 3 won't "force Java devs to use JavaScript for their views".

As for "forc[ing] them to deal with integrating JS and Java code", it shouldn't be much different from the current situation dealing with Element and NativeEvent (com.google.gwt.dom.*), Storage, Geolocation, etc. and Elemental 2 (to be released shortly after 2.8 AFAIK) should help bridging this gap.

 

At this point, you have to ask 'Why bother with Java/GWT at all' - switch the full application to pure JS.

If you have the luxury to "switch the full application" to another stack (i.e. "big rewrite") and you have devs whose JS skills are comparable to their (or the other team's) Java skills, then why not?

 

For existing large projects, switching to GWT 3 is almost a non-starter as there will be far too much existing view code to convert over so they will have to stick with the GWT 2 stream and hope that it remains well supported. This is the situation my company face with one of our products.

So GWT 3 is not ideal for new projects and doesn't help with existing projects. Where is it's market?

I think Google is increasingly building "hybrid apps" where they want/need to share "business code" between several platforms rather than rewrite the same thing in 3 languages: server, web client, android, and iOS. Server and Android can be coded right in Java, GWT will bring the shared Java code to the web client (where the UI could be written in JS, as is the case for “Inbox by Gmail” or Google Spreadsheets), and J2ObjC will bring that code to iOS (that's actually exactly the pitch in the J2ObjC homepage introduction: http://j2objc.org/).

So GWT becomes more about "sharing/integrating Java with JS" than "using Java instead of JS".

But keep in mind that there still are apps at Google that use widgets (Google Groups, where I'm writing this, to begin with), and Google likely won't maintain J2CL and the GWT compiler in parallel (at least not for long) so they'll have to find a migration path for their apps: either rewrite their UI in JS (Closure), or make widgets J2CL-compatible, or something in between (rewrite the UI without widgets, but still in Java, using Web Components or some new widgets library).

[Thomas Broyer]

On Monday, November 16, 2015 at 1:28:16 PM UTC+1, stuckagain wrote:

Thanks for all the feedback. But it does not put my mind at rest right now.

 

It would have been much better if GWT 2.8 would have provided at least the basis for the future of GUI development - because that was one of its main selling points for me.

 

I understand why element/widget/uibinder are going away, but right now there is no low-level alternative that would allow a less painful migration later on.

 

I am not expecting a 100% backward compatibility with 3.0, but at least some certainty that the code rewrites will be limited or easy, if we restrain from using certain technologies. The only certainty we have right now is that GWT 3.0 will compile Java into JavaScript, and all the rest will change or will just disappear assuming that there will be 3rd party extensions.

 

If GWT does not offer a basis for widget and UI development then there will be multiple incompatible GUI libraries or frameworks that will make it difficult to mix.

Web Components to the rescue?

As I just wrote above, Web Components can be written in Java with JsInterop, and can be consumed quite easily with GWT too (whether the component was written with GWT or not).

I know that answer won't satisfies you as you have to deal with ancient IEs, but Google has no such need, and has, over the past year(s?), expressed its will to simply stop supporting them in GWT altogether (Vaadin and Sencha were those asking for keeping support in); so they won't invest in such backwards-compatibility (I'm talking about browser here).

 

I could take the approach of JsInterop with AngularJS, but Angular 2,x is also not going to offer backward compatibility. So I solve one problem and end up with another one.

 

I guess I will be trying UiBinder with GQuery and not rely on Widget for my project. The UiBinder might disappear, but we are using mostly plain HTML and Bootstrap styles. So we are only interested in binding events. The UiBinder templates will be easy to migrate later on.

 

Any idea what is going on with Singular ? Is it also abandoned or will it finally appear after GWT 2.8 is final ?

My impression was that they're waiting for J2CL (but I have absolutely no insight)

[Julien Dramaix]

Thomas gets it all correct. I just want to add one thing: If you are happy with the current GWT stack (uibinder + widget ...), stay with it. As I mentioned during the key notes, the GWT 2.8 will be a long maintenance release and you have now everything you need to do a great web app. 

Don't try to already migrate an existing application to something that is not there yet. 

--

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/02a9f89b-1420-4289-be10-f8094decdfe7%40googlegroups.com.

[Robert Stone]

On Monday, 16 November 2015 12:34:51 UTC, Thomas Broyer wrote:

On Monday, November 16, 2015 at 11:29:14 AM UTC+1, Robert Stone wrote:

On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:

My worry about "just pick a mainstream JS framework and use it via JSInterop" is that if you're a) coupled to a JS environment for unit testing and b) interfacing with a framework that is inherently dynamic/untyped, what's the benefit of using GWT in the first place?

 

And this for me sums up GWTs main issues going forward. The benefit before was that existing Java devs could use GWT to work on all the layers of an application. GWT 3 will force (not a bad thing) Java devs to use JavaScript for their views and will also force them to deal with integrating JS and Java code.

I think Vaadin and Julien Dramaix showed during the last months how you can use GWT to create Web Components (through Polymer), so no J2CL or GWT 3 won't "force Java devs to use JavaScript for their views".

As for "forc[ing] them to deal with integrating JS and Java code", it shouldn't be much different from the current situation dealing with Element and NativeEvent (com.google.gwt.dom.*), Storage, Geolocation, etc. and Elemental 2 (to be released shortly after 2.8 AFAIK) should help bridging this gap.

Yes and I agree, but taking this approach doesn't truly isolate the Java devs from needing to know JavaScript as GWT/JsInterop is providing a very thin wrapper over the JS framework of choice. Someone has to put that wrapper in place be it a 3rd party or someone in the team and that someone really does have to understand the underlying JS framework. At the end of the day, the Java devs will benefit from having more of an understanding of JS/HTML than they did in 'pure' GWT days. And again, I'm not saying this is a bad thing :) 

 

 

At this point, you have to ask 'Why bother with Java/GWT at all' - switch the full application to pure JS.

If you have the luxury to "switch the full application" to another stack (i.e. "big rewrite") and you have devs whose JS skills are comparable to their (or the other team's) Java skills, then why not?

I'm not talking about a re-write here, I'm talking about new projects. For new projects, I can't see a compelling reason for picking GWT, if the devs are going to have to understand JS to use GWT then it is better to invest up front time in getting them familiar enough with JS to use it for the whole project. This is the decision we have taken in my organisation.

 

For existing large projects, switching to GWT 3 is almost a non-starter as there will be far too much existing view code to convert over so they will have to stick with the GWT 2 stream and hope that it remains well supported. This is the situation my company face with one of our products.

So GWT 3 is not ideal for new projects and doesn't help with existing projects. Where is it's market?

I think Google is increasingly building "hybrid apps" where they want/need to share "business code" between several platforms rather than rewrite the same thing in 3 languages: server, web client, android, and iOS. Server and Android can be coded right in Java, GWT will bring the shared Java code to the web client (where the UI could be written in JS, as is the case for “Inbox by Gmail” or Google Spreadsheets), and J2ObjC will bring that code to iOS (that's actually exactly the pitch in the J2ObjC homepage introduction: http://j2objc.org/).

So GWT becomes more about "sharing/integrating Java with JS" than "using Java instead of JS".

But keep in mind that there still are apps at Google that use widgets (Google Groups, where I'm writing this, to begin with), and Google likely won't maintain J2CL and the GWT compiler in parallel (at least not for long) so they'll have to find a migration path for their apps: either rewrite their UI in JS (Closure), or make widgets J2CL-compatible, or something in between (rewrite the UI without widgets, but still in Java, using Web Components or some new widgets library).

 

True, but I would be amazed if Google were to start any new projects using GWT 3. Everything I heard at GWT Create and everything I have seen since has convinced me that they are interested in using J2CL/J2ObjC but nothing more than that.

[Robert Stone]

On Monday, 16 November 2015 12:51:35 UTC, Thomas Broyer wrote:

On Monday, November 16, 2015 at 1:28:16 PM UTC+1, stuckagain wrote:

Thanks for all the feedback. But it does not put my mind at rest right now.

 

It would have been much better if GWT 2.8 would have provided at least the basis for the future of GUI development - because that was one of its main selling points for me.

 

I understand why element/widget/uibinder are going away, but right now there is no low-level alternative that would allow a less painful migration later on.

 

I am not expecting a 100% backward compatibility with 3.0, but at least some certainty that the code rewrites will be limited or easy, if we restrain from using certain technologies. The only certainty we have right now is that GWT 3.0 will compile Java into JavaScript, and all the rest will change or will just disappear assuming that there will be 3rd party extensions.

 

If GWT does not offer a basis for widget and UI development then there will be multiple incompatible GUI libraries or frameworks that will make it difficult to mix.

Web Components to the rescue?

As I just wrote above, Web Components can be written in Java with JsInterop, and can be consumed quite easily with GWT too (whether the component was written with GWT or not).

I know that answer won't satisfies you as you have to deal with ancient IEs, but Google has no such need, and has, over the past year(s?), expressed its will to simply stop supporting them in GWT altogether (Vaadin and Sencha were those asking for keeping support in); so they won't invest in such backwards-compatibility (I'm talking about browser here).

Fully agree with web components, but (as I've said above) I can't see a compelling reason to write them in Java (polymer makes JS web component creation so easy) and once you've started down this route it becomes very easy to justify not needing Java/GWT for the rest of the application.

[Jens]

I'm not talking about a re-write here, I'm talking about new projects. For new projects, I can't see a compelling reason for picking GWT, if the devs are going to have to understand JS to use GWT then it is better to invest up front time in getting them familiar enough with JS to use it for the whole project. This is the decision we have taken in my organization.

If you just want to write that new app thingy that can do 3 things very well and your client side code never reaches a critical size then fine, I guess I would also skip GWT. But if you have a 500-5000 KLOC client side application then its a totally different story and you quickly wish that you would have used GWT/Java or a different language with better tooling support than JS.

So THE compelling reason for picking GWT is your expected app size. Even for small apps for which I might want to skip GWT I would, at least, use TypeScript to put as much type information as possible into my code to help devs and IDEs to reason about code.

-- J.

[Stephen Haberman]

 

I guess I will be trying UiBinder with GQuery and not rely on Widget for my project. The UiBinder might disappear, but we are using mostly plain HTML and Bootstrap styles. So we are only interested in binding events. The UiBinder templates will be easy to migrate later on.

FWIW this is what we're doing, with a small variation:

Use UiBinder, use regular CSS styling (bootstrap/etc.), but only very minimal/core widgets, like TextBox (just an input tag), HTMLPanel, and ListBox (select tag).

My theory/hope is that porting away from UiBinder + TextBox/ListBox to some other templating language + "basically a text box, basically a select box" replacements should not be too painful.

So, yes, it's still using widgets, but it's not the full slate of layout panels, trees, cells, etc. that would be much harder to port.

That said...if you could get away with widget-less UiBinder? That's interesting. I've not really tried that. E.g. just use an <input ui:field="..."> instead of "gwt:TextBox" at all. That sounds like a good idea to me...

- Stephen

 

 

Any idea what is going on with Singular ? Is it also abandoned or will it finally appear after GWT 2.8 is final ?

 

On Mon, Nov 16, 2015 at 12:10 PM, Alain Ekambi <jazzma...@gmail.com> wrote:

Well the hope is that someone will step in and port existing js libraries to gwt 3 or create new one ? See vaadin sencha etc .. We will def port our ext js wrapper to gwt3

On 16 Nov 2015 11:29, "Robert Stone" <rob.a...@gmail.com> wrote:

On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:

My worry about "just pick a mainstream JS framework and use it via JSInterop" is that if you're a) coupled to a JS environment for unit testing and b) interfacing with a framework that is inherently dynamic/untyped, what's the benefit of using GWT in the first place?

 

And this for me sums up GWTs main issues going forward. The benefit before was that existing Java devs could use GWT to work on all the layers of an application. GWT 3 will force (not a bad thing) Java devs to use JavaScript for their views and will also force them to deal with integrating JS and Java code. At this point, you have to ask 'Why bother with Java/GWT at all' - switch the full application to pure JS.

For existing large projects, switching to GWT 3 is almost a non-starter as there will be far too much existing view code to convert over so they will have to stick with the GWT 2 stream and hope that it remains well supported. This is the situation my company face with one of our products.

So GWT 3 is not ideal for new projects and doesn't help with existing projects. Where is it's market?

--
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/342561ff-64da-4e7a-aec4-6e9b84846f09%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/CAGw%3D_ty7rjFQmUZhYv95aQBj8KgwSKcGk0nEyUkdTd4upBNtdA%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/CABrJHW2uZjj_BAdr8WZJCN%2BQX_p91zvUxE%2BTMBa%3DZpjijaDRyA%40mail.gmail.com.

[Alain Ekambi]

Errai UI ?

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANnRKuW3FS6EcB4cP6wyfrv_Ozuj9T%2Bgh3cLf%2BM%2Bi2tLQxS4Yg%40mail.gmail.com.

[Ray Cromwell]

My hope would be that some enterprising individuals will start porting pieces of GWT generators to annotation processors in the future. Some of them are definitely doable without much effort (CssResource/ClientBundle/etc) Some of them will require more work, but are still possible (UiBinder with caveats), and some of them just plain won't work (RPC) because of the requirement of global information.  

Other useful bits of com.google.gwt could be easy modified to use JsInterop instead of JSNI as we have done in much of the JRE to share code with J2CL.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGw%3D_twBmnjAwHT_%2BfkWSRyA6yDMxg7x91koxH6m%2BdL%3DchuKUg%40mail.gmail.com.

[Robert Stone]

We have 2 big applications, one written in GWT and the other (slightly smaller) written in JS. The JS one is actually embedded inside the GWT app, we had the chance to write it in GWT but our experience with writing the big app led us to switch to JS. Don't get me wrong, GWT was the correct decision at the time we started the main app (5 years ago) because it solved the cross browser issues well and because of the relative immaturity of JS frameworks/unit testing/build tools at the time. But JS frameworks have improved so much over those years, the problems that used to plague pure JS solutions are much easier to avoid now.

I can't remember the last time I suffered an issue due to dynamic typing, so I would disagree with you on the needing TypeScript point. My IDE of choice for my JS dev is Sublime Text with a few plugins, I feel more productive in that environment than in any of the 3 Java IDEs. With very good unit tests in place our JS application has far better code coverage than the GWT app and the ability to express/solve problems in JS seems to naturally lead to a much smaller (and more understandable) code base than the Java code.

We will still be using GWT and I will be looking into what we can do with the code base to take it forward, thankfully we are using MVP so it should (in theory) be possible to move our views over to a more native solution (possibly using Elemento) which would allow us to at least think about moving to GWT 3.

It may not sound like it, but I'm incredibly grateful for what GWT has been able to offer me over the years, indeed I wouldn't be in my current (very enjoyable) job without it :)

[Ray Cromwell]

Keep in mind at Google, we write lots of large Web projects, and even the ones that are pure JS (G+, Gmail, Docs, Maps, etc) use Closure Compiler and lots of typing. We find it invaluable.

But the world is going mobile, and going forward, you need to support Android, iOS, and Web, and you need to be flexible and not box yourself in. You have a few choices to do this:

1) Try to deploy mobile Web everywhere.

2) Go with something like React-native

3) Rewrite all 3 clients 3 times in 3 languages

4) Try to share code as much as possible between platforms.

We have decided to go with option #4 for some projects. For example, the next-generation Gmail (Inbox), Google Spreadsheets, and others. We share 80% of our code with all platforms.

J2Cl will join J2ObjC is providing an aligned solution for Hybrid apps. This may not fit everyone's needs, in which case, there's still GWT.

IMHO, with J2Cl, Java8, Elemental2, and JsInterop, you'll have a solution which lets you stay in Java 95% of the time, compile orders of magnitude faster than GWT, interoperate with arbitrary libraries with much less wrapper JSO boilerplate, and provide excellent integration with any Java IDE as far as coding is concerned. The round-tripping should be nearly as fast as Typescript.

But if you're conformable with ES6 or TS, I'd say go for it. Always use whatever you're most productive in or what suits your needs.

-Ray

--

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/d03c7beb-f1ff-46ac-873c-5ad1b13a4438%40googlegroups.com.

[Goktug Gokdogan]

I think I need to make a few clarifications.

We (we as in Google) are not planning to go on delete any code from GWT-SDK after 2.8 release.

Yes, we believe Widget, GWT-RPC, RF etc. reached end of its useful life and we will not invest on them anymore however if there is enough interest/demand outside, there is nothing preventing you from resurrecting the pieces you see useful. If you like old GWT widget / MVP style coding, go ahead and use it. Being said that I would highly suggest maintaining them as separate libraries outside of the SDK and let them progress at their own pace, otherwise they will become more irrelevant in time.

Please also keep in mind that GWT is not the only framework that provides widget abstraction. Actually there is very healthy ecosystem outside of GWT that solves similar problems. So don't think that you are bound with earlier patterns, abstractions, framework etc. I personally find recent frameworks very innovative and productive.

Also note that; Julien's demonstrated Angular integration as part of the *JsInterop* presentation; the whole idea was to show that how easy to integrate with JS; it wasn't a recommendation. He had a demo for Polymer as well but the code could have confused listeners due the way polymer works so we chose to skip that; otherwise there would have been a polymer demo in the presentation as well. We are not actively working on any framework. Again use whatever works for you, or better invent your own.

And finally, at Google side; our current guiding principle is to enable the java language and tools for use in modern web development. Our customers are people who want to use Java; either because they love it or because they need it in for code charing. I see that as the most value we bring into the table and we will do that as best as we can. So if you don't fall into that category, probably you need to look for something else.

Cheers.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fXyXkij3C0fH%2Bgbd%3DO2z6FrrT%2BJtLKC-D_P-f3qamhmA%40mail.gmail.com.

[Manuel Carrasco Moñino]

Exactly, although future releases of  GWT will still allow you to create your UI components (you have access to the DOM tree), the point is to reuse external widget collections instead of reinvent the wheel.

Obviously nowadays UI designers are much more comfortable writing components using html + JS than using uibinder + java, and the community is creating really good quality elements. So let's take advantage of it in gwt.

My talk in the GWTCon 2015 [1] was about using polymer catalog in GWT. Gwt-polymer-elements [2] library allows not only  to use them as plain elements but as widgets for classic apps. Notice that the library uses JsInterop and all the java code needed to use the components in java is generated automatically.

If you do a basic search in github, you could see much more contributions to modern widgets developed with polymer than pure gwt. So if you want a modern and good looking app you have either develop your own widgets, or you will end reusing 3party JS libraries (polymer, angular, materialize, material lite, jquery-ui ...) .

[1] http://www.slideshare.net/dodotis/rock-gwt-uis-with-polymer-elements

[2] https://github.com/vaadin/gwt-polymer-elements

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1zSRm-wxacCtHfmgCu9%3DV4et3dogQUPr5L5wKyyFPBoA%40mail.gmail.com.

[CodeLess Solutions]

This is very good question and actually one of the biggest problem not only in this particular situation but also in general software development.

Imagine you decide to build something large like ERP or Banking Information system for an example (with hundreds even thousands of tables and forms) You didn’t even finish it because of its complexity and one day you find out that Swing or Angular1 or Flex or “something else” come to its end of living and you are not able to switch easily to anything else?

I happened to me once long time ago with some other widget library, so I am talking from the personal experience :-(

I will try to explain our strategy how to solve this problem:

We are using GWT and we are really enjoying to use it but:

We are not using WindowBuilder (it’s not supported anymore since version GWT 2.6 and it’s also useless when you are creating large application because it’s to slow), not using UIBinder because it generates to much boilerplate that we do not need at all, not using Request Factory that generates who knows what, not using MVP… nothing that is too specific or bound too much for the platform. The only thing that we use and is specific is Code Splitting but it’s totally hidden from developers and done automatically for each controller. We are not using any external library to do this. It’s simple to implement and it would be probably easy to replace it with something else tomorrow. Everything is done with a single annotation.

GWT-RPC may also disappear? We are using JPA classes (with Hibernate) but we don’t use DTOs because there is simply no need to pack and unpack everything. We do not write code for every document we need to save (create, update, delete), there is only ONE class that is doing the job via GWT-RPC. Exceptions are rare (less than 10%) that you have to do something special while persisting the document and you are able to do that as a custom business logic that executes in the same transaction. Current implementation is GWT-RPC based, but when we decide to change this, it can be done in a single day (probably in couple of hours) because its’ ONE class and not hundreds/thousands of classes that we have to change. We are not afraid of changes when someone decide to stop supporting GWT-RPC or it’s suddenly surprisingly proven that it is prone to vulnerabilities. We have less than 10 services to change and note that we are dealing with >650 forms/JPA classes in this moment. All custom actions go via ONE custom action service, we do not create 100 services because it is used in 100 controllers.

About UI: We are using something that I call “meta description approach” for UI. Describe you fields, views and forms on technology agnostic way including events. Your views should only describe the view, you should never see any TextBox or any other concrete widget in your code. Use interfaces in your controller and never use concrete GWT/GXT/GwtBootstrap widget. Current implementation is GXT 3 based but there is also ongoing GwtBootstrap 3 version that works equally well but it looks (much) better but that is personal opinion. You can even mix this libraries. In GwtBootstrap version you can create fields as widgets or you can use Bootstrap HTML and CSS, even jQuery JavaScript that sometimes comes with it, from any source and bind existing tag like this one:

<input class="form-control" type="text" placeholder="User name" id="name">

to your meta field named “name”. The beauty of this is that you can do it even without any compile, it will simply work instantly. You do not need to add any annotations or even write any controller code if there is no need for it. We have a youtube movie that proves this: https://www.youtube.com/watch?v=ROZ5Oa6DoUg

No widgets anymore? Ok, let’s rework engine not to use widgets and implement new version of your metafields that is using Elemental2, JsInetrop2 or whatever it is called today/tomorrow. You do this on engine level and nothing changes in your views, controllers or model. You like GXT, and they decide to do this? Great, make your new implementation in the meta platform engine to use GXT5(?) and you are ready to go. You like Vaadin webcomponent gwtpolymer ? GwtMaterial ? … Add this to the engine/platform. You do not need to change your controller, model, or view code because of this. Don’t want to use Bootstrap templates any more, and you want to use some other templates instead? When all mappings, field properties and events are in meta descriptions it would be much easier to replace it comparing to dealing with concrete widgets.  When you think “meta way”, you are not bound to concrete technology and that is the way we decide to go.

I am not concerned about the future, I am prepared for the changes this time.

Hope this helps.

 

 

 

[David]

Good points and in most cases we are covered:

- Using a Command Processor over GWT-RPC, but I will move it to a REST implementation.

- GUI is split up in MVP and the important code is not depending on any GWT widgets or anything else.

We are using UiBinder in our current application, but switching to something else is not something that I am afraid off. When I use UiBinder I try to avoid using widgets as much as possible. So if this needs to move to Angular or some other HTML based template mechanism, I don't expect a lot of difficulties since it is already close to pure HTML anyway.

Abstracting behind a meta description language for the UI that part we did not do. One of the main reasons is that you lose a lot of the performance benefits that GWT is offering. This optimisations mattered because we needed to support older browser (IE6/IE7).

One important component we have does this, but that one is very much tuned for one specific task (editing financial messages defined through XSchema's). It can not handle writing entire GUI's with rich tables, tabs, splitter panels etc. But has some domain specific optimisations that are not that easy to do when you need to write a complete abstraction of the UI.

We alse have dependencies on the CellTables because they offer quite good performance and we enhanced the capabilities of those cell tables to add missing functionality. But the CellTables are hidden behind a factory and the interactions happens against interfaces, so the client code will not too much impacted either.

What I am mostly afraid of with losing Element or Widget classes is that every widget vendor will start declaring their own base classes and interfaces for common functionality. This will make it hard to mix components from different vendors.

Web Components are interesting, but as usual it is too soon to go down that trail. Chrome is not the most used browser in banking and enterprise environments and web components on IE11 is still a mess. I tried polymer but it is way too slow to scale to large GUI's at this point.

--

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/72e2237e-12b7-4e3f-8537-7536212089a9%40googlegroups.com.

[CodeLess]

Good points and I agree with almost all you said ;-) We did not notice any performance degradation by using meta approach comparing to manual or UIBinder way, but that is something that we will try to demonstrate in the following weeks. Well, we do not have to support IE6/IE7 so this would be a good test, thanks for mentioning this! I will let you know when we create such a demo so you can take a look if you like. 

Let's see what will happen with Elemental2 in the following couple of weeks, I think Julien is working on it and if I remember well he said somewhere that he will have something in the following month or two. Anyway, I hope your fears will not come true.

Cheers.

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

[David]

did you post any articles about the design of your meta approach - I'm very interested in reading a bit about it to see if I can learn from it ? I've seen similar approaches where an XML representation was used (looking a lot like XUL syntax), but I had to help in improving the performance and factoring out GXT widgets with custom made ones.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFHJR8Wpeq1HqUG8OsGfxgcLqnnXwtgAmNh-ig5bm%2BwYkv4q1Q%40mail.gmail.com.

[CodeLess Solutions]

No, but intend to will write a blog or an article about this. I will let you know when it's done. Probably in a few weeks as I need to write some other things before this.

In the meantime, you can take a look here: http://www.codeless.solutions or here: https://www.youtube.com/channel/UCgyHx-eZSXvVPvAVKa6BhHg

Maybe you will understand a bit more from the movies. Note: When you design the form in Form Designer you are working with real widgets (you drag and drop, move around real widget), when you save the form you only save Meta description of it, you do not save any UIBinder file, or Java file with content like: TextBox tb = new TextBox("text") anywhere. In other words, this is not a simple generator. The proof is that you can use new form immediately without the need to compile anything as shown in the movies, otherwise it would not be possible. That is what I call "Remote" meta form. The same as remote you can get with "Local" meta form (Local is written each time you save it in Form Designer so it's exactly the same as remote). Instantiation of real widgets from meta description is very fast and you will not notice any performance degradation. The similar counts for Remote meta form. If form (meta description) is missing, it will be fetched but only once, similar how gwt code splitting works but with the difference that here you can control this cache in the runtime (see Cache Manager movie).

This is not XUL and it does not use a single XML file. Yes it could, but there is no reason to do so.

BTW, I hope you are ok there in Leuven, not so nice things are happening recently in the Bruxelles.

P.S. Fill free to email me with any question you might have.

[David]

Thanks for the info. 

And don't worry, Leuven is still a peaceful and quite city which is worth a visit thanks to its vibrant nightlife, shops and lots of students. Brussels is a bit less hospital at the moment since the underground is closed and there are a lot of armed forces keeping an eye out for our safety. But I'm sure this will be resolved in the coming days.

--

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/9bebcf1f-96a0-41de-91ac-150c192cc581%40googlegroups.com.

[CodeLess]

Yes, very nice city I know. I been there couple of times ~ 10 years ago when I was living in Rotterdam.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW2%3DXVz00WfwniVwqmTuCJ69HfnSKyxxYt_LC-RCo-ENqg%40mail.gmail.com.

[Ümit Seren]

Regarding the Java wrapper for 3rd party libraries: 

Typescript uses type definitions for 3rd party JS libraries (http://definitelytyped.org/). Potentially something similar could be done for GWT/Java or even one could leverage the Typescript type definitions to automatically create Java wrappers. 

AFAIK the gwt-polymer-elements (https://github.com/vaadin/gwt-polymer-elements) wrapper generates the Java custom element wrappers by leveraging the polymer static analyser (https://github.com/Polymer/hydrolysis), so there is no need to generate those wrappers by hand. 

I am not that concerned regarding the future of GWT. IMHO having a typed language such as Java (especially as Java8 reduces boilerplate quite a bit) with a good JsInterop is the way to go.  
BTW the new Dart release (1.13) features a new JsInterop system that looks quite similar to GWT's one and they are also working on a dev_compiler, that looks a lot like what the J2CL compiler will do (supposed to make it easier to consume Dart code from JS).

In the last ChromeDevSummit (https://developer.chrome.com/devsummit), that took place a couple of days ago, it became clear that Google is pushing the mobile web quiete a lot by exposing mroe and more native APIs and providing web-plattform primitives so that mobile web apps can compete with native apps. 

Until now performance and tooling has been much better for native app development but Google started to tackle the issues from different angles ranging from a fully type aware Javascript engine (Turbofan) to improved Dev Tools and new best practices (RAIL, app shell, service worker, etc). 
So I think GWT 3.0 (Elemental 2, JsInterop, J2Cl compiler) will be in a good place to leverage those things (maybe I am to optimistic and deliberately leaving out the pain of migration). 

[Julien Dramaix]

> Typescript uses type definitions for 3rd party JS libraries (http://definitelytyped.org/). Potentially something similar could be done for GWT/Java or even one could leverage the Typescript type definitions to automatically create Java wrappers. 

I'm working on a tool that could convert these d.ts files to Java classes annotated with JsInterop. Stay tuned.

--

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/432020a6-7b7d-4c94-96c6-a397b59be007%40googlegroups.com.

[CodeLess Solutions]

As I promised the last time, I have uploaded the video that demonstrates Meta Platform's performance: 1000 forms, 1000 tables, 10 different types of columns, 1000 rows in each table... it's 10.000.000 (10 millions) of distinct information in the database, 100 complex documents with 8 nested child each and 8 M2O on each child table... and all with 0 lines of code. 

You can find movie here: https://www.youtube.com/watch?v=APKFGGBMYIk&feature=youtu.be 

No UI and no controller code used in the demo. Note that this movie has been recorded on my 2 years old laptop so it's not the super computer responsible for such a performance ;-) All forms are Remote, if I switch all of them to Local, the performance would be even better. I will demonstrate this in coming weeks as well,

I will write a blog and description about this and the Meta Approach in general as I promissed the last time, you will be able to find it here http://www.codeless.solutions/ in couple of days. The same would be with 10.000 tables / forms as well, the point is that it's the simple as Pet Clinic application you can find on the site as well. Analytical Approach is the second most important approach after Meta Approach that we have discussed earlier. It means: make things simple and solvable and that is the whole point.

[CodeLess Solutions]

David,

Here is the post about Meta approach you asked for: http://www.codeless.solutions/#!Meta-Platform-survival-guide/enstx/566ac8fc0cf239106876cf13 

I believe it will give you the answer on your post question or at least an idea what you can do next.

Kind regards,

Predrag.

[stuckagain]

Thanks Predag,

I'm looking into it.

Best regards,

David

[James Nelson]

So, a little late to jump in, but figured I'd add my $0.02 to this conversation.

I've been hard at work building a future-oriented declarative UI DSL.

Specifically, I extended the Java 8 JavaCC parser to include xml, json and css expression syntax.

This allows creation of UI's like the following toy code:

<app
  ref = "root"
  title = "Hi"
  data =
      {
          // The one button uses postIncrement++ so we start its count at 1
          one: 1,
          // The two button uses ++preIncrement, so we start its count at 0
          two: 0,
          text: ""
      }
  class = .{
      .cls{
        background-color: #011151;
       }
      .cls .btn {
        background-color: #010931;
        color: white;
      }
    }
  >
  <box
        size = ( 300 * (()->150 + 10 * $root.data.one) )
        align = center
  >
      <button ref="one" text="Button 1" class="btn button1" onClick=e-> {
        $one.setText("You clicked one " + $root.data.one++ + " times");
      } />

      <button ref="two" text="Button 2" class="btn button2" onClick=e-> {
        $two.setText("You clicked two " + ++$root.data.two + " times");
      } />

  </box>
  <box align = center>
      <button text="Close" onClick=System.exit(0) />
  </box>
</app>

It allows you to freely mix and match any form of AST you care about,

then a code generation subsystem allows you to define handled for any tag or attribute,

where you can turn any valid ast structure into whatever generated java syntax you want.

The really fun part?  It creates an interface, a base class and any number of implementations, with both GWT and JavaFX currently supported (Android support next; maybe iOS via J2ObjC some day).

For GWT, I am currently using Elemental 1 for low-level implementations, however, the abstractions are all designed to be completely orthogonal to low-level wiring.
Only the implementation classes know about GWT at all, so you can focus on business logic and correct abstractions, instead of making business logic dependent on UI implementation details.

The final bit I am working on before doing an official public release is the tag generator.
That is, a generator for the tag "define-tag", which will create not just the api, base and impl classes, but generate a code generator to then handle that tag in other UIs.

Best of all, the GWT implementation actually exports web components, so your defined "XApi declarative UI tag" actually becomes a web component bound to your java classes,
which can use DOM attributes as accessors  to primitives, and javascript for any kind of interop you want to do with the outside world.

Here is an example component I am using in my prototype:

<define-tag
    name = "Point"
    tagName = "wti-point"
    model =
        @Extend("HasAuthors")
        @Import("de.mocra.cy.shared.model.*")
        {
            lines: @Many // Ensures treatment of field as List-Type.
                IntTo.class.$generic(ModelText.class),
            title: String.class,
            hasLinks: public boolean hasLinks(){
                return getLines().hasMatch(t->t.allText().hasMatch(TextNode::isLink));
            }
        }
    api = [
        public String getTitle() {
            return $model.getTitle();
        }
        ,
        public $Self setTitle(String text) {
            $model.setTitle(text);
            return this;
        }
    ]
    impl =
    @Import({
        "de.mocra.cy.shared.ast.WtiParser",
        "de.mocra.cy.shared.css.HasWtiStyle",
        "de.mocra.cy.shared.css.WtiStyle"
    })
    [
        private HasWtiStyle resources;, // ugh;, semicolon comma on purpose. , is for json array parser
                                        // Either make it a statement w/ semi-colon, or use (parens)
        public HasWtiStyle getResources() {
            return resources;
        },
        public WtiStyle getStyle() {
            return resources.css();
        },
        public $Self ui() {
            return this;
        }
    ]

    ui =
        <box>
            <if notNull=$model.title>
                <wti-title ref="title">$model::title</wti-title>
            </if>
            <for allOf=$model.lines as=text>
                // setting the model directly is the cue for the generator
                // that this is going to be an ElementWithModel that has a .fromModel method.
                <wti-text model=text style=getResources() />
            </for>
        </box>

/define-tag>

Finally, this framework is good for more than just UIs...  I also use it to generate all sorts of other repetitive tasks;

for example, TriFunction or QuadFunction, etc...  The java sdk functional interfaces are pretty sparse,

so I've taken to generating my own extrapolations of N-ary functional interfaces (by default scaling up to 5-in, 5-out, with potential to dynamically generate higher arities if needed for method references.

package xapi.fu.out;
@Generate(
    in = {
        <var name = "max"
            default = 5 />,
        <var name = "types"
            default = ["Type", "Int", "Long", "Double", "Bool"] />
    },
    out = {
        <loop
            from = 1
            to = $max
            var = "size"
        >
            <generateInterface
                var = {
                    typeParams :
                        $range(1, $size, $i->`O$i`),
                    wrappedParams :
                        $range(1, $size, $i->`Out1<O$i>`)
                }
                template =
                    @Import({
                        "xapi.fu.HasOutput",
                        "xapi.fu.Rethrowable",
                        "xapi.fu.Lambda"
                    })
                    public interface Out$size <$typeParams>
                                extends HasOutput, Rethrowable, Lambda {

                     Immutable$size <$wrappedParams> outAll();

                     @unfold(from = 1, to = $size, var = "n")
                     default O$n out$n(){
                         return out$nProvider().out1();
                     }

                     @unfold(from = 1, to = $size, var = "n")
                     default Out1<O$n> out$nProvider(){
                         return outAll().out$n();
                     }

                     @unfold(from = 1, to = $size, var = "n")
                     default Out$size<$typeParams> read$n(In1<O$n> callback){
                         callback.in(out$n());
                         return this;
                     }

                     @unfold(from = 1, to = $size, var = "n")
                     @var(
                         name = "outParams",
                         value = $range(1, $size, $p ->
                             $p == $n ? "To" : `O$p`)
                     )
                     default <To> Out$size<$outParams> mapped$n(In1Out1<O$n, To> mapper){
                         return Out.out3(
                           $range(1, $size, $p ->
                               $p == $n ? mapper.supplyDeferred(out$pProvider()) : out$pProvider()
                           )
                         );
                     }

                     @unfold(from = 1, to = $size, var = "n")
                     default <To> Out$size<$typeParams> spy$n(In1<O$n> callback){
                         return
                           $if($size == 1, $print(()->{
                               O1 out = out1();
                               callback.in(out);
                               return out;
                           }))
                           .$else(
                               Out.out$size(
                               $range(1, $size, $p ->
                                   $p == $n ? out$pProvider().spy1(callback) : out$pProvider()
                               )
                           )
                         );
                     }


                }
            /generateInterface>

        </loop>,

        <loop
            from = 1
            to = 3
            var = "size">
            <var name = "asPrimitive"
                value = {
                    Type:"O$n",
                    Int:"int",
                    Long:"long",
                    Double:"double",
                    Bool:"boolean"
                } />,
            <var name = "asObject"
                value = {
                    Type:"O$n",
                    Int: "Integer",
                    Long: "Long",
                    Double: "Double",
                    Bool: "Boolean"
                } />
        </loop>
    })
public class Out {
}

So, it's definitely a work in progress, but I am hoping that the community finds value in it, and it gains more than one maintainer going forward. :-)

[Jens]

Wow that looks too weird for me to see any value in it :D

[Predrag Remark]

@James, do you have any working example (link to some site where application is hosted or youtube video of locally running application) of your framework that you can share with us ?

Can you create something like this http://petclinic.cloudapp.net/ with your framework and then to demonstrate (create video or deploy somewhere) how that would work and how the code looks like ?

Here is the version of Spring Pet Clinic made with Meta Platform: https://www.youtube.com/watch?v=gAN6iWAStZ8

It's done without any code. There is no Java, JavaScript or any other scripting code anywhere.

It's hard to understand how your framework is working from this 3 code snippets. I would like to learn more.

Thanks for sharing your thoughts,

PR

[Thomas Broyer]

On Thursday, January 26, 2017 at 7:33:06 PM UTC+1, Jens wrote:

Wow that looks too weird for me to see any value in it :D

+1

I tend to remove as much "magic" as possible from my projects, even if that means writing 2 lines of code instead of 1, trying to have the code be as explicit as possible, removing as much "context awareness" as possible, and using code generation only for boilerplate (OK, "templating" is a bit special here).

That said, it always surprises me how James come up with those kind of tooling, making things appear simple (to use), though (I suspect) being very complex on the inside, in (generally) so little time. James is a machine!

[Predrag Remark]

It's interesting how people think differently about the question: "How software development should look like" :-) 

From the couple of the last posts we can see that:

One person think that James framework is too weird to have any value in it, other one respects his hard work and wants to learn more from it and the third one thinks that it's great and appears to be simple to use.

 

One person think that applications like Spring's reference Pet Clinic application is complete boilerplate (except the ui templates), other one think it's better to write more code than less as he (thinks) will loose some power that should be in his hands (but he doesn't realize that this is not "writing of 2 lines of code instead of 1", it's 100 person months compared to 5 person months to achieve the same, take a look at Forrester Research of low code platforms: http://informationsecurity.report/view-resource.aspx?id=2915).

I think that different opinions are great. Different thinking can only bring more value. I really respect each one's opinion and of course if we all think the same, the world wouldn't have any progress at all.

Hopefully there will be more of that, 3 reactions in one day on someone's asking for opinion and possible help to bring something new on the table looks like 3 guys (with different opinions) are standing in the desert wondering where is the water and all of them are looking in the different directions. Far, far away, one guy is asking for help, he is thirsty and he is looking for water. Looks like the story, but the comic one...

Hopefully guys from G will finally give us something soon before it's too late. J2CL, Elemental 2 ? Singular is not even worth mentioning...

Take a look at this post from Julien Dramaix (just scroll up):

"I'm working on a tool that could convert these d.ts files to Java classes annotated with JsInterop. Stay tuned." It was 24.11.2015. and now is 27.01.2017. 

I'm still tuned... 

[James Nelson]

Hi Predrag;

There is not currently an online demo of the framework just yet,

but the prototype application being built with it is designed to make explaining complex ideas and processes as simple and as concise as possible,

and it will certainly contain tutorials on how the custom elements are defined and generated.

When that demo is ready, I will post about it here and in the G+ group, as well as pushing fresh jars to maven central.
I would set an ETA on that to mid-February; the demo project itself is actually higher priority than the framework,

but that is a discussion for another thread.

As for Thomas' guess, he would be right that it is ....a bit on the complex side internally,

though I am slimming it down to make each piece an independent, intelligent unit that is easy to read and reason about.

The ultimate goal is that you can define an entire UI component in a single file, and have that component run on any supported platform (currently GWT and desktop; Android up next);

where some people like a minimum of magic bits, I like things to be as declarative as possible, with all boilerplate generated (preferably before GWT even starts).

My heuristic is "can I do something at build time so when I write implementations, I am writing the minimum amount of code possible".

In most cases, the data model and the actual ui rendering is almost everything; the actual wiring of elements, injecting css, managing shadow dom, binding web components, etc is all generated.

The one Bad Part (tm) that I will admit to is that this currently relies on a hacked GWT compiler (I maintain a fork of GWT);

I've been steadily reducing the amount of magic I need from that fork so I can eventually deprecate it...

The primary use case being arbitrary magic method injection (making my own GWT.create-like methods anywhere needed, like adding reflection support).

Instead of relying on whole-world knowledge from GWT to do that code generation and method swapping,

I'm instead using javac plugins to do a "precompile phase" which generates the necessary support classes, and swaps in the magic methods.

Since generators themselves appear to be on the way out, I was hoping to offer something of a replacement for those who like generated implementations;

if I find the time, someday, I might even expose the gwt.ext.typeinfo AST classes, though I doubt it will ever actually become a priority, as I don't really use Gwt generators anymore.

....Buuut, this is certainly a much lower priority goal; when J2CL is closer to going public, and people start missing their generators, I will likely polish it up and post about it then.

Because my javac generators run before the GWT compile, that means that, provided it plays nicely with incremental javac, it will also play nicely with incremental Gwtc.

By stripping all but standard compilation from GWT, it should become very fast; the only (obvious) problem there is how to invalidate a java type that depends on external resources...

Perhaps somebody here has some suggestions, but what I have been doing is emitting a @Generated({ "/path/to/resource", "abcHASHofFILE", ... }), containing all used source files,

and running a daemon process to monitor input files then forcibly recompile any dependents when those inputs change (I use a development server that runs javac or gwtc on demand).

It's a bit clunky, but it works.

Anyway,

I don't want to dangle something shiny and not deliver;

I'm hammering away at this demo every free minute,

but would be happy to discuss with anyone what features they think a good UI Templating system should offer.

My reference for the UI templating part the project was actually ReactJs...  I liked JSX, but felt like it was too ...rigid and opinionated;

also, I don't like how React throws away DOM elements, which makes it hard to integrate via standard HTML (yay custom elements / web components!).

The cross-platform aspect is due to the fact that my framework was born to do cross-platform service injection,

and adding UI generation is a natural evolution of that effort.

Once I get this demo finished, I'll likely upgrade to Elemental 2 (currently using Elemental 1),

and some day, when it is released and I no longer need JSNI or GWT magic methods, J2CL.

In the meanwhile, I'd love to hear what other developers would want in terms of binding declarative UI to java classes.

My current implementation creates classes for UI templates, with references to internal elements stored as fields (using the ref="name" attribute),

generates data models (which have generated CRUD endpoints), internal data fields (with simple unary expression support; no binary, etc. yet),

and some rudimentary looping / conditional / compile time evaluation.

Adding compile time methods is as simple as defining java methods that take either primitives or AST arguments,

so end users can add their own utilities without having to touch the more complex services.


Sorry if this seems ranty; the demo site is an implementation of something I call "structured markdown",

where I can embed tangential points [inside of a link]-> {

  so you can read a concise summary of an idea before diving deeper into subtopics that interest you.

}.  
Part of the demo content is explaining the technology used in the site,

which will include examples of the framework, as well as the ability to "view source" for any custom element (showing all generated java, css and source .xapi files).

Most of the work for viewing / editing source borrowed from the CollIDE project I took over when the Big G open sourced and ditched it.

Some might say I have too many irons in the fire... And they would probably be right.

But, at least after a half decade or so, all the grand plans are (finally!) coming to fruition. :-)

[CodeLess]

Hi James,

I am really looking forward to see it in the action.

Regards,

Predrag.