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

[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

-- 
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+unsubscr...@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.

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

[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.

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:
>
> 
> 
> 
> 
> 
> Your final cost is {{cost}}
> 
> 
>
> /* 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
>
>
> 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  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?
>>>
>>> http://stackoverflow.com/

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

[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

On Monday, 28 October 2013 20:11:44 UTC, Colin Alworth wrote:
>
> 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. 
>
> On Monday, October 28, 2013 3:08:47 PM UTC-5, Chak Lai wrote:
>>
>>
>>
>> On Monday, October 28, 2013 3:49:19 PM UTC-4, Jens wrote:
>>>
>>> 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 >>> 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 ... etc. 

>>>
>>>
>>> I guess you have to uncheck the checkbox "Display intranet sites in 
>>> compatibility view" in IE's compatibility view settings.
>>>
>>> -- J.
>>>
>>
>>
>>
>> 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.
>>
>

-- 
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+unsubscr...@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.

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

[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.




On Monday, October 28, 2013 4:11:44 PM UTC-4, Colin Alworth wrote:
>
> 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. 
>
> On Monday, October 28, 2013 3:08:47 PM UTC-5, Chak Lai wrote:
>>
>>
>>
>> On Monday, October 28, 2013 3:49:19 PM UTC-4, Jens wrote:
>>>
>>> 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 >>> 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 ... etc. 

>>>
>>>
>>> I guess you have to uncheck the checkbox "Display intranet sites in 
>>> compatibility view" in IE's compatibility view settings.
>>>
>>> -- J.
>>>
>>
>>
>>
>> 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.
>>
>

-- 
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+unsubscr...@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.

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

[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. 

On Monday, October 28, 2013 3:08:47 PM UTC-5, Chak Lai wrote:
>
>
>
> On Monday, October 28, 2013 3:49:19 PM UTC-4, Jens wrote:
>>
>> 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 >> 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 ... etc. 
>>>
>>
>>
>> I guess you have to uncheck the checkbox "Display intranet sites in 
>> compatibility view" in IE's compatibility view settings.
>>
>> -- J.
>>
>
>
>
> 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.
>

-- 
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+unsubscr...@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.

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

[Chak Lai]

On Monday, October 28, 2013 3:49:19 PM UTC-4, Jens wrote:
>
> 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 > 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 ... etc. 
>>
>
>
> I guess you have to uncheck the checkbox "Display intranet sites in 
> compatibility view" in IE's compatibility view settings.
>
> -- J.
>



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.

-- 
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+unsubscr...@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.

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

[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  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 ... etc. 
>


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

-- J.

-- 
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+unsubscr...@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.

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

[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  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 ... etc.  


-- 
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+unsubscr...@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.

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

[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);
  }
  //...
}


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. 


On Monday, October 28, 2013 12:00:57 PM UTC-5, Thomas Broyer wrote:
>
>
>
> 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  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)
>

-- 
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+unsubscr...@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.

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

[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  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)

-- 
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+unsubscr...@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.

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

[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)

-- 
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+unsubscr...@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.

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

[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 {
  void execute( T value );
}

and when we perform an rpc, we just decorate

service.doSomething( "david", modal( new Callback() {
  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

On Fri, Oct 25, 2013 at 5:59 PM, 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?
>
> http://stackoverflow.com/a/4725052/497700
>
> -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  wrote:
>>
>>> I just read through the notes from the GWT steering 
>>> committeeand
>>>  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+**unsubscr...@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+unsubscr...@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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe fro

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

[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



On Fri, Oct 25, 2013 at 11:19 PM, 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:
>
> 
> 
> 
> 
> 
> Your final cost is {{cost}}
> 
> 
>
> /* 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
>
>
> 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  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 o

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

[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.


On 26 October 2013 00:06, Ed  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
>
>
> 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).
>
> --
> 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+unsubscr...@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.
>

-- 
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+unsubscr...@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.

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

[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). 

-- 
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+unsubscr...@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.

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

[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:






Your final cost is {{cost}}



/* 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


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 > 
> 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?
>>
>> http://stackoverflow.com/a/4725052/497700
>>
>> -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  wrote:
>>>
 I just read through the notes from the GWT steering 
 committee

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

[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

On Friday, October 25, 2013 1:21:22 PM UTC-4, Ray Cromwell 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?
>>
>> http://stackoverflow.com/a/4725052/497700
>>
>> -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  wrote:
>>>
 I just read through the notes from the GWT steering 
 committeeand
  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.

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

[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

On Oct 25, 2013, at 1:21 PM, Ray Cromwell  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?
> 
> http://stackoverflow.com/a/4725052/497700
> 
> -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  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+unsubscr...@googlegroups.com.
> To post to this group, send email to google-we...@googlegroups.com.
> Visit this group at http://gro

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

[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.



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?
>
> http://stackoverflow.com/a/4725052/497700
>
> -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  wrote:
>>
>>> I just read through the notes from the GWT steering 
>>> committeeand
>>>  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+unsubscr...@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 yo

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

[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

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 >wrote:
>
>> I just read through the notes from the GWT steering 
>> committeeand
>>  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+unsubscr...@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+unsubscr...@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.

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

[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



On Fri, Oct 25, 2013 at 4:50 PM, Andy  wrote:

> I just read through the notes from the GWT steering 
> committeeand
>  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+unsubscr...@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.
>

-- 
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+unsubscr...@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.

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

[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 

> I just read through the notes from the GWT steering 
> committeeand
>  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+unsubscr...@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.
>

-- 
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+unsubscr...@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.