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

[Andy]

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.

[Dennis Haupt]

there should be simply no frameworks which support anything below ie9 at all, so the enterprise is forced to adjust :)

2013/10/25 Andy <pul...@gmail.com>

--
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-tool...@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.

[David]

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

--

[Andy]

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?

http://stackoverflow.com/a/4725052/497700

-Andy

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

[Ray Cromwell]

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.

[Timothy Spear]

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

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

[Andy]

Thanks Ray, I appreciate the detailed response.

We do most of our rendering server-side and use very few widgets, so it sounds like we'll be fine. We don't use any panels other than FlowPanel and we use simple widgets like Hyperlink and CheckBox with a few cases of SuggestBox and our own wrapper around a DateBox. We started using GWT with 1.5 and so have never used UiBinder and all of our CSS is done with SASS on the server-side.

That said, we have over 150k lines of GWT (including whitespace, comments, etc) and are pretty committed to it. We may be a bit unique, but we use GWT mostly as a (much, much) better version of coffeescript and rely heavily on the DOM/event abstractions, deferred binding, code optimization, JSNI, and RPC, and of course the ability to use Java for all of this.

Thanks for all of the great work you guys have done over the years. I'm really looking forward to 3.0.

-Andy

[Ray Cromwell]

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:

https://github.com/cromwellian/angulargwt/blob/master/src/main/java/com/google/gwt/angular/client/todomvc/TodoController.java

https://github.com/cromwellian/angulargwt/blob/master/src/main/webapp/angulargwt.html

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

[Ed]

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 

Can't wait ... Would love seeing this...

I feel the pain: a company abroad makes the html/css and then I put the logic behind it with gwt... But still find it far from optimal, used UIBinder a lot in the past, but not flex enough (not-change and test friendly). 

The develop process "gap" is simple too big which reduces productivity. 

I am sure that a higher and efficient/low cost productivity, realized with GWT, will surely attract more people using it (something I put this in the vaadin survey). 

[James Horsley]

Ray, sounds fantastic and can happily say that something along those lines would tackle many of the issues with GWT I noted in the current GWT survey. Will be eagerly awaiting the design docs and proposals.

--

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

[David]

Hi Ray,

Sounds good to me. Just a few questions on this approach:

- Will we be able to mix old and new style or will it be all-in or out ? Being able to mix is quite important in a big application since we need to add new functionality but we don't want to rewrite the old stuff, that is fully tested. If we can't mix it will mean either a complete rewrite of everything or not using the new technologies until I have the chance to start working on something completely new.

- Will this be compile time or runtime binding ? I know that GWT tends to prefer doing most of the work at compile time. But in our applications we often have UI that is rendered at runtime based on some meta-data. This meta-data  is only know at runtime so using a generator is not an option for us - unless we could interact with the GWT compiler on the fly. We tend to render stuff in bulk and then attach to the needed Elements. That is really fast, much faster than even UiBinder. We can even chose if the HTML bulk rendering takes place serverside or clientside.

David

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

[David]

Hi,

No, I am not using an abstract class, I just defined a one method interface (or you could reuse something in Guava or Java) and I am using a decorator approach to add error handling or modality in case we want to block the UI when an RPC call is happening. So you basically start with

interface Callback<T> {

  void execute( T value );

}

and when we perform an rpc, we just decorate

