Elemental in GWT 2.5 is what?

[mp31415]

I'm trying to make some sense from that Elemental feature. But I'm definitely missing something. On 2.5 main page there is a link to a brief article about Elemental which really does not add much. GWT team is notoriously bad on documentation side and it's not getting any better. Just please don't tell me to shut up and use something else. It's impossible to see the big picture without some background information, like what was missing before, what real purpose of the feature is. It's very nice that we can now call some latest API but what about the more trivial stuff that say  UiBinder was in charge so far? Or maybe it is not about UI but more about better hiding JSO types? Or something totally different at all?

It's not any better with all other features in fact, but right now my gripe is about Elemental. 

I looked at the Collide project code. They reference elemental.* packages all over the place and elemental classes carry copyright statement from 2010. So is it new or just recently opened by Google?

I mean we get some random pieces of information from GWT team which I have a hard time stitching together.

And I didn't download yet 2.5 RC, as I prefer to understand things first, before diving into some low-level details.

Thanks.

[Thomas Broyer]

DISCLAIMER: this is what I know about Elemental, and my interpretation of it, and I haven't yet looked closely at it (its internals). Everything below can be read online (e.g. on Google+)

On Tuesday, July 10, 2012 12:34:13 AM UTC+2, mp31415 wrote:

I'm trying to make some sense from that Elemental feature. But I'm definitely missing something. On 2.5 main page there is a link to a brief article about Elemental which really does not add much. GWT team is notoriously bad on documentation side and it's not getting any better. Just please don't tell me to shut up and use something else. It's impossible to see the big picture without some background information, like what was missing before, what real purpose of the feature is. It's very nice that we can now call some latest API but what about the more trivial stuff that say  UiBinder was in charge so far? Or maybe it is not about UI but more about better hiding JSO types? Or something totally different at all?

The main thing about Elemental is that, for the most part, it's auto-generated, which makes it a breath to maintain: grab the IDL files from WebKit (yes, the same files that are being used to generate the C++ code that powers Chrome and Safari, themselves being more or less copies of what can be found in W3C specs) and regenerate the Java files out of them.

The goal is to be as close to the browser as possible, removing all abstraction layers.

That implies there's no deferred-binding being used: it's not meant to hide browser discrepancies, it's meant to be used in environments where those discrepancies don't exist or can be worked around in your code (code running in a UIWebView in a mobile "native" app, as a Chrome extension, or simply targeting only the most recent versions of browsers, where differences are vanishing a bit more each day that passes, thanks to the many standardization efforts).

Ideally, you no longer produce 1 permutation for each user agent, but a single one running everywhere (just like everyone else doing web dev out there, in JS, CoffeeScript, Dart, etc.)

In addition to that, Elemental is made of interfaces for the most part, so you can easily mock things in unit-tests, contrary to com.google.gwt.dom.client.* and the like.

(BTW, UiBinder doing "trivial stuff"? really?)

 

It's not any better with all other features in fact, but right now my gripe is about Elemental. 

I looked at the Collide project code. They reference elemental.* packages all over the place and elemental classes carry copyright statement from 2010. So is it new or just recently opened by Google?

Elemental is not new. It's only been open-sourced recently.

[mp31415]

