Subjective thoughts on best practice with GWT applications.

If you have spent anytime with me you know I love GWT.  But in my humble opinion there are ways to build web applications that still involve the gamut of javascript frameworks and bog-standard HTML5 and javascript.  Through my vast and continued learning experience of GWT I am beginning to see it in its current guise as being great for building complex and large widgets embedded in a web environment that is built in a more traditional web application framework.  Using the word tradition is kind of absurd in the web application design sphere because a tradition is established in a matter of months and then disposed for a new tradition within a couple of years.  However we appear to be heading towards a path of convergence in how and the way we code.  I recognise this as entirely subjective but for companies adopting GWT for the first time, experimenting with complex GWT widgets, then embedding them into their existing web applications is a great way to start on the GWT path.

Model-View-Controller (MVC) and Model-View-Presenter (MVP) are becoming the de-facto design patterns for building desktop, web and mobile applications.  Developers pay attention, if these are not on your resume, get them on there as fast as possible.  You should not leave home without it.  Many frameworks in almost every language develop according to this pattern.  So whether you are using Ruby on Rails, Grails, GWT, Spring MVC, Backbone.js they all design their frameworks around this convention.  GWT is a little late to the game with regards to this and so two additional frameworks have been around for a while which in my opinion currently offer a lot more features than the "Activities and Places" inbuilt infrastructure.  These two frameworks are GWT-Platform and MVP4G.   They are both on Google Code and both have extensive user collaboration and input.  Developing outside of GWT in the standard HTML-CSS-JS arena backbone.js offers a Javascript implementation of MVC.  I haven't used it as of yet but from the brief tutorials I have read it appears to be very easy to use.

In a similar vein, Dependency Injection is also a must have.  Design your code to interfaces and inject interfaces at runtime.  This is achievable in GWT using Google GIN on the client and Google GUICE on the server.  However my current overwhelming suggestion on the server is the Spring framework.  If you are writing Java server code and not using Spring, you are probably writing lots of boilerplace bullshit.  Stop it now!.  My server side framework knowledge is limited so would love to hear from other developers on alternatives, but from what I have seen this is well adopted, supported and promoted in the media and job adverts.  Spring is about more than Dependency Injection but this is at the core of the framework.  If you want to develop modular, testable code then you need to use DI.

Using the Facebook web site as an example lets look at how you might construct this from scratch.  Some GWT developers will suggest that the whole site should be built in GWT.  I disagree but more on that later.  However I believe that you will have a more flexible and productive if you develop the complex parts of your web site in GWT and embed them into the website.   So when looking at your newsfeed the complex box that controls updating your status etc might be a small GWT application but it is embedded in an AJAX-controlled feed panel table.  The reason I think this?  Unless your whole team consists of ninja, ex-Google GWT developers that worked on the ad-sense or ad-words interface, then you are going to experience delays in your project as you migrate your developers to a new way or working.  By concentrating complexity in small manageable chunks you reduce your exposure to delays in your project.