%ICON_SCOOBY_LOGO%

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:

JSP 2.0 (with JSTL)

Agility

JSP is fairly agile under the right set-up. With most app servers everytime a jsp file is touched it is re-compiled and you will see the results on the next page load.

The controller in this scenario is a Java servlet, so a change in the controller will require a rebuild and application restart. There shouldn't be happening much in our controllers though.

Support

JSP is very well supported. It is a Sun product and is the basis for other popular frameworks including Struts.

Skinability

Nothing special.

Performance / Scalability

Very good - jsp's are compiled into java servlets so no parsing has to happen. Also, since it's just plain jane JSP there's not a lot of features slowing it down.

I8ln

JSTL has tag library for accessing J2SE MessageResource^? bundles. Application is responsible for determining what Locale is appropriate for given user.

Expression / Templating Language

The expression language is pretty powerful, simple and easy to read - simply evaluates anything in braces preceded by a dollar sign. Typical use: "Welcome ${firstName} to Scooby!"

The templating language for JSP comes in the form of html-like tags. Using these tags you can perform (amongst other things) for-each loops, conditionals, and String manipulation.

It is quite adequate for Scooby's needs.

Componentization

It is extremely easy to create parameterized component-like blocks of html through tag files. Although I would not consider them true components (due to their inability to maintain state, lack of a backing class for logic) this is adequate for Scooby.

Summary

Using just JSP without any additional framework is the most conservative and lightweight approach to take. There's no complicated configuration, there's good support and what it does it does well and simply.

Tapestry

Agility

Developing in Tapestry is fairly agile - changing the page's template or specification (an XML file which describes the components that a page contains) requires that the user hit a "reset" link before seeing the changes, but no recompilation or restart of the appserver is necessary unless the (optional) java backing class is changed.

Support

Tapestry has been around for at least 5 years and has been slowly gaining momentum, especially since the release of 4.0 to beta.

Tapestry powers the theserverside.com and nhl.com, both fairly high-profile sites.

Lately however it seems to have had it's thunder stolen a bit by Sun's JSF - seen by some as the "official" component based web-application framework.

Also, Tapestry's documentation is pretty sparse and out of date right now.

Skinability

Tapestry's component nature makes it easy to pass around blocks of html or tapestry mark up as parameters. We could use this as a way to pass in html to those components that need custom skins

Performance / Scalability

I have had some concerns about Tapestry since unlike JSP based frameworks it doesn't compile (as far as I can tell) pages and heavily uses reflection. However, the use of reflection has decreased significantly with 4.0 and benchmarks have been run (pre 4.0) which put Tapestry at only slightly slower than JSP

I8ln

Integrates nicely with J2SE i8ln. You can even have different templates for different locales, which is unique as far as I know.

Expression / Templating Language

All Tapestry templates are straight html. To make a tag a tapestry tag you just add a jwcid like so:

Welcome <span jwcid="@Insert" value="ognl:firstName">Bobby</span>!

What's nice about this is that if you give try to have a browser render the template as is, it will be able to do so, since it's just straight html.

The expression language is ognl, which can do just about anything java can do in a simplified but familiar syntax.

The one negative thing that comes to mind about this syntax is that you can't simply just write ${firstName} to eval an expression, you have to put in a tag like above - this can be a little verbose.

Componentization

Tapestry is extremely component oriented and creating components is quick and easy. There is really nice integration of Javascript into components as well which ensure that multiple components of the same type on a page won't have javascript variable names that conflict.

Summary

Tapestry is a powerful framework which is well suited to creating lots of server-side components. There is a fairly steep learning curve (with mediocre documentation) to learning the way form handling works, but this is proportional to its power.

Of course, Scooby will probably not have many components on the server side, so Tapestry's main strength would be wasted here. However, it still should be considered a contender.

JSF

Agility

Not very agile is the main complaint from people - lots of annoying XML config.

Support

Good support - it's a sun product.

Skinability

Its componentized nature helps here.

Performance / Scalability

Not sure right now.

I8ln

Tags for integration with J2SE I8ln.

Expression / Templating Language

JSP tags and JSP-like tags.

Componentization

Very much so, although it is not as easy to create a component as it is in Tapestry.

Summary

JSF is a mature product with a strong developer support. However it is not appropriate for this project, as the overhead needed to do a lot of the development will be wasted since we won't be using most of the features.

