Last time we talked about Google Web Toolkit (GWT) and reviewed the advantages. Here we’ll look at some of the disadvantages and see when you might not want to use it.
(Side Note: This blog post is just about my own personal experience. Recently Vaadin put out a very nice set of infographics about GWT which
covers a more statistically significant view of the strengths and
weaknesses of GWT since it surveyed many GWT developers.)
The
primary disadvantage in my view is compile time. Granted: many people
are building large applications with GWT and large applications take a
long time to build no matter what language you’re using. But the fact
remains that even small to medium sized projects take far longer to
compile than you would expect for something of that scale.
GWT
also has a lack of good UI components. Generally we need to write all of
our widgets from scratch and spend a lot of time on styling, as opposed
to choosing a full featured widget library and theming it. Granted:
this is by design, GWT does not pretend that it is there to provide a
strong set of UI components. But it would be nice to have more
components built in than it does, since it already provides everything
else for you to structure your entire application. Additionally, the
widgets it does have generate a lot of (needless to say, non-semantic)
markup, complicating your CSS. How many times have I worked with a UI
designer who cursed the markup that GWT was generating!
One of the strengths I mentioned before is also a weakness: Coding in Java.
- More Code: There is simply more code to write in Java than there would be in Javascript. Strong typing gives you compile time type checking at the expense of much more code where types are close but not the same and cannot be inherited. Additionally, programming for the web requires something much more like callback-oriented programming, and Java is not designed for that. Things that would be a one or two-liner in Javascript can take 5 or 10 lines in Java.
- Unit Testing: GWT tantalizingly provides a GWTTestCase for unit testing UI classes. However, any test that runs based on this class is going to be agonizingly slow - increasing the pain of build times and destroying the possibility of having fast unit tests.
- Finally, the strength of making front end development accessible to back end developers actually comes at the expense of excluding the majority of front end developers in the world. Most front end developers will be fluent in JS/CSS/HTML but not GWT and Java.
The only other disadvantages I’ve noticed are miscellaneous but worth mentioning.
- There is sometimes a difference between “compiled” mode and “dev” mode. This is very very rare (it happens to me maybe once per year), but when it does happen it is next to impossible to debug.
- Can’t debug network traffic: If you are using GWT-RPC or GWT-Dispatch, the network traffic is encoded and impossible to manually inspect. While developing this is not a problem since you can set a debugging breakpoint just before objects get marshalled or unmarshalled. But in a production environment, it will be impossible to troubleshoot a problem by looking at the network traffic (say, to see what data the productionserver thinks it’s getting). This can be alleviated by using RequestBuilder and overlay types to call JSON REST services, although this is more work.
- Given that many services are allowing multiple application clients (like what happened with Twitter) and that growth of mobile devices is outpacing growth of desktop computers, there is a disadvantage to requiring one language or framework for a front end application to interact with your services. If you use GWT-RPC or GWT-Dispatch, you can’t easily write mobile apps for your service - and neither can anybody else. The client would have to be a GWT client capable of making GWT calls. Again, this can be alleviated by using RequestBuilder and overlay types to call JSON REST services, although this is more work.
So: when should you not use GWT?
- You have front end developers who are already fluent in JS/CSS/HTML
- You are planning on allowing third party development of applications for your services
- You are planning on writing native mobile applications for your services
- You don’t have enough money to buy extremely powerful build servers to compile your GWT code (Just Kidding! Or am I ?!?)
No comments:
Post a Comment