5 ms·

GWT. To create client-side web apps, rather than writing Javascript, write Java and have it transpiled to Javascript. Java has IDEs, isn't a new language to le

GWT. To create client-side web apps, rather than writing Javascript, write Java and have it transpiled to Javascript. Java has IDEs, isn't a new language to learn (like Dart), has static type checking, support for refactoring in the IDEs, etc. GWT could do tree shaking, obfuscation, etc. You could write your server code in Java, and "call" remote server methods from your client code, "passing" Java objects transparently back and forth between the client and the server. It was released in around 2006, it was not without issues but seemed to be a much better way to develop complex client code than the Javascript options available in 2006, as far as I could see. It never really took off. Google moved their team over to Dart at some point. I guess the Oracle Java lawsuit meant Google were unenthusiastic about continuing to have anything to do with Java where they didn't need to. The compile times were slow. Not all Java compiled so you had to have a mental model in your head not only of Java but also the Javascript that was going to be generated which was mental overhead.

BjoernKW 9y ago
GWT was quite complex. You had to write a lot of code for achieving very little. There also was a huge impedance mismatch between Java and JavaScript at the time. Nowadays you can write decent functional code in Java but back then you needed anonymous classes for that.
- adrianmsmith 9y ago
  That's true, but while it was difficult back then to write functional code in Java (now solved), it was difficult back then to write class-based object-oriented code in Javascript (now solved).
  - abritinthebay 9y ago
    If you go into JS classes assuming they work at all like Java/C++ classes... you’ll have a bad time. They’re just sugar around protypical object-oriented code.
bambax 9y ago
What I would really like to know is why Google didn't buy Sun. It seemed such an obvious match. Did they try and fail, or did they not try, and why???
le-mark 9y ago
This came up a few weeks ago, and someone from google chimed in saying google just recently release new apps usin gwt, and it's still active. But I share your view that it was a failed technology. All the gwt I see in my area is legacy. I remember prototyping a project with it and being flummoxed by the ui not laying out the way it ought to have. From that experience, I never used it again.
- adrianmsmith 9y ago
  I haven't worked with GWT for about 5 years, but out of personal interest I want to a GWT conference in Florence, Italy a few weeks ago. The open source movement is still ongoing, but there is apparently no help from Google any more. Apparently Google do use GWT internally, but it's a fork and not the same as the open source version that we can all use. Apparently the reason is they integrate it with their own build tools (i.e. not Maven) that themselves are not open source. At the conference they were talking about GWT 3 which is basically a re-write, open source, but it seemed to lack a lot of the features that made GWT good. I appreciate the time they're devoting to the project, and don't want to sound ungrateful, but I do not expect a useful GWT 3 any time soon.
