3 ms·

I really like GWT. I will be writing some posts that will go into more detail.

by wedig 13y ago

jayvanguard 13y ago
I kid... partly. What I can't get over is a common justification for using GWT seems to be "but you can program in java and Swing then!", which only holds for fans of Swing. It seems is most often advocated by people uncomfortable with Javascript development and little UI development experience outside of Java. I don't think Swing is terrible but I do think it isn't particularly productive for user interfaces compared to Javascript or even Objective-C, C#, etc. So if all you have a Java/Swing hammer then GWT is great, otherwise not so much. In any event, I look forward to your post.
- wedig 13y ago
  No worries then :) I'm comfortable with JavaScript and I've never used Swing. I just use GWT to reach the browser, not to embrace it as an all encompassing framework or anything. I use Bootstrap as the UI starting point.
curun1r 13y ago
I gave up on GWT ~3 years ago, so some of this might have changed since then, but here is my list of things that annoyed me: * Compilation speed. Even when I dug into the compiler to increase parallelization, it was still dog slow. Yes, running in hosted mode helps, but compiles were still frequent enough that we'd have coffee breaks simply to wait for the compiler to finish. * Testing. GWTTestCase never worked right for me. And tests that don't run in pure Java are, again, slow. We got around it by writing a Java agent to transform the bytecode at classload time to intercept all of GWT's native methods, but this was a huge PITA. * Doesn't play well with others. The way that GWT loads makes it difficult to use on concert with other front-end frameworks/technology. * The inability to embed structured data in the page. The serialization in GWT's RPC is fantastic. Embedding type-unsafe JSON for reference data in a page seemed wrong. But GWT didn't give any supported way to serialize and deserialize outside of an RPC call. We eventually figured it out, but the solution involved having to sometimes include unused code in a RemoteService to ensure that the deserialization code was compiled in, which always felt hackish). Still, for what it was, GWT was always impressive. It's performance always beat what we were able to achieve with hand-coded JavaScript. Chrome has somewhat lessened the need to write high-performance JavaScript, but it's still impressive that GWT's generated code was that fast. And I've yet to encounter another RTE that was as easy to use and "just worked" as well as GWT's RTE. Every time I'm asked to do something with CKEditor or any of the native JavaScript options, I always wish that it was possible to use GWT's editor outside of a GWT application.

I really like GWT. I will be writing some posts that will go into more detail.

by wedig 13y ago

I really like GWT. I will be writing some posts that will go into more detail.

I kid... partly. What I can't get over is a common justification for using GWT seems to be "but you can program in java and Swing then!", which only holds for fans of Swing. It seems is most often advocated by people uncomfortable with Javascript development and little UI development experience outside of Java. I don't think Swing is terrible but I do think it isn't particularly productive for user interfaces compared to Javascript or even Objective-C, C#, etc. So if all you have a Java/Swing hammer then GWT is great, otherwise not so much. In any event, I look forward to your post.

wedig 13y ago
No worries then :) I'm comfortable with JavaScript and I've never used Swing. I just use GWT to reach the browser, not to embrace it as an all encompassing framework or anything. I use Bootstrap as the UI starting point.

curun1r 13y ago

I gave up on GWT ~3 years ago, so some of this might have changed since then, but here is my list of things that annoyed me: * Compilation speed. Even when I dug into the compiler to increase parallelization, it was still dog slow. Yes, running in hosted mode helps, but compiles were still frequent enough that we'd have coffee breaks simply to wait for the compiler to finish. * Testing. GWTTestCase never worked right for me. And tests that don't run in pure Java are, again, slow. We got around it by writing a Java agent to transform the bytecode at classload time to intercept all of GWT's native methods, but this was a huge PITA. * Doesn't play well with others. The way that GWT loads makes it difficult to use on concert with other front-end frameworks/technology. * The inability to embed structured data in the page. The serialization in GWT's RPC is fantastic. Embedding type-unsafe JSON for reference data in a page seemed wrong. But GWT didn't give any supported way to serialize and deserialize outside of an RPC call. We eventually figured it out, but the solution involved having to sometimes include unused code in a RemoteService to ensure that the deserialization code was compiled in, which always felt hackish). Still, for what it was, GWT was always impressive. It's performance always beat what we were able to achieve with hand-coded JavaScript. Chrome has somewhat lessened the need to write high-performance JavaScript, but it's still impressive that GWT's generated code was that fast. And I've yet to encounter another RTE that was as easy to use and "just worked" as well as GWT's RTE. Every time I'm asked to do something with CKEditor or any of the native JavaScript options, I always wish that it was possible to use GWT's editor outside of a GWT application.