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
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<javascript:>>
> 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 <pul...@gmail.com> wrote:
>>>
>>>> I just read through the notes from the GWT steering
>>>> committee<https://groups.google.com/d/msg/gwt-steering/ldyo7OXUnHQ/ogtT-kPFoaoJ>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://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 <javascript:>.
> To post to this group, send email to
> google-we...@googlegroups.com<javascript:>
> .
> 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.
