Google Web Toolkit – Web Component Framework for Java Developers on Steroids

I have been Java Developer for most of my software developer career. I have been involved in all kinds of projects – Java Back-end, Front-End, Native Android, even in some small cases in embedded applications. I was a little bit closed up to the functional programming to be honest. I probably don’t know everything in deep details because of my unfocused attention but that is not always a disadvantage. The benefit of touching a lot of stuff is that you could potentially open up your eyes to wider horizons.

One of the technologies that I have been involved professionally – when working professionally for other people and organizations, as well as when working on personal projects is Google Web Toolkit http://www.gwtproject.org/ – a framework that you have the power to code in Java and the framework will generate JavaScript and (partially) CSS Front-End and also the necessary glue and the Back-End. Here are some pros and cons that I have encountered over the years:

It give you full control over the flow of the information. This can be a good thing from one point of view. If you need more control over what information is transmitting to the server and back, what is saved locally – how and when the information is moving etc.

This is feature from developer (coder) point of view means more coding (code) that could potentially create more bugs. If the business case is such that you don’t need such control, maybe VaadinFramework may be better choice of technology. In the incoming version 10 of Vaadin there will be more client side and server side components so you – you’ll have more options soon.

If you want (and don’t need) you could use the already provided by the framework or some third party components and forget all about how the stuff below actually works in terms of JavaScript or CSS and focus on coding in Java Programming language – Front End and Back End logic. This is only partially true if you use good components because forgetting how the stuff is implemented in the browser will hurt the user interface and in the end – the user experience. That is one error that I stumbled upon because of my lack of design skills.

You could also step into the shit with both feet and implement the User Interface on you own. The GWT Framework gives the possibility to create UIBinder Components – Components where you could separate the Interface (HTML & CSS) from the logic (JavaScript – that is GWT Java code). This is an approach that I have used. There are for example – Bootstrap, Material Design and other Responsive Design GWT Libraries and components. But what I have done with several of my projects is – import the CSS (and the JavaScript if needed) into the host HTML page and using UIBinder – I have placed the necessary CSS classes on my GWT components so the stuff looks good.

Also, it is super easy to use other JavaScript libraries via the Java Native keyword that is originally designed for C and C++ code but, in this case the Native Language is JavaScript. The syntax is very simple and in my experience – as I am not so afraid of JavaScript – this feature is super cool.

In this framework – the data transmission is hidden behind Java Interfaces. So if you code your project entirely on GWT, you could forget about how the abstractions are made and implement it all in Java. This is also true in Vaadin. Internally it uses optimized custom data transformation. At least this is the way I was using GWT. There are also methods to use existing REST /JSON/ Services with a little bit of extra work.

Unlike in Vaadin where you could potentially write any code anywhere, GWT enforces strict separation of what code is client-side and what is server-side, because it uses Java to JavaScript compiler (that is sadly very very slow) and it needs to know how every Java type is represented in JS. From other point of view – this code separation is good because better caching of the resources could be implemented (CSS, JavaScript, Images). Google Web Toolkit Compiler also merges the used by the application images into one (this transformation is called CSS Sprite Image) on compile time and there is no need for a designer to merge them.

For large applications the code could potentially become very big. If your kept your code clean and implemented good separation of concerns of the software components a build into the Compiler separator of the JavaScript code could be used http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html.

One other tip from my experience of using GWT is that – you should think about optimizing how much components you instantiate. When using the build-in components – the framework creates JavaScript object for every widget. You better optimize the quantities created. This could be workaround-ed a little bit with the UIBinder components where you could implement the positioning of the elements with HTML & CSS and bind only the necessary stuff into GWT JavaScript. By placing HTML string code directly into the browser’s DOM structure you give up a little bit of the control, but that way the application becomes more memory efficient.