The future of frameworks

I have been working recently on a greenfield project, at the start of coding. It is a great place to be, you get to choose your weapons and start with a clean slate.

It also focuses the mind on choice of frameworks, wether to roll your own, package structure definition, build, etc, etc. Its interesting that there is still no standard stack that everyone just uses without question or arguments (although frameworks like Spring do tend to dominate the conversation).

We have been using a framework called Restlet as we wanted to expose a pure HTTP api to part of our application. As it turns out, we are spending quite a bit of time “restling” with restlet and have ended up writing quite a bit of framework code inside our application, specifically to isolate ourselves from the implementation of the restlet code! The obvious question here is: “What is the framework doing for us ?”

We are also doing the same thing in another part of the application which is using Struts. Although we use some of the features of struts, we want to keep aspects of the framework in our own codebase, such as validation.

Ok, so where is all this leading ?

It occured to me that whatever frameworks you use, you will end up with some amount of framework code within your own codebase, as a kind of “adapter” to the local constraints and conditions of the domain you are in.

What if ? frameworks were more about providing a platform to build your own framework, rather than trying to do everything for you ?

The Commons HttpClient library is an example; it provides some simple encapsulations for you to use how you will. Infact, the commons libraries in general offer something along these lines.

As I write this I realise I may just be talking about “libraries” of code rather than frameworks. However, the point is that the framework should have a “fuzzy” outer layer which you then adapt to your specific codebase, but should also provide you with useful set of encapsulations which save you repeatedly writing the same classes (e.g. something like HttpStatusCode).

To summarise:

In the future, the frameworks that will be most widespread are those that provide a framework for building your own framework.

In some ways this is already happening with Spring. We are, for example, using the Spring JDBC components independantly of the other aspects of the framework, and I think that this ability to pick and choose features contributes to the popularity and success of Spring.


2 thoughts on “The future of frameworks

  1. Hi Jim,

    Glad to hear about your experiences with Restlet. We had been thinking of using it and sounds like something to avoid for now.

    Also, if the framework were more about providing a platform for a framework, I’d probably call it a library :-) I believe I remember someone talking about frameworks call your code, vs libraries where you call them… or something like that.

  2. Hi Pat,

    Thanks for the comment. Intereting idea about frameworks calling you and you calling libraries.

    I have started a post with some more detail about what it was we liked / didnt like about restlet which might be of some help.

Comments are closed.