Unless I'm mistaken, they're not really comparable. GWT is an entire framework (Java front and back), as opposed to React being a component rendering library (the V in MVC). It would be more accurate to compare GWT to Node, or React to Polymer.
You do not /have/ to use the GWT serialization lib which comes with RPC. You can use JSON with GWT. It's actually very trendy and some new librairies simplify this.
But the combination GWT + node is surprising...
One of main advantages of GWT is you use the same language client-side and server-side. It's not at all "a swing portage" as it more or less used to be at the very beginning, but still, GWT comes from the Java world. If you want a strong-typed langage for your client code (big client application, huge dev team, or whatever), GWT is really the most mature solution today.
So :
* if you are ok with JS, and about making your backend in JS (I can't...), just use JS everywhere...
* if you want GWT, but a "reactive backend" like node, there are lots of good reactive backend-frameworks in the Java ecosystem
The backend part of GWT is really tiny : a RPC library which stays optional ; lots of people do not use at all nowadays.
I haven't took the time to look how react exactly work yet, but it seems the notion of virtual dom is really comparable to GWT initial component model. Even if the initial motivation is not the same, in both models there's a separation between the DOM and the components tree you manipulate.
I have done both. The answer is that it depends on what the problem is your are trying to solve, and what the team who will be doing the work has skills in. GWT uses the Java language and React uses Javascript so the two worlds are totally different.
Recently I picked React, but seeing the recent improvements in GWT I realise that GWT has improved leaps and bounds in the last two years and does somne things better than react
For example, 70% of inbox.google.com web app is written in Java and transpiled into JS. And front end is written in Closure. Inbox Android app uses the core as it is while iPhone app transpile the core via J2ObjC. Google Drive Spreadsheet, Calender are also built with this combination. I think Google values GWT not because it's good front end framework, but because of its power to share the code across different platforms.
8 comments
[ 4.5 ms ] story [ 34.5 ms ] threadYou do not /have/ to use the GWT serialization lib which comes with RPC. You can use JSON with GWT. It's actually very trendy and some new librairies simplify this.
But the combination GWT + node is surprising...
One of main advantages of GWT is you use the same language client-side and server-side. It's not at all "a swing portage" as it more or less used to be at the very beginning, but still, GWT comes from the Java world. If you want a strong-typed langage for your client code (big client application, huge dev team, or whatever), GWT is really the most mature solution today.
So :
* if you are ok with JS, and about making your backend in JS (I can't...), just use JS everywhere...
* if you want GWT, but a "reactive backend" like node, there are lots of good reactive backend-frameworks in the Java ecosystem
I haven't took the time to look how react exactly work yet, but it seems the notion of virtual dom is really comparable to GWT initial component model. Even if the initial motivation is not the same, in both models there's a separation between the DOM and the components tree you manipulate.
Recently I picked React, but seeing the recent improvements in GWT I realise that GWT has improved leaps and bounds in the last two years and does somne things better than react
Not that it's strictly relevant but people (including me before) often assume GWT is widely adopted at Google.