- Unit testing, while it exists, isn't very convenient.
- Cross browser compatibility. This is a complete nightmare. Of course I'll be the first to admit that on most enterprise projects there is just one target browser.
You've now got a neatly separated domain model, presentation model, controller and view.
And it's all unit tested.
And you can refactor all you want.
And async calls/AJAX become utterly trivial.
And it's browser compatible.
No more muttering about having to manage with simple text renames instead of Alt+Enter/Ctrl+1. No more muddling around with explicit XMLHttp or JSON calls. The latter are now abstracted to simple RPC style method calls.
You may also want to read: The difference between a web application and a website
Imho, GWT works for Ajax-only sites with a domain model that isn't too crazy. If you have a complex, database intensive domain model, using a framework like Wicket is easier and by default more efficient (because of locality, though if you optimize properly, which probably results in a maintainability penalty, GWT is hard to beat). Also, whether using a layout manager works for you depends on your taste and what your team looks like.
I see two advantages of the GWK approach:
You can code the logic of business rules once to enforce them on both the client and the server tiers.
As your design evolves, you can move business logic from client to server or vice-versa. Good design is an iterative process; it is naive to imagine that you can get it just right the first time. If the tiers are written in different languages, refactoring the architecture requires throwing away and re-implementing good code.
I have been using GWT for a while. My opinion is that for small applications GWT is OK but if you have a large domain model it is hard to integrate the front end & back end well. I have the the model part of my application represented by EJB3 session/entity beans & have found there is a lot of massaging(like copying entity objects from EJB compatible(i.e. Serializable) to GWT compatible classes(i.e IsSerializable)) which needs to be done at GWT service layer before you can show meaningful data in the front end.
Databinding for complex UI components to the back end object is not straightforward. Validation is another pain. All this results in a large codebase which can be avoided if you start with a full stack frameworks like RIFE or Seam. I am seriously looking at Seam to see how much less work I'd have to do for a similar application.
You're right in saying that GWT makes sense only for AJAX sites. That's it's forte. But it also kicks ass for complex presentation models (believe me, I'm doing this every day at work - MVC is a breeze :-)). Tie it into Spring and those database problems are no longer problems. The domain model on the GWT (client) side should have minimal complexity - they should little more than dumb DTOs, possibly with validation. All the business logic should be on your server - if you're seeing that stuff in your GWT code and tests then it's definitely a code smell.
GWT is a essentially compiler while Dojo et al. are frameworks - comparing them is a bit of an apples and oranges thing. While they do try to achieve the same goal, the paths taken are completely different.
I couldn't agree more.
I'm afraid I've never worked with EJB's - Hibernate and Xstream have been the weapons of choice in ThoughtWorks - but my colleagues tell me that Spring goes pretty well with GWT. I don't see a way to avoid the Serialiazable to IsSerializable conversion layer, though. Thanks for the tips on Seam and RIFE - I'll be sure to check them out.
PS: I totally agree with that full-stack comment by aejaz. If someone could just replace Rails' ActionView with GWT...
I agree with the apples and oranges argument, though the same applies for comparing frameworks like GWT, Wicket and JSF. In the end you want to create web applications with any of them :)
I think it is a matter of getting comfortable with a framework as well. Whatever framework you use, you have got to know the gotchas and optimizations etc. Whether GWT is a better choice than, say, Wicket or Echo, depends more on style and preferences than them being inherently better than the other. That said, I believe, JSF is full of wrong choices and the 'web mvc' frameworks like Struts and SpringMVC weren't very helpful in the first place.
The Rife framework and everything around it is very well done. Big kudos to Geert on that. However I disagree with it's continuations-centric philosophy, which basically forces you into a procedural programming model. I believe a (stateful) widget based approach is more suitable for developing user interfaces (which Geert thinks is too heavyweight btw).
This attitude is what really fuels GWT adoption: people are, by nature, lazy and do not want to make an effort to understand that different platforms do require different skillsets, knowledge of different APIs and languages. Really, why screw your head trying to understand anything at all.
Namaste Sidu, Thanks for sharing your thoughts on GWT. I happened to find your blog when searching for "GWT JCR". In your profile you refer to a project using both components, I am very interested in your "end2end" experience and in the tools you use to glue the two frameworks together.
The overall experience was quite good.
We provided access to Jackrabbit through a layer which exposed functions like getNode() and search() through Axis webservices hosted in Tomcat and which used XStream for serialization.
These services were consumed by another layer which in turn exposed more business domain specific web services. We had a requirement that there should be 'raw' access to the repository available for other applications to use, hence the two layers.
The GWT server was one of the consumers of these business services and through the GWT server, the GWT client had access.
Authentication and authorization is one area in which we had a fair amount of trouble. Jackrabbit has quite a way to go before it can support users and roles for node level access.
I know this is a very superficial explanation so let me know what areas you want clarified and I'd be glad to go into greater depth :-)
Server side (generative) approaches are great from a programmer productivity perspective, but they are pretty useless when doing client side mashups, which is where I see a lot of value in AJAX.
Post a Comment