Posted on

GWT is here to stay

Scroll down to see more content

For the uninitiated, Google Web Toolkit aka GWT (pronounced as gwit), is a web development framework that allows writing the “client-side” code in Java. The toolkit compiles the code into javascript. Using GWT has several advantages over javascript- based frameworks

Advantages

  1. Java is strongly typed and hence most coding problems get caught during compile time itself
  2. Powerful IDEs like Eclipse are popular for Java and allow very quick coding, shortcuts, refactoring and code analysis
  3. Optimized javascript. The compiler in-lines the methods, removes dead code, minifies it. Further, the code is split into separate javascript files and hence the application can load gradually as you visit new screens
  4. Management of static resources. Referring static resources such as css and images in code requires explicit declaration in the Java code. It allows for a clean separation and also allows to easily locate the resource usage. Eclipse users, think using Ctrl+Shift+G to determine where all is an image referred in code !
  5. Has an in-built structure for server side component as well. That too comes with a super-optimized serialization for object transmission. Coders do not need to work on json – server and client talk classes and objects. And it still allows putting in your own serialization strategy, your own server side components

Now all that is good, and GWT looked set for a bombardment in all development teams. Yes, it did start that way. Techies were excited to see that it shall take out the pain of working on web development.

However, this hype did not last, and we like many other teams became apprehensive about going ahead with GWT.

The bottlenecks

  1. Browser plugin required for development. The browser plugin was not being maintained to work with newer browser versions. A discouragement for its adoption
  2. Every change in the client side code required a re-compilation. Coders were used to the speedy change-refresh-check method. Compilation slowed things down
  3. UI look and feel. Though the initial version was great for its time, the look and feel did not move with time
  4. Evolution of the toolkit itself slowed down. If you see the release versions
    1. From launch in May-2006 to Aug-2008, significant improvements were brought about
    2. Then after a gap of a year, in Aug 2009 we saw code splitting and deprecation of plugin
    3. Then there was a series of fixes-only releases till 2012

So the important time when the world was moving to the cloud-based web applications, GWT was in slumber… or so it seemed. Numerous other web frameworks came that conquered the huge developer base that was now doing web applications. GWT missed this bus. Resultant “market share” of GWT slipped hopelessly low.

However, Google turned it around later. It put in enough resources to make GWT alive again

Evolution

The relatively recent developments put the trust back.

  1. Realworld applications using GWT like Google Inbox
  2. A major release in 2.5.0 in 2012. This laid the foundation of SuperDev mode – the giant leap in web development. We believe this is going to the way to go for all web-app frameworks. Also, subsequently we have seen important releases in 2.5.1, 2.6.0 and then 2.7.0
  3. Frameworks like GWT MVP and GWTP that standardized the application structure
  4. UI look and feel with gwt bootstrap3
  5. History management – allowing the user to navigate in the application using browser back and forward buttons
  6. Incremental compilation – re-compilation only compiles what has changed
  7. SuperDev by default – refresh now serves the new application. Though this is not as fast as others, but still the overall speed of development due to Java makes it very fast
  8. Declarative UI in xml with uibinder

Statistics say it

Some statistics from the Future of GWT survey 2015

  • Developers who use GWT rate it at a good 4.47 out of 5, with 82% rating it above 4.0
  • 78% have been using GWT for more than 2 years. So its a framework that has actually stood the test of time
  • 33% said that their GWT teams have grown
  • 56% of these applications have more than 20 screens. It supports the fact that GWT is for large maintainable business applications on which users spend several hours in a day
  • 85% would want to use GWT in their next project
  • 43% and 35% respectively also considered using AngularJS and JQuery

Challenges that a team might face initially

  1. Framework standardization – gwt MVP or gwtp or your own. When you are spoilt for choices and there is no clear answer then the team is left consfused. Our take is to go with gwtp
  2. Widgets – Since bootstrap3 is not supported out-of-the-box, so a project called gwtbootstrap3 does it. Now this support may not be complete and you may miss some widgets. Also, some other native js+bootstrap widgets will not be directly available. However, gwt allows native js as well. Or you might need to port some widgets to gwt
  3. Current handson and bias of team would be with other frameworks
  4. Designer shall need to understand atleast uibinder. Or you can have the coders to do the ui once the hi-fidelity wireframes are done by the ux/ui team

Further reading

One thought on “GWT is here to stay”

Comments are closed.