I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

JavaLobby Web Framework Comparison Guide: A Call To Arms

  • submit to reddit

Over the next few months here at JavaLobby and Web Builder Zone, we plan to provide the most comprehensive guide to the Java Web Frameworks available. The idea for this came about when I, a desktop developer, decided that I wanted to write a web application using one of the Java-based web frameworks. It became apparent that we have a lot of choice (maybe too much!) and that there is no single source of comparison for these frameworks.

This effort will involve a lot of community involvement and hard work. I'd like to go through the main points of this drive here.

  • We've all heard, and read, the heated discussions that happen centered around "why do you used framework X when framework Y is so much better and newer". There's a common reason for this: the developer works for a company who have mandated that this is the technology to be used. It probably happens even more in the current economy, where there's no time for research or changing frameworks.
    By providing an informed comparison between all frameworks,  we do the research for these companies.
  • By having a benchmark, perhaps we can ensure higher quality of web frameworks. I don't mean to say here that frameworks are unstable or written badly. But with a benchmark to aim for, new (and current) framework developers have something to test against - this can't be a bad thing.
  • End the search for people like me! When someone new to (or rusty on) web development needs to find a framework, they can look at the framework comparison to find the best fit for their project.

The Process Behind It All  

I have a process in my head for how this should work, but I need you, the community, to help me fine-tune and agree on this. Here's the plan:

  1. Volunteers. The first thing that we need are people who can put the time into evaluating one web framework. When you consider the amount out there, you can see how many volunteers need to get involved! You can volunteer to this effort anytime - I guess the easiest way is to indicate your interest in the comments thread in this article. If you have a particular framework you are interested in evaluating, let us know. 
  2. A List Of Frameworks. Once we have a list of volunteers, we need to decide what we'll get them to evaluate. Over the next few days I'll compile a list of the frameworks that are out there and publish them here. Where possible we'll put volunteers names against each framework and let you know if we need more people.
  3. A Reference Application. To carry out a complete and fair evaluation, we need to have the same reference application to be implemented in each framework. I plan to have the reference application requirements defined by the end of this week.
  4. An Evaluation Form/Article Once the reference application is implemented, an article will be provided for each of the frameworks, describing the experiences, the positives and the negatives, with an initial score for that framework. We will provide a template for each of the volunteers to fill in at the end of their evaluation.
  5. Final Evaluation All the evaluations will go through a panel of the editors here at DZone, before we start publishing them. Results and reference applications will be freely available to all.

We're looking for your help in evaluating these frameworks, as well as looking for your feedback on how we should run this comparison. Perhaps you have some ideas of what the reference application should include? Or maybe you want to make sure a certain framework goes through the evaluation process. Just let us know, and together we can make this a successful project.


Howard Lewis Ship replied on Mon, 2009/01/19 - 11:54am

So is the goal to see what a new developer for the given framework can accomplish, or what an experienced developer can accomplish?

Kristian Marinkovic replied on Mon, 2009/01/19 - 1:02pm

 i'd volunteer in doing the implementation with Tapestry 5. but i'd need the requirements first.

Tobias Marx replied on Mon, 2009/01/19 - 2:00pm

What about "2.5  - Requirements"...A list of requirements or things to consider would be essential when trying to evaluate different frameworks. What about collecting a list of requirements and problems to be solved for all frameworks and then summarize (maybe by examples) how they would be solved with the different frameworks? The final result might be a table with different requirements/perspectives that shows which framework is suitable for which requirement...and what the strength of each framewoen it comes to rating the framework. Some points that would be worth to be considered when evaluating frameworks are:

  • numbers of developers
  • number of other projects that are built on top of this framework
  • speed/performance (T5: + Wicket: -)
  • code efficiency (number of lines of code to implement a reference application T5:+ Wicket:-)
  • design flexibility (major template changes without touching the java code or war file) (T5:+ Wicket:-)
  • multiple output media (e.g. mobile phone version and parallel web version without duplicating java code) (T5:+ Wicket: -)
  • dynamic form generation (e.g. reading the configuration for a input form from a database) (T5:- Wicket:+)
  • theming
  • documentation
  • number of code examples (T5:+: Wicket:++)
  • how messy/clean is Javascript integration (T5:+ Wicket:-)
  • debugging

