Using GWT for an exsting large-scale app

[gary fong]

This is great! GWT experts.

I currently work for a company that has a very complex web app, 40+ screens. This web version has been in the works for about 6+ years, maybe longer. It has a heavy dependence on IE and all of its idiosyncrasies. Way before the AJAX buzz, this app used remote scripting via hidden iframes, and still does. It leverages DHTML, IE behaviors, ActiveX controls, and more. And then there's the javascript. Tons of it. Most of it business logic. This is all mixed together with a homegrown java library which generates JS/HTML components tied to our model.

In the past 2 years, there's a realization that we have a big unmaintainable, rigid, fragile mess. Some attempt has been made to look at overhauling the front-end. So far it has been limited to incoporating JS libraries like YUI, prototype, and scriptaculous and trying to swap in Swing MVC as the front-end controller. But all of us are sort of still trying to grapple how the new frameworks will help us out now and in the future.

I've only read bits of GWT in Action and only a bit more about GWT in general. Our skill base is primarily Java (and Smalltalk), though we know JS very well. This alone is why I graviate towards GWT being a good fit for our company. However, it is so different from the standard paradigm, where the client is coded in JS, that it seems a big risk to pursue this path.

My question is can GWT be used as the cornerstone technology for a large-scale web application such as ours? What are some of the downsides? Also, how can GWT be introduced slowly, over a period of releases?

[Adam Tacy]

Originally posted by gary fong:

My question is can GWT be used as the cornerstone technology for a large-scale web application such as ours?

It can certainly be used as a cornerstone for large scale apps - I would go as far to say that the tool support you can harness go a long way towards resolving some of the issues you mention in your post "a big unmaintainable, rigid, fragile mess".

Originally posted by gary fong:
What are some of the downsides?

For me the biggest current drawback, when looking at complex apps, is there is no native modularization to loading your application - i.e. you typically have to download the whole application. The more complex/larger you app becomes the larger this download will becomes.

There are design ways around this, but it would be nice to have it supported natively.

For the majority of applications the above is not a massive problem once the GWT compiler mashes its way through your code stripping out unwanted aspects and cutting down, but at some point it becomes a consideration.

Originally posted by gary fong:
Also, how can GWT be introduced slowly, over a period of releases?

This will probably become the million dollar question as GWT gets more and more adoption; and the answer is going to be very dependent upon the starting point.

It's hard to give strict guidelines, but here are some thoughts I've used in the past...

Client "look and feel" has two extremes:

If your application is divided into well isolated components, then a strategy could be to replace these components release by release:

* components can be placed in a page using the standard GWT's ability to place elements at named DOM elements,
* you could link your existing code via JavaScript and JSNI (e.g. let your GWT component expose an API or harnessing the new "mashable" code from GWT 1.4 for JavaScript to GWT comms and using JSNI for the other way around).

At the other end, if the application is really spaghetti like, then it might be easier just starting all over again.

Another consideration is where you store the model; other technologies/toolkits/framwork tend to have the model on the server, with GWT it becomes more natural to migrate the model towards the client (though not necessarily completely to the client).

Any migration strategy would also have to think about moving the model location, as well as how to maintain consistency if the old approach has the model on the server and the new one moves it more to the client.

When moving the model, you also need to start thinking about granularity of saving the information to the server - too low and you have a high amount of network traffic; too low and the user risks loosing data.

As you are thinking about migrating you could also consider making the client/server interfaces you will end up with more robust or open, such as moving from hidden frame JSP request to GWT's RPC, or using JSON/XML etc - though maybe simple "Ajax" updates are enough.

The final issue I want to mention about migration is you need to think about what you will do with those ActiveX aspects, etc, that you mention. Can you perform the same tasks in JavaScript or do you need the ActiveX. That could restrict your options in migration, or require you learn a little more on JSNI.

Not knowing your application, but one approach might be to look at migrating it page by page - creating a GWT application per page; this way you minimise the model issue (since you can have whatever model you need on the client side per page, and then before moving page, you could refresh your "overall" model on the server, and I would imagine that each page is relatively isolated.

Once you have all pages migrated, you could then look at packaging pages together into meatier GWT applications; this would reduce round trips to the server and start reducing the number of GWT applications you have ended up with from the first step.

Of course, this might not be applicable for your app - it's hard to tell from the description, but it might be a way to start thinking.

Hope some of that is useful!!

//Adam