3 ms·

Technically GWT is still an active project. They're (slowly) working towards a 3.0 release. I use GWT in my day job.

by Bjartr 8y ago

acemarke 8y ago
I used GWT to build an app in 2011-2012. It was my first web app, and it needed to have a desktop-like feel. GWT + the SmartGWT UI library allowed me to leverage my existing experience with Java, its IDEs and tooling, and various desktop GUI frameworks to build an app that did what I needed. But, over time GWT became a hindrance rather than a help. The DevMode plugin stopped working as of FF27, and I had to keep around a copy of FF24 just to debug the client. The entire app had to be recompiled every time I made an edit and refreshed the page, wrapping JS libs to expose them to the Java code was a pain, and no one else on the team I moved to had ever worked with GWT. The discussion around this notional "GWT 3.0" didn't help either - it sounded as if half of the technologies around GWT would be removed, like GWT-RPC, but at the same time all the threads about it have been saying "well, J2CL is still internal to Google, we'll get it out eventually". Really uncertain future there. I spent the next couple years working on a JS app, introduced Backbone+Marionette, and became comfortable with JS. In mid-2015, I began exploring the idea of rebuilding my app's client with a modern JS stack, and decided to try these "React" and "Redux" things I was reading about. Prototyped a client rewrite, and it was clear this was the way to go. A few months ago that rewrite finally reached feature complete, and I got to go in and rip out every last line of GWT in the codebase. I was absolutely GLEEFUL when I did that :) The React+Redux codebase, with Webpack+Babel as the build toolset, allows us to iterate so much faster and with a better dev experience. I can understand why GWT would still have some semblance of usefulness in certain enterprise situations, but I would never touch it again myself.
- stickfigure 8y ago
  I think GWT suffered from being a bit too early. If source maps and Java8 closures existed in the early days, GWT would have been a lot more compelling. I also did a lot of GWT work about a decade ago and haven't touched it since. But there's a lot of things I miss, and I would be willing to consider a "modernized" GWT if it ever materializes. I especially miss GWT-RPC; statically checked typesafe interfaces are just much faster and safer than hand-coding REST interfaces and hoping the client and server agree. That said, I do think the train came off the rails when added all that crazy model-blah-blah-presenter pattern stuff. If GWT is ever going to make a comeback, it needs some sort of simple equivalent of Angular or React.
  - acemarke 8y ago
    Yeah, it's kind of funny when you look at what GWT had vs what modern JS development looks like. Multiple browser targets, using the same language on both client and server, static types, RPC declarations, a dev mode server, etc. That said, GWT-RPC also went from being nice to a pain. The serialization formats were "proprietary", in the sense that they were GWT-specific and couldn't be reused with any other platform. There were actually two separate formats. Client->server was some kind of custom text format, while server->client was _technically_ JSON, but the contents were still basically opaque. (I found a document that tried to reverse engineer the format, and it was pretty ugly.) That was another pain point, actually - inspecting API calls in a browser's Network tab was useless, because you couldn't interpret anything out of the contents. Also, I'll take promises (and `async/await`) over GWT's ugly `MyRpcInterface/MyRpcInterfaceAsync` definitions and success/failure handlers any day. When I rebuilt my app, I was lucky enough to be able to re-expose the same internal API endpoint implementations over JSON-RPC. That let me keep my existing backend logic, and build out the new JS client separately while keeping the old one in place until the new one was ready.
    - stickfigure 8y ago
      I agree the implementation of GWT-RPC could have been better. It was also pretty slow if the payload was a lot of tiny objects. But I'm less enthused with promises than you are; I like GWT-RPC's programming model. I'm surprised some sort of IDL-based client & server generator for REST services hasn't taken off.
      - bb88 8y ago
        Have you looked at Swagger's IDL? The big problem with an IDL that people want to avoid is tight coupling, IOW, all systems have to be upgraded at once to use a change in API.
stolsvik 8y ago
Tried Vaadin? It's a different take on the "write Java rich client code and run it in browser"-idea. It uses GWT as its "backend". They switched to GWT several years ago - too bad if they have to switch again due to GWT dying.

Technically GWT is still an active project. They're (slowly) working towards a 3.0 release. I use GWT in my day job.

by Bjartr 8y ago

Technically GWT is still an active project. They're (slowly) working towards a 3.0 release. I use GWT in my day job.

I used GWT to build an app in 2011-2012. It was my first web app, and it needed to have a desktop-like feel. GWT + the SmartGWT UI library allowed me to leverage my existing experience with Java, its IDEs and tooling, and various desktop GUI frameworks to build an app that did what I needed. But, over time GWT became a hindrance rather than a help. The DevMode plugin stopped working as of FF27, and I had to keep around a copy of FF24 just to debug the client. The entire app had to be recompiled every time I made an edit and refreshed the page, wrapping JS libs to expose them to the Java code was a pain, and no one else on the team I moved to had ever worked with GWT. The discussion around this notional "GWT 3.0" didn't help either - it sounded as if half of the technologies around GWT would be removed, like GWT-RPC, but at the same time all the threads about it have been saying "well, J2CL is still internal to Google, we'll get it out eventually". Really uncertain future there. I spent the next couple years working on a JS app, introduced Backbone+Marionette, and became comfortable with JS. In mid-2015, I began exploring the idea of rebuilding my app's client with a modern JS stack, and decided to try these "React" and "Redux" things I was reading about. Prototyped a client rewrite, and it was clear this was the way to go. A few months ago that rewrite finally reached feature complete, and I got to go in and rip out every last line of GWT in the codebase. I was absolutely GLEEFUL when I did that :) The React+Redux codebase, with Webpack+Babel as the build toolset, allows us to iterate so much faster and with a better dev experience. I can understand why GWT would still have some semblance of usefulness in certain enterprise situations, but I would never touch it again myself.

stickfigure 8y ago
I think GWT suffered from being a bit too early. If source maps and Java8 closures existed in the early days, GWT would have been a lot more compelling. I also did a lot of GWT work about a decade ago and haven't touched it since. But there's a lot of things I miss, and I would be willing to consider a "modernized" GWT if it ever materializes. I especially miss GWT-RPC; statically checked typesafe interfaces are just much faster and safer than hand-coding REST interfaces and hoping the client and server agree. That said, I do think the train came off the rails when added all that crazy model-blah-blah-presenter pattern stuff. If GWT is ever going to make a comeback, it needs some sort of simple equivalent of Angular or React.
- acemarke 8y ago
  Yeah, it's kind of funny when you look at what GWT had vs what modern JS development looks like. Multiple browser targets, using the same language on both client and server, static types, RPC declarations, a dev mode server, etc. That said, GWT-RPC also went from being nice to a pain. The serialization formats were "proprietary", in the sense that they were GWT-specific and couldn't be reused with any other platform. There were actually two separate formats. Client->server was some kind of custom text format, while server->client was _technically_ JSON, but the contents were still basically opaque. (I found a document that tried to reverse engineer the format, and it was pretty ugly.) That was another pain point, actually - inspecting API calls in a browser's Network tab was useless, because you couldn't interpret anything out of the contents. Also, I'll take promises (and `async/await`) over GWT's ugly `MyRpcInterface/MyRpcInterfaceAsync` definitions and success/failure handlers any day. When I rebuilt my app, I was lucky enough to be able to re-expose the same internal API endpoint implementations over JSON-RPC. That let me keep my existing backend logic, and build out the new JS client separately while keeping the old one in place until the new one was ready.
  - stickfigure 8y ago
    I agree the implementation of GWT-RPC could have been better. It was also pretty slow if the payload was a lot of tiny objects. But I'm less enthused with promises than you are; I like GWT-RPC's programming model. I'm surprised some sort of IDL-based client & server generator for REST services hasn't taken off.
    - bb88 8y ago
      Have you looked at Swagger's IDL? The big problem with an IDL that people want to avoid is tight coupling, IOW, all systems have to be upgraded at once to use a change in API.

stolsvik 8y ago

Tried Vaadin? It's a different take on the "write Java rich client code and run it in browser"-idea. It uses GWT as its "backend". They switched to GWT several years ago - too bad if they have to switch again due to GWT dying.