Overview

Inner dialog on GWT – benefits and drawbacks

6 Comments

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.

Kommentare

  • Dimitris

    2. November 2010 von Dimitris

    I have had the same thoughts exactly.

    Even though personally I am equally fluent with both Java and Javascript, and enjoy hacking the UI with the later more, I have come to prefer working with GWT on projects with fellow developers that have little JS experience. Proper JS requires a lot of discipline. Java enforces that and results in better code organization and easier collaboration.

  • and bod

    2. November 2010 von and bod

    For someone who sais that it has a “deep knowledge” of GWT you sure miss alot of points. Here’s some:

    1. GWT optimizes js in so many ways: obfuscates automatically, separates by internationalisation, loads all js at once (as opposed to 10000 manually created js files).

    2. GWT optimisez images: all your images are chunked into one big image, making downloading all of them a one-http-call.

    3. GWT optimizes development. Not only do you have compiler time check, and automatic browser independence (which you skim off as a small thing, you big web developer you), but the built in jetty server which allows on the fly compilation/code generation, makes deployment actually faster during dev cycles than it would with regular js/html.

    Try doing any of the above manually: make a complex ui in JS , with alot of images. Then redo it in GWT. See how much smaller the generated js is, and how much less calls and data transfer it needs. Then try optimizing your manual code to do that. Good luck.

  • Dusan Zamurovic

    3. November 2010 von Dusan Zamurovic

    Dimitris, thank you for your reply. I’m glad you agree with me.

  • Dusan Zamurovic

    3. November 2010 von Dusan Zamurovic

    And Bod, GWT can provide more benefits than I stated, that’s for sure. I just tried to be short as possible and stick to the subjects that bother me the most at the moment.
    You have some valid points, but there are some things that I cannot agree with you, though. For example, it’s questionable for me if I want to have all my JS loaded at once, having big load at landing page. Another one is optimizing development. I wouldn’t be so free to call development using GWT optimized. Certainly, there are some benefits of it but there are situations where “Java way of thinking” forces you to do things slower and make more complicated design than JS would, as I already stated in my post.
    We can agree or disagree on benefits and drawbacks of GWT, but there will always be a question of personal preferences towards GWT and suitability of GWT for specific project. Along with that, maybe I didn’t have an opportunity to work on projects complicated enough to produce so much JS problems as you did.

  • Sasa

    Personally, I would choose JS over GWT anytime. I must admit I never liked the idea of GWT, even before working with it. I like it even less now that I had the misfortune of having to have to use it. And I’m a big fan of Google products. I am aware of the great deal of benefits it brings. But I’m also painfully aware of other things.

    Compile process is slow as hell. Even if you configure it to compile just for one browser. I’m not a fan of waiting half an hour just to compile something. And compiler optimization is that good, that is squeezes every last bit of power from the processor, so that you can’t actually do anything else until it finishes.
    It forces you to make bad design decisions, it limits your options with other frameworks. Not a fan. At all.
    My two cents.

  • smithimage

    Hi there!

    Just wrote a similar post on this subject.

    http://smithimage.com/?p=117

Comment

Your email address will not be published. Required fields are marked *