The forth point would be interesting - this would lead to developers enhancing the sample application all the time, trying to optimize the code as much as possible in order to be on the top of the list in the category "code efficiency" :-) In the end there would be a list of top frameworks for every category and a top list of frameworks across all categories.

It would also be fun to do a "framework competition" - get together all lead developers of all frameworks, give them a small sample application to do at the same time and then see who finishes first....:-)

Gregg Bolinger replied on Mon, 2009/01/19 - 2:21pm

I don't see how this "research" can be anything but biased opinionated information no better than the slew of data already all over the web, except that its centralized.  Everyone has a favorite framework or two.  For example, you aren't going to find a Wicket user able to evaluate Struts2 fairly.  And really, comparing an action based framework like Stripes to a component based framework like Tapestry is unfair.  They approach things so differently that you'd have to compare action based vs component based, not Stripes vs Tapestry.

 Lost cause IMHO.

James Sugrue replied on Mon, 2009/01/19 - 2:38pm in response to: Howard Lewis Ship

Good question Howard. For now, I think it's the new developer that will benefit most from this.

James Sugrue replied on Mon, 2009/01/19 - 2:40pm in response to: Gregg Bolinger

I see your point Gregg. But one of the points of this comparison is also to find out those things - when is component based better than action based for example.


Gregg Bolinger replied on Mon, 2009/01/19 - 3:04pm in response to: James Sugrue

There's no answer to that question, IMHO.  Generlizing project needs doesn't work.  So you can't say projects requiring features X, Y, and Z should use a component oriented framework.  Hats off if you guys happen to pull something off, I just don't have the highest of hopes that you produce something that doesn't just create more flame wars.

replied on Mon, 2009/01/19 - 3:49pm in response to: Tobias Marx

That's an arbitrary list like any, and I disagree with half of it.

replied on Mon, 2009/01/19 - 3:57pm in response to: Gregg Bolinger

I agree. Like programming languages, frameworks have their strengths and weaknesses that are best experienced by actually spending some time playing around with it. 

Richard Kennard replied on Mon, 2009/01/19 - 11:45pm

Hi James,

As part of building examples for my Metawidget project, I have implemented the same sample application using Swing (desktop), GWT, JSF, JSP/servlets, Spring and Struts (Web) and Android (mobile):


The application is non-trivial, though it is not exactly complicated. Still, you may find it a useful starting point, especially comparing the Swing-implementation to the Web ones.

Note: Metawidget uses these other frameworks, it does not compete with them, so the comparison is pretty unbiased.



Jose Maria Arranz replied on Tue, 2009/01/20 - 4:26am

Some helpful links:


Choosing a Java Web Framework

Choosing a Java Web Framework (Revisited)


I can help to answer any doubt about ItsNat and help to build the reference implementation (but I'm not the appropriated person to evalute it).


James Sugrue replied on Tue, 2009/01/20 - 6:04am in response to: Jose Maria Arranz

Thanks Jose - some very useful links in there.


Fab Mars replied on Tue, 2009/01/20 - 11:38am

I'd volunteer for JSF.

But I would like to draw your attention to the fact that the conclusions can be REALLY different whether the application is written with JSF alone or JSF+some RIA lib (RichFaces, IceFaces, etc). From my experience, and trying not to disclose anything in advance, I guess JSF alone will be painful; and it will be trivial with some extra component lib, not even mentioning Facelets, Seam, etc...


Maybe it's a good idea to make the exercise twice: once with JSF alone, once with RichFaces for example. It would help some people realize some things.

One may argue that it would be biaised to add "functionality" to the framework for this exercise. I would answer that leveraging extra functionality is the whole point of having an extensible framework. That raises the issue of the "limit" to give to this extensibility. RIA lib or not ? (i thought both) Seam or not ? (i think no) Facelets ? (no real opinion) Version ? (1.2 obviously).

Alex(JAlexoid) ... replied on Tue, 2009/01/20 - 2:37pm

Hey... You should also include a "Roll your own framework" as an option :)

Lutz Huehnken replied on Wed, 2009/01/21 - 1:01pm