Spring MVC

Agility

Pages are JSP's. Configuration of controllers, etc. are Spring bean config files, which can be a little verbose, but are pretty easy to read.

Support

Spring has a very active developer community and is well supported and documented.

Skinability

Spring has themes!

Performance / Scalability

Adequate.

I8ln

Since it's JSP, just use jstl tags for this. Themes can also be internationalized.

Expression / Templating Language

JSP based.

Componentization

None, except for what JSP gives you.

Summary

Spring is a very solid choice. It is a more modern framework supporting newer programming idioms (like IoC^?) and is well supported. Its theme support is very well suited to our skinning needs. Since it's JSP we can also pull in tiles if we need to for page layout components.

Struts w/ Tiles

Agility

Editing pages is quick and easy, but adding new pages or new tiles is irritating, requiring lots of XML.

Support

Struts is well supported, and is the de-facto standard for web-app development right now.

Skinability

Tiles could be very useful here.

Performance / Scalability

Adequate.

I8ln

Since it's JSP, just use jstl tags for this.

Expression / Templating Language

JSP based.

Componentization

Tiles are sort of like components, but not as flexible as Tapestry's components.

Summary

Struts is another safe bet - everyone knows how to use it, and it's known to work. Tiles is nice for laying out pages and could be useful for skinning. Config is really annoying though.

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.

Stripes

Agility

Pretty agile. Stripes is another JSP based struts-like framework - but it seems to require a lot less artifacts than struts and also let's you throw up a JSP without having the backing classes in place so you can preview the page.

It makes pretty good use of annotations as well which can be more convenient than editing a bunch of XML files (although you can get a similar level of convenience with a Struts/XDoclet solution)

Plus the annoying problems of Struts indexed properties and nested properties seem to be solved here which is a major headache. But we probably won't be using forms like that anyway so it doesn't matter.

Support

The documentation seems pretty decent. There doesn't seem to be that much of a community around it though which could be a problem.

Skinability

Nothing special included, but I suppose you could integrate with Tiles...

Performance / Scalability

Not sure really, but I would imagine it would not be a problem - it's a not an unusual architecture or anything.

I8ln

Integrates with J2SE i8ln like everyone else, but does some stuff to make things simpler - like calling setLocale on every request so you don't have to.

Also has support in its validation framework for i8ln which is nice

Expression / Templating Language

JSP Tag lib w/ JSP Expression Lanaguage

Componentization

None.

Summary

Like WebWork^?, a viable contender for best re-working of struts. WebWork^? seems to have a larger community of developers, but stripes has better docs and what seems to me a larger (or at least more compelling) feature set.

Rife

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.

The amount of XML configuration is similar to tapestry.

Support

There is a small but active rife community.

Skinability

Nothing special that I see.

Performance / Scalability

Hard to find any info on this so far...

I8ln

None as far as I can tell.

Expression / Templating Language

Rife templates are normal HTML with some specially formatted HTML comments being used to render dynamic values and blocks of html.

Rife takes a unique approach in that there are no control constructs (loops, conditionals, etc.) in the templating language. Instead, the backing request handling classes have full control over the template and can render the same block multiple times with different params, or not render them at all, or manipulate them in anyway. This level of control over the template from the backing class is fairly unique and allows for a very clean separation of logic and view.

One criticism is that the comment tags are kind of ugly and hard to read.

Componentization

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

Summary

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. The lack of an expression language, control constructs will also get in our way here (although a good idea for other types of apps).

Echo2

Summary

Echo2 is so different than other web frameworks that using the same criteria to evaluate it would not make sense. Programming in Echo is much more akin to programming in Swing or some other "traditional" event/component based framework than any other web framework. From what I can tell, there is no notion of templating - if you want to add a table or a button or whatever to a page, you do it programatically. There is also tons of support for AJAX.

This is a very interesting approach, but won't work for us for several reasons:

• Having to do the entire view programatically is too much work.

• We are more attracted to using javascript and DHTML to provide us with and event-based gui model. In other words, we want to do something very similar to echo, but almost entirely on the client because...

• ...maintaining the state of each gui component of each user would place an undue burden on the server, and doesn't really win you anything

• Choosing Echo2 would lock us to it way too much.

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