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.
Feedback To-Date
- 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.
- Training
- 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.
Next Steps
- 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
- As another example, how the Spring JavaScript and Spring Faces components of Spring Web Flow 2.0 might shift the playing field
- The potential consequences (whether negative or positive) of eliminating one framework or the other from our development environment.
30 comments:
If you plan on supporting REST in your webapp someday, I believe Spring MVC is a better choice. If you want your application to operate like a desktop application, JSF will likely work better.
Since you're considering JSF, is using JBoss Seam an option? There could be an issue with vendor tie-in there, and you didn't mention anything about what technologies & standards you're using in the other application tier(s) so that would be another factor in deciding whether to use Seam.
Not that its very helpful, but I think you missed out when you lost Struts2 as a choice.
Matt,
Thanks for the feedback. It looks like there are plans to better support REST-ful URLs in JSF 2.0, but I don't think we can wait that long, as one of our requirements will be to embed Web components that we develop within an Eclipse RCP-based Hybrid container when necessary, where that container is being used to provide a level of richness and real-time interaction that simply cannot yet be achieved with Web technologies alone.
I have read that there are ways to workaround the inherently POST-ful nature of JSF to provide links, etc., but I think we would rather have a framework that supports it now by default.
Thanks,
Mike
JBoss Seam was actually a contender at the enterprise level within my company for potential support, but they settled on JSF+ because there are more books, tutorials, supporting vendors, and a wider development community supporting JSF than Seam.
They were also kind of nervous about depending on a specific vendor implementation and/or extension of JSF, just as they would be nervous about depending on Spring's heavy integration with JSF in Spring Web Flow.
Dusty,
Struts2 was also a serious contender at the enterprise level, and was found in some ways to be more elegant, extensible, pluggable and developer friendly than Spring MVC. However, a number of our business units had already started using Spring MVC, so at the enterprise level, they really only wanted to have to support one action-oriented framework (on top of our legacy Struts 1.x applications).
Thanks,
Mike
Hi Mike,
I am the lead of the Spring Web Flow project, and technical lead of the Spring Web MVC module in the Spring Framework. If you have questions about the JSF integration in the Spring Faces module, or how JSF relates to MVC, I'd be happy to answer them for you and your team to help in your evaluation process.
In summary, Spring Faces allows you to use the JSF UI Component Model with Spring Web MVC and Web Flow controllers. We feel this approach combines the strengths of JSF with the strengths of traditional web MVC architecture.
I tend to agree with Matt, JSF is not a fit for all projects, but when it is a fit we believe Spring Faces makes the component model considerably easier to integrate, particularly for people coming from a Struts or Spring MVC background.
You probably already saw this, but this "Spring-centric" integration approach is noted in the recent Web Flow 2 GA announcement at springframework.org as well as this presentation. We also have a number of users using Spring Faces on our forums - you might find some good tidbits there relating experiences out in the field.
Hope this helps! Let me know if I can answer anything specific -
Keith
Keith,
Thanks for taking the time to review the post and provide your feedback.
I guess we have concerns about Spring Faces being tied to Spring Web Flow. Shouldn't Spring Faces ideally only have a dependency on Spring MVC?
We're also concerned about Spring replacing the entire JSF lifecycle. Was what came out of the box with JSF that problematic in this regard? It just seems like a lot for a company to bite off, and for its customers to swallow, in case anything were to go awry, etc.
How about tooling? Are there any IDE plugins that would help in the building or visualization of Spring Faces applications?
While I have your attention [ :-) ], are there any plans to provide visualizations or task-based wizards for Spring MVC itself (or maybe this is already available in Spring IDE or SpringSource Tool Suite)?
Finally, what are the plans and notional time line for Spring MVC 3.0? Will Spring RichFaces move under the Spring MVC umbrella? What about Spring JavaScript?
If it would be easier just to set up a meeting to discuss these questions, just let me know when would be a convenient time for you.
Mike,
It was good talking with you on the phone.
Just to quickly iterate through your questions here for your readers:
- Spring Web Flow is a MVC extension for implementing stateful controllers in a domain-specific flow definition language. Its stateful nature fits nicely with the JSF Component model, which is also inherently stateful and at a similiar level of absraction. While it is possible to execute phases of the JSF lifecycle in a stateless environment such as a MVC @Controllers, there are limitations there--you cannot execute the postback phases, and the level of abstraction is somewhat different... MVC Controllers are a bit lower-level.
I think you'll see Web Flow's "blueprint" model and high-level of abstraction broaden over time to allow for defining an entire site structure declaratively: including, standalone, bookmarkable pages as well as controlled flows (rather than see us try to shoe horn JSF into the @Controller paradigm). We are interested in feedback in this area.
- As far as how we are integrating JSF, we are not replacing the JSF lifecycle, rather we are executing it in the context of the Spring MVC and Web Flow View processing lifecycles. This is done using standard JSF APIs implemented by the leading JSF implementations (both the RI and MyFaces). There is nothing we are doing that is non-standard. This approach lets us fully exploit MVC principles, by having Controllers that govern the selection of the JSF views for rendering. Plain JSF is very "view-centric" and can't do basic tasks like invoke an initialization callback before rendering a View--because our model is Controller centric, things like this are very easy to do. It's just standard MVC concepts at work here.
- For tools, the SpringSource Tools Suite team is working on Web Flow 2 support, as well as support for visualizing your entire site map. In addition, they are working on JSF tooling to allow for things like code-completion of model binding expressions from your views. Tooling is definitely an important area for us right now.
- Spring 3.0 will address important topics like REST, declarative validation, among others. I think you'll see the web part of the Spring Portfolio continue to stand on its own separately from the core Spring Framework distribution, as this space moves quite rapidly and we need a dedicated distribution for web application development with Spring to best meet the needs of our customers.
Hope this helps!
Keith
I definitely have to agree with matt in this. REST is the way to go in the web. To operate like a desktop application in the web will bring down many of the benefits coming from the REST architectural constraints as explained by Roy Fielding in his dissertation. I would recommend stateless interactions. We are now finishing a customer management application using struts2 (plus Spring, JPA, Hibernate) with its REST plugin and it has been a very successful approach. If you are restricted to Spring MVC and JSF I would vote for the former.
jsf is technology from the past. i hope i've never have to code with it never again.
In terms on long-term support of either framework, Spring-MVC seems to have fewer dependencies on other libraries. The + of JSF+ and coordination of add-ons, component libraries, etc.. makes JSF a bad support choice. With JSF 2.0 around the corner why bother if you know Spring-MVC will not change.
Sad you will miss out on the longer term RIA options which is where you will be in a few years anyway. Better to decouple presentation from service layer now with something like Spring.
If JSF make apps look like destop apps, and the Swing model is the best model in web developemnt that based on HTTP protocol. that sound strange, we are in request-response world, how a component can map the web architecture esp AJAX. I never see that JSF can handle multithread component, that every component can produce his own services that fetch by the browser or RIA.
I prefer to use SpringMVC rather than JSF, but that will be cool if we can standarize SpringMVC to become JSF 3.0, which we know little thinny IoC in EJB3.
and dont forget to bring Struts team also in the board.
Our IT department also recently struggled with the JSF vs. action-based frameworks (Struts 2 in our case) question. We did two applications with JSF; those two apps were outsourced to a leading JSF vendor so that we could benefit from their experience.
* Some of our pages are incredibly bloated, resulting in performance issues. I'm not talking about download times, but rather DOM manipulation and memory issues in IE 6 (our current corporate standard).
* We requested that the vendor adhere to web standards as much as possible. Unfortunately some of the popular JSF component libraries that they used seem to contain IE-specific JS code that breaks in Firefox.
* In hindsight, our JSF apps are every bit as "locked in" as our Struts apps. Sure, JSF is technically just a reference, but the reality of the situation is that there's really not that much choice between implementations, especially if you want JSF 1.2.
* The lockin is further exacerbated by the lack of progress in the JSF world. Most of the 3rd open source party component libraries are very stagnant. We feel like we're missing out on some of the cool stuff going on in the web dev world because JSF doesn't play well with anything outside of the JSF world.
While some on our architecture committee may still favor JSF, I think the momentum is shifting in favor of the action-based frameworks.
One HUGE development that has helped has been the Google Web Toolkit. GWT allows component-based UI development on top of an action-based framework. To me, it seems like JSF done right. Furthermore, unlike JSF-land, the free/open source community is incredibly active, pushing out new components, wrappers for Javascript libraries and components, etc.
At the beginning of this thread, Matt said "If you want your application to operate like a desktop application, JSF will likely work better." I would tweak that to say "If you want your app to operate like a desktop app, use Spring MVC + GWT."
Are you using Spring?
If you are already using Spring in your application (for a service layer, for example), then Spring MVC is a natural extension. That is, you configure Spring MVC very much like you configure Spring. If you have already chosen Spring, then using Spring MVC for the Web tier will lessen the amount of material your developers need to learn and reduce maintenance costs.
If you are not planning on using Spring at all, then this will not be a concern.
kyle,
Thanks for sharing your experiences with JSF and with GWT.
I guess my concerns with GWT are very similar to those with the JSF libraries that generate JavaScript: Will that JavaScript be compatible/interoperate with our current corporate standard of the Dojo framework?
Some other concerns:
* RESTful URL support
** How does GWT and/or GWT extensions support this? How difficult is it to do?
* The slow release cycle
** The last major release was back in August of 2007
** A second milestone for the latest release was made available in April, but with no indication of when it might become a formal release candidate.
* Web design standards
** Aren't we taking Web site designers out of the loop with this model? How do you enforce a common look and feel across an application or multiple applications?
** How are things like accessibility addressed?
eric,
Thanks for your comment, but I disagree that just because you're using Spring for IOC, Spring MVC is a natural fit for Web application development.
Almost all major Web frameworks (action-oriented and component-oriented) support Spring IOC integration.
But I see your point that the configuration aspects of Spring MVC can be very similar to configuring other aspects of the Spring portfolio.
Thanks,
Mike
I tend to agree with Matt, JSF is not a fit for all projects, but when it is a fit we believe Spring Faces makes the component model considerably easier to integrate, particularly for people coming from a Struts or Spring MVC background.
Please provide any feedback you might have based on your experience with either of the two frameworks.
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.
As I can see from the posts, you made discussions in 2008. So you probably came to a solution, and probably know best about the trend? From now, what would be the answer of the question Spring MVC or JSF? What about the future of these technologies?
Thanks.
Thanks for sharing the such information with us.
hello Matt i agree with you, JSF is not a fit for all projects, Spring Faces makes the component model considerably easier to integrate, particularly for people coming from a Struts or Spring MVC background.
I would definitely go with the Spring MVC.
I love it! You have more information about this blog. I really say thanks to you.
re-ask question with portlet enviroment.
@Matt Raible
yes i am agree with your thought
Tadalish SX
Generic Viagra
Sildenafil citrate
I think your article its very important and interesting,good work,.
belt conveyors
Thanks for this for this article
pleas share more articles about this
my website talking about home improvement you can visite it from this url
شركة تنظيف افران
تنظيف افران
Post a Comment