Friday, November 22, 2013

Re: Thoughts on GWT 3.0 re: Java 8 and IE 8/9

I think this is very important feature. We are using UIBinder extensively and we think it is a great step forward in therm of declarative design, however it is still hard to use and produce XML's by our UI designers. 
The best template engine I've ever seen for UI designers is Thymeleaf and Angular's so I'm looking forwart to seeing such feature in GWT.
Another great engine I know is that comes with Errai. The drawback is that it needs live application context and cannot be used separatelly.

On Friday, 25 October 2013 23:19:12 UTC+2, Ray Cromwell wrote:

We're thinking about introducing a way of developing UI that is more like traditional HTML design, you create HTML, CSS, and then attach behavior via Java. UiBinder is sort of like this, but it is not HTML and still requires building. What we want to do is follow the Web Components spec, which is a standards-based, browser supported, way of doing templating, which means GWT could interop with widgets developed in JS or Dart or any other language easily. There's not even an internal proposal for this yet, we expect to hash it out before the gwt.create conference.

But I could see it working something like this:

<!-- Foo.html -->
<html>
<head><link rel="import" href="shippingaddress.html"></head>
<body>
<acme-shipping id="ship"></acme-shipping>
Your final cost is {{cost}}
</body>
</html>

/* Foo.java */
class Foo {
  AcmeShipping ship; // auto-injected
  double cost; // auto-injected, both two-way databinding

  onChange() {
     cost = ship.calculateCost();
  }
}


Another option is angular-style, see my AngularGwt TodoMVC example:

We don't expect you to 'port' your existing apps to this. Those can keep using the old way, but if you are designing a new mobile phone or mobile tablet app, than it will be recommended to use this lighter weight approach. The way mobile browsers work, the less JS is involved in layout and DOM manipulation, the better in terms of performance. Daniel Kurka will have a talk on this.

-Ray


On Friday, October 25, 2013 10:32:27 AM UTC-7, Timothy Spear wrote:
Ray,

There is already two existing versions of most container components. Are you stating GWT will introduce a third? Or just migrate the Layout ones?
In addition, do you know if there will be significant changes to UiBinder?

Tim

On Oct 25, 2013, at 1:21 PM, Ray Cromwell <cromw...@google.com> wrote:


I think what we're really thinking about doing is preserving IE8 for the existing gwt widget stuff, but any features (APIs) we add going forward are going to leverage modern browser stuff, and we are not going to design (poorly performing, hacky) fallback/polyfill workarounds. 

For GWT 3.0, we are looking at making a new, parallel way of writing Web UIs that is based on the emerging Web Components standard, and we will lean heavily on modern browser layout engines, e.g. flexible box model.  We're not going to break your existing apps, but we're not going to make these new models work on old browsers. For example, to make data-binding working efficiently in Web Components, you need mutation observers, Node.bind, Object.observe(), etc. 

We are not going to require Java7 or Java8 to run servlet code or even invoke the compiler, but we will support compiling Java8 code to JS, and we'll have super-sourced versions of java.util.function/java.util.stream.

Basically, the future is easier interop with the browser APIs, external libraries, and web components, and less reliance on heavy weight widgets that run lots of JS and shield the browser. This is a vision more in tune with the fact that mobile is increasingly becoming a bigger and bigger chunk of the web, and the original GWT metaphor of a Desktop-like AWT/Swing-like UI library with layout done by executing code is less efficient on mobile and is suboptimal for fast browser jank-free execution.  We don't want to break existing applications, and we don't want to hamper designs for the future by requiring them to work on ancient browsers.



On Friday, October 25, 2013 8:59:28 AM UTC-7, Andy wrote:
Thanks for your input. It sounds like we're in the identical situation.

Regarding onFailure, do you use an abstract implementation of AsyncCallback, like I mention in this post?


-Andy

On Friday, October 25, 2013 11:47:43 AM UTC-4, stuckagain wrote:
IE8/IE9 I agree, we are in the same situation. Our customers only just migrated to IE8, so that will take at least 2 years before they will move on.
We could wait longer to move on to GWT 3.0, but the problem is that other customers are already asking for IE11 support. 

About Java8 support on the client, I am looking forward to lambdas instead of asynccallbacks, it would make my code a lot more compact! I only have one onFailure implementation so it would be great if the APIs would decouple these and allow for a default implementation.

But the gwt-servlet.jar will still need to be compiled for Java 7 compatibility or we will be really in big problems. A lot of customers are still running Java 6 on the server side.
Java 7 is about to become mandatory for us, but Java 8 that will take ages.

David



On Fri, Oct 25, 2013 at 4:50 PM, Andy <pul...@gmail.com> wrote:
I just read through the notes from the GWT steering committee and would like to share our perspective. I know you have a lot of survey results and we're just 1 company, but here's some more info based on our needs.

Java 8 only

I would encourage and support this move. I've been writing a ton of Javascript for the past few weeks and really miss the functional style when I come back to Java. Lambdas in Java 8 are going to be powerful and fun and they should be used liberally throughout the GWT 3.0 APIs. We won't be able to move our backend to Java 8 for a while, but since we only ship the JS output of the GWT compiler, I'm happy to use Java 8 for front-end development.

Dropping IE 8/9

We just decided on Tuesday to drop IE7 with our next release. We got tired of working around hasLayout bugs, etc. We have several major customers that still have users with XP/IE7, but after consulting with them, we decided we could go ahead with dropping support. Unfortunately, many of our customers are using IE8 and we won't be able to drop IE 8/9 anytime soon. As a developer this is extremely frustrating, but it's the sad reality of the enterprise.

So Java 8 would be awesome, but dropping support for IE 8/9 would prevent us from being about to use GWT 3.0 until our enterprise customers upgrade their browsers.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)