service.doSomething( "david", modal( new Callback<String>() {

  void execute( T value ) {

}));

Where modal is a static import that shows a glasspanel and animation to keep de user happy. It wraps the Callback into an AsyncCallback with our default error handler, but you can also use a second form of the modal function where you use 2 Callbacks one for success and one for failure.

This will easily map to Java 8 lambdas (Most of the time all we want to do in the callback.execute is to forward to a method of the class, so I could just pass the method reference instead of needing to create a Callback everytime).

David

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

[Chak Lai]

If IE7support is removed from GWT, will GWT run correctly on IE in Intranet? (IE will default to IE7 Browser mode for Intranet Website)

[Thomas Broyer]

On Monday, October 28, 2013 4:22:29 PM UTC+1, Chak Lai wrote:

If IE7support is removed from GWT, will GWT run correctly on IE in Intranet? (IE will default to IE7 Browser mode for Intranet Website)

Include the correct <meta http-equiv="X-UA-Compat"> in the HTML?

A Google search led me to http://tesmond.blogspot.fr/2011/10/ie9-intranet-compatibility-mode-in.html (which also links to http://blogs.msdn.com/b/ie/archive/2009/06/17/compatibility-view-and-smart-defaults.aspx)

Otherwise, well, just don't upgrade to a newer GWT: if you live in the past, don't use cutting-edge tools. (this is not a criticism)

[Colin Alworth]

We've found experimentally that the meta tag has no effect on IE8 when in intranet mode. We've further found that it does seem to respect the http header, which could be set in a filter like this:

public class LatestIEFilter implements Filter {
  @Override
  public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException {
    ((HttpServletResponse)resp).setHeader("X-UA-Compatible", "IE=latest");
    chain.doFilter(req, resp);
  }
  //...
}

<rant>
Since IE8-pretending-to-be-IE7 behaves like neither IE8 nor IE7 (at least not completely), I generally maintain that code trying to fit either one shouldn't be expected to work. IIRC, IE8-pretending-to-be-IE7 can't be distinguished from IE7, so the only way to make a library/application work in a so-called compatibility mode is to custom tailor it for that mode, and ignore the 'real' browser modes.
</rant>

[Chak Lai]

In Intranet environment, that META tag can only change IE Document Mode (such as how IE layout the web page), but it cannot change IE Browser Mode (such as IE's JavaScript Engine). It is because the Browser Mode is loaded (Intranet is detected) before IE parse the HTML.

Even with the <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> tag, in the Intranet environment IE 9 can display HTML5 sites in appearance only, but using IE 7's JavaScript engine, which does not support HTML5 feature like <canvas>... etc. 

[Jens]

In Intranet environment, that META tag can only change IE Document Mode (such as how IE layout the web page), but it cannot change IE Browser Mode (such as IE's JavaScript Engine). It is because the Browser Mode is loaded (Intranet is detected) before IE parse the HTML.

Even with the <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> tag, in the Intranet environment IE 9 can display HTML5 sites in appearance only, but using IE 7's JavaScript engine, which does not support HTML5 feature like <canvas>... etc. 

I guess you have to uncheck the checkbox "Display intranet sites in compatibility view" in IE's compatibility view settings.

-- J.

[Chak Lai]

My concern is even if the users are using IE9 or IE10, in Intranet the application can be broken because IE7 Browser Mode is being used, and the users or developers may not aware of what is going on.


P.S: In my opinion, it is great for GWT moving forward, and personally I hate dealing with IE. However, just heads-up for those who are stuck with Intranet + IE.

[Colin Alworth]

Chak, take a look again at my post - while the meta tag definitely does not work to tell IE8 to behave when in intranet mode, loading the exact same html content and sending the same ua-compat details over a HTTP header *does* solve this.

[Chak Lai]

I have tried your filter, and the IE Browser Mode has changed, however:

For IE8, I got Internet Explorer 8 Compatibility View, and the user agent is:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322; InfoPath.3)

For IE9, I got Internet Explorer 9 Compatibility View, and the user agent is:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/1)


I am not sure if your filter solves the issue; I would expect to see MSIE 8.0 for IE8 in the user agent.

[nas]

Hi Colin,

We are very excited about GWT3, with so many planned enhancements and improvements, can't wait.  

In terms of sencha GXT4 road map for web and tablets, I couldn't resist asking the question on the road map:  

will GXT4 be based on GWT3 with HTML like design with its possible enhancements above?

Using the latest browsers is not an issue for us.

Thanks,

Nas

[Piotr Kosmowski]

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.

[Mike Dee]

This sounds very much like Wicket.  When we were evaluating frameworks to use, about 2.5 years ago, to update our app it boiled down to Wicket and GWT.  Wicket had the advantage that it allowed designers and coders to work better together (markup and code in separate source files).  GWT won out because we are largely Java developers and it looked like designing an app that always filled the screen (for desktop and tablets - but not phones) would be easier.

I never understood why there wasn't more of a convergence between Wicket and GWT.  When uibinder was introduced I was hoping it would be more HTML-ish, like Wicket