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 firstname.lastname@example.org. 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 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 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 Lukas Vlcek on August 24, 2007 at 12:17 AM MDT #
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 http://click.sourceforge.net . 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:
Posted by David Marko on August 24, 2007 at 03:39 AM MDT #
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 Zone.net'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 #
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:
Posted by Felipe Nascimento on August 24, 2007 at 02:25 PM MDT #
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:
(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:
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
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 ( 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 :
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 :
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 :
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 :
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:07 AM MDT #
I like java open-source, as I used spring.net 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 asp.net-like 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 #
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:
Tapestry is a superior framework in many respects to its competitors, however there are certain weaknesses touched upon by Kent Tong in this post: http://agileskills2.org/blog/2007/09/my_thoughts_on_the_differences.html
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 #
Posted by Delphi's Ghost on October 26, 2007 at 02:22 PM MDT #
Posted by Angelo Chen on October 31, 2007 at 06:46 AM MDT #