...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.
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.
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'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.