Web Framework Comparison

---

---

This document is intended to help us arrive at a decision as to which web framework we are going to use for the Scooby web application.

The web framework being talked about here is the system which serves templated HTML pages to the client. We are not discussing the method by which XmlHttpRequest's are handled, which is another discussion altogether.

Criteria:

Here are the criteria I am using to evaluate the various frameworks. They are listed in order of how relevant they are to Scooby.

Agility

The DHTML and Javascript work in Scooby is going to be particularly complicated. We want a framework that will not get in a front end developers way - ideally, one should be able to see their changes immediately without a re-compile/deploy/restart.

Support

How active is the developer community for this framework? How much traction do they already have? What large, successful rollouts using the framework are there? Using the latest and greatest is fun - but we want something that will continue to be developed and supported for a few years at least.

Skinability

Different organizations using Scooby will want to apply their own look-and-feel to Scooby. The ideal framework would allow for this with a minimum learning curve for the end user - in other words one shouldn't have to learn the ins and outs of a framework to be able to skin it.

Performance/Scalability

How well does this framework serve up pages compared to others? Does the framework lend itself well to scalability - i.e. can you easily add more servers without the framework getting in the way?

Performance of course is vital to any application - the only reason this criteria doesn't appear higher up in the list is that the differences in performance between most mature frameworks are rather small.

Internationalization

Although the exact requirements for Scooby i8ln over the long term are not defined, it would be ideal to use a framework with a robust and convenient mechanism for handling i8ln.

Expression/Templating Language

How powerful/easy-to-use/easy-to-read is the expression/templating language? I don't forsee this being that important an issue for Scooby seeing that most of the dynamic stuff happens in the client side.

Componentization

One of ways in which some web frameworks are helpful is that they allow you to define parameterized components, thereby saving the developer from repeating themselves.

While some level of componentization will be necessary, it will be less important than other considerations in Scooby - again due to the fact that most of the dynamic aspects of the front-end (including the dynamic creation of components) will occur on the client

Frameworks:

The following frameworks will be compared:

JSP 2.0 (with JSTL)

Tapestry

JSF

Spring MVC

Struts w/ Tiles

WebWork

Stripes

Rife

Echo2

Evaluations:

Warning: Can't find topic Teams.JspEvaluation

Warning: Can't find topic Teams.TapestryEvaluation

Warning: Can't find topic Teams.JsfEvaluation

Warning: Can't find topic Teams.SpringEvaluation

Warning: Can't find topic Teams.StrutsEvaluation

WebWork

Agility

WebWork^? using JSP as a view is fairly agile when editing pages, but you have to do some configuration when adding new pages and actions - though not as tedious as Struts/Tiles

Support

The WebWork^? community seems small but pretty active. Documentation is a little sparse, but the learning curve doesn't seem that steep.

Skinability

Nothing special that I see here.

Performance / Scalability

Adequate.

I8ln

Tags for integration with J2SE I8ln.

Expression / Templating Language

WebWork^? has support for different view technologies including both velocity and JSP, so the templating depends on what view technology you use.

The expression language is ognl - just like Tapestry.

Componentization

None as far as I can tell.

Summary

Webwork seems to me like a Struts with a cleaner architecture, but a little less more mature and a smaller feature set. Pretty cool stuff, but nothing compelling for Scooby.

Warning: Can't find topic Teams.StripesEvaluation

Warning: Can't find topic Teams.RifeEvaluation

Warning: Can't find topic Teams.EchoTwoEvaluation

Summary:

An important thing to keep in mind here is that what framework we choose for Scooby is a pretty non-crucial decision. Most of the heavy gui lifting will happen in DHTML/JS anyway so there should be little dependencies on whatever we choose - meaning it should be easy to swap it out if we don't like it. What all the criteria really boil down to is finding something decent that doesn't get in our way of doing the interesting stuff.

While there are several viable contenders here, Spring seems to come out on top. It has a good support and lots of developer momentum, it can use any of several view technologies (including JSP), is easy to configure, and has theme support. So we'll go with Spring, and possibly drop in Tiles if we need it.

Notes

-- GeertBevin - 04 Oct 2005

Hi,

I read notes about RIFE and would like to correct some mistakes and misconceptions. I hope you'll adapt your overview.

Thanks a lot for having considered RIFE.

