Most of the time developers are not doing the picking. So this is one of the key variables. Another variable is whether application is green field or not. I would imagine if developers had a choice they would pick something they are most familiar with or if the framework was end of life something close to what they are familiar with. I am sure there are some exceptions to this rule, operative word being exceptions. I do not have any data, but I would be hard pressed to come up with an argument to use Struts 1.x unless it is a legacy application or all other applications in the shop are Struts 1.x and there are no plans to switch.
Now coming back to the point of who is doing the picking. If you have a competent development manager and the application is “green field” the choice of the framework would consist of the following analysis: (1) Resource Availability; (2) Framework Maturity; (3) Testability; (4) Standardization; (5) Available Tools; and (5) Problem Fit. I would do them in that order. It might seem odd that the problem fit is a last on the list, but if frameworks to be competitive they need to address majority if not all of the common cases. Unless you have a unique problem #5 becomes academic.
All things being equal my choice would be between JSF(MyFaces, Seam, etc) and Spring MVC. If a development manager is less competent or company mandates using well accepted standards JSF would still be a choice. Other choices may still include Spring MVC or GWT because they are big names and it is hard to go wrong.
So in short, JSF, Spring MVC, and maybe GWT. I couldn't agree more. Time will tell.
As an Ajax vendor, JSF is not there yet and people seem to be liking Spring and Struts 2 (hell Struts 1 for that matter). While JSF has been on the horizon for a few years now I think that other new frameworks like GWT are gaining ground a lot more quickly - GWT, next to ASP.NET is the most popular server side Ajax framework around. Haven't tried Wicket too much but Tapestry has had its day and Seam is a dark horse that might really explode this year.
..., Struts 1 is not "end of life".
Struts 1.3.9 was released in August 2007, and work continues on Struts 1.4. S1 is mature and stable, and Struts 1 will live as long as there are volunteers to support it. As an open source project, we have no economic incentive to discontinue support. All that matters is that people continue to use the product, and that the community around the product remains active.
If you check the Struts user list, you'll find that people still recommend Struts 1, depending on the circumstances, and many of those people are Struts committers.
Statistically, even after all these years, more job posting cite Struts (as in Struts 1) than all other web frameworks combined, including JSF. If anyone is adopting anything else yet, it's still a statistical blip. In practice, most people seem to be standing pat. Rick knows this, but to do some research on your own, indeed.com has an interesting Job Trends tool.
Incidentally, one thing both Struts 1 and Struts 2 lack is support from corporate volunteers. To date, I don't know of anyone who has been paid to work on Struts as part of their day job. But, still, we keep on keeping on
My response to T:
Not only do I know this. But I have discussed it on my blog at length many times. I am not trying to hide Struts continued success. Although from a technial stand point, I feel Struts 1.x comes after JSF, Spring MVC and WebWork/Struts2.
That said, Struts is a case study in how you run a successful Open Source project. For a lot of companies, Struts was their first open source project that they used so it has openned a lot of doors. The number one download on TheServerSide in 2007 (and probably 2005, 2006) is a book I wrote on Struts so I get it (The book was written in 2004).
I do think using Struts 1.x on a new project is a mistake (more on this later, see blog). Struts 2, Spring MVC or JSF would be a much better choice.
The problem with indeed.com is since there still is not as many folks with JSF skills or Spring MVC skills, Struts is even listed if a company is looking for JSF developers or Spring MVC developers. Also, there is no reliable way to differentiate between Struts 1.x and Struts 2.0 since many job requests don't list version numbers. Also many people who are using Spring just assume Spring MVC as well so they don't list it.
In short, it is hard to tell how many people are moving from Struts 1 to Struts 2.
That said indeed.com is a great indicator. It can't be the only one though. And it has some problems. I was hoping for others.
As indeed.com goes, JSF growth was fairly slow until January 06. Then is started to take off and grew very quickly. Demand doubled in less the a year and then double the next year as well. Why? I am not exactly sure. My guess would be the AJAX component frameworks for JSF (like Ajax4JSF, Avatar, IceFaces, etc.), composition components via Facelets (and perhaps Clay), Seam, improvements in JSF 1.1 and JSF 1.2, and folks coming up with workarounds for JSF problems, etc. There seems to be a lot of interests in JSF in the Java community and growing job demand to match.
Let's put it this way: If job demand for the Struts framework and JSF were a stocks and you invested in it in April of 2005 by July of 2007 you would barely break even with Struts but with JSF your investment would have grown 700% as of July 2007. (According to indeed.com.)
JSF 2, which is forming, incorporates Facelets concepts, adds native Ajax support (similar to Ajax4JSF) and makes JSF component development easier. JSF 2 should further enhance ones investment in JSF. The new model has partial page rendering via Ajax, which is available today from tools like Ajax4JSF.
With the above said, JSF is still plagued with issues (some technical, some community) and is far from perfect (which I will blog about this year).
I am not tied to JSF. When I wrote Crank (a Java CRUD framework), I made sure it was not tied to JSF so I could switch to Struts 2, Spring MVC or Wicket if I needed to (or was paid to do).
Does anyone have any market data other than indeed.com?
Wicket has had the most active mailing lists for over a year now (see http://www.nabble.com/Web-Development-Framework-f16257.html) and it's downloads are currently skyrocketing. Wicket In Action is almost done, and in the mean while another title is written on Wicket (and possibly one more in preparation). If you're looking for a 'winning' Java web app framework, consider looking at it.
Now, personally I don't think it matters what market data says. Hire developers with solid foundations and let them learn a framework on the job. It's not rocket science, and companies should not go for choices that are less than best fits just because they assume it might be easier to find people for them in the market place.
Is it the most active mailing list because the docs are so poor and people need to ask a lot of question or because Wicket is popular? I've never used Wicket but heard good things about it.
I don't believe there will ever be a dominant framework again like Struts 1.x was. I think many folks have realized it's possible to have more than one framework in their organization and they use one over the other depending on their application's needs. For example, using Spring MVC when the need is speed, using Grails when rapid prototyping is more important.
For request-based frameworks, I believe Struts 2 and Spring MVC will be the leaders, with both of them stealing more and more ideas from Stripes. Stripes will have a hard time taking over either unless they start writing books and putting more efforts into marketing.
For component-based frameworks, I believe JSF will dominate only because it's a standard - not because it's technically superior. Wicket continues to impress and I'm sure Tapestry 5 will not be disappointing. I believe that companies that adopt Wicket will be happier than those that adopt Tapestry 5 as Tapestry has a bad track record of backwards compatibility (sorry Howard).
I believe if Grails beefs up their Wicket Plugin, and Seam adds support for Wicket - it could quickly become the dominant component-based Java web framework.
I do believe all-in-one starter frameworks like Seam, Rails, Grails and AppFuse are excellent. However, I also believe they're solving a problem that only 10% of companies have. Most companies don't have the ability to start applications from scratch - unless they're a startup. Most companies have an existing infrastructure in place for the backend and they simply need a better web framework to slap a pretty face on it. I don't know the best solution for this, but it seems like a logical choice to RESTify the backend (possibly with a web framework) and then use a modern web framework for the front-end. IMHO, the best web frameworks for a RESTified backend are Flex, GWT and Appcelerator. If nothing else, these appear to be the most promising web frameworks for a REST architecture in 2008.
Well put. Well said. I agree. Will this be the year that Java + Flex and GWT take off? Is server-side Java EOL?
Hey Rick, great question. I'm seeing a strong trend in my (non-geek) client firms (those for whom IT is primarily a functional solution and who are more concerned with issues such as familiarity, skills acquisition, and company or government compliance) towards JSF adoption. This seems to be largely to the standardization, products and support led by Sun, inclusion into the J2EE spec. Features and ease of use vs. other technologies are of secondary importance to this sector.
There's the camp that will go with what they know, which is Struts, meaning they will continue with Struts 2. In a large company, that has invested time and developer training on their Struts 1.x apps it would be a logical choice. Then there's new projects. I doubt there will be dominance in one framework. The determiner will be architect or development manager, which has to make decisions on staff resources, maturity, supportability, and project requirements.
Staff resources is that same problem when C# came out. The language was written in such a way that it could in theory pull hordes of developers away from Java, or so it was marketed as such.
Maturity and goes in hand with standardizations. With thes two comes the ability to find resources or developers should problems arise during the project lifcycle. You can hope to expect to find an actively supported framework.
Finally, project requirements. This is a tough "holy grail" for any framework. Projects not only have to meet delivery deadlines, but support any requirements in the future, and this is where we see good implementations of frameworks go bad over time.
My gut says that there won't be a single framework, and although JSF is coming along, it's not here yet. It will help recapture and solidify the ability to grab the Swing developers.We are seeing some of the ideas from JSF spill over to swing in the idea of EL bindings and validation, which are in JSR 295. I think a lot of developers are hesitant because of the EJB debacle, and oters started java application development in Servlets, Struts, or templates(velocity, jsp), and may have never done swing/awt development.
I see. Struts seems like such a poor choice to me. After using Spring MVC and researching WebWork, I don't see how anyone can stick with Struts 1.x. But, Struts 2 is backwards compatible so now you can use your investment with a new framework that is more well thought out (a.k.a. WebWork).