j_s 9y ago
In C# land, it also has yet to catch on. There is commercial backing right now, though. https://bridge.net/ https://bridge.net/
nickm12 9y ago
In addition to the ones mentioned, another issue with GWT was that the differences in browser JS environments were much more salient in 2006 (IE6 was still a massively popular browser) and browser development tools were limited. If your script didn't work, debugging was likely difficult.
- adrianmsmith 9y ago
  It was a stated goal of GWT to produce different JS files, one per browser, so that it could generate the right JS dialect for each browser. (And so that the browser didn't have to download "if" statements containing code for other browsers that it was never going to run, meaning a smaller downloaded, also relevant then.) That always worked perfectly for me, but I only used it for about 6 months, on a small project. Also, it had a debugging version where it actually ran the client code in a JVM, and you could step through it with Eclipse etc. Of course that didn't help if the bug only happened after the Java-to-Javascript compilation process, but in my short experience with it I never had such a bug. Of course Javascript and the browsers have caught up, but I would have expected these features to be gladly embraced by the development community at the time, as they really did help. But they weren't.
dehrmann 9y ago
There was a time when the consensus was that things like GWT were too far from the "bare metal" of the browser that issues in anything beyond toy projects were impossible to debug. Now we have React and JSX. Maybe the tooling just caught up.
leephillips 9y ago
Doesn't clojurescript use GWT? If it does, then GWT has certainly lived on. If I'm confused, sorry.
- adrianmsmith 9y ago
  I'm no expert but I think Clojurescript takes the Clojure language (spelt with a "j") and converts it to unoptimized Javascript, which then gets processed by the Closure compiler (spelt with an "s"). The Closure compiler takes unoptimized Javascript and emits optimized/minified Javascript. Closure is from Google, but is independent of GWT which is also from Google, despite the two projects having similar aims. Closure is modern, whereas GWT is not. The open source team who maintain GWT now (after Google abandoned it) are in the middle of a re-write, which will be called GWT 3 (current version is GWT 2). GWT 3 will convert Java to unoptimized Javascript and use the Closure compiler to optimize it etc (as Clojurescript does). Current GWT 2 does not use Closure but does its optimizations itself. I may have got some of that wrong, corrections welcome!
  - leephillips 9y ago
    Thanks for untangling that.
- bpicolo 9y ago
  They generated a Closure compiler implemented in js by running the closure compiler through GWT, but it's worse than the java equivalent (fewer features, slower)
tmzt 9y ago
Not using Java, but I'm working on non-JS iso rendering of web applications.
collinmanderson 9y ago
WebAssembly is probably the closest similar technology - the ability to compile any language into the browser.

BjoernKW 9y ago

GWT was quite complex. You had to write a lot of code for achieving very little. There also was a huge impedance mismatch between Java and JavaScript at the time. Nowadays you can write decent functional code in Java but back then you needed anonymous classes for that.

adrianmsmith 9y ago
That's true, but while it was difficult back then to write functional code in Java (now solved), it was difficult back then to write class-based object-oriented code in Javascript (now solved).
- abritinthebay 9y ago
  If you go into JS classes assuming they work at all like Java/C++ classes... you’ll have a bad time. They’re just sugar around protypical object-oriented code.

bambax 9y ago

What I would really like to know is why Google didn't buy Sun. It seemed such an obvious match. Did they try and fail, or did they not try, and why???

le-mark 9y ago

This came up a few weeks ago, and someone from google chimed in saying google just recently release new apps usin gwt, and it's still active. But I share your view that it was a failed technology. All the gwt I see in my area is legacy. I remember prototyping a project with it and being flummoxed by the ui not laying out the way it ought to have. From that experience, I never used it again.

adrianmsmith 9y ago
I haven't worked with GWT for about 5 years, but out of personal interest I want to a GWT conference in Florence, Italy a few weeks ago. The open source movement is still ongoing, but there is apparently no help from Google any more. Apparently Google do use GWT internally, but it's a fork and not the same as the open source version that we can all use. Apparently the reason is they integrate it with their own build tools (i.e. not Maven) that themselves are not open source. At the conference they were talking about GWT 3 which is basically a re-write, open source, but it seemed to lack a lot of the features that made GWT good. I appreciate the time they're devoting to the project, and don't want to sound ungrateful, but I do not expect a useful GWT 3 any time soon.

j_s 9y ago

In C# land, it also has yet to catch on. There is commercial backing right now, though. https://bridge.net/ https://bridge.net/

nickm12 9y ago

In addition to the ones mentioned, another issue with GWT was that the differences in browser JS environments were much more salient in 2006 (IE6 was still a massively popular browser) and browser development tools were limited. If your script didn't work, debugging was likely difficult.

adrianmsmith 9y ago
It was a stated goal of GWT to produce different JS files, one per browser, so that it could generate the right JS dialect for each browser. (And so that the browser didn't have to download "if" statements containing code for other browsers that it was never going to run, meaning a smaller downloaded, also relevant then.) That always worked perfectly for me, but I only used it for about 6 months, on a small project. Also, it had a debugging version where it actually ran the client code in a JVM, and you could step through it with Eclipse etc. Of course that didn't help if the bug only happened after the Java-to-Javascript compilation process, but in my short experience with it I never had such a bug. Of course Javascript and the browsers have caught up, but I would have expected these features to be gladly embraced by the development community at the time, as they really did help. But they weren't.

dehrmann 9y ago

There was a time when the consensus was that things like GWT were too far from the "bare metal" of the browser that issues in anything beyond toy projects were impossible to debug. Now we have React and JSX. Maybe the tooling just caught up.

leephillips 9y ago

Doesn't clojurescript use GWT? If it does, then GWT has certainly lived on. If I'm confused, sorry.

adrianmsmith 9y ago
I'm no expert but I think Clojurescript takes the Clojure language (spelt with a "j") and converts it to unoptimized Javascript, which then gets processed by the Closure compiler (spelt with an "s"). The Closure compiler takes unoptimized Javascript and emits optimized/minified Javascript. Closure is from Google, but is independent of GWT which is also from Google, despite the two projects having similar aims. Closure is modern, whereas GWT is not. The open source team who maintain GWT now (after Google abandoned it) are in the middle of a re-write, which will be called GWT 3 (current version is GWT 2). GWT 3 will convert Java to unoptimized Javascript and use the Closure compiler to optimize it etc (as Clojurescript does). Current GWT 2 does not use Closure but does its optimizations itself. I may have got some of that wrong, corrections welcome!
- leephillips 9y ago
  Thanks for untangling that.
bpicolo 9y ago
They generated a Closure compiler implemented in js by running the closure compiler through GWT, but it's worse than the java equivalent (fewer features, slower)

tmzt 9y ago

Not using Java, but I'm working on non-JS iso rendering of web applications.

collinmanderson 9y ago

WebAssembly is probably the closest similar technology - the ability to compile any language into the browser.