GWT Is Here to Stay
GWT Is Here to Stay
Join the DZone community and get the full member experience.Join For Free
Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required
- Java is strongly typed and hence most coding problems get caught during compile time itself.
- Powerful IDEs like Eclipse are popular for Java and allow very quick coding, shortcuts, refactoring, and code analysis.
- 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!
- Has an inbuilt 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 to take hold in all development teams. Yes, it did start that way. Techies were excited to see that it could take the pain out of working on web development.
However, this hype did not last, and we, like many other teams, became apprehensive about going ahead with GWT.
- Browser plugin required for development. The browser plugin was not being maintained to work with newer browser versions. This discouraged its adoption.
- Every change in the client side code required a recompilation. Coders were used to the speedy change-refresh-check method. Compilation slowed things down.
- UI look and feel. Though the initial version was great for its time, the look and feel did not move with time.
- Evolution of the toolkit itself slowed down. If you see the release versions:
- From launch in May-2006 to Aug-2008, significant improvements were brought about.
- Then after a year, in Aug 2009 we saw code splitting and deprecation of the plugin.
- Then there was a series of fixes-only releases till 2012.
So, during the time when the world was moving to cloud-based web applications, GWT was in slumber… or so it seemed. Numerous other web frameworks came and conquered the huge developer base now doing web applications. GWT missed this bus. Resultant “market share” of GWT slid hopelessly low.
However, Google turned it around later. It put in enough resources to bring GWT back to life.
The relatively recent developments brought the trust back.
- Real-world applications using GWT like Google Inbox
- A major release in 2.5.0 in 2012. This laid the foundation of SuperDev mode – a giant leap for web development. We believe this is going to be 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
- Frameworks like GWT MVP and GWTP standardized the application structure
- UI look and feel with gwt bootstrap3
- History management—allowing the user to navigate in the application using browser back and forward buttons
- Incremental compilation – re-compilation only compiles what has changed
- SuperDev by default – refresh now serves the new application. Though this is not as fast as others, the overall speed of development in Java makes it very fast
- Declarative UI in XML with UiBbinder
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 it's 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
- 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 confused. Our take is to go with GWTP.
- Widgets – Since bootstrap3 is not supported out-of-the-box, 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.
- Current hands-on experience and biases of team will probably lean toward other frameworks.
- Designer shall need to understand at least UiBinder. Or you can have the coders do the UI once the hi-fidelity wireframes are done by the UX/UI team.
- GWT usage stats on builtwith – http://trends.builtwith.com/framework/Google-Web-Toolkit
Published at DZone with permission of Prince Singh . See the original article here.
Opinions expressed by DZone contributors are their own.