Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Choosing a JVM Web Framework: Stories Wanted

My last post on choosing a web framework got quite a few comments. Some seemed to like the application categorization technique as a means to narrow the choices. However, others seemed to disagree. So if application categorization is not a good methodology for narrowing the choices, what is?

I think one of the best ways to figure out a good methodology is to find out what people have done to choose their web framework. I'm looking for stories from developers who have evaluated 2-3+ frameworks for a project. I'd like to come up with 3-5 stories as part of my talk to highlight how some teams have chosen their web framework. What were your important criteria? What made you choose the one you did? Was it a tight race between a few of them? Did industry buzz or application categorization play a part in your decision?

Please send any stories you'd like to share to Of course, you can also post your story in the comments - but an e-mail gives it a bit more validity. If you'd like to share your company name, that'd be great, but it's by no means required. I haven't decided if I'm going to prevent all cases as anonymous companies or not. If you do send a story, I'll make sure and ask your permission before I share any of your personal/company information. Thanks!

Posted in Java at Aug 22 2007, 12:02:58 PM MDT 19 Comments

I've tried many, JSF, Spring MVC, a little GWT, and they all try to work like VB or Delphi, allowing me the developer to set them up graphically. Unfortunately that's not the way most of the corporate shops I've worked in are set up, we get a ton of CSS and HTML from some graphic designer, and we're forced to try and wedge our code into the midst of 6+ deep div nesting, where everything is controlled by HTML ids, even when using that element in that particular place might be against spec. The to top it off we have to make it work in a portlet. That's why I'm currently intrigued by Wicket, in the case I've been able to sneak it past the corporate "accepted standard" weenies...which doesn't even include allowed me to do what I needed to do while impacting the html I was handed only minimally, practically not at all....though I still wound up having to change all of their repeating IDs into Classes.

Posted by Mike on August 22, 2007 at 07:55 PM MDT #

I had a project I started with JSF and spent about 2 weeks coding the dao and service layer when finally starting the work on the UI. I ran into some nasty problems I couldn't came around (displaying buttons in a datatable that work even when the backing bean is not stored in the session). Then I found Facelets which solved some of my JSF problems, but not all - although it was nicer than plain old jsp-jsf soup. I played around with wicket 1.0 some months before this project and thought I would give it a try. I spent about 6 days on the UI with JSF when doing the switch to wicket and in about 6-7 hours all of my UI pages were converted from JSF to wicket. The service layer wasn't affected much, the conversion from JSF backing beans to Wicket components was quite straightforward in my case - I could even automate some of the facelet xml conversion to wicket style plain old html.

This was in late 2005 and I haven't looked back ever since. I've started developing a cms style portal with wicket in early 2006 called which just won an award in Hungary as one of the best web pages focusing on a city. In the mean time I pushed wicket hard at some companies I'm consulting for: mentoring developers on the framework, putting together a course for newcomers. There are some pretty large applications that were written in wicket during last year including a loan frontend for a major Hungarian bank. We like the technology very much, it's really easy and straightforward once you get it.

Posted by Janos Cserep on August 23, 2007 at 05:51 AM MDT #

My favourite option is Stripes. I have tried Struts (1.x) and some home-grown frameworks before but I don't have any reason to switch to other framework since I've met Stripes. It fully satisfy my needs. Easy integration with AJAX, easy configuration and yet the framework allows for easy extension as well. Easy integration with Spring and Hibernate. Nice validation. I have used Stripes for more then 5 projects now and the fact that I haven't find any show-stoppers yet is self-explanatory I guess. For me Stripes is the real option when the project does not require other framework to be used.

Posted by Lukas Vlcek on August 24, 2007 at 12:17 AM MDT #

Lukas - thanks for the story. However, if you've only tried Stripes vs. Struts 1.x - I don't know if that qualifies as a comparison. ;-)

I'm looking for stories that companies can learn from - ones where 3+ frameworks were seriously considered. I want to figure out the ways that folks are widdling down the options to their chosen framework. From what I've seen, the technology and ease-of-use are not always the most important factors. I'll try to write a post on what I think is important in the near future.

Posted by Matt Raible on August 24, 2007 at 02:00 AM MDT #

My preference is Click Framework . Its quite unknown but very powerful, easy to setup project and use. It has nice bindings to Apache Cayenne ORM, what simplifies starting project.

Click Framework PROs:

  • component based with many components easy to use
  • very nice internal design that makes things easy to use
  • huge documentation
  • very nice architecture and almost none required dependency on any other projects
  • Apache Cayenne integration
  • plugin for Eclipse

