5 ms·

"Pathological love for Java and anything resembling Java." I've often sensed this, when they push stuff like [1] GWT and to some extent Dart. and of course th

"Pathological love for Java and anything resembling Java." I've often sensed this, when they push stuff like [1] GWT and to some extent Dart. and of course the entire android brouhaha. [1] https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/

cgs1019 14y ago
GWT takes the (very large) pool of capable Java programmers and magically enables them to become capable web programmers without mastering cross-browser subtleties. It's all about compartmentalization. For any/all its faults, that's an astoundingly immense value.
- chubot 14y ago
  It depends what you mean by "capable". It's more accurate to say it takes large pool of Java programmers and lets them write slow and bloated UIs with canned widgets that are subtly (or not so subtly) inappropriate for the task at hand. Google should be producing best-of-breed UIs, not ones that are easy for the unskilled to write. It's not like Google can't afford to hire the best. A main reason for the slowness is that GWT obscures the boundary between the client and the server. People end up writing things like: for (x in hugelist) { doSynchronousCall() } without realizing it. And then people test it on fast internal network connections and they don't realize what a poor experience results for average users/mobile users. Another problem with GWT is that the JavaScript world has moved extremely fast in the 4 or 5 years since GWT was developed -- and most programmers don't know how to interface GWT with native JS (and that would defeat the "purity' anyway). So they're locked out of that functionality. No matter how big the GWT team is, it can't keep up with the rest of the web advancing the state of the art in JavaScript. I've also heard from people working on the Wave codebase that GWT was a big part of the reason they were locked into a particular design and couldn't iterate. For some reason Java just encourages people to dump out mountains of code. Maybe you can get away with that on the server, but when generating JS it just leads to UIs that crash the browser.
  - justinmk 14y ago
    > People end up writing things like: for (x in hugelist) { doSynchronousCall() What are you referring to here? I use client-side GWT daily; it is clear that RPC success() and failure() callbacks are asynchronous. > the JavaScript world has moved extremely fast in the 4 or 5 years since GWT was developed ... So they're locked out. GWT uses the Closure compiler, which presumably takes advantage of modern javascript advantages. > when generating JS it just leads to UIs that crash the browser. I work on a very large GWT client-side application, and size is indeed becoming a problem. Java is like kudzu.
    - chubot 14y ago
      OK I guess I'm misinformed -- all I'm saying is that I've opened up a bunch of GWT applications in firebug / chrome developer tools. And I see lots of multi-second latencies and dozens or even hundreds (!) of round trips to the server. Which makes it clear to me that the developers don't understand what they are actually writing. I'll admit to being wrong on that one point, but I was upvoted like hell so I guess other people have the same impression of GWT that I do.
      - drivebyacct2 14y ago
        Server calls != synchronous... Why is this being downvoted? Calls to the server to update state do not have to be synchronous and it's fairly obvious that this is a mistake the parent poster is making in his obnoxious claims against GWT.
    - johnyzee 14y ago
      Consider GWT's code splitting when the codebase starts to become large: https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting https://developers.google.com/web-toolkit/doc/latest/DevGuid...
  - orangecat 14y ago
    Google is also developing AngularJS (http://angularjs.org/ http://angularjs.org/), a pure JS/HTML framework which I'm very impressed with.
luriel 14y ago
I still can't believe GWT is not an April fools that got way out of hand.
hermanhermitage 14y ago
Having used GWT for a large web application it is hard to say much positive about building web client applications in Java. The GWT compiler technology and debugger support are great... but the flaws and rigidity of the Java language are so deep that quickly it becomes frustrating. Yes you get the syntax and semantics of java which may be a benefit for certain developers to quickly produce web apps but the abstraction is leaky and the nature of the language is unsuited for use in the browser (or GUI programming in general). I think the results speak for themselves - anyone care to name a GWT application from google with a world class GUI?
- cromwellian 14y ago
  flights.google.com or google.com/hotelfinder for example. Parts of Google Docs use GWT. Oh, and of course, Angry Birds for HTML5 was done with GWT. :)
  - hermanhermitage 14y ago
    Flights is a bit thin on, hotelfinder is better but on my iPad here it's got that typical clunky google UI feel - and to be fair they aren't a design or GUI strong company - but it's clear they are making steps to address it. Good point - Angry birds is an excellent counter example and fair use case for GWT. It's not what I'd call a GUI app - I was more thinking Forms, Document interaction (word, excel, illustrator, photoshop). I see a strong use case for Java on GWT, emscripten et al for apps like games that are a universe to themselves, using a very narrow surface area (canvas, ogl) of the browser application interface. Where these abstractions fall down for me is the friction at every interface interchange. In java case that's callback friction (brievity matters to me), the heavy burden of types on variables versus values, a verbose and inarticulate typing system, and like C/C++ and many Algol derivatives a complete paucity of expressive Literals for expressing all data types that can be modelled by the type system.
latj 14y ago
They dont seem to be "pushing" GWT too hard at IO this year.

cgs1019 14y ago

GWT takes the (very large) pool of capable Java programmers and magically enables them to become capable web programmers without mastering cross-browser subtleties. It's all about compartmentalization. For any/all its faults, that's an astoundingly immense value.

chubot 14y ago
It depends what you mean by "capable". It's more accurate to say it takes large pool of Java programmers and lets them write slow and bloated UIs with canned widgets that are subtly (or not so subtly) inappropriate for the task at hand. Google should be producing best-of-breed UIs, not ones that are easy for the unskilled to write. It's not like Google can't afford to hire the best. A main reason for the slowness is that GWT obscures the boundary between the client and the server. People end up writing things like: for (x in hugelist) { doSynchronousCall() } without realizing it. And then people test it on fast internal network connections and they don't realize what a poor experience results for average users/mobile users. Another problem with GWT is that the JavaScript world has moved extremely fast in the 4 or 5 years since GWT was developed -- and most programmers don't know how to interface GWT with native JS (and that would defeat the "purity' anyway). So they're locked out of that functionality. No matter how big the GWT team is, it can't keep up with the rest of the web advancing the state of the art in JavaScript. I've also heard from people working on the Wave codebase that GWT was a big part of the reason they were locked into a particular design and couldn't iterate. For some reason Java just encourages people to dump out mountains of code. Maybe you can get away with that on the server, but when generating JS it just leads to UIs that crash the browser.
- justinmk 14y ago
  > People end up writing things like: for (x in hugelist) { doSynchronousCall() What are you referring to here? I use client-side GWT daily; it is clear that RPC success() and failure() callbacks are asynchronous. > the JavaScript world has moved extremely fast in the 4 or 5 years since GWT was developed ... So they're locked out. GWT uses the Closure compiler, which presumably takes advantage of modern javascript advantages. > when generating JS it just leads to UIs that crash the browser. I work on a very large GWT client-side application, and size is indeed becoming a problem. Java is like kudzu.
  - chubot 14y ago
    OK I guess I'm misinformed -- all I'm saying is that I've opened up a bunch of GWT applications in firebug / chrome developer tools. And I see lots of multi-second latencies and dozens or even hundreds (!) of round trips to the server. Which makes it clear to me that the developers don't understand what they are actually writing. I'll admit to being wrong on that one point, but I was upvoted like hell so I guess other people have the same impression of GWT that I do.
    - drivebyacct2 14y ago
      Server calls != synchronous... Why is this being downvoted? Calls to the server to update state do not have to be synchronous and it's fairly obvious that this is a mistake the parent poster is making in his obnoxious claims against GWT.
  - johnyzee 14y ago
    Consider GWT's code splitting when the codebase starts to become large: https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting https://developers.google.com/web-toolkit/doc/latest/DevGuid...
- orangecat 14y ago
  Google is also developing AngularJS (http://angularjs.org/ http://angularjs.org/), a pure JS/HTML framework which I'm very impressed with.

luriel 14y ago

I still can't believe GWT is not an April fools that got way out of hand.

hermanhermitage 14y ago

Having used GWT for a large web application it is hard to say much positive about building web client applications in Java. The GWT compiler technology and debugger support are great... but the flaws and rigidity of the Java language are so deep that quickly it becomes frustrating. Yes you get the syntax and semantics of java which may be a benefit for certain developers to quickly produce web apps but the abstraction is leaky and the nature of the language is unsuited for use in the browser (or GUI programming in general). I think the results speak for themselves - anyone care to name a GWT application from google with a world class GUI?

cromwellian 14y ago
flights.google.com or google.com/hotelfinder for example. Parts of Google Docs use GWT. Oh, and of course, Angry Birds for HTML5 was done with GWT. :)
- hermanhermitage 14y ago
  Flights is a bit thin on, hotelfinder is better but on my iPad here it's got that typical clunky google UI feel - and to be fair they aren't a design or GUI strong company - but it's clear they are making steps to address it. Good point - Angry birds is an excellent counter example and fair use case for GWT. It's not what I'd call a GUI app - I was more thinking Forms, Document interaction (word, excel, illustrator, photoshop). I see a strong use case for Java on GWT, emscripten et al for apps like games that are a universe to themselves, using a very narrow surface area (canvas, ogl) of the browser application interface. Where these abstractions fall down for me is the friction at every interface interchange. In java case that's callback friction (brievity matters to me), the heavy burden of types on variables versus values, a verbose and inarticulate typing system, and like C/C++ and many Algol derivatives a complete paucity of expressive Literals for expressing all data types that can be modelled by the type system.

latj 14y ago

They dont seem to be "pushing" GWT too hard at IO this year.