I've heard the Google Web Toolkit isn't that good for web sites with more than 5 pages and a common layout. Is that true? We have at least a 100 subpages and a common layout defined in CSSes. Today were using PHP but we will move to a Java front either Spring MVC or GWT. We're using som jQuery AJAX and other jQuery components like a jqGrid. We also have some .swf-films and fusion charts. Will opting for Spring combined with GWT be a good choice or is Spring MVC with a jQuery library a better choice for us?
-
14Where did you hear that GWT is not good for _web sites with more than 5 pages and a common layout_? Also, GWT is not made for web _sites_, but for web _apps_, if that can help you make your choice. – Thomas Broyer Apr 04 '12 at 10:40
5 Answers
It's not true now. Earlier GWT versions really had some issues with scalability (e.g. problems with JS code size in IE - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440), but since GWT 2.0 you have no limitations here.
Moreover, latest GWT versions support functionality for splitting projects to the parts that may be loaded dynamically when they're needed. Please refer to https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting to learn how it works.
Take into account also that since Spring is Java, you have possibility to share classes between server- and client-side. Plus Java has very good support in IDE - all kind of refactoring will be available for you (it is not so convenient in case you use jQuery).
So Spring+GWT looks more preferable choice.

- 649
- 3
- 13
GWT is not a universal framework for building just a any webapp from scratch. It is very useful when you have a lot of complicated logic on client side, (image editing, real time collaboration, diagram drawing, games , complex reports building and etc etc). But all of this can be done without GWT. GWT can be used when:
- your team hates/dislikes JS (and is unable to build nothing complex with JS, just because they hate JS)
- your team is quite experienced with Java
- your team understand how all this browser related stuff works (HTTP, JS, DOM , CSS and etc)
- in this project there are will be a lot of logic running on client side
I've seen quite a few big projects built completely with GWT. Some of them should never used GWT, because the were no reason for them to use it in such way. For most projects it is enough to use GWT only for some part of application.
The choice depends on your team and the project you are doing. If your team can't really see what benefits GWT will bring to the project, then you shouldn't use GWT.

- 9,850
- 1
- 42
- 57
Our enterprise-level application utilizes both and we're quite happy with the results. GWT is a powerful toolkit which lowers development time by orders of magnitude. That said, there are still things that GWT either doesn't handle all too well or just plain isn't suited for (and that's ok... that's why Spring MVC lives nearby). We have GWT-RPC hitting Spring services directly and it works incredibly well.
Our project though is a true webapp, not a website. We use a unified design which spans all "pages" (using a DockLayoutPanel
and swapping out just the center
makes this super easy).
IMO, whoever told you that GWT isn't good for consistent design across numerous "pages" is nuts...

- 22,308
- 13
- 63
- 94
I think any assertion that GWT (or any other method) lowers development time by an order of magnitude has already been debunked by Frederic Brooks in a time when shoulder pads and Jan Hammer's synthesizer were fashionable: http://en.wikipedia.org/wiki/No_Silver_Bullet.
But seriously, if you're a PHP shop, moving to 100% Java would be a huge investment, and not to be taken lightly.

- 531
- 3
- 7
-
3I'd disagree that GWT lowering development time was debunked by Brooks. His comment was "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity." He said that in 1989, stating that *within a decade* no such development would happen. It has been more than two decades, thus his statement was true *and* GWT offers exactly that which he said wasn't going to happen. – Chris Cashwell Apr 04 '12 at 12:59
-
I take his words to mean that no single technology leads to a tenfold increase in productivity within a decade after its widespread adoption; not that mankind's ingenuity would suddenly make a giant leap ten years hence. A combination of technologies just might do the trick. But has GWT in itself *really* made you ten times more productive? I'm not saying it can't. I love GWT, but it doesn't work miracles. – Jasper Sprengers Apr 04 '12 at 13:40
-
Miracles? No. A productivity improvement of >1 fold, yes. If nothing else, I have spent *100% less time* making special-case code to accomodate platform/browser idiosyncrasies. GWT handles this by creating multiple permutations, one for each (statistically significant) browser, effectively eliminating the time spent planning and reacting to how different browsers react to the same code. – Chris Cashwell Apr 09 '12 at 15:37
-
I agree. I remember having to deal with the sheer maddening differences between IE3 and Netscape 4 back in 2000. Things have certainly improved since then. – Jasper Sprengers Apr 09 '12 at 17:55
On my experience of GWT, my only bad experience was with GWT compilation slowness due to lot's of permutations. Our application had more than 20 languages to support, which multiplied by 6 for browsers specific result in 120 permutations, which proved to get horrible performance.
But this is not a real bug issue, because you'll mainly use the dev mode, with instant code update, and you can have special compilation unit with reduced set of browser and language (even one language and one browser => one permutation if you wish).
So in my case, using Jenkins we made the big prod target full build nightly, deploying on a QA platform so that the QA team test every browser language combination. And on every commit a reduced build (1 browser and 2 languages in our case) was deployed on a dev validation platform.
GWT is definitively a great tool for large app. ;)

- 2,962
- 2
- 20
- 28
-
GWT Super Dev Mode has gotten this time down to around 4-6s per refresh. Quite manageable. – Joseph Lust Mar 12 '14 at 17:23