Posted by David Marko on August 24, 2007 at 03:39 AM MDT #

Just to make the story complete, we were considering Stripes, Tapestry and Wicket. We ended with Click. We were really surprised by the development speed and fun you get when things go very seamlessly. But i thing the ORM plays the sugnificant role as well. When using Tapestry we used Hibernate. It was XML pain. using click and Apache Cayenne we dont touch XML configurations at all.

Posted by David Marko on August 24, 2007 at 03:45 AM MDT #

We started using Groovy on Grails with version 0.5, and have since moved to 0.5.6.

We've had no stability issues or performance issues, even though it's months away from a 1.0 release and we're testing it on a server with limited specs. The speed is beyond what I expected: pages that take a second or so on development on my Core2Duo 2.33GHz are spit out in milliseconds on the live site, which is running on one of's lowe-end VU200 virtual servers.

Productivity has been great, even considering the learning curve. I came to Grails with no knowledge of Spring or Hibernate, and have had on occasion to learn not only of Grails and Groovy but the foundation it's based on. Even so, in most cases it's been out of curiosity for how something is being done behind the scenes (much time spent scrying Hibernate logs or looking at the generated db structure).

For me, the best thing so far was realizing that for the first time in a while it was taking me longer to come up with an implementation or design that I felt happy with than to actually execute it, and to experience how easy it is to change courses if I come up with something better. No "crap, if we do it better we've got to throw away three day's worth of code" resistance.

That means my time is being used where it's truly useful, and I'm ending up with approaches I'm happy with.

The only problem of note so far is that we were unable to get it to run successfully on Debian 4 or 3.1. Instead of chasing the issue, which seems to be Hibernate-related, we've simply had it replaced with CentOs 4.5.

I'm absolutely sold, and will using Grails again on an upcoming project for a client.

Posted by Ricardo J. Méndez on August 24, 2007 at 08:58 AM MDT #

> Just to make the story complete, we were considering Stripes, Tapestry and Wicket. We ended with Click.

David - while I appreciate the Click salespitch, you haven't done anything to describe your framework elimination process. Did you pick Click purely on technical and ease-of-development? Did you eliminate Rails because it wasn't Java? I'm not looking for people's opinions on the best framework - unless that's backed up with useful information (that companies can use) on how they came to that conclusion.

Same goes for you Ricardo. ;-) You haven't talked about any other frameworks or any sort of evaluation/elimination process.

Posted by Matt Raible on August 24, 2007 at 09:37 AM MDT #

I have used Struts 1.x with hibernate and a home made service layer. I have also used Spring + Hibernate + SpringMVC (AppFuse 1.9.x). Nowadays I am using Grails 0.5.x (but have used it since Grails 0.3). Grails is all about productivity in JVM platform. It is an agile web framework form the JVM platform. It's a Groovy abstraction to Spring + Hibernate + SpringMVC + Sitemesh + Quartz + ..... On of my applications is a online store, and it is in production. No problems. Stable as it should be. After all, it is based on stable Java frameworks. Grails has my vote.

Posted by Felipe Nascimento on August 24, 2007 at 02:12 PM MDT #

To complete my story: my elimination process was the balance between productivity and production environment stability.

Even Grails being not 1.0 release yet, it is stable with the functionalities of a pre 1.0 release. It is stable beacuse it is based on stable frameworks (Spring, Hibernate, etc). It is not totally stable in regard of API, as some API changes have occured since 0.3 (it is RC0.6 now, going to 0.7 and then 1.0 in october/07). But when a tested an app in production env, the Grails app is stable.

In terms of productivity, I havent seen anything like Grails in JVM platform. It is so productive to develop with. And fun! A Grails app is very smooth to maintain. If you like Code By Convention over configuration, Grails is great. But if you need to do something different from the convention, you can configure Hibernate, or Spring with their xml config files.

I also evaluated the following: if you have legacy Java code, you can use it with grails. If you have SpringMVC controllers, you can use them with grails. If you like Java open source projects (like apache lucene, http commons, XFire, whatever), you can use them with grails.

So, the conclusion was:

  • Grails is JVM? YES
  • Grails is production stable? In my opinion and experience, YES
  • Grails can take advantage of known Java frameworks? YES
  • Grails is productive to develop with? YES YES YES YES!!!!!


Posted by Felipe Nascimento on August 24, 2007 at 02:25 PM MDT #

