A post on Javalobby (Are Serverside Web Frameworks Becoming Irrelevant?) got me thinking again about javascript based web apps also called SOFEA or SOUI applications. While I don’t believe that the end is near for server side frameworks, (after all a similar post was written 3 years ago), I think it there is a growing interest in these development models.

Now and again I take a look at javascript based client side web development interacting with web services since the notion of a thick, rich client using distributed stateless reusable web services that can just be deployed off into the cloud can be very alluring.

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.

In other examples, the list of items was rendered in the page, and upon completing some Ajaxy action, the HTML for the extra item was added to the list in a separate piece of code. Such practices, which I would imaging are fairly common in these kind of frameworks, are just begging to be a maintenance nightmare (DRY anyone?). You could write some javascript method to render the item in the page and use it in both places, but that seems to defy the syntactic sugar these frameworks target.

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.