3 ms·

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 synchronou

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 :)
jcampbell1 14y ago
> 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. 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.
chubot 14y ago
As mentioned below, the point about synchronous calls was made based on seeing 30+ second latencies in more than one GWT app and opening them up in firebug, and seeing a crazy number of roundtrips (with many of them serialized). With async APIs people can somehow still structure their applications so that logically many full round trips are needed to render the page. 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.
- cromwellian 14y ago
  I smell selection bias. Have you never visited HuffingtonPost, Gizmodo, or PandyDaily and looked at the network tab? Javascript does not automatically make people produce fast and snappy sites. That is based on experience, regardless of language. There are tons of websites that make a boatload of script include requests and image requests because the developers haven't learned about UglifyJS or Closure Compiler yet, or don't know about CSS spriting. Take a look at flights.google.com, it is a GWT app of non-trivial functionality that loads faster than most comparable sites (<2 secs) and makes far fewer requests. Another good one is the SpeedTracer app for Chrome (it runs as an extension). It has a very very nice UI, better than Firefox and WebKit WebInspector, and it's a GWT app. 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.

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 :)

jcampbell1 14y ago

> 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. 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.

chubot 14y ago

As mentioned below, the point about synchronous calls was made based on seeing 30+ second latencies in more than one GWT app and opening them up in firebug, and seeing a crazy number of roundtrips (with many of them serialized). With async APIs people can somehow still structure their applications so that logically many full round trips are needed to render the page. 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.

cromwellian 14y ago
I smell selection bias. Have you never visited HuffingtonPost, Gizmodo, or PandyDaily and looked at the network tab? Javascript does not automatically make people produce fast and snappy sites. That is based on experience, regardless of language. There are tons of websites that make a boatload of script include requests and image requests because the developers haven't learned about UglifyJS or Closure Compiler yet, or don't know about CSS spriting. Take a look at flights.google.com, it is a GWT app of non-trivial functionality that loads faster than most comparable sites (<2 secs) and makes far fewer requests. Another good one is the SpeedTracer app for Chrome (it runs as an extension). It has a very very nice UI, better than Firefox and WebKit WebInspector, and it's a GWT app. 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.