Hello, I'm working for the biggest OSS/BSS Telecom. software provider in the world. We would required to chose the web application framework for the new web application, main requirements for it were:
  1. It should look the same as any other web application developed in our company. Explicit control over visual HTML.
  2. It should be compatible with J2EE and should be deployed in WebSphere Application Container.
  3. It should be a mature, stable framework with many successfull deployments in the mission critical applications.
  4. The framework should allow us to write testable applications - that's the main criteria from the developers point of view.
  5. We've expected to have a explicit tree and table components therefore component orientation of the framework was essential.
  6. Framework should consider performance as a essential application features, horizontaly scalable (HTTP Session control better be explicit)

After four man/years development efforts the second version of the application is already deployed by the biggest telecommunication operators in Germany. Application performance is very good.

All visual requirements were satisfied. Testability of the application is exceptional, testing coverage is exceptional (comparing to the previous approach where we've used internal Struts based framework). Internal and external customers of the framewok were very satisfied.

As you already guessed, the framework was chosen - Tapestry 4. We are very satisfied with the framework and would recommend it for further use.

Posted by Renat Zubairov on August 27, 2007 at 03:46 PM MDT #

I've been using RIFE for a few years now and it has treated me extremely well. It is a single solution that includes most things you'd need for building J2EE web applications. I have tried a few other solutions, which most recently was Wicket, and found that the time/code it took to get something done was much greater than with RIFE. Here are a few things that should be known about RIFE:

  • Lightweight but Complete: RIFE is a single jar download that includes most things you'd need and it does it all without a plethora of dependencies.
  • Simple Application Structure: RIFE's application structure is created within an XML document, much like Hibernate mapping files. While the choice of XML might be frowned upon, it does provide a simple viewpoint into the structure of your application and how it flows.
  • Simple ORM: RIFE's ORM support is dead simple. Create your POJO, create constraints, which unfortunately are in a separate Java file, and then tell RIFE to create your database objects. RIFE even uses the constraints to validate your POJO much like the Hibernate Validator does.
  • Simple Templating: I feel like RIFE's templating design and syntax spoils me. When I tried to convert a RIFE basic page to Wicket, I did it with much less Java and HTML than I did with RIFE. I feel spoiled by RIFE's very simple syntax and markup support. No need to use special tags in my HTML or anything.

(Note: While I do make direct comparisons to Wicket, I do not have hard feelings for Wicket nor do I discredit it's importance. I also do not claim to be a well-versed Wicket developer so some of my statements may not be valid but they are things I thought when trying to convert a simple page from RIFE to wicket.)

There are many more reasons I like RIFE but when trying out other things recently, those things came to mind. All in all, I love RIFE and the simplicity it adds to my web development cycle, although I sure would appreciate more documentation. ;)

Posted by Jeremy Whitlock on August 28, 2007 at 02:00 PM MDT #


we wrote 2 web based applications for transportation organisations. the applications includes:

  • Fleet-Management
  • Staff-Management
  • Order-Management
  • Reportings
  • Accounting
  • Customer-Management
  • and more ...

we choose, and we are very lucky for that, the tapestry framework.
we start with tapestry 3.0 and now porting this applications to tapestry 5.
the very clean structure and the consequent MVC decrease the development time and help us to separate the business logic from the UI so that we have no problems (we tested it) to developing the same application under the head of a Swing-UI without change one code line in the logic base.

one contra: the high learning curve

greetings from
homburg Softwaretechnik

Posted by Sven Homburg on August 31, 2007 at 12:40 PM MDT #

This spring, I had to choose a WebFramework for a major (re)development (a big v2) of our application InterLDAP ( ). InterLDAP is an Identity management software, witch works upon LDAP directories.

The base code of the web tier was quite old : first version was done around 2003 and was a mix between Struts and a home-brew framework with some kind of component orientation. Trying to upgrade, debug and maintain existing code would be a bottomless resource pit. And it was not our business to build a webframework.... So, the resolution was made to drop all this code to adopt a real webframework.

The requirement was :

  • it has to be in Java. Our society is open to Ruby (we develop and daily-use a kind of bug/request manager in RoR that should be open-sourced this autumn) but InterLDAP is in Java, and so should be the web layer ;
  • it has to integrated very well with Spring 2 ;
  • it should be "component oriented", because that was the natural way adopted in the deprecated code and (our team think) a better approach for us ;
  • it could be "in development" as long as its durability was made sure, because the soft wouldn't be due before mid-2008 ;
  • it has to be cool, pragmatic, effective and thrilling because developers works better when the love the techno they use ;) And we already payed the price with Struts... So, the framework must have as little burden as possible (the framework have to be an helper, not an encumbrance) :
    • a minimum of XML if possible ;
    • hot reloading ;
    • testing facilities ;
    • ease of code reuse (a good component orientation) ;
    • good separation of concerns (logic/template).
  • we didn't care that the framework will be a full stack framework because :
    • our core techno, LDAP, is never known of such framework ;
    • we already have a big amount of code for the data access/middle tiers.

