Inner dialog on GWT – benefits and drawbacks

Project I’m currently working on really interested and intrigued me. Main reason is GWT, technology I had chance to meet more than once, but never to get to know it very well. When I heard that it will be used, I was very enthusiastic about it, because I wanted to get into it and learn it good. As time passes by and as I am more familiar with it, I must say, I am starting to feel far less excited – sometimes it creates troubles and makes me really miss JavaScript (which I am very fond of). Never the less, when I remember of GWT few years ago, its progress is more than obvious. Without going into the details, here are some of my conclusions about GWT and about the reason that, in my humble opinion, should drive the usage of GWT as a technology.

MVP pattern is, at least it looks like it is, becoming a standard way to implement client logic on GWT projects. It is definitely a pattern that brings order into client side of application. There is a model, consisted of data that needs to be presented to the user, and there is easily understandable relationship between UI (view) and logic responsible for that view (for specific part of UI). Furthermore, there is a clear boundary separating the responsibilities of view and presenter classes, which is not exactly the case in MVC approach. It is simple to understand which part of logic is used for smart things and operations and which only for presentation of data. This is clearly great benefit.

This pattern is used in conjunction with event bus mechanism on our project – every presenter class has EventBus instance injected and is capable to fire and listen to the events. This proved more than useful, especially in cases when is necessary to transfer a message from one presenter to another (or more others). Simply, every presenter interested in certain type of message needs to register appropriate event listener and it will be notified upon the firing of the event of that type. This was also easy to implement, since nowadays GWT provides a built-in mechanism for such a thing (HandlerManager). But be aware, there is a potential danger of piling up different types of these events and their listeners which would surely lead to serious issues in maintainability of the application. Basically, one has to know what is really needed to be registered through the event bus and what not. For example, events of UI components, such as onClick or onMouseOver, are usually events that shouldn’t be processed in that way. On the other hand, events that describe changed state of application, for example, are exactly what should be registered.

Another thing that eases the job is UI Binder – an option that speeds up development of view classes and makes it more natural. By using XML definitions (in which names of GWT widgets are XML tag names), UI Binder brings writing of UI closer to what web pages really are – HTML. But, combination of UI Binder and MVP pattern does have footprint too great. Beside data model classes, there has to be a presenter logic and separate view class – beside XML definition of the view, there has to be a .java view class – it all makes a sum of, at least, four files for each page or component. Every page that is more complex than really trivial, and at the same time has good modularity, will demand far more than these four files. I have doubts regarding this. On one hand, it’s a good thing to do this kind of modularization, but, on the other, there is a good chance that an explosion of code happens after some period of development. And what is the time needed for this phenomenon to happen? In our case, not very long. Maybe a two or three sprints – roughly, some time over two months of work.

Since I am much more into GWT now then I was before, there is a question that emerged in meantime and now really bothers me. What would be a valid reason for choosing the GWT as project technology? What would be a reason to choose a technology that is more complex and more engineered than any other of the kind and purpose? Why choosing something that copied the Swing approach for development of web application? Common excuse is that GWT can completely remove JavaScript from the sight (if JSNI option is not used). This is not good enough, I think. There has to be more of it, because if people are not capable of writing good and quality JavaScript code, time will show that they are not capable of doing some other stuff and then company has a problem. If chosen as project technology, GWT will have a significant impact of development and how source will look like. It is not one of those lightweight technologies that can be used without even knowing that its classes are on the buildpath. Totally opposite, it’s a technology that has great influence on application’s design. I cannot shake off the feeling that GWT (Java), actually slows development in this case. Why? To write Java code means to think in Java way, taking care about method and field visibility, design of application’s inner APIs and other details that don’t make sense in JavaScript – and after all, all of that effort ends up compiled into JavaScript. Of course, GWT covers all of the browsers at the same time, great feature, but this is something that can be also solved with JavaScript, some JS framework (jQuery, PrototypeJS…) and a bit of effort. Somebody will say that JavaScript cannot be tested well. OK, maybe there is not easy way to write unit tests for it, but there is Robot framework and acceptance tests that can show if client side is behaving as it should behave.

So, what is the biggest selling point of GWT? Simple answer: Java. No matter how good your people are in writing JavaScript, maintaining it and upgrading it in uniform way is much harder than Java source. Programming languages like Java itself maybe slow down development, but at the same time they prevent developers of making silly mistakes that are hard to recognize and creating “clever” functions full of programmer’s tips and tricks. None the less, one should really think before choosing GWT as a project technology. It is not simple and lightweight as I already stated. It is complex, robust and demands solid knowledge to be used properly. Apart from situation when application should have some critical functionality that no other technology can deliver, maintainability and testability that Java provides are clearly criteria that are on plus side of GWT.