We've been using GWT-RPC for a while now as well, and the alternatives seemed less desirable the last time I poked around at them. Reading over some of the cited poor choices GWT-RPC, they seem to me to be more like "features" and "trade-offs" instead of simply being bad choices.
Version skew is a good example. It's cited as a negative, but in other contexts is actually a positive. The client has outdated information regarding the service/model objects? It SHOULD blow up. Old/new clients/servers communicating with each other I'm sure is commonplace at Google and in it's related applications, however this is absolutely unheard of in a static deployment environment, such as in consumer or enterprise deployments. Version skew actually catches deployment errors during testing in those situations.
The compile time argument has me scratching my head. I've listened to many presentations from Ray/Daniel regarding GWT (big fan, btw). The compiler is often cited as what separates GWT from those other JS lib technologies. I especially liked Daniel's dig at Angular via Singular, but it was a good demonstration of how powerful compile time analytics can trump a runtime library. To paraphrase: we have a powerful compiler, let it do work for you, you can't get that from <insert latest JS lib here>.
To cite GWT-RPC as requiring the compiler time-hit that it does strikes me as a choice/trade-off, not a negative. For some applications, it may be a "good thing" (tm), but a "bad thing" (tm) in others (see version skew above). To me, this feels like GWT is a little self-conflicted. We have this compiler, it could do a lot of work for us, but we don't want it to do too much work for us because we want it to be lightning fast! Maybe I'm just old-fashioned, but I'm ok with compilers taking extra time if it serves some value/purpose.
While I know there is this great "quest" to speed up GWT compiles such that developing in GWT has very little overhead as compared to just regular JS development, I would implore that a "carrot" approach is taken over the "stick." If, as a developer, I'm willing take a compile time hit for a feature (GWT-RPC or otherwise), seems like having the option would be a "good thing", while on the other hand the GWT compilation speed can still be lightning fast when we ask less of the compiler by not using such features.
On Wednesday, July 13, 2016 at 3:24:14 PM UTC-7, Daniel Kurka wrote:
-- Version skew is a good example. It's cited as a negative, but in other contexts is actually a positive. The client has outdated information regarding the service/model objects? It SHOULD blow up. Old/new clients/servers communicating with each other I'm sure is commonplace at Google and in it's related applications, however this is absolutely unheard of in a static deployment environment, such as in consumer or enterprise deployments. Version skew actually catches deployment errors during testing in those situations.
The compile time argument has me scratching my head. I've listened to many presentations from Ray/Daniel regarding GWT (big fan, btw). The compiler is often cited as what separates GWT from those other JS lib technologies. I especially liked Daniel's dig at Angular via Singular, but it was a good demonstration of how powerful compile time analytics can trump a runtime library. To paraphrase: we have a powerful compiler, let it do work for you, you can't get that from <insert latest JS lib here>.
To cite GWT-RPC as requiring the compiler time-hit that it does strikes me as a choice/trade-off, not a negative. For some applications, it may be a "good thing" (tm), but a "bad thing" (tm) in others (see version skew above). To me, this feels like GWT is a little self-conflicted. We have this compiler, it could do a lot of work for us, but we don't want it to do too much work for us because we want it to be lightning fast! Maybe I'm just old-fashioned, but I'm ok with compilers taking extra time if it serves some value/purpose.
While I know there is this great "quest" to speed up GWT compiles such that developing in GWT has very little overhead as compared to just regular JS development, I would implore that a "carrot" approach is taken over the "stick." If, as a developer, I'm willing take a compile time hit for a feature (GWT-RPC or otherwise), seems like having the option would be a "good thing", while on the other hand the GWT compilation speed can still be lightning fast when we ask less of the compiler by not using such features.
On Wednesday, July 13, 2016 at 3:24:14 PM UTC-7, Daniel Kurka wrote:
I summed up what I think about GWT RPC and it's future here:On Thu, Jul 14, 2016 at 12:01 AM JonL <jo...@percsolutions.com> wrote:While I agree that it could theoretically work with annotations, annotations require access to code, so for things you have no control over, you either would need to implement custom serialization anyways, or use the GWT serialization.I personally think there are optimizations to be had in the serialization policy generator that would prevent that whole classpath rescan issue, but I haven't had a chance to look into the code.If we were to use annotations, I think it would be better to use annotations on the RPC mechanism.
On Wednesday, July 13, 2016 at 9:23:19 AM UTC-7, Thomas Broyer wrote:
On Wednesday, July 13, 2016 at 5:53:20 PM UTC+2, Paul Robinson wrote:--
On 13 Jul 2016 9:17 a.m., "Kay Pac" <kmjs...@fastmail.fm> wrote:
>
> Will the gwt serialization mechanism used in GWT-RPC remain? GWT object serialization has been plugged into the atmosphere (realtime communication/websockets) GWT extension. It would be useful to know if we should migrate away from the GWT serialization and towards JSON.It's the serialisation that's the problem, so it will be gone in 3.0. JSON is a good choice. (I'm moving that way)
The actual problem is not serialization per se, it is that the RPC generator scans the whole classpath for subclasses of transferred classes to generate their specific ser/deser code (taking into account their CustomFieldSerializer if one exists).RPC (thus probably Atmosphere) could be made to work (as annotation processors) if they use another mechanism to determine what can be transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).I believe Daniel Kurka said something along those lines a year ago when first talking about those changes. The logical next question is: is there anyone willing to make those changes and continue to maintain GWT-RPC? The answer seemed to be (have been?) "at least that won't be Google", and this is why people start to "panic". That does not mean RPC will be gone (that doesn't mean it'll still be there either).But let's concentrate on 2.8 for now.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com .
To post to this group, send email to google-we...@googlegroups.com .
Visit this group at https://groups.google.com/group/google-web-toolkit .
For more options, visit https://groups.google.com/d/optout .
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment