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.
