Subscribe
About

Choosing a Web framework

The vast number of frameworks available makes the decision a difficult task.

Andre van der Schyff
By Andre van der Schyff, Senior developer at DVT.
Johannesburg, 02 Jul 2009

In the last six months, I've discussed which Java Web framework a company should choose. In this last Industry Insight, I'll look at the last factors to consider.

The sheer number of available frameworks can make it difficult to make a choice. Before choosing a framework, it often helps to compare their various features. Some of the more important features to consider are the following:

1. Learning curve: Is the learning curve short or long, and steep or gradual? For example, Rife provides a number of unusual concepts such as Web continuations, while JSF has quite a complex request life cycle. These are powerful tools and ideas, but they can take time to understand. Try and find a framework that is powerful but also intuitive, or where a small amount is needed to be understood to get going.

2. Binding: Does it provide a mechanism to bind front-end forms to business objects? This is a useful feature that saves developers from writing a lot of boilerplate code. Good binding frameworks provide flexibility by converting text submitted from the Web page into the desired data types or business objects on the fly.

3. Validation: If validation is included, how powerful and flexible is it? Some frameworks provide simple type-checking on the front-end using JavaScript, which is fast and useful, while others work with a binding mechanism to assemble the entire business object and allow more complex validation in the back-end, which is slower but more powerful. Even better, some frameworks such as Wicket can assemble the object for validation in an Ajax call, which provides both speed and flexibility.

4. I18N: To what extent does the framework support internationalisation?

5. Resource requirements: What kind of memory and processing overhead is required on the server? Rich Internet applications can be resource-intensive as they track client state on the server, while simpler frameworks tend to be less resource-intensive. The application design is also crucial: for example, objects should be discarded after the request and not added to the session unless absolutely necessary. Seam provides a number of interesting features to help manage this, such as a process scope that maintains state during a business process. For rich clients, the minimum requirements of the client machine must also be considered.

Most recent frameworks provide at least some level of Ajax support out of the box, saving developers from having to work with separate JavaScript libraries if this is required

Andre van der Schyff is a senior developer at DVT.

6. Ajax support: Most recent frameworks provide at least some level of Ajax support out of the box, saving developers from having to work with separate JavaScript libraries if this is required. The extent of Ajax support differs vastly between frameworks: those with really good support provide advanced features such as server push and replacement of front-end components.

7. Components: Does the framework supply anything more complex than HTML out of the box? If so, are they easy to extend and customise, and has the community contributed to extend the functionality of the components or provide new ones?

8. Unit testing: How easy is it to 'unit test' the front-end? How complete is it; for example, can Ajax calls be tested?

9. Debugging: Can the front-end code be debugged easily or at all? This mostly applies to very rich frameworks such as ZK or GWT.

10. Support and community: Is the community active and helpful? How many people use the framework, and how much documentation is provided? If further assistance is needed, does the support require payment, and how helpful is the commercial support?

11. Maturity: With more mature frameworks, someone has already solved most of the common problems. Newer frameworks, on the other hand, provide new and interesting features, which may be more important to companies if they are willing to experiment.

12. Separation of concerns: How well is the front-end separated from business logic? The framework should preferably not support mixing of logic and presentation at all, as this prevents bad coding practices from creeping in.

* Andre van der Schyff is a senior developer at DVT.

Share