Geert

---

> Agility
>
> Some agility is lost due to the fact that there are no control structures
> in the templating language (see the templating section below.) While this
> may be more philosophically sound, for our modest templating needs it is
> probably over-engineering."

RIFE will automatically reload when the Java source code for the element implementation changes if the elements were not compiled manually before. This extracts the logic from the templates themselves while still providing you with a development environment that rarely needs to be restarted. Apart from Java, a lot of JVM scripting languages are supported and you can use them instead of the Java for the implementation of element. These will of course also be auto-reloaded.

More information here:
http://rifers.org/integration (Scripting languages)
http://rifers.org/wiki/display/RIFE/Groovy+support

---

> The amount of XML configuration is similar to tapestry.

The XML is just one way to declare the logic flow and data flow of your application, these declarations are fully supported in Java, Groovy and Janino and can even be auto-generated (RIFE/Crud). While these declarations might seems like an unnecessary overhead, they offer a lot of benefits once your application grows bigger than a couple of pages. It makes it very easy to see exactly what goes on, and the engine has complete knowledge of all state transitions which is the foundation of its advanced features (componentization, etc). Don't be fooled by the 'no-configuration' movement, they just shift the overhead elsewhere and often this means that it's scattered and less easy to find or maintain.

More information here:
http://rifers.org/wiki/display/RIFE/Site+structure+and+element+declaration+without+XML

---

> Skinability
> Nothing special that I see.

Since templates contain no logic, it's very easy to setup skins or themes. Just use a nomenclature for them. Typically, you can use the name of the skin as the first directory of the templates. Templates can also be stored in databases if that makes them easier to maintain. Another approach can be to use a clean, undecorated basic collection of templates and use template transformation to provide the skins.

More information here:
http://rifers.org/wiki/display/RIFE/Templates+stored+in+a+database
http://rifers.org/wiki/display/RIFE/XSLT+support

---

> Performance / Scalability
> Hard to find any info on this so far...

From the 1.0 release announcement:

"RIFE is now running on sites with 300000 daily page views, it is used for critical systems in a leading telephony company and has scaled down to embedded usage in mobile phones."

Performance is very good, as is scalability.

---

> I8ln
> None as far as I can tell.

RIFE fully support L18N, up to the URLS, more information here:
http://rifers.org/wiki/display/RIFE/URL+localization
http://rifers.org/wiki/display/RIFE/Localization+through+ResourceBundles
http://rifers.org/wiki/display/RIFE/Localization+through+blocks
http://rifers.org/wiki/display/RIFE/Reloading+localization+resource+bundles
http://rifers.org/wiki/pages/viewpage.action?pageId=281

---

> Expression / Templating Language
> One criticism is that the comment tags are kind of ugly and hard to read.

Did you see this page about alternative tag syntaxes:
http://rifers.org/wiki/display/RIFE/Alternative+tag+syntaxes

Anyway, the tag syntax is configurable, and you can setup the template factories to use other delimiters if you prefer.

---

> Componentization
> Not so much, but you can define parameterized blocks of html and use them
> on many pages.

RIFE is componentized at the core. Everything is built for it, an excerpt from the homepage of http://rifers.org:

"However, instead of mapping actions and controllers directly to the request, RIFE provides a component object model that behaves identically in many different situations such as individual pages, intercepted requests, portal-like page fragments and integratable widgets. Components can be wired together and be packaged as groups that are components in their own right. They can be distributed separately and be seamlessly integrated into any other RIFE project. This provides the same form of reusability as component-based frameworks, but with the raw control of the request-based approach."

RIFE provides many levels of componentization, and doesn't merely focus on widgets or portlets.

---

> RIFE is a very interesting approach to web-app development featuring an
> end-to-end solution all the way from dao's to the view. However, this feature
> set is too large and not appropriate for scooby which is not a "traditional"
> web app.

Nothing requires you to use all features. We have users, that for example only use the DAO inside mobile phones without any web-related features. RIFE is only a 2MB jar file without any dependencies. That file is literally all you need (besides JDBC drivers, etc, of course). This categorizes it as a lightweight solution that happens to have a lot of features.

What makes your Scooby application not "traditional"? If I understand correctly, it's an Ajax application. RIFE is perfectly suited for Rich Internet Applications, and excellent demo of that is http://blablalist.com