Thank you very much Thomas for the expanded answer. (I'm somewhat worried about GWT as a "bus factor" looks close to one).

I understand what you say, but my question is more of an Elemental consumer nature. I mean it's definitely a big time saver for the GWT team to generate semi-magically all java wrappers for all existing and forthcoming features, it makes keeping GWT up to date much easier, but from GWT consumer point of view (i.e. all developers using GWT not developing it) it buys what? It's definitely better to have 5 permutations (e.g. per locale) instead of 30 but that's just compilation time, so it's nice but not critical. Also supporting old browsers still will add a few extra permutations anyway. 

The unit-test factor is probably important if you have them - I'm so far from them in my adventure, that I cannot appreciate this.

Removing all extra layers. Hmm... If we get too close to DOM and JavaScript then GWT advantage may be questioned as well. Java being a statically typed language is a double-edged sword. Those programming closer to the metal in fact prefer to stay behind extra layers of abstractions be it jQuery, CoffeeScript or Backbone.js.

Again I'm not questioning Elemental utility greatness, but so far it looks to be much more important to GWT "internally" than to the rest of us, mere GWT consumers.

Thanks.

P.S. Saying "UiBinder for doing trivial stuff" I meant trivial on my part, not on UiBinder part, I really appreciate UiBinder magic. I just hoped to find similar breakthrough with Elemental but it's probably not the case.

[Thomas Broyer]

On Tuesday, July 10, 2012 2:32:19 PM UTC+2, mp31415 wrote:

Thank you very much Thomas for the expanded answer. (I'm somewhat worried about GWT as a "bus factor" looks close to one).

I understand what you say, but my question is more of an Elemental consumer nature. I mean it's definitely a big time saver for the GWT team to generate semi-magically all java wrappers for all existing and forthcoming features, it makes keeping GWT up to date much easier, but from GWT consumer point of view (i.e. all developers using GWT not developing it) it buys what? It's definitely better to have 5 permutations (e.g. per locale) instead of 30 but that's just compilation time, so it's nice but not critical. Also supporting old browsers still will add a few extra permutations anyway. 

Not having permutations "per UA" is not only a compile-time thing, it also means you don't have to "sniff" the UA at runtime, so there's no risk of false-positives or false-negatives (http://code.google.com/p/google-web-toolkit/issues/detail?id=2938, http://code.google.com/p/google-web-toolkit/issues/detail?id=5278, http://code.google.com/p/google-web-toolkit/issues/detail?id=6665) and supporting a new browser (https://groups.google.com/d/topic/es-operating-system/8oWtRZnDK_w/discussion) comes for free.

 

The unit-test factor is probably important if you have them - I'm so far from them in my adventure, that I cannot appreciate this.

Removing all extra layers. Hmm... If we get too close to DOM and JavaScript then GWT advantage may be questioned as well. Java being a statically typed language is a double-edged sword. Those programming closer to the metal in fact prefer to stay behind extra layers of abstractions be it jQuery, CoffeeScript or Backbone.js.

AFAIK, CoffeeScript is not a "layer of abstraction" as its only a language that compiles to JS (similar to how Xtend is translated to Java: http://www.eclipse.org/xtend/ , or Traceur brings ES6 and experiments to any ES3 or ES5 engine http://code.google.com/p/traceur-compiler/ )

jQuery is known not to scale well on mobile (hence the jQueryMobile effort, or Zepto).

For every abstraction layer you have, you add bloat. Mobile or resource-intensive web apps (games, even running on desktop browsers) need to get rid of every bit of bloat. The closer you get to the browser, the faster you are. Feel free to add abstraction layers in your app, but you shouldn't have to pay for the ones of the library you use.

With Elemental now you have the choice: cutting-edge but rough, or with some candy but necessarily behind.

 

Again I'm not questioning Elemental utility greatness, but so far it looks to be much more important to GWT "internally" than to the rest of us, mere GWT consumers.

Everyone has different needs. "Enterprise" apps probably need even more full-featured widgets doing plenty of fancy stuff out of the box (SmartGWT, GXT), but there are also game makers (PlayN) and mobile devs. When you know what Google did to make GMail on Mobile start fast and run smooth, you understand why they'd need Elemental to do the same with GWT. http://googlecode.blogspot.fr/2009/09/gmail-for-mobile-html5-series-reducing.html (it was 3 years ago, but GMail is not really what could be called "resource intensive", so it probably holds true today, at a different scale)

[Derek]

On Tuesday, July 10, 2012 9:47:56 AM UTC-4, Thomas Broyer wrote:

Not having permutations "per UA" is not only a compile-time thing, it also means you don't have to "sniff" the UA at runtime, so there's no risk of false-positives or false-negatives (http://code.google.com/p/google-web-toolkit/issues/detail?id=2938, http://code.google.com/p/google-web-toolkit/issues/detail?id=5278, http://code.google.com/p/google-web-toolkit/issues/detail?id=6665) and supporting a new browser (https://groups.google.com/d/topic/es-operating-system/8oWtRZnDK_w/discussion) comes for free.

The goal is to only have a single permutation? I thought the multiple permutation system of GWT was only good (though admittedly I have been burned by IE9 and 10). Isn't it preferable to not send -moz-linear-gradient(...) to Chrome and -webkit-linear-gradient(...) to Firefox? (Same with mozIndexedDB vs webkitIndexedDB.) I thought this made the code smaller and better tailored than the "this or this or this" style of coding.

Also, assuming I go this route, how do I tell GWT to just do one permutation without UA concerns? I've been working on an app that I was originally only targeting webkit for (thus <set-property name="user.agent" value="safari"/>), but nothing in it should necessarily have broken in Firefox (besides the WebSQL stuff). So I decided to point Firefox to it, and immediately got an alert saying Firefox wasn't supported, despite the app working well enough. Obviously it was easy to fix by adding gecko1_8 to set-property, but how do I create the one permutation to rule them all that doesn't complain?

 

Again I'm not questioning Elemental utility greatness, but so far it looks to be much more important to GWT "internally" than to the rest of us, mere GWT consumers.

Everyone has different needs.

 

I'm very happy to be able to use Elementals to use a new Web API without having to hand-generate the overlays myself. (Haven't actually sat down to play with it yet, but I'm excited.)

[Thomas Broyer]

On Tuesday, July 10, 2012 4:45:43 PM UTC+2, Derek wrote:

On Tuesday, July 10, 2012 9:47:56 AM UTC-4, Thomas Broyer wrote:

Not having permutations "per UA" is not only a compile-time thing, it also means you don't have to "sniff" the UA at runtime, so there's no risk of false-positives or false-negatives (http://code.google.com/p/google-web-toolkit/issues/detail?id=2938, http://code.google.com/p/google-web-toolkit/issues/detail?id=5278, http://code.google.com/p/google-web-toolkit/issues/detail?id=6665) and supporting a new browser (https://groups.google.com/d/topic/es-operating-system/8oWtRZnDK_w/discussion) comes for free.

The goal is to only have a single permutation? I thought the multiple permutation system of GWT was only good (though admittedly I have been burned by IE9 and 10). Isn't it preferable to not send -moz-linear-gradient(...) to Chrome and -webkit-linear-gradient(...) to Firefox? (Same with mozIndexedDB vs webkitIndexedDB.) I thought this made the code smaller and better tailored than the "this or this or this" style of coding.

I think it depends the use cases ;-)

Browser sniffing has bad press, and for good reasons. That obviously doesn't mean feature detection has no cost.

The thing is: with modern browsers slowly reaching feature parity, the future is in the feature-detection side; differences between browsers are becoming marginal enough than putting them all in the same script with runtime checks doesn't cost that much (BTW, this is the approach used for com.google.gwt.geolocation, com.google.gwt.media, com.google.gwt.storage, etc. with deferred-binding mostly helping in saying "no" in browsers we're sure the feature isn't there)

 

Also, assuming I go this route, how do I tell GWT to just do one permutation without UA concerns? I've been working on an app that I was originally only targeting webkit for (thus <set-property name="user.agent" value="safari"/>), but nothing in it should necessarily have broken in Firefox (besides the WebSQL stuff). So I decided to point Firefox to it, and immediately got an alert saying Firefox wasn't supported, despite the app working well enough. Obviously it was easy to fix by adding gecko1_8 to set-property, but how do I create the one permutation to rule them all that doesn't complain?

To have only one true permutation, you'd have to get rid of everything doing deferred-binding on the user.agent property.

You can produce a single script using soft permutations http://code.google.com/p/google-web-toolkit/wiki/SoftPermutations but it only "hides" permutations, it doesn't remove them (browser-sniffing is still there, just moved out of the selection-script down to the permutation scripts).

[emurmur]

Elemental is a GWT api that exposes the raw browser api's defined in
the browser IDLs. So, Elemental is a 'to the metal' way of
programming the browser using Java (assembly programmers please
forgive the usage). It allows me to program the browser in a type-
safe language using direct browser api's with basically zero
overhead. Prior to Elemental, I've been using GQuery to do something
similar, but Elemental improves on this in that new API's are
implemented sooner and with full fidelity. For me, this means that I
can read any article showing how to use a new HTML5 api and implement
it in type-safe Java. I can more fully benefit from the experience of
the huge community of Javascript programmers that are constantly
experimenting with these new apis.

I will still use UIBinder and other GWT api's for widget-heavy UIs.
However, much of my work is now on mobile and tablets and does not
involve IE8 or prior, so Elemental offers a lighter-weight way to
handle these platforms.

It's true that there is very little formal documentation or examples
on Elemental right now. I hope that changes. I would expect that the
community will start to use it and that will result in a lot more
discussion and examples. I have a little tutorial that explains how
to get Elemental, CodeServer and Source Maps working within Eclipse,
I'll post that soon.

Ed

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I can see how this would be helpful for some apps - ones that need
HTML5 features, only need to support one (or a couple) of up-to-date
browsers, like mobile or tablet apps as others have mentioned.

But a huge selling point of GWT at my organization (where we don't
need HTML5 features and need to support as many browsers as possible,
even older IEs) is that a compiled GWT app more-or-less Just Works on
all our target browsers. Our devs mostly don't know - and don't want
to know! - browser-specific quirks or workarounds. We don't even have
easy access to Windows machines for testing with IE.

I get that UA sniffing is error-prone, but in my experience with GWT's
UA sniffing and permuted compiles, it works well enough to make
browser-specific fixups much, /much/ rarer than when I wrote apps with
plain JS and Jquery.

> the most recent versions of
>> browsers, where differences are vanishing a bit more each day
>> that passes, thanks to the many standardization efforts

I really hope you're right, though I'm very, very skeptical about this.

Implementing browser-specific workarounds and feature detection was
such a miserable process compared to having GWT do a permuted compile
that I do /not/ want to go back.

That code using Elemental is more easily mocked out and unit tested is
a great thing, for sure.

> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit
> https://groups.google.com/d/msg/google-web-toolkit/-/VEaRwNLJXKIJ.
> To post to this group, send email to
> google-we...@googlegroups.com. To unsubscribe from this
> group, send email to
> google-web-tool...@googlegroups.com. For more options,
> visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/8mXAACgkQ5IyIbnMUeTv1MgCfSPQ3CKPjH6O8CO/BTrTjD5u7
seoAn0wClmR20P5YTpbAEP1s3W1/ZmQU
=6gQe
-----END PGP SIGNATURE-----

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> (just like everyone else doing web dev out there, in JS, CoffeeScript, Dart, etc.)

TLDR: There are many of us out here, I suspect, for whom this is exactly
what we do not want.

Elemental sounds cool, but I'm glad it's optional. I hope that stays
the case, and that the permuted-compile use case stays well-supported
for the foreseeable future.

iEYEARECAAYFAk/8m1UACgkQ5IyIbnMUeTty+QCbBDoyDq4DnxqgwLdAew2XdhEC
AOMAniJ4ljyl/bKFQoKIUginr1ziPNZx
=DN8m
-----END PGP SIGNATURE-----

[Thomas Broyer]

On Tuesday, July 10, 2012 11:15:01 PM UTC+2, Clint Gilbert wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> (just like everyone else doing web dev out there, in JS, CoffeeScript, Dart, etc.)

TLDR: There are many of us out here, I suspect, for whom this is exactly
what we do not want.

Elemental sounds cool, but I'm glad it's optional. I hope that stays
the case, and that the permuted-compile use case stays well-supported
for the foreseeable future.

I see no reason it wouldn't be.

AFAICT, Elemental is not meant to replace what already exists, it's a new, different way of doing similar things (and more!) for people who need it. It's "new" as in "new choice", not "new vs. old".

As Ray said at I/O, it's best-suited for mobile apps where you need to cut every possible overhead, or for people who need to use bleeding-edge APIs without waiting for someone to hand-wrap them.

https://developers.google.com/events/io/sessions/gooio2012/218/