

What server-side Java web framework will be the next for 2008?

  • submit to reddit

...this is a question that interests us as well. We were just discussing the rapid growth of Wicket and wondering if it was the successor. I'll certainly be interested to see what you find out. And if you'd like to write a book about it, we'd be interested in publishing it.

I have heard a lot of good things about Wicket so far I don't agree.

In 2008, there's no question most IT managers are turning to JSF for most new projects. JSF is finally coming into its own and the adopt rate of JSF continues to increase exponentially. Tool support for JSF is still a bit flakey but there are still good tool options out there for companies willing to use a particular tool vendors flavor of JSF (such as NetBean’s JSF components or Oracle’s ADF Faces). Also, the availability of AJAX extensions to JSF such as Ajax4JSF and Apache Trinidad make JSF attractive to IT managers who want to flashiness of AJAX without the JavaScript developer skill sets required for frameworks like Dojo.

As far as what developers want, most are keen to start using Ruby on Rails. The speed of prototype development offered by the Rails scaffolding is extremely compelling and the restful controller resolves a lot of the complaints developers have had with JSF and Struts. However IT managers at conservative companies are often reluctant to adopt Ruby.

Developers are also very attracted towards Seam as it greatly reduces the level of “cookie cutter glue code” between the web layer and the database/services layer. I predict you’ll see Seam adoption increase significantly in 2008. However I’ve also observed that many conservative large corporations will continue to be fearful of Seam’s LGPL (in part due to the Linux GPL’s community’s recent use of the GPL to attack Microsoft, which only feeds the F.U.D. around the GPL and LGPL) and JBoss will remain unwilling or unable to dual license Seam under a commercial license that might resolve these companies concerns.

Longer term, the forces you’ll see driving the adoption trends are (a) the desire for more AJAX style applications, (b) the IT manager desire to tap offshore resources successfully. And unfortunately for the present they have competing skill set needs. Adding true JavaScript controllers to applications ala Google Maps and GMail requires a strong JavaScript developer and tends to be seen as increasing overall application complexity. Whereas off shoring to India and elsewhere drives IT managers towards easy to learn, easy to use, low risk frameworks like Struts, Struts 2, and JSF. With these two forces, sentiment towards JSF remains somewhat mixed. It’s currently perceived by IT managers as the safest way to add AJAX to an application while leveraging a Java developer skill set (although some may argue this on purely technical grounds pointing to GWT and other frameworks). However the need to assemble a hodgepodge of extensions like Facelets and Trinidad to do effective JSF development increases the learning curve for offshore resources, introducing risk most IT managers would rather avoid. This may push these IT managers towards Struts 2 adoption, but only time will tell as it’s too early to call.


Someone else who is pro JSF. I think JSF + Facelets + Ajax4JSF is a great combination for developing web applications. If you web application is more web than application then Spring MVC makes more sense.

I have no market data, but I would guess JSF is going to capture the biggest marketshare in the Java market.

I see.

I'd have to say: Rails, Grails or Tapestry 5 (see how open minded I am ). Rails has a lot of hype and is a great fit for many common in-house applications, though it takes considerable expertise to "draw outside the lines" and overcome some limitations in the database access layer, ActiveRecord. It'll be interesting to see if Rails using JRuby hits a real sweet spot.

Grails really takes a lot of the Rails goodness, without leaving the Java space. Groovy is a very interesting compromise language, between the full openness of Ruby and the dogmatic lock-down that is Java.

And then there's Tapestry.

Tapestry 5 currently skimps on some of the RAD features of the Rails/Grails set, but boy does it make up for it in other ways. I can personally attest (having written 95%+ of the code) that it is very developer focused, in ways that I could only dream of in earlier versions of Tapestry.

Instant class and template reloading. Powerful templates. True inheritance of pages and components. Super testable. Case insensitivity. Very high performance. Easily extensible. Really, really, really good feedback when things go wrong.

I know this sounds like marketing fluff, but I'm just very excited seeing T5 come into its own after a careful build-up of features over the last year and a half.

In addition, the Tapestry story has grown larger than just the code and the community; we'll be seeing true professional support for Tapestry early this year ... Tapestry finally has the last piece that it needs for true success: mature corporate backing, in the form of my new employer, Formos Software Development.

Tapestry 5 seems great. Most of my friends who were big advocates of Tapestry seemed to switch to RoR or some other shiney object. If I were a big company looking for a new web framework to use would I switch to Tapestry? It seems that Tapestry has backwards compatibility issues and switching from one version to the next is difficult. Tapestry 5 is not backwards compatible with Tapestry 4 at all. I have used Tapestry in anger. I have experienced some of these issues. If you are looking for an alternative from JSF to web component development, Wicket seems more stable. Whatever happened to Trails?

Anecdotal mostly (based also on my personal experience) - Spring MVC, then probably JSF

Again, you probably can't go wrong if you guess the top three. Unless Wicket is the black horse that dominates them all.

I'm not sure what the market data is on what developers are adopting for web frameworks. I can only use anecdotal evidence by what my collegues are using in other companies and what I saw in use at other companies while contracting. That was 100% Struts 1.x.

