My business unit is trying to standardize if we can on a single Java-based Web framework going forward to simplify the Web development process, especially as individual developers move from one division to another, or centralized support groups need to maintain multiple applications from multiple divisions.
At the enterprise level within my company, the architecture group says that they will provide support for either Spring MVC or JSF+ (where the + represents the accompanying technologies you would use to provide a more maintainable application and a more rich user experience, e.g. Facelets, Richfaces, etc.).
Now my business unit is trying to decide which of these two frameworks, Spring MVC or JSF+, is the most appropriate to standardize upon for our development community.
What follows are some considerations based on discussions we've had internally thus far.
Please provide any feedback you might have based on your experience with either of the two frameworks. Are any of the perceptions or claims below inaccurate? Are there key considerations that we are not even thinking of that can help us to come to a reasonable recommendation? Any feedback you have is welcome.
- In general, our business unit divisions who have developers coming from a component-oriented programming model background seem to prefer having their developers remain with this programming model when migrating to Java Web app development.
- It provides a more familiar programming environment
- It would hopefully make developers more productive as they would have less of a learning curve
- For those Web application developers that are already coming from a Struts background, obviously their learning curve would be much less steep if they were able to continue to use a page-based, action-oriented Web framework like Spring MVC.
- Knowledge of / Experience with Frameworks
- Within our company, there appears to be a greater amount of experience with Spring MVC than with JSF currently.
- Within the industry, it seems that there is a greater amount of experience with JSF if you are to look at developers' resumes, the greater amount of books and other documentation available, etc.
- A "Comprehensive Spring Training" course that includes about a 2.5 hour session on Spring MVC authored by SpringSource and tailored to our company's needs by another business unit is already available through our training center.
- An additional "Spring Rich Web" course is also already being jointly planned.
- No training modules are yet available internally for JSF, but obviously many are externally.
- Migration of Developers' Skill Sets
- If we were to choose Spring MVC, component-oriented developers would have to learn a new programming model.
- If we were to choose JSF, action-oriented developers would have to learn a new programming model.
- Either way, training and re-tooling would have to take place.
- Anecdotally, it is probably true that we have more component-oriented developers than action-oriented ones.
- Vendor Lock-in
- With Spring MVC, you can write controllers in such a way that they are effectively annotated POJOs, but even the annotations introduce a Spring dependency.
- In all likelihood, we would want to extend some of the controllers that Spring provides based on the use cases for a particular page flow.
- Thus, most likely, selecting Spring MVC means that applications built using it depend upon it, and they can't easily be ported to another Web framework.
- With JSF, you're really just dealing with a specification, so although the JSF RI provided by Sun is the currently recommended RI, there is nothing that ties you to it specifically.
- Maturity / Market Penetration
- The first RI of JSF and the first version of Spring MVC both seem to have emerged around the same time in 2004.
- From a vendor and tools perspective, there has been much more traction around JSF, especially in terms of providing a "drag and drop" user experience for component developers.
- That said, SpringSource itself is now a vendor that offers support for its entire Spring portfolio (including Spring MVC), and the Spring IDE does a decent job at getting users going on building and visualizing Spring-based applications.
- If we're using a combination of technologies for developing JSF applications like Facelets and JBoss Richfaces, would there be an Eclipse plug-in / extension or (if we could justify the cost and complexity) yet another IDE that could simplify and automate the usage of those technologies together?
- If the push from the industry seems to be towards migrating complex UI interactions to the client via Ajax and Flex, what value would JSF+ add on top of this?
- For example, if we were to standardize on Spring MVC for the Web framework, Dojo for the Ajax toolkit, and (when appropriate) Adobe Flex for very rich components that it simply does not make sense to do in Ajax, how would JSF+ improve this picture?
- In addition, if we try to follow our company's enterprise standard of using Dojo for Ajax, and a component library like Richfaces is leveraged, what if Richfaces didn't use Dojo under the covers or it used a different version of Dojo? Would it interoperate properly with any Dojo-enhanced elements of the page that perhaps did not come from a JSF component?
Some Potential Options
- A member of our working team proposed that we recommend the use of Spring MVC as our Web application framework, given its relative familiarity to existing action-oriented developers, its simplicity, modularity, and the overall trend towards doing components more using client-side versus server-side technology.
- There was some definite resistance to this idea, at least until we have some greater insight into where these two frameworks stand in the industry today and what their roadmaps are for future enhancements.
- The possibility of supporting both frameworks was also discussed, but we are trying to narrow down the use of technologies to one wherever possible from an IT simplification perspective if that is plausible.
- It was also mentioned that Spring MVC supports using JSF as its view technology (just as it supports JSP and Velocity), but it is unclear whether that hybrid approach would really provide any benefit to component-oriented developers who would still have to learn the Spring MVC request life cycle.
- Obtain greater insight into and share with the working team:
- The market penetration of each framework
- Perceptions of these frameworks by major technology advisory firms like Gartner, Forrester and Burton
- The future short-term and long-term plans for each framework
- For example, JSF 2.0 and Spring MVC 3.0
- The potential consequences (whether negative or positive) of eliminating one framework or the other from our development environment.