Re: Elemental in GWT 2.5 is what?
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/ -- 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/-/XR7mV96P8B8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
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. -- 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-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
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. -- 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/-/phvjqORQWG8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
Elemental really is two things. Firstly, a set of collections that have very little overhead compared to the java emulated classes. They are created based on JSO objects and are about as performant as you can get. Secondly, a generated set of JSO mappings to ALL webkit/chrome exposed javascript api's. These are not hand created like the rest of GWT. Instead they are created by a python script that runs against the browser IDL defined interfaces. So elemental can be kept up to date with the bleeding edge of the web more easily. So you are asking what the point of this is? If you want maximum performing collections then you can use the new ones provided in elemental. If you want to write a GWT program with the minimum possible footprint then using the JSO elemental bindings will provide this. In addition, if you want to access some part of the browser api not covered by GWT then elemental will provide a way to do that. It is mainly targeted for writing code for modern html 5 browsers. I think the idea is to make it a bit more general than webkit/chrome in the future. On Monday, July 9, 2012 6:34:13 PM UTC-4, 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? 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. -- 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/-/zo9D8bBCrxsJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
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) -- 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/-/BYy_DMyB2AEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
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.) -- 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/-/fLWF8JlAGsEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
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). -- 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/-/YSbfkr-rZMcJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
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 On Jul 9, 3:34 pm, mp31415 mp_...@yahoo.com 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? 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. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Elemental in GWT 2.5 is what?
-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. On 07/10/2012 04:49 AM, Thomas Broyer wrote: 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. -- 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-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@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- -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to
Re: Elemental in GWT 2.5 is what?
-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. On 07/10/2012 05:06 PM, Clint Gilbert wrote: 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. On 07/10/2012 04:49 AM, Thomas Broyer wrote: 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. -- 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-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at
Elemental in GWT 2.5 is what?
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. -- 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/-/EHhuWV6M5ZUJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
