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()
}
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.
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.
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.
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.
https://developers.google.com/web-toolkit/doc/latest/DevGuid...
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
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)
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 :)
I use Adwords quite a bit, and it is buggy. I probably have to refresh every 10 minutes or so to get the buttons to work again. It is an absolutely massive application with more features than all of Google Docs combined, so I am not surprised. The bugs can be frustrating, but it is not like there is an alternative place to buy ads on Google's search pages. Google will be fine no matter how many bugs are in Adwords.
Adsense is quite simple, and works well.
That being said, Adwords has been getting much better.
I'm not necessarily saying that's GWT's "fault" -- the claim is that the developers writing GWT don't understand what they're writing. I said essentially what I said here to a tech lead of a GWT app and he's like... that's EXACTLY the problem we're having. This happened to be an app I've never even used, but he was shaking his head in agreement.
I think GWT was written by skilled engineers who had written tons of JS and got sick of the repetitiveness and the primitiveness of it in 2007 or whenever. But the claim of the OP: "GWT takes the (very large) pool of capable Java programmers and magically enables them to become capable web programmers" is not true. Empirically, people who've never written JS are writing GWT, and they are writing terrible web apps.
I guess you can say that tools create apps with a "smell". PHP creates web apps with injection security holes. C creates apps riddled with dangerous and costly buffer overflows (or used to before crazy amounts of compiler/library work). I'll take a dig at my favorite and say Python creates apps that dump stack traces on invalid input and don't handle signals correctly.
GWT's smell is creating bloated and slow apps now with bad UIs. I was pretty surprised at the number of upvotes I received, so I'm not the only one that smells it. Like C and others, it's possible that people will derive so much value the tool that they eventually learn how to overcome the pitfalls.
Anyway, why do you think Google does all of their hand-coded JS apps with Closure and the Closure Compiler? It's not because JS 'out of the box' is conducive to producing best-of-breed apps. Web programming requires a large amount of on-the-job acquired knowledge. How many people are aware of CSS selector performance, or the performance effect of reading element.offsetWidth?
GWT doesn't prevent you from shooting yourself in the foot, just like any other language. Producing optimal apps in any language requires experience in that language. Knowing how to arrange non-blocking behavior in script inclusion, or batching requests, is something that comes with experience. I wish I could produce a boilerplate framework that could make amateurs produce absolutely optimal apps out of the box, but that would trade off a lot of freedom.
However, GWT does offer tools to reduce your HTTP requests, and it's been doing this for years before they became common place in JS. For example, GWT has had automatic CSS spriting and image optimization since 2007. It's been doing CSS optimization nearly as long. GWT 'perfect caching' has been in from the beginning, which guarantees that most of the time, the app is loaded via a single HTTP request to a small 2k bootstrap file. In fact, it's possible to load your initial page: html, js, css, images in just 1-2 requests if you desire. Obviously, there are tradeoffs there too, that are platform and app-dependent.
There certainly are some APIs in the GWT SDK that can produce bloat if you use them, and that is wholly dependent on your preference. The GWT RPC system, for example, is great for internal apps, because it makes server communication trivial, but GWT also includes regular JSON/JSONP/XHR support. You can choose to use Widgets, or you can built your UI with HTML templates and CSS, just like you might do with Handlebars in JS.
I guess my point is this: I don't deny that an amateur Java programmer could take GWT and unknowingly compile a huge amount of junk into their app or make an insane number of HTTP requests. I just don't think producing apps with terrible startup latency is GWT specific, and I've seen enough websites in JS that are absolutely terrible to know that the way you get an optimal UI is by hiring good engineers with web experience, not by language choice.
And on that note, it's quite easy to get upvotes IMHO when you start a language war, because people are so opinionated on one side or another about it. My own personal opinion is that you should use the tools you feel most productive in, period, and if that's JS, or GWT, or CoffeeScript, or Objective-J, than more power to you.
He never claimed otherwise. His point seemed to be that if someone just picks up GWT and whips up an application, it's likely to exhibit some (severely) suboptimal behaviour here and there.