While it is generally a noble idea to help people to choose a web framework from the many options available, I am very sceptic about the chosen approach. Comparing them by implementing a reference application, that is. Different frameworks have very different strengths and weaknesses .

Do you have a lot of stateless pages, and want to minimize session creation/handling on the server side? Then JSF, Wicket, Echo3, WingS might just not be the right choice (I hope I don't get flamed for claiming this. I may be wrong. I haven't looked at those frameworks for a while. They might be an excellent choice).

You might choose GWT, Echo3, ZK if you want pure Java Programming and a very AJAX-y interface.

You might choose an action oriented framework like Struts if, I don't know, if you need to for some reason.

Your choice might also be influenced by what level of Spring integration you need, how much you want search engine robots to crawl you site, how many users you wish to serve, if you run on a cluster or not, if you build for the internet or an intranet, if your design is plain or fancy, if you want to use script.aculo.us or jQuery, and so forth.

I think the outcome of the comparison will be very much influenced by the design of the reference application.

Another thought: I use a framework that works great for me, but takes some getting used to (if you need to know, I'm talking about Tapestry). That is often the case with "opinionated" software - I hardly met anyone who liked, say, Maven, on first contact. But once you "get it", that often changes. (And in the case of Maven, sometimes changes back again later :)

Will the common reference application be enough to "get" the framework?


David Lee replied on Fri, 2009/01/23 - 10:56am

Forget the nay sayers.  This is EXACTLY what's needed to demonstrate, more than anything, the weakness of framework A vs B,C & D.  The time it took to implement said reference implementation should also be recorded, to show the difference in productivity between the frameworks.  Sure that can be manipulated, but some data on time is better than none. Simply force participants to signup in order to take part, and record when they download the specs, record when they upload the specs(ala SCJD).

I'd love to see the results, and would gladly volunteer my time if you need any help making this happen.

Mahesh Lavannis replied on Sat, 2009/01/24 - 3:13am

I spent about an year seriously learning and evaluating Java web applications development framework. Specifically, I looked into the following:

* EJB3







My conclusion is that, at this point, choosing the "best" framework is less and less of a complicated question. Here are the reasons:

1.  EJB3 with JPA is now so close to Spring and Hibernate, that choosing between EJB3 or Spring+Hibernte is no longer a very relevant question. They are functionally equivalent. Of course, there are some differences between EJB3 and Spring (Spring does not support annotations, for example) - but architecturally they are now equivalent.

2. Hibernate is now the front runner ORM no matter which framework you choose.

3. JSF+Facelets+Richfaces now provides component oriented view technology - which is clearly cleaner and better than Tapestry & Wicket

4. Seam provides the complete integration of JSF+Facelets+Richfaces+EJB3+Hibernate - what is left?!!! In addition Seam provides enhanced functionality to the integration - by providing page level granularity for  navigation specification & a superb contextual model.

5. As for Grails - it is an attempt to make Ruby on Rails (RoR) available in Java. Though it does a good job of integrating with Spring and Hibernate - it has a poor component view technology. You need to do the wicket or tapestry integration yourself. In addition, Ruby on Rails (RoR) is a page-centric MVC framework - which is not as good as the modern DI-powered domain-model-centric frameworks like Spring and EJB3. So in attempting to duplicate RoR, Grails has unnecesarly limited itself to RoR idiosyncracies- like forcing you to have a controller class for every page.This kind of approach is unnecessary when you attach a component driven front end to Grails (like Wicket or Tapestry)

Conclusion: JBoss Seam is by far, as of today, the best & only fully integrated end-to-end solution out there for Java based web frameworks.



Mahesh Lavannis replied on Sat, 2009/01/24 - 3:25am

Possible reasons for not going with Seam:

1. You are already invested in Spring/Wicket/Tapestry

2. You need the level of AOP support that Spring provides.

David Lee replied on Sat, 2009/01/24 - 9:29am in response to: Mahesh Lavannis

This is exactly the kind of riddle this "contest" can solve.  I concluded the opposite about Seam, I would guess one's productivity w/it fair somewhere near the bottom of all frameworks(this would be true for all jsf based frameworks).  While I'm not fan of grails, I would guess your productivity would very good.  Why one would take grails and slap tapestry in front of it, rather than just using groovy w/tapestry or wicket is a mystery but to each his own.

 For me the question is which framework allows me to get the job done on time, and allows for the next developer to maintain the app w/the least amount hassle. 

Tobias Marx replied on Sat, 2009/01/24 - 10:10am

I have just looked at Seam....and when I see the first "getting started" example I just have to close the browser window.....










What a xml massacre !! web.xml should be enough and maybe one page config if you can't avoid it...but not all those! That becomes a maintenance nightmare....



Ronald Miura replied on Sat, 2009/01/24 - 10:25am


Seam probably do more, but not necessarily better.

It's a personal opinion, but I think Wicket's model for state handling (your state is what is serialized with the page, period) is much more clear and intuitive than Seam's (a 'cloud' of objects, mixing both structural and transient ones referenced by global names, with no clear boundaries). Maybe a bit less powerful, but certainly much simpler, much lighter (see the comparison: http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/), and probably powerful enough for its purpose, which is, state handling.

Even Spring WebFlow's model, which is somewhat similar to Seam's, is much more manageable, since there is a clear mechanism for declaring what is the state used in a flow (beans that will be created at the beggining of a flow and will be put into the flow scope). You can put things into the scope in scattered locations in the code, but Seam's only mechanism is to put things in scattered locations in the code (@Out annotation).

And, Spring does support annotations. Were you doing research in 2004's dusty books? :)

Mahesh Lavannis replied on Sat, 2009/01/24 - 12:02pm

Dear Java ethusiasts,

I accept all of your valuable comments. What this brings to light is the more fundamental question - WHY should a framework be considered 'better'? Until this question is answered - it is really a run in circles!

I present my reasons for choosing Seam (and please feel free to differ). Please note that I am not a core-developer/consultant for any framework. I primarily had to go through all this study for my own needs!

 #1. First note that only Seam and Grails are end-to-end  frameworks. Other frameworks - JSF/Wicket/Tapestry/EJB3/Spring/Hibernate/Toplink are not end-to-end but solve part of the problem. JSF/Wicket/Tapestry are for component view technology, EJB3/Spring are for server side component modeling & Hibernate/Toplink is for ORM.

If you independently choose your favorite presentation techonlogy (JSF/Tapestry/Wicket), then your favorite Server Component Technology (EJB3/SPring) and then your favorite ORM (Hibernate/Toplink) - that would be IDEAL. Unfortunately, that means that you will have to worry about the integration yourself.

If you are not inclined to do that, then your choice reduces to Seam or Grails (at least as of today).

Seam has the fullest integration stack: JSF/Facelets/Richfaces/EJB3/JPA

Grails has: JSP/Spring/Hibernate

There are attempts to integrate wicket/hibernate into both Seam and Grails - I believe the formal integration of these into any of the above is not yet complete.

Also note that both Seam and Grails support Groovy - so that is not a point for comparison.

#2. I believe that what makes an application supportable/extensible/scalable in the long run is a domain-driven approach. In other words, if you believe in designing applications primarily around your ~bussiness objects~ - as opposed to designing it around your web pages or database tables - then you need a strong component based view technology + a strong ORM.

Seam comes integrated with both (JSF/Facelets/Richfaces & JPA). Grails is integrated with one (GORM).

Grails, on the other hand, brings in the Ruby-On-Rails philosophy of page-driven-design. I am not driven to this philosophy because web page designs have a tendency to change rapidly (and they should - to meet user needs). A page-centric model forces the application code to have to be modified too often (which should not change often - for each change can potentially break the code)

#3.The framework which helps you solve the problem "fastest" is not necessarily the best one - because the architechture it dictates might not be one that scales well in the long run. This is where domain-driven design shines. They always remain true to your UML model- so if one member of your team leaves, someone can pick up where s/he left - provided of course you believe in your team using UML, and not directly jumping into code(!)

 #4. There is a strong feeling that "XML means bad!" - this is sad. What is sad is when XML is abused - when it forces you to specify miles and miles of "XML code" in a single file. Seam has correctly identified and resolved this problem by introducing "configuration by exception" - which in the Ruby-On-Rails world is called "convention over configuration" (and has proved to be a big hit).

So now you have to do very little XML, primarily for customizing (overriding defaults). Secondly, Seam supports page.xml - so tht you have little configlets for page level navigation - instead of one big config file for navigation.

#5. What stands out about Seam the most is its "big picture" attitude. The Seam team has commited itself to providing an end-to-end solution - and feels free to use proven technologies to achieve this goal - instead of being tied to any technology. Therefore they have already provided support for Groovy, they are working on integrating Spring and also Wicket.

Tomorrow if a new technology shows up which is very good, they will work at making it available as well.

In this sense, Seam has the .Net approach more than any other framework. What has been good about .Net is that Microsoft - from the very beginning - focussed on delivering a end-to-end solution. Looks like the Java open-source world has finally caught up(!)







Ronald Miura replied on Sat, 2009/01/24 - 1:06pm in response to: Mahesh Lavannis


But is the proposed comparison restricted to pre-integrated solutions? Or could include stacks composed by two or three independent frameworks which are easily integratable (and probably have integration libraries already)? And, just because Seam or Grails comes pre-integrated, do you really believe you won't face any integration problem with them? Well, I'm not that optimistic.

About 'better', yes, without context, it's completely subjective. And in the end, what will matter is the opinion of the one who chooses to use some technology or not, being backed by numbers (which is pretty subjective, too) or not.

To you, it may be clear that Seam is 'better'. To me, not so much. So, let the community post all the reference implementations they can, and let each reader decide what's best from his own point of view.

Mahesh Lavannis replied on Sat, 2009/01/24 - 2:27pm


Yes, I agree with you. Simply being an "integrated" solution is not the reason for being 'better'.

These are just my opinions and I wanted to share my reasons with the community. I myself look forward to other opinions and reasons people choose what they choose.

That said,I am a little sceptical of the proposal to create a "sample" application in different frameworks - and compare the implementations.

1. My experience is that there being no one requirement for web applications, the 'sample' application might just implicitly favor/disfavor frameworks.

2. Any sample application will be a small one - something that can be implemented by one developer in say, 1 month? This itself is not very representative - since we all know that any real industrial application requires a team of people working on it.

My proposal is that a comparison be made, not based on coding or specific features, but how a framework would be used in a realistic scenario. For example:

1. How independently can a team of Java programmers, database administrator, information architects, graphic designers and bussiness process analysts work together in each framework?

2. How auto-documentable is the framework? In other words, if someone on the team leaves, how much irrecoverable knowledge (in their 'head') leaves with them?

3. How easy is it to change the front end (web page design) or back end (database) without having to make changes to the application?

4. How true is the application domain model to the bussiness model? How much is the 'glue'/infrastructural/integration code? Because at the end of the day, it becomes the developers responsibility to maintain this code as well(!)

5. Does the framework lend itself easily to performance analysis? What tools are easily available to detect and resolve performance issues - such as slow response times, high bandwidth or server usage?

6. If a better framework comes up in the future (and it will!) will your investment in code move forward?

Mahesh Lavannis replied on Sat, 2009/01/24 - 3:07pm

Please note that though I might 'appear' to be promoting Seam - it is really not my intention at all. There are many things about Seam that are not my best-case scenarios:

1. I feel Spring is better than EJB3 - it has a better focus on AOP, whose benefits I feel will be a blessing moving ahead.

2. Though a big deal is made about annotations - how they free you from XML - I am not fully onboard. Because annotations implicitly tie the POJO to the framework. So if you have to drop the framework, you have to redo the annotations - and touch all the POJOs!

I think 'configlets' are the real solution - small, centext-centric XMLs. That way if you change framework, the POJOs remain available. You just have to figure out how to modify the configlets (and chances are high you will be able to write a script to automate update of configlets)

3. Seam does not address issues of migration of existing code investments. Clearly, people are already invested in Spring/Tapestry/Wicket - how efficiently can this code be brought on board Seam? Where are the tools and documentation?

Ronald Miura replied on Sun, 2009/01/25 - 7:33pm in response to: Mahesh Lavannis

These criteria are mostly related to the architecture, not the (web) framework, and are completely subjective.

(1) is relevant, would be a nice comparison point. (2) is nonsense, no framework makes your code auto-documented. (3,4) are architecture-related, not framework-related. (5) is not really relevant, if you have JMeter and the Netbeans' profiler you are sufficiently equiped for almost any (developer) performance analysis (which nobody does, anyway). (6) is most related to architecture too, and if you take in account the 'standards live forever' argument, anything is excluded besides JSF+JPA+WebBeans, I mean, Seam.

This is just a simple technology comparison. It will not end the my-framework-is-better-than-yours wars, anyway. I'm interested in it because I want to see how people tend to use each framework, and draw my own conclusions (which is what most readers want to do, too). And I guess the comparison 'moderator' won't end it saying '... and framework X is clearly the best one!', because it would be just too lame. :)

