5 ms·

GWT takes the (very large) pool of capable Java programmers and magically enables them to become capable web programmers without mastering cross-browser subtlet

by 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.
  - verra 14y ago
    AngularJS is like magic. Though it also got performance issues once you got large number of watchers/bindings (1000+)
- cromwellian 14y ago
  Maybe you shouldn't comment on GWT if you don't know anything about it. Pretty much everything you state about GWT is wrong. 1) GWT does not emulate synchronous APIs. That would incredibly expensive to do, requiring the implementation of continuation emulation or CPS transformation of the entire program. 2) GWT does not advocate "shielding" the developer from DOM or CSS. You are free to use the widgets, or not, just as you are free to use JS libraries with widgets, or not. The purpose of GWT isn't to hide the browser. 3) Most GWT programmers know how to interface with JS. I have not encountered any non-trivial GWT app that does not contain at least some portion that makes calls to JS. 4) On Javascript evolution. Sorry, Javascript has moved glacially slow. What has moved fast is the HTML5 API bindings. When ES6 arrives and GWT doesn't support it, then you have a point. 5) GWT is open source. It doesn't matter how big the GWT team is, it only matters how big the community is. 6) GWT UIs don't "crash the browser". Google derives the majority of its revenue from AdWords and AdSense, which are GWT, and if they were crashing customer's browsers like you say, I'm pretty sure Google would be in trouble. GWT is a compiler. You can write bad code, or you can write good code. In 2009 I ported jQuery to GWT. The resulting code was smaller than jQuery, and faster than all other competing libraries at the time. See the result here: http://www.youtube.com/watch?v=sl5em1UPuoI http://www.youtube.com/watch?v=sl5em1UPuoI I don't have anything against JS, and I don't think GWT is the right tool for every project, but I don't think you should respond to threads like this and make what appear to be authoritative statements which are obviously and completely false (synchronous calls)
  - jrockway 14y ago
    I'm going to agree. I have not written any GWT code, but I have heavily read a certain internal codebase that's a GWT app, and most of the time reading has been spent thinking, "wow, that's awesome". I think GWT's abstractions are excellent; the Java reads extremely well and generates code that makes interacting with HTTP APIs transparent. (Specifically, code reads like you are writing a command-line UI with in-memory dependencies, but is actually an async web app that gets all its data from various APIs. I think that's cool.) Like all abstraction layers, this could be good or bad. But there are definitely GWT features I wish I had about 5 years ago when I was writing web apps for a living :)
  - 14y ago
- deleted 14y ago
  [deleted]

by cgs1019 14y ago

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.
- verra 14y ago
  AngularJS is like magic. Though it also got performance issues once you got large number of watchers/bindings (1000+)
cromwellian 14y ago
Maybe you shouldn't comment on GWT if you don't know anything about it. Pretty much everything you state about GWT is wrong. 1) GWT does not emulate synchronous APIs. That would incredibly expensive to do, requiring the implementation of continuation emulation or CPS transformation of the entire program. 2) GWT does not advocate "shielding" the developer from DOM or CSS. You are free to use the widgets, or not, just as you are free to use JS libraries with widgets, or not. The purpose of GWT isn't to hide the browser. 3) Most GWT programmers know how to interface with JS. I have not encountered any non-trivial GWT app that does not contain at least some portion that makes calls to JS. 4) On Javascript evolution. Sorry, Javascript has moved glacially slow. What has moved fast is the HTML5 API bindings. When ES6 arrives and GWT doesn't support it, then you have a point. 5) GWT is open source. It doesn't matter how big the GWT team is, it only matters how big the community is. 6) GWT UIs don't "crash the browser". Google derives the majority of its revenue from AdWords and AdSense, which are GWT, and if they were crashing customer's browsers like you say, I'm pretty sure Google would be in trouble. GWT is a compiler. You can write bad code, or you can write good code. In 2009 I ported jQuery to GWT. The resulting code was smaller than jQuery, and faster than all other competing libraries at the time. See the result here: http://www.youtube.com/watch?v=sl5em1UPuoI http://www.youtube.com/watch?v=sl5em1UPuoI I don't have anything against JS, and I don't think GWT is the right tool for every project, but I don't think you should respond to threads like this and make what appear to be authoritative statements which are obviously and completely false (synchronous calls)
- jrockway 14y ago
  I'm going to agree. I have not written any GWT code, but I have heavily read a certain internal codebase that's a GWT app, and most of the time reading has been spent thinking, "wow, that's awesome". I think GWT's abstractions are excellent; the Java reads extremely well and generates code that makes interacting with HTTP APIs transparent. (Specifically, code reads like you are writing a command-line UI with in-memory dependencies, but is actually an async web app that gets all its data from various APIs. I think that's cool.) Like all abstraction layers, this could be good or bad. But there are definitely GWT features I wish I had about 5 years ago when I was writing web apps for a living :)
- 14y ago
deleted 14y ago
[deleted]