GWT for large-scale applications
I have heard that the Google Web Toolkit is not suitable for websites with more than 5 pages and a general layout. It's true? We have at least 100 subpages and a generic layout defined in CSSes. We've used PHP today, but we'll move to the Java front-end with either Spring MVC or GWT. We are using som jQuery AJAX and other jQuery components like jqGrid. We also have some .swf movies and merge plots. Would the choice for Spring combined with GWT be a good choice, or Spring MVC with jQuery the best choice for us?
source to share
This is no longer the case. Earlier versions of GWT did have some scalability issues (like JS code size issues in IE - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440 ), but with GWT 2.0 you have no limit here.
In addition, recent versions of GWT support functionality for splitting projects into parts that can be loaded dynamically when needed. Please refer to https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting to see how this works.
Also note that since Spring is Java, you have the ability to share classes between servers and clients. Plus Java has very good support in the IDE - all refactoring will be available to you (this is not so convenient if you are using jQuery).
So Spring + GWT looks preferable.
source to share
GWT is not a universal framework for building an entire website from scratch. This is very useful when you have a lot of complex client-side logic (image editing, real-time collaboration, drawing diagrams, playing games, creating complex reports, etc., etc.). But all of this can be done without GWT. GWT can be used when:
- your team hates / dislikes JS (and can't build nothing with JS, simply because they hate JS)
- Your team is experienced with Java
- Your team understands how this browser related stuff (HTTP, JS, DOM, CSS, etc.) works.
- this project will have a lot of client side logic.
I've seen quite a few large projects built entirely with GWT. Some of them should never use GWT because they had no reason to use them that way. For most projects, it is sufficient to use GWT for only some part of the application.
The choice depends on your team and the project you are doing. If your team cannot understand what benefits GWT will bring to the project, then you should not use GWT.
source to share
Our enterprise application uses both and we are happy with the results. GWT is a powerful toolkit that cuts development time by an order of magnitude. However, there are still things that GWT either doesn't do very well or just doesn't fit (and that's ok ... why the WMA60 lives nearby). We have GWT-RPCs pushing to Spring services and it works incredibly well.
Our project though is a real webapp and not a website. We use a single design that covers all "pages" (using DockLayoutPanel
and replacing only center
makes it very easy).
IMO, whoever tells you that GWT is not suitable for sequential design across multiple "pages" is nuts ...
source to share
I think that any claim that GWT (or any other method) reduces development time by an order of magnitude has already been debunked by Frederick Brook at the time when shoulder pads and John Hammer's synthesizer were in vogue: http://en.wikipedia. org / wiki / No_Silver_Bullet .
But seriously, if you're a PHP store, going to 100% Java will be a huge investment and won't be taken lightly.
source to share
In my experience with GWT, my only bad experience was the slowness of compiling GWT due to a lot of permutations. Our application supported over 20 languages, which was 6 times for specific browser results at 120 permutations, which turned out to be terrible.
But that's not a problem, because basically you'll be using dev mode, with instant code updates, and you can have a custom compilation unit with a reduced set of browsers and language (even one language and one browser => one permutation if you like).
So, in my case, using Jenkins, we made a big prod target full of full overnight deploying to the QA platform so that the QA team will test every combination of browser languages. And on every commit, a shorthand build was installed on the dev checkout framework (1 browser and 2 languages in our case).
GWT is a great tool for a large application.;)
source to share