Based upon these requirements, We spent some time (almost a week) in the jungle of Java Web Framework, just reading comparison, looking at the "ecosystem" of the framework (community, project linked to it, press buzz, etc). Quite quickly, the choice list drop to JSF, Wicket and Tapestry.

Wicket as a really good press, and was a kind of buzz work (not as bussing as RoR, but intrigating). Tapestry was the old one component framework, the one that open the way, and I had several friends that really love it, from a long time. JSF was the "obvious" choice, the norm, it has to be part of the choice. Struts 2 was almost retained : we already had a good experience with it, but we really want a component oriented framework, this approach better matching the deprecated code.

Quickly, JSF was dropped : too complex, too huge, too much XML, it reminded us the worst day of Struts or EJBs. Perhaps we should have gone to Seams, but we just found JSF frightening.<p/>

From that point, we decided to code a little application, an LDAP directory viewer, based on our existing business code and each framework to see which one we should choose. But before the test, we had to look more closely to what version choose for Wicket and Tapestry :

  • Wicket 1.2 was the current stable version but 1.3 will be the one graduated to Apache top level, and would bring a lot of interesting features. The compatibility and upgrade problem was a major point of interest for the developer, but as 1.3 was schedule with the graduation of Wicket this autumn, we choose 1.3 ;
  • the choice for Tapestry was easier, but not comforting : Tapestry 5 was in its first alpha, but it will be completely incompatible with previous version. Moreover, it seems to be an habit for Tapestry, so than the community is completely parcel out between Tapestry 3, Tapestry 4, Tapestry 4.1 and Tapestry 5 (even if at this time, T5 community was ridiculously small). That was a BIG drawback for Tapestry. In fact, at this point, we almost find that the risk was too hight with Tapestry and discard it. Nevertheless, we decided to test Tapestry 5, even if its first release should be only in 2008 (other version were dead ends).

At this point, we spend between a week and 10 days with each framework to code our small application. It's really short, too short, but we can't spend more time.

