Raible Designs

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 www.szeretgom.hu 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 #

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

Posted by David Marko on August 24, 2007 at 03:45 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 #

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!!!!!

Felipe

Posted by Felipe Nascimento on August 24, 2007 at 02:25 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 #

This spring, I had to choose a WebFramework for a major (re)development (a big v2) of our application InterLDAP ( http://interldap.org ). 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 #

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

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