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.