Wicket was impressive. The mailing list is really responsive, the approach of the framework is innovative (at least, for me who doesn't have any Swing background), the separation between code and style is really strict, etc. Still, there is several drawback :

  • Wicket is hard, at least in the beginning, when you just don't how what and how to do things the Wicket way, especially because the documentation is really light and (I found at the time) confusing, so you spend a lot of time frustrated, not succeeding in doing really simple things ;
  • the "statefull by default" approach is interesting, but we (with our Web background) spent a lot of time (in the given time frame) dealing with using it in the good way, and dealing with cases were we just want a stateless behavior ;

So, we ended the test with a mixed opinion : Wicket seems the have a really steep learning curve (especially for us and our lack of Swing background), but the reward seems to be that a powerful framework : look at code written by Wicket expert, you just have to say "ho, you can do it this way ?" And just after "Yes, it has to be done this way". But how much time to become a Wicket expert ?

Tapestry 5 was... Wow. It was the effect it did to me and the other tester. Its simplicity is amazing : its a joy to create new components (simple POJOs with some conventions and annotation), test them and reuse them along your application. The separation between HTML and logic is rather good, the reload facility a must have (Wicket also have this), the injection framework is amazing.

But it was an alpha, and lacks a bunch of basic features and components : no AJAX, really few "input editors" (for instance, no date picker). A lots of bugs were also present, the documentation was rather inexistent, the mailing split across Tapestry 3/4/5 users...

But there was this "wow" effect, the feeling to be highly effective, to have the things just done, and easy and well... to enjoy developing a WebApp in Java, something that before that, I thought I will nether feel (RoR was here for that ;)

The Tapestry 5 choice would have a hight part of risk, especially in the doubt around the long term support of the framework (perhaps i will be an incompatible Tapestry 6 version in 2 years ?), its adoption curve that may be really slow, and its "alpha" status. But it is so pleasant to use (and Howard L. Ship assure that it will never be a Tapestry 6, and it's an Apache top level project, and the adoption will be quicker as soon as it will be released, and the alpha status would not last always).

So we goes Tapestry 5.

With several month with it, I can say that :

  • Tapestry 5.0 was really alpha, and lacks the polish and all the ecosystem that goes around a mature project ;
  • the doc are still really lite, but it improves (the wiki with HowTo start to be well-filled) ;
  • the community is parcel out, and resources seems to be wasted between a lot of version ;

But Tapestry 5 is great , and it's a joy to use it. It meets almost every of our requirements and we are really happy with our choice. We just hope that a lots of people will give Tapestry a chance, be amazed and help the community to grow.

Note : all the remarks (negatives and positives ones) on frameworks are personal feelings and are relevant only for our team and project, with our background. I do not want this comment to be understand as "Tapestry is the best and JSF suck" or something like that... Different need, different answers. For us, Tapestry 5 was (and is) the best suited.

Note2 : sorry for my awful English, hope it is understandable :/

Posted by Francois Armand on September 04, 2007 at 08:50 AM MDT #

I just wonder why don't u guys write a framework like ? I personally think developing web (JUST WEB) in is good for : 1.almost pure html-template except for <asp:repeater> 2.url fully-controlled. 3.consistent API

Posted by nazar on September 30, 2007 at 03:07 AM MDT #

Sorry. I add some comments.

I like java open-source, as I used and NHibernate in my projects.
But it is the java web frameworks that keep me at bay.
I HATE taglibs badly.

sorry for my complaints. I myself just need a web framework (not for its drop-in controls IDE. but for its almost-pure html templates and fully-controlled url).

If Matt think I'am noisy, just delete my comments please.

Thany u guys.

Posted by nazar on September 30, 2007 at 03:20 AM MDT #

Hi All,

I did an extensive study for a dissertation, lasting a year on web frameworks. but particularly Tapestry 4. I also wrote a complex web application spanning over 1000 personal man hours.

My findings are related to productivity and interoperability as these were seen as perhaps the most important areas for businesses. Tapestry was a success for the project, but had two critical failings:

  • Backwards compatibility
  • Documentation and project resources

Tapestry is a superior framework in many respects to its competitors, however there are certain weaknesses touched upon by Kent Tong in this post:

I don't see wicket as the answer, but his comments do ring true... I would be reluctant to throw around the word genius so much as well, also add to that URL handling could have been better in Tapestry 4.

One thing I did uncover in my research, was the innovation of the Spring framework, which is one of the primary catalyst for abandonment of EJB 2 and the flourishing of web frameworks... credit is certainly due to the architects of Spring.

JSF is the most serious contender for longer term investment by a company in a web framework, yes it is immense, but they have heavy investment and rock solid documentation and training material, Once you are using it, it is really simple. EJB 3 now also uses Pojos, so is also a far cry from EJB 2.

As far as view technology goes JSF again is getting it right, they are striving for clean separation of the view to make it pluggable. This is vital for the future (as many new platforms and devices are using the net more and more, and there is an increasing need for vector based interfaces so that new resolutions can be accommodated). So if they keep at this, they should get ahead of the game.

Posted by Peter Stavrinides on October 04, 2007 at 03:32 AM MDT #

I've spent a while (a year) on and off going through different frameworks. Struts 1, while it had a strong user base, but looked like it was on its way out and Struts 2 was going to be a new and rather different animal. JSF was a standard so it appeared that it would be a good choice provided we could work with it. Turns out that we could (why everyone says it is complex and requires an IDE I have no idea). Ideally, we were looking for JSF + Spring + Hibernate combo. Wicket, Tapestry, Click and others all looked like minor players. We did consider Spring MVC given that we were interested in Spring. However, in the end, Seam won out. Even though it is primarily EJB based, it provided a lot of other elements in a single stack over picking and choosing different pieces. Elements such as Jsf with Ajax & Richfaces, pageflow management, EL expressions throughout the framework, state and conversation management, dependency injection/outjection, Facelets support for JSF, built in security and workflow management. The other frameworks all presented part of the solution, I still had to go and pick other libraries for the rest of the solution, and try and get them all to play nicely. Additionally, there was/is the prospect of the Red Hat Developer Studio IDE which would give us a single stack from the Application Server, to the framework to the IDE tools. It is like the of the Java world. I now find myself as productive using Seam as I am/was with Borland Delphi, perhaps more so since Java libraries in general seem to try and eliminate a lot of boilerplate code.

Posted by Delphi's Ghost on October 26, 2007 at 02:22 PM MDT #

Hi Delphi's Ghost, I'd like to know how Seam make you productive like you using Delphi? I'm very productive with Delphi and would like know if there is any tools for the web offering almost the same? Thanks.

Posted by Angelo Chen on October 31, 2007 at 06:46 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed