Why GWT?
Monday, October 10th, 2011 01:35 pm GMT +2


GWT is a set of tools which allows you to write javascript code in java language. That is, to avoid confusion, GWT does not have a lot in common with tons of existing Java technology stacks out there.

It is designed in a such way that backing your javascript application by server build on top of Java stack becomes a huge advantage. However, it does not mean that you can’t build GWT apps backed by PHP/Python/Ruby servers which might be more lightweight solution (both from technology & business points of view).

You can easily implement your data exchange using JSON or use ports for your favorite language of native GWTs RPC serialization mechanism.

One might be curious about GWT language choice, but If you’ll google a little bit about available Java projects & tools, the solution google folks made, becomes very obvious. Java as a language & technology proven to be successful over long period of time. By using Java in GWT you’re able to leverage good stuff from both worlds.

The bottom-line is as following: if you want to use GWT in your project there only few prerequisites:

  • Your devs are familiar with basic OOP principles & are strong in JavaScript for modern browsers
  • You are ready to pay an upfront cost of GWT/java lurning curve & overall initial slowness of development cycle

What are the main problems GWT was designed to solve

The problem of large-scale javascript development

Javascript as tool was not designed for writing huge applications, therefore it has some serious problems. Lack of tools, huge cost of maintenance, debugging issues, differences between Javascript engines, etc. (for more details see p.5)

The problem of building desktop-alike applications in browser (RIA)

From the very beginning you should clearly understand the difference between web site & web application, because some people confuse between these two.

A web site is a collection of related documents or information resources containing images, videos or other digital assets.

A web application is an application that is accessed over a network such as the Internet or an intranet.

What this means, is that you have to use completely different approach for developing complex web-apps. As a consequence, your web-app will be a more like a desktop GUI application from the architectural point of view.

If it’s more about GUI, than you’d better use somewhat time-tested, bulletproof architectures like MVC/MVP and look for their implementations in your technology stack. Otherwise, without having that kind of backbone, within a couple of months, blindly coding, you’ll end up with a pile of unmanageable crap.

The conclusion is as following:

It’s too risky to develop large javascript apps without special tools to manage complexity

What kind of tools we’re talking about? Simply put, those could be categorized as:

Each of these tools focuses on a number of particular problems: crossbrowser issues(jQuery), building consistent GUI(jQueryUI), abstracting data layer(PersistenceJS), offering a full implementation stack of well-known architecture pattern (Sproutcore, Javascript MVC).

It’s up to you wether to use them or not, but in 2009, when we made evaluation(see spikes section p.7) none of mentioned solutions proven to meet our needs. Some of them were pretty buggy, others were not mature enough and some of them didn’t have a strong community.

As you probably see, there are tons of different ways on how to write your webapp in javascript, but

there’s no stable and consistent technology which is widely adopted for developing large-scale webapps

Should I use GWT or just stick with modern Javascript/HTML5 stack?

That is not the right question to ask. It’s not wether you should use GWT or not, but what kind of user experience do you want to deliver?

As I already mentioned, GWT will allow you to build feature-rich user interfaces and deliver desktop-alike experience to your end users: almost instant action response, rich interactions with complex business logic. GWT is not for creating web-sites, however your application will be run in browser. From this point of view, browser is just a way to deliver application to your customers.

Check this out, if you’re still in doubt by making your decision in favor of GWT:

Of course, no-one can prohibit you from building your RIA by means of modern HTML5 technologies, using plain JavaScript. But you must be aware that this will probably work only for tiny projects. Why?

Javascript flaws

As you might heard, Javascript was invented as a tool for scripting purposes by Netscape developers. The main goal of javascript was to write small programs which would enhance behavior of web pages.

Later on, it was adopted in other areas as a general tool for automation by system administrators, graphic artists, 3D modeling industry, etc.

An important thought here, is that javascript was not designed for writing real-world complex apps from the beginning:

That said, you’ll inevitably need a special tooling to develop large apps in javascript

Pros & cons of GWT

Pros:

  • Mature technology stack backed by Java(OOP & strong typing is a huge win on large projects)
  • Debugging tools
  • By using Java, code maintenance & refactoring becomes really fun to do
  • Comprehensive, easily restyled widget library + GWT designer to build complex GUI interfaces
  • Security against JavaScript attacks
  • Logging
  • Accessibility
  • Internationalization
  • Data transport / management mechanisms
  • Crossbrowser
  • MVP framework
  • Unit testing framework
  • HTML5 support
  • Open-source
  • Tons of great libraries & frameworks (Mvp4g, GwtQuery)
  • Strong and active community, supported by Google
  • Deployment & optimization tools
  • Scales well by increasing number of developers

And one of the major advantages of GWT is:

At the end, it’s still javascript, which means that you can leverage all existing javascript/HTML5 technologies either by using plugins or by writing native javascript through JSNI

Cons:

  • Initial java-related overhead for setup/configuration (dev-mode, special plugins for modern browsers, etc.)
  • Speed of development is highly affected, you need top-notch hardware to comfortably write code
  • A lot of data abstraction layers are highly coupled with Java backends
  • Relatively high entrance threshold for new developers

You might want to check out feature comparisons matrix for different javascript frameworks as well.

Spike scenarios to examine different technology stacks

  • Data abstraction, packaging, event-binding spike. There should be a simple form with one textfield. As you type, 2 different widgets on the test page should update themselves with a data from textfield. Those 2 widgets should be controlled by independent business logic in separated packages(modules) of application.
  • Form validation spike. This will examine how easy it is to validate user data, including validation made on server-side.

By implementing first spike & evaluating your solution, ask yourself about units of functionality that will make up your future application:

  • How will those pieces be organized into units of code?
  • How will those pieces communicate with each other?
  • How will dependencies between components be expressed and managed while adhering to the principle of loose coupling?
  • How will components manifest themselves in the DOM? Do they need to?
  • How will we persist data across URL and page loads?
  • How will we manage communication with the server?
  • How will we make sure users only see the data they’re allowed to see?

There is no spike whatsoever which can show you strengths of GWT in managing large-scale apps right away. This is obvious — until you’re going to play with some trivial samples, it might look as an unnecessary technology overhead. But it greatly pays off in the long run. Our 2+ years of frontend development proved GWT to be the right choice.

You might be interested to investigate why others are using GWT & what are the type of projects being built.

Hidden cost of transition from GWT to javascript

What if, after huge investment in GWT you decided to switch back to Javascript?

That is a pretty serious question from the business perspective. Remember, that we’re talking about apps here, not web-pages. This means, that your existing GWT application already carries a lot of complex business logic, it’s not a simple presentation layer as one might think.

Keeping this in mind, you’ll probably end up with:

  • Complete rewrite of application (you’d better want to spent this time for new valued features to compete in your market, don’t you?)
  • Hiring pretty expensive javascript-gurus (you don’t want those numerous folks writing random jQuery snippets to develop your complex business-logic app, do you?)

From these points of view, transition doesn’t seem to be a good idea, even though you might find out that GWT resources are pretty expensive. The trick why those folks are so expensive is that they specialize a lot on GWT backend stacks, which is an enterprise class java technologies. Instead, if your back-end stack is non-java, you could happily hire senior javascript guys & easily convert them into GWT devs. Our 2+ years experience showed that it works pretty well — monthly learning curve and your dev-team is able to use all of GWT strengths.

How to leverage existing Javascript solutions?

Javascript is so widespread today and there are tons of cool stuff already built. How is it possible to grab some piece from that tasteful cake?

You’re probably looking at these:

  • Cost of javascript resources is pretty attractive
  • Re-use of existing open-source javascript code

But wait, is GWT really java? Nope. At the end it’s the same old javascript which is used everywhere. What this means for you as business, is that you could still leverage any javascript solutions out there.

In the case of existing GWT application, the solution seems to be pretty obvious. Core GUI front-end may be maintained using GWT & third-party extensions can be easily built using plain javascript. However, this does bring a few of technical problems:

  • There is a need to invent a well designed interface for integration of GWT Core app and third-party javascript
  • There is a problem of css-styling of core app by means of third-party extensions

Those are a real technical problems, which you just need to spent some time to resolve. This way, you’ll continue to happily use GWT for the “core” stuff & leverage javascript extensions which might add a huge value to your application.

, ,