3 ms·

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

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.

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.