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