Mahesh Lavannis replied on Sun, 2009/01/25 - 9:36pm


Yes, several of the points relate to architecture - but oftentimes, frameworks (and languages too) implicitly favor/disfavor architectural styles.

Obvious examples - when you go with Spring, it promotes a strong DI-centric & AOP-centric application, Hibernate promotes a domain-centric architechture, Grails promotes a page-centric architecture.

That said, I am 110% with you that the comparisons should not be allowed to denigrate to the usual my-framework-better-than-yours  - that helps no one achieve anything. Needless to say, Java community has the highest respects for all the developers and user community of all the frameworks.

Now, moving ahead, I think the comparison can be narrowed down by breaking them up, as follows:

1. Compare the front end: Wicket Vs Tapestry Vs JSF+Facelets+Richfaces

2. Compare the middleware: EJB3 Vs Spring

3. Compare ORMs - Hibernate Vs Toplink

4. Compare integrated solutions - Grails Vs Seam

5. Compare architectures - Page Driven Vs Domain Driven, and which frameworks will be best for each

 Finally, comparisons should not tend towards simply a differentiation - but should also point out similarities. That way it becomes clear if going with a framework A will get you 80% of the features of framework B - in other words, when its not an all-or-nothing game.

Mahesh Lavannis replied on Sun, 2009/01/25 - 10:29pm

