The Web Framework Evaluation - Part 07

In this article series, we are going to explore web frameworks from a Java point of view. It covers Java based frameworks and frameworks based on scripting languages that can run inside of a Java application server. The latter are for example Ruby, Python, PHP, Groovy based frameworks. This article is taken from my eBook 'The Web Framework Evaluation'.

You can get the eBook at http://www.laliluna.de/shop.

Difference between the free article and the eBook in PDF format.

• eBook is printable
• eBook includes the upcoming detailed framework evaluations about 1-2 months earlier
• eBook includes a number of performance and load tests showing rendering performance and memory consumption under load.

Strategies to find the best framework

We have set out to find the best web framework for out needs. At this point we are aware of technical options and explored the pros and cons of these options. I made bold predictions on technologies to disappear and finally we need to answer the question, how to select a framework. Let's go.

Analyze the characteristics

The first step is to analyze the characteristic you want to offer to your users.

• Which kind of look and feel do you want to have in your application?

• What's the environment of potential users?
  One browser, different browsers, powerful or slow hardware?

• Which kind of installation requirement can you accept?

• Do you want to be dependent on an operating system for ever or not?

• What is the level of control of the user interaction you need?

• Do you need animations?

• How much risk are you going to accept? Single vendor or not, Open source technology or not?

• What experience and know-how do you have already?

• What is the customer's preference?

Go through the chapters describing the characteristics and exploring the technologies and collect information which can help you to create a general decision. It good to play with demo applications or even get to grips with writing a 'hello world' with different technologies.

Don't be seduced by pretty dialogs. The programming model must be carefully evaluated in the next step. 'Hello world' is easily done with most technologies but only a real use case can show if you can easily implement non standard functionality. But this is not the level you decide in the first step. Try to stick with general characteristics and not with framework specific features.

There won't be a single technology type which is clearly the best. Every decision comes with a significant trade off.

Take a decision on the general technology

After you have analyzed the characteristics you want to offer, you should be able to decide at least if you go for a SingleP or a MultiP application.

The next step is to evaluate concrete frameworks.

New criteria to select web applications frameworks

You need to find new criteria without repeating the error we made at the beginning. A lot if not even most criteria are hard to measure and very difficult to compare. Therefore defining a kind of arbitrary scale like Ajax level has 3 out of 5 points is a pretty useless approach.

On the one hand, criteria allowing a boolean answer are fine on the other hand, you might consider allowing a verbose answer to a criteria. Verbose can be a comment or even better a piece of code showing what you can do.

This leads us to an approach, I like a lot for evaluating technologies. You are all aware of things you need to do in a web application, common caveats or tricky areas. Define a number of use cases you need to implement. In fact, there is not a large number of things to do in a web application.

Do implement those things for every framework. Note your experience, note the code. This approach will provide you with a verbose impression and code is valuable information for a developer of a framework as well.

This real experience and the real code can be discussed far more easily by software developers than an evaluation like �Ajax support got three points of out five�. The caveat following this approach is that you are likely to have zero experience with the framework and implementing things will be hard and painful and can even lead to false assumption if something did not succeed. Imagine a framework with a steeper learning curve but offering great functionality. You might not be able to reach the level of know-how where you can profit from this functionality.

Always consider asking in forums for feedback or if you can afford offer to pay forum members for support. Remote support from a contributor to the framework is probably a lot cheaper then finding a consultant. You might consider visiting a Java conference as well to be able to speak to other people.

I will not define use cases to implement or criteria for you. Because your customers probably have different requirements than mine, your focus might be completely different from mine, your experience is likely to be different from mine. You might use the criteria in chapter 3 as a starting point. Always be aware of the evaluation problems.

Things to consider for evaluation criteria

Defining a scale for a criteria like 3 out of 5 points is pretty useless, if nobody can tell you what level 3 looks like. There is a simple test for this approach. Let all team members describe how level 3 looks like. Only if you get the same description from all people, you can use it. I assume that this will never work.

Aggregation of evaluations is likely to produce nonsense in most cases. 2 points in Ajax support and 4 points in documentation does not natural lead to an average of 3 points. Adding a weight does not improve the nonsense.

Verbose evaluation at least don't as deceptive as scale based evaluations or aggregations.

You will never be able to aggregate all the evaluation steps in a single number unless you believe in the computer 'Deep Thought' which can tell you the eternal truth. So, if a framework reaches 42, then you should choose it.