In practice though, I generally find problems with the essential basics. Data binding is still immature, and I have doubts about using a single page interface for something more complex than Facebook, GMail or google search pages, not to mention having to code your own browser history.
There still seems to be some debate as to whether the server side methods are supposed to return XML, JSON or plain HTML. If you return HTML, you may as well stick with a server side framework since that’s where the view layer is still coming from. JSON and XML could make for an interesting development model especially since there is already a lot of support for them. (I’m planning on writing a post about Java EE 6 web services returning XML and JSON soon).
I still believe server side component frameworks are the way to go for now. People don’t want to be hand coding moving data values around and micro-managing HTML any more than they want to be pushing values around in CPU registers in assembly language. *Something* (akin to the controller) needs to mediate between the back end and the UI layers, currently, that something resides at the front of the server side. Could it possibly reside on the client? Maybe.
Taking the quote “Google uses Bayesian filtering the way Microsoft uses the if statement” and applying it to frameworks, Component frameworks uses pagination controls the way other frameworks use page parameters. They just operate at a higher level of abstraction that makes development much faster without requiring the application framework generate most of the content (i.e. Rails, Grails).
Another (easily resolved) criticism is that the UI needs to know about the data model in order to know what data to fetch. For example, loading a person and knowing to include the phone and address as well for the person details page. Other times though, you will want just the person instance and their name to display them. This is also a problem for server side frameworks, but the logic to deal with it is on the server as well so it’s still able to load that data. Once it has shuttled off to the client, there’s no ability to lazily load.
On the other hand, this problem gives you the opportunity to introduce a more interesting way of dealing with the data model. You could have a very decoupled data model by using multiple data requests to fetch the data needed for the page. First you load the basic person instance, then make separate requests to fetch an address for a person and then their phone number as they are needed in the page. I remember an interview with Werner Vogels, CTO of Amazon.com claiming.
“If you hit one of Amazon’s pages, it goes out to between 250 and 300 services to build that page.”
The interview itself is quite an interesting read for those interested in SOA (Amazon CTO Werner Vogels). The notion of a very decoupled data model is again rather alluring.
One of my personal problems when looking at most of this technology is that I can’t help but think how much easier and less convoluted it is to do similar things with JSF and CDI or how lacking it is in terms of features. In the back of my mind, the specters of more complex use cases (i.e. multi-page state management, or pages using multiple pagination) cast doubts that these frameworks will be able to be as usable as other frameworks. This probably curtails my ability to experience the benefits of such frameworks and gain enough knowledge to tackle some of the thornier issues leaving me safely in my comfort zone. I also find most excitement over new technology misplaced as people mistake a compact and concise technology for one with a a lack of features.
In the end though, with the Google App Engine, Amazons Web Services, Spring’s cloud efforts, and the focus on cloud based solutions, it is a programming model that well supported and attractive enough to developers that it will probably mature well and is no doubt worth looking at.
Feel free to post in the comments which libraries you are using for the view and server side layers that might be worth taking a look at.