If I were to use indeed.com or other job resources databases, I'm not sure I could formulate the appropriate queries to get at that data correctly. For example, most job reqs will list things like "Struts, JSF" together giving no specificity to what they are looking for (they'll take a person with either skill). This would inflate the stats for JSF and dilute the stats for Struts, particularly for Struts 2.x shops looking for just "Struts" people, regardless of version since the transition is painless).

My gut would say that they would eventually migrate to Struts 2.0 since it is able to leverage the experience of developers and provides for a low risk migration/upgrade path (you can run slices of the same application using Struts 1.x style side by side with slices running 2.x style.) This then allows a company to migrate at their own pace. There is almost no downside to this approach.

The fact that Struts 2.x is substantially a Webwork re-branding is accurate, but also somewhat academic. "If it walks like a duck and quacks like a duck..." Struts 1.x people will feel at home in Struts 2.x and incur almost no loss of productivity. There's a lot of upside to that.

On the JSF side, the fact that it's now a Sun/Java standard is also accurate, but also somewhat academic. EJB 2.x was a standard, yet people looked at it, used it, and Spring and Hibernate just took over. They conceded that EJB 2.x was the standard; they just didn't care and opted for a more suitable solution for their needs.

Finally, I'll even be so bold as to question if Struts 1.x truly is end of life. My personally belief is that we need not keep reinventing the wheel to the same problems over and over. We can't keep switching to the web framework flavor of the day, only to do basically the same thing. The value in the app is not the web framework, it's the business logic. Imagine if we changed the syntax of Java every 3 years or important subsets of it such as the Collections. I guess I am of the view that a company is not an R&D shop. They have "real" work to do, and thus "should" place more value on productivity and continuity of acquired skills, than experimenting.

That said, Struts 2.x gives you the best of both worlds: an upgrade path if you absolutely have to be using more recent techniques (i.e convention over configuration), while still retaining a base of knowledge and skills allows the developers to be immediately productive.

Okay so you like Struts and not JSF. Got it. I agree that Struts 2 provides an upgrade path to WebWork which has a much better design than Struts 1.x and Struts 2 will likely do well.

Published at DZone with permission of its author, Rick Hightower.



kent tong replied on Tue, 2008/02/12 - 2:46am

I am teaching a course on both JSF and Wicket. All the students joined the course to learn JSF and had never heard of Wicket. After learning both frameworks in the course they were asked which one they would use. 4 chose JSF and 3 chose Wicket. The rest didn't respond.

Ha Vo replied on Sun, 2008/04/06 - 10:54am in response to: kent tong

Kent, if you were to chose one of these choices and you knew that a lot of the devlopment had to be done by rather junior offshore developers who will be lead by seniors. Which one would you chose? I guess I'm asking what alternative can better be learned and controlled in an offshore model.

 Thnx for the reply

kent tong replied on Sun, 2008/04/06 - 9:23pm in response to: Ha Vo

In my opinion Wicket is much easier to learn and use than JSF. It also contains a built-in efficient unit testing framework which should be a major plus in an outsource model. Of course, juniors often don't write testable code, so having a unit testing framework alone is definitely not enough; mentoring is very much required.

Gerd Ziegler replied on Fri, 2008/11/07 - 7:28am

For those who like the simplicity of Apache Velocity theres a framework out there at www.ztemplates.org with form ajax support. For short intro take a look at introduction to ztemplates from Lunatech Research.

Ghanshyam Baheti replied on Sun, 2008/12/07 - 12:09am

Hi, Probably I may not be Ideal person to sure which framework has demand or big buzz for future days , but like to share some of my experience of working on Struts, Spring, wicket and JSF.

Spring is most suitated framework for Buissness logic layer and widely used with Integration with another frameworks like Struts,Wicket,JSF and.,,lab..la. So Spring is Common part with when we design most of the applications. So obiviously I feel its widely used. Also recently Spring Framework 3.0 is released with further features. go for more detail for my blog for this or spring official site. So Obiviosly spring is in demand I feel.

Here now question remains which one from Struts, Wicket and JSF.

Struts:- People are posting about it from 1995. so google have lot of stock! we know struts is no more. So less chances of use in new application devolpment. It is coming with struts 2 as well needs to be take into picutre.

Wicket:-Wicket is all about simplicity. It is Swing for Web Applications. There are no configuration files to learn in Wicket. Wicket is a simple collection of components. In Wicket, your web applications will more closely resemble a Swing application than a JSP application. If you know Swing, yes you know most of the Wicket!
None of the existing frameworks are appealing to me in terms of quickness, ease of development, easy to understand etc.

JSF:- It is another framework on which started to work recently. most of the Drag and drop devlopment is provided and looks very good. I see its growing widely. Still I need to learn lot in this, you can add here.

I missed here about other frameworks as i don’t have much Idea about them. you can make valuable addditions for us.

Rick Hightower replied on Thu, 2009/01/15 - 4:36am

It has been a year. Is there any current insight into this topic?

Bruno Vernay replied on Mon, 2009/02/16 - 4:45pm

I worked on a document about Web Frameworks. I would like to post it on JavaLobby. I would  remove the long list of framework and if you have other remarks, I would be curious to see what people think.



Comment viewing options
