What Makes a Good Web Framework
7 February 2008A friend recently asked me if there are any server side or web frameworks I like besides the one I developed, Persevere. I have been critical of a number of frameworks, but I think it worth articulating what I don’t like about many frameworks, because there are many out there that I believe are good.
One of the principle issues I have against many web frameworks is the reliance on server session state in the web framework. Many web frameworks rely on the session data in order to achieve basic functionality. While developers should be able to use session data, in particular authentication is usually held in session, but it is advisable to avoid unnecessary use of sessions to store application state information. It is frameworks that rely on sessions themselves for basic application state storage that I do not like.
Why not use sessions to store application state? Let us consider the construct of a session. Is there anywhere else in the in computing world, where it would be acceptable to use a component that will fail if it is not used for a given amount time (of 30 minutes), and until this time of inactivity has passed, the component will consume resources? This is simply a terrible construct to build applications. It consumes unnecessary resources, and forces users to essentially restart their application if they leave it idle for too long. When application state is stored on a client, instead of the server, there is an inherent scalability advantage as well. The more clients that connect to your server, the more room there is to store application state. If application state information is stored on the server, the room for application state stays constant even though the number of clients (and required need for application state) grows.
Component-based frameworks often rely on sessions. An object or component is used as the controller for a certain part of an application, and the framework will keep this component in the session so the object can stay alive to handle and respond to different actions from the client. A particular heinous use of sessions is when frameworks keep an active copy of the UI on the server. This copy of the UI may be a various different forms, where as a DOM tree, or in set of objects that correspondence to the server’s representation of the UI. Of course maintain a copy of the UI layout on the server is particularly burdensome. Offenders include Java Server Faces and ZK.
So what are frameworks that I like? I did a project using Spring MVC, and that framework does an excellent job of avoiding the pitfalls of session reliance. However, I believe Spring is more suited for traditional page-based applications than Ajax-based. In the Ajax world, I think DWR is excellent framework. DWR does not attempt to handle UI work, but simply provides a easy framework for JavaScript and Java communication, with minimal server load.
Another important aspect of a future web frameworks is use of standards, in such a way that different frameworks can work with each other. One of the most important aspects of this in the client/server communication. Most web frameworks do not make any attempt to use a standard based client/server communication, perhaps because there has not historically been very many standards for this communication (other than HTTP, but that is a given). However, with the increasing popularity JSON and conventions like JSON-RPC (and hopefully SMD, JSON Schema, and others), it will be possible for client server frameworks to use more open standard based communication. This will allow other client and server technologies to plug in to the communication. With this mind, I also like frameworks like jabsorb. Client side libraries like Dojo also must utilize the standards, if they want to take advantage of higher levels of communication with the server, and I appreciate this.
No comments yet