If the Grails tem would be kind enough to officially integrate Wicket/Tapestry, that would be really cool :)

Ronald Miura replied on Sun, 2009/01/25 - 11:14pm

Hm... the post title says 'web framework', not middleware, persistence, or architecture... Maybe we should narrow the scope for now :)

Mahesh Lavannis replied on Mon, 2009/01/26 - 12:47am

Yes :)

I guess the point I am trying to make is that, though it 'appears' like there are a lot of choices out there for choosing frameworks - many of these frameworks are ~not~ in direct competition with each other. Some are in competition and others are complimentary frameworks - so there is a need to make sure apples are not being compared to oranges!

 To me it appears that, practically speaking, the only real critical framework decisions are:

1. Spring Vs EJB3

If you choose EJB3, chances are high that you will use JSF(+Facelets+Richfaces) --> and you will consequently use Seam.

If you choose Spring, you will have to choose again:

2. Wicket Vs Tapestry5

In this case, you might also decide if you want to go with Grails (which is good if you come from Ruby-On-Rails world and want to leverage your knowledge).


--- My take on EJB3 Vs Spring ---

Spring is so good - that EJB2.1 component model was bascially thrown out of the Window, and replaced with Spring :) Except, from what I understand, Spring's other powerful feature - AOP -is still superior to EJB3s interceptor-based model. 

As for specific features, each will catch up with the other - sooner rather than later. For example, it looks like Spring has already started supporting annotations.

--- My take on Tapestry5 Vs Wicket ----

Tapestry5 now has a POJO based component model. Also, they provide the integration with Spring, allowing beans defined by Spring to be injected into Tapestry IoC services. They also support annotations over XML.

One of Wicket's highlight was the absense of XMLs -I guess Tapestry can now say it has eliminated XML as well.

The other thing going for Wicket is the absense of code in their templates (However, they create view components in code - I am not sure why that is a good thing). For its part, Tapestry5 allows for its bean methods to be directly specified as event handlers - so templates should be code free.

 It looks like Tapestr5 has taken the best part of JSF (POJO centric components) and eliminated the bad part (over-specified XML)


I look forward to more opinions and insights!





Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.