This post is intended to be a reference for those evaluating or contemplating using JSF. Once in a while, I find myself having to convince people that there are far, far, better alternatives to JSF. With this blog post finally in place, from now on I will probably just refer people here. Please pass this link on to those you feel will benefit from this fairly large selection of links and real-life experiences collected from across the interwebs. And if you have any more such links, do let me know in the comments.
My 2c:
Clearly, many architects recommend JSF as a “safe choice” for new projects just because it is a “standard”. All I’ll say is that there is more than enough evidence to prove that JSF is flawed in some significant and fundamental ways – especially compared to available alternatives.
We all know what happened to EJB 1.X / 2.X. Will JSF go the same way?
You read and decide.
[2004-03-04] JCP Releases JavaServer Faces 1.0 – JSF 1.0 approval is announced on TheServerSide, not many people sound impressed. The negative reaction (along with quotes) is summarized in this Internetnews.com article: Programmers So Far Underwhelmed by JSF. Quote from the article:
The Java Community Process (JCP) has approved a standard for building Web applications at the presentation layer, but the reaction of some programmers so far is that it adds another layer of complexity while delivering nothing they can use.
[2004-03-05] JSF: The Ultimate in Flexibility? Or Complexity? – JDJ article by Steve Benfield. Quote:
What I see in JSF is overengineering. Let’s think of every possible usage pattern for Web pages and address them, not necessarily a bad thing. The resulting standard is one in which there are several layers of abstraction, many, many moving parts, and ultimate flexibility.
[2004-06-09] Improving JSF by Dumping JSP – O’Reilly / OnJava.com article on one of the problems that has plagued JSF for a long time and many unfortunate teams (who don’t use Facelets) face even today. Keep in mind that this article is from 2004. Quote:
Don’t get me wrong: I like JSP and I like JSF. I wouldn’t have spent so much time contributing to the specifications and writing books about these technologies if I didn’t think they had value. It’s the combination of these two technologies that I don’t like, because they don’t complement each other in a natural way.
[2004-08-06] My JSF Experience – blog post by Matt Raible. Some follow up discussion here where David Geary (JSF EG member) admits that JSF is not perfect. Quote from Matt’s blog post:
Whatever you do, don’t use JSF. Not yet anyway.
[2004-09-20] Boycott JSF – blog post by Hani Suleiman (who currently happens to be a JCP Executive Committee member). Quote:
So I beg of you all, don’t use JSF, boycott it, avoid it all you can. Do not let it thrive or prosper. We don’t want it improved or tweaked, we want it to die the horrible painful death it so richly deserves.
[2005-07-??] Gradebook – Taming JSF 1.1 – an article / wiki page by Ray Davis detailing the problems faced by the Sakai project and how they had to work around some of the issues faced. The content here can be considered somewhat outdated (relates to JSF 1.1) but serves to highlight the elementary problems that JSF has had in initial versions of the spec itself. Some commentary also on other blogs here and here.
[2006-01-20] JSF Burrito: More Complete List – commentary and a list of JSF pain points by Tim Shadel. Part of a series of blog posts – read the others here, here and here. Quote:
Ultimately, JSF provides a Leaky Abstraction that (in spite of its promise) still requires all developers to understand Request-Response in addition to the 6-layer lifecycle. (”Response already committed” error, anyone?)
[2006-02-10] JavaServer Faces – why? – discussion thread at “Joel on Software”. Quote:
I’m a complete JSF newbie, and I’ve been trying to hack together a small demo app. I’ll spare you all the gory details but long story short I _hate_ JSF. Hate it, hate it, hate it. I honestly can’t imagine how anyone at Sun could ever imagine this as a competitor to ASP .NET.
[2006-02-21] Usability problems in JSF – blog post by Adam Winer. Quote:
A second category of annoyances in JSF consist of “nothing happened” problems. For example, if a validation error stops you from going on to Invoke Application, but you’ve forgotten to add an tag or something similar to your page, all that you see is – nothing.
[2006-05-03] Where JSF and Portlets went wrong… – blog post by Jevgeni Kabanov, founder of the company that makes JavaRebel JRebel. Some follow up discussion on JavaLobby here. Quote:
What’s worse, JSF have imposed on us a highly complex and clumsy API, that one needs to follow to achieve even a little reusability and broke the familiar way of capturing logic in custom JSP tags.
[2006-05-19] JavaOne: Google Web Toolkit vs. JSF – blog post by Bob Lee, creator of Google Guice. You can’t help thinking – if JSF is so great as the vendors / authors / evangelists would have you believe – why are there so many competing Java web-frameworks? Quote:
For the majority of intents and purposes, GWT invalidates JSF. Both frameworks seek to isolate web developers from HTTP, but due to the fact that Google built GWT from the ground up with AJAX in mind, GWT offers a cleaner abstraction, better type safety, and a lower learning curve. When it comes to AJAX and JSF, you’re at the mercy of which functionality your JSF components offer.
[2006-06-19] JSF Rough Spots – blog post by Don Brown compares JSF and Struts 2, talks about how JSF is more verbose and cumbersome to use.
[2006-06-20] RE: What Web Application framework should you use? – blog post by Matt Raible, and the comments are well worth reading. Quote:
JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you’ll find many complaints and issues on how things work.
[2006-09-08] JSF and RSFHistory – wiki page detailing some of the issues with JSF that led to the creation of RSF (Reasonable Server Faces). Quote:
I could go on about JSF’s other architectural deficiencies (firstly the existence of FacesContext, and secondly the global access to it which is the most utter destroyer of testability, thirdly the crazy table rendering model, fourthly the fragile and untrustable PhaseListener system, fifthly the lack of any coherent policy wrt. exceptions &c), at some length, but I will move on :P
[2006-09-13] Geebis Blog: Wicket – blog post by Caleb(?) that discusses experiences with Seam / JSF and how Wicket appears to be better. Quote:
The biggest reason is that creating custom components in JSF can be difficult, especially if you want your components to have lots of javascript/css that it contributes to the page. JSF requires that you use a writer to send your component’s HTML to the browser. With this system you end up with spaghetti code that’s hard to debug, and hard to test. Add ajax functionality to the mix and you have a featureset that JSF just can’t handle in the current version.
[2006-09-16] Tinman and the Scarecrow – blog post by Dhanji Prasanna, Google Wave Core Engineer and creator of the Google Sitebricks web-framework. Quote:
It is no secret that JSF is made for tool vendors. However, it is somewhat possible to get away with working with JSF by hand only (in fact Ive done a fairly large project this way), though this is neither on par with using tools nor easy as many proponents claim. Principally, it is not fun and doesnt offer as much reward to a developer for effort spent hitting keys.
[2006-10-19] MyFaces: The emperor has no clothes – a detailed blog post by Ignacio Coloma. Of all the many rants against JSF out there, I would pick this as my favorite. It deals with the author’s experiences with JSF on a real-life project and goes into the technical details of various issues. A must read. It looks like Ignacio Coloma was so disgusted with JSF that he later decided to create a new Java web-framework called Loom. Quote:
I do not have enough space here to explain the hell that developing a custom component is, so will leave a short summary: you will be fine if you are doing a simple stupid component that is shown as a single textfield, and there are big, red, horny demons in your way if you try anything more sophisticated.
[2006-12-15] Nightmares on JSF Street in Trinidad – blog post by Rainer Eschen. Quote:
If you keep in mind that Sun started in 2003 to talk about the JSF specification in the public, we hear and talk about JSF for three years now. If I have a look at the results, I’m a bit disappointed. This is comparable to the Swing development and the missing practical GUI designers (for years).
[2006-12-19] Reasons to choose Wicket over JSF and Spring MVC – InfoQ article on experiences evaluating web-frameworks. Quote:
I liked [JSF's] form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it.
[2006-12-26] not enamored by JSF 1.1 – great rant by Timothy Stone on the JavaRanch forums. The whole thread is worth reading. Quote:
The RI of JSF v1.1 hijacks and pollutes the id attribute of HTML for its own use, thus rendering CSS stylesheets almost useless and making work with the DOM in Javascript a PITA. This is probably the single greatest problem I’m staring down the barrel at.
[2007-01-01] JSF in 2007 – O’Reilly.net / ONJava article by Shashank Tiwari. This promptly triggered a lively debate on TheServerSide here.
[2007-01-18] Tech Talk: Ed Burns on JSF 1.2 yet another discussion of JSF issues ensues on TheServerSide.
[2007-02-19] JSF is cool but it is too young and it has too many bugs! – yet another forum thread on JavaLobby. Quote:
I’m very tired, I spend the double of the time to develop this because of the problems I had to check out on the net, maybe I will wait for JSF to become better and for now use other technologies.
[2007-02-28] JSF Anti-Patterns and Pitfalls – article on The Server Side and discussion here. The article opens with these words:
This article covers anti-patterns and pitfalls of day to day JSF development. Most of these issues have kept the author up at night; some of these are the same old challenges with a new face, pun intended. These challenges include performance, tight coupling, thread safety, security, interoperability and just plain ugliness.
[2007-03-17] JSF – Still pretty much a steaming pile of donkey turd – another classic rant by Wille Faler. Wille has since embraced Wicket and went on to initiate the Wicket RAD project. Quote:
The end impression is that it is a horribly convoluted, over-engineered framework that goes to great lengths to replace existing, well functioning technologies without addressing any of the pain-points at all.
[2007-04-16] JSF still sucks? – by Matt Raible, creator of AppFuse and someone well respected in the Java community especially for his web-framework comparisons. Quote:
Conclusion: don’t use JSF simply because it’s a “standard”. Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.
[2007-04-26] Creating a jsf div component – blog post by Andrej Koelewijn. The amount of code and effort that is required for just creating an HTML DIV is to be seen to be believed. Discussion on TheServerSide here.
[2007-05-14] A Wicket user tries JSF – a side by side comparison of JSF (MyFaces) with Wicket by Peter Thomas. Lots of discussion in the comments. Quote:
JSF is supposed to be a component oriented framework but I wouldn’t call them Java components and definitely not Object Oriented.
[2007-05-22] Rethinking JSF – The Real Problem – after a flurry of JSF-bashing blog posts appearing in early 2007, Joseph Ottinger (then editor of TSS) attempts to do some damage control. But the ensuing discussion thread is a good read with some gems in it like this one comment by Leo Lipelis that does a great job of listing and explaining a bunch of JSF issues. More discussion can be found here on the Artima forums. Quote (Leo Lipelis):
JSF multi-rendering capability — it’s an API bloat the weight of which you feel when designing custom components. Whether a project will benefit from multi-rendering or not is questionable. Why should I pay the price in terms of conceptual complexity of an API when I may not even need to use it in 99.9% of the use cases?
[2007-05-23] Six Things JSF Breaks (and How To Fix Them) – blog post by Josh Justice, title is self explanatory. Quote:
This is certainly no small list of challenges! JSF was built in a time when fewer client-side technologies were available, but it also seems to be targeted to projects that require less client-side interaction. If you are developing the next great web 2.0 application, you may want to consider a framework that intrudes less into the markup of the page, such as Struts or Spring.
[2007-05-25] JSF and real stuff – yet another laundry list of JSF problems outlined in this JavaLobby thread.
[2007-05-28] anti-JSF thoughts – blog post by Mert Can Akkan.
[2007-06-05] Re: Rod Johnson: “Java EE 6 Gets it Right” – in response to a comment I made on a TSS thread, Rod Johnson says this:
I still haven’t made up my mind about JSF, but we have people in our community who want to use Spring (and Spring Web Flow) and JSF, and it’s important that we accommodate that.
To put that quote in context, note that three years prior, Rod Johnson and Juergen Hoeller (Spring Framework #1 and #2) had this to say about JSF on page 408 of the book “Expert One-on-One J2EE Development without EJB” [2004, Wiley]:
Java Server Faces has been hyped as the next big thing in J2EE web development for more than two years and is now taking shape. In its current incarnation, JSF is a JSP centric affair that is heavily targeted toward GUI builder tools, resulting in code that gathers all sorts of concerns in the web page. There is no notion of view-agnostic controller and model, and no concept of pluggable views. With this programming model, JSF is well-suited for attracting .NET and other RAD developers, but not for becoming the de-facto standard web MVC framework in the Java world.
We expect to see a massive vendor marketing push behind JSF. However, we are not convinced that JSF will represent a real advance on existing open source solutions such as Tapestry, WebWork, and Spring web MVC.
[2007-06-07] c:forEach vs ui:repeat in Facelets – blog post by Roger Keays. Facelets is supposed to rescue JSF from JSP but it is not without its share of quirks !
[2007-06-11] the death of reason, professional addition – yet another blog post that suggests JSF is guilty of driving a fair number of developers away from Java. Quote:
i’ve been in a JSF class this week that has only reinforced my opinion that java web development sucks. it’s an over-engineered amalgam of crud. what i’m noticing, too, is that JSF is way behind the curve on annotations-is-the-new-xml java craze. this class has more than doubled my appreciation of ASP.NET.
[2007-06-27] Prefer RIFE,Stripes,Wicket to JSF – blog post by Frederic Daoud. Quote:
I recently worked on a professional project with JSF and ran into several problems. Don’t think I didn’t try “extras”: Facelets, Seam, … In the end it just piles on complexity without solving the problems, or solving them but introducing new ones.
[2007-09-07] Re: Java’s Fear of Commitment – O’Reilly / OnJava.com article by Robert Cooper. Quote:
I think JSF blows chunks.
I think Seam blows chunks squared.
While I can appreciate the design ideals of component based development on the web, each of these technologies, and especially stacked, represent an abstraction above and beyond what HTTP really is that makes me sick to my stomach to think about.
[2007-10-25] JSF Today: Standards versus OSS – blog post by Bruno Borges. Quote:
JSF 1.2 (JSR 252) is targeted for JavaEE 5.0. And I don’t even see JEE 4 in every customer I go, just like JSE 5, so try to imagine when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including Wicket, are improving faster than JSF since that time.
[2007-10-27] JSF First Impressions – blog post by Keith. Quote:
[...] with JSF — you’re farther away from the final HTML. Its the components you include on the page that generate DIV tags and so forth. Having accrued 10+ years experience working with HTML, I find this the most frustrating aspect of JSF.
[2007-10-30] Xebia Web Framework Contest – a contest where different teams had to develop the same application using different Java web-frameworks. The team using JSF really suffered. Some follow up discussion here on Matt Raible’s blog. Quote: (‘Google translated’ from French):
JSF is clearly not the most productive framework, at least not on a day because the entry cost is heavy. And even once used to the framework, one may wonder how to be productive without error recovery and ask what limits the buffer management in the framework of a real project?
[2007-11-22] I’m a nerd. Or do I mean geek? [...] – blog post by Noah Sloan. Quote:
The problem with all that is that the JSF Ajax implementations suck. And the learning curve for JSF (much less components) sucks. It’s just too quirky. Hopefully JSF 2.0 will make component creation easy, enable RESTful services, and will make it easier for newbies and old hands to just get things done. I’d like to hope all of that, but the only positive things I tend to hear about 2.0 are from Ed Burns, who seems like a very nice guy, but whose rhetoric reeks of corporate “gotta toe the line/I think my company is the best ever [...]“
[2007-12-26] JSF 2.0 Faces Disjointed Components – SD Times article on how the “next version of JavaServer Faces aims to reduce configuration headaches”. Quote:
Sometimes, the cure for one’s woes is a hard look in the mirror. JavaServer Faces is facing up to its own configuration problems with JSR 314, the specification for JSF 2.0
[2008-01-04] Nobody Uses JavaServer Faces – blog post by Matt Long. Quote:
The bottom line is I’ve done a lot of web applications in my career, and I would *never in a million years* choose JSF to build a web app. It’s nearly unusable. Don’t get me wrong. I am getting the project done, but that’s a testimony to my own development skills, not how great the technology is. JSF stinks.
[2008-01-11] A Year of Wicket – blog post by Julian Sinai who evaluated web technologies and chose Wicket over JSF and other contenders like Tapestry. Quote:
I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.
[2008-01-28] Choosing a Java Web Framework – blog post by Ryan Sonnek. Quote:
Considerable ramp up time and tool support is a requirement to be productive. Instead of just working with standard Java and HTML, you end up locking into a particular toolset. The tools get you up and running very quickly, but you pay for the convenience since you can only build what the tool supports and they restrict how much you can do with the internal framework.
[2008-03-02] [OT] JSF vs. WebObjects – thread on Apple mailing lists. Quote:
As a final word i’d say that I won’t choose JSF for new project, i’d rather choose other frameworks like wicket or tapestry which are far more mature.
[2008-04-01] Thoughts on Java web frameworks and RIA – blog post by Sanjiv Jivan, creator of GWT-Ext and SmartGWT. Quote:
I’ve said this before that I feel that JSF is an incarnation of EJB 1.x which is overengineered and too focused on “enterprise patterns” making the simple things not so simple to implement.
[2008-04-10] JSF: A Wish List – Java Developer Journal article by Shay Shmeltzer. Quote:
Since the JSF specification doesn’t include a definition of how AJAX should be incorporated into the JSF lifecycle, each vendor/framework has its own approach to handling AJAX events, usually involving extending the JSF lifecycle. The result is that developers end up with one set of components that collides with the architecture of another set because they have different lifecycles. This must be addressed in the next release of JSF.
[2008-04-28] JSF2 – wiki page maintained at the Seam web-site on all the stuff in JSF 1.X that needs fixing in 2.0. It is painfully clear from this list how much of a raw deal JSF 1.X is. And *another* page of things to be fixed in JSF2.1 exists! Look for it somewhere below.
[2008-05-03] Game Over Java Server Faces – this was a great rant that suddenly does not seem to exist on the web anymore – so I’ve linked to the DZone entry for now. If anyone knows where this blog post can be found now – do let me know!
[2008-05-14] Developing long term strategies for using Java EE technology – a very telling quote from this IBM DeveloperWorks article goes like this:
JSF is still a relatively new technology. JSF is undergoing a major revision for the next round of specifications with an expected integration between JSF managed beans and Enterprise JavaBeans™. The risk of changes affecting existing applications will be higher here than with other presentation technologies. IBM does have representation on the JSF expert group and will keep a watchful eye out for problems.
One area of future concern is be how well Ajax support in JSF will follow the specifications for the OpenAjax Alliance. Through its participation, IBM will try to ensure that compatibility is maintained as the standards move forward. Ajax support in JSF will be new (when it appears) and use of that feature will be at a somewhat higher risk than other parts of JSF. More details will be known in early 2009.
[2008-05-14] JSF Issues – blog post by Phill. Quote:
Although JSF does make some development quicker, the amount of time you lose to stupid problems like this probably negates any gains you made originally.
[2008-05-29] At RailsConf 2008 [new] – I think the commenter that submitted this link (Ignacio Coloma) says it best:
I love the part where Craig McClanahan pulls JSF out of a hat, throws it to the crowd, then moves on to develop Rails applications.
[2008-06-06] Has anyone noticed? JSF components are hard even when they are easy… – blog post by Jesse Sightler. Quote:
Ever since I’ve had the experience of using ASP.Net and comparing it to JSF, I’ve been hoping that someone would come up with a way to improve the sorry state of affairs that is JSF component creation. Far too much time is spent on complex components and supporting a billion renderkits, when most of the time, I just want to be able to composite a couple of preexisting controls.
[2008-07-10] Seam, a second look at JSF – blog post by Petrik de Heus. Quote:
I actually forgot how much JSF sucked (I remember it was hard to test). The biggest problem is that it’s been developed by someone who doesn’t use it to write real applications. It’s full of crappy implementations of concepts that seem like a good idea from an ivory tower.
[2008-07-11] Java Frameworks – JSF vs Wicket, etc – discussion on Ars Technica forums. Quote:
No, you aren’t missing anything. JSF sucks huge monkey balls. The worst part is the convoluted, and heavy-weight response life-cycle. When it works, everything is wonderful and magic. When it doesn’t work, good luck figuring out why.
[2008-07-25] Wonderful Wicket – blog post by Sergey Grigoriev. Quote:
After I had read a book on JSF, I had impression that JSF is overcomplicated technology. Nevertheless I downloaded the latest release of ICEFaces and tried to write a simple “hello world” application with a singe button and a message area. I’ve spent two hours configuring it and six hours figuring out how to eliminate an exception.
[2008-08-25] JSF: The Good, the Bad, and Yes, the Ugly – article by Rob Williams. Quote:
In the most recent JSF tour, we were doing a wizard and had to bind to checkboxes. That turned into a nightmare, and for all the typical JSF reasons. JSF gets a low grade for heuristics (intuition is rarely the road to figuring things out).
[2008-08-31] A rant on Java standards – blog post by Jose Noheda. Quote:
How can something like JSF be promoted to be the standard? A component framework that lacks even one interesting component! That relies on third party libraries (many OSS) that are, of course, incompatible between them. Each one with a different AJAX approach (as the specification says nothing on the topic). And, worst of all, incompatible with JSP/JSTL and portlet development.
[2008-09-22] Fundamental Failing of JSF, Some Ideas for Overcoming – blog post by Rob Williams.
[2008-09-25] More Suggestions for Suturing JSF Breach – blog post by Rob Williams.
[2008-10-04] Web Framework Project Comparison Matrix – quote:
Users say, JSF “is the EJB of web frameworks. Cool in theory. Hell in practice.”
[2008-10-26] JSF is Not Fixable – blog post by Subbu Allamaraju, author of “RESTful Web Services Cookbook“.
I have not read the latest JSF 2.0 draft thoroughly, but upon a quick reading of all the changes, I don’t see anything to address the basic web usage. Unless there are more changes coming that will magically fix the core without an overhaul, JSF should the follow JAX-RPC into the JSR-graveyard.
[2008-11-03] “Simple” JSF 2.0 Component vs. Tapestry – article by Howard Lewis Ship. Yes, even in the not-yet-final JSF 2.0 custom component creation leaves much to be desired. Hope this answers JSF apologists who would complain about the above list of links claiming that it is outdated and that JSF 2.0 fixes everything etc.
[2008-12-18] JSF with a Web Designer
We’ve done only the first page of our application, and I’m really wondering if we took the right library. I believe now that in case you have a web designer in your team, you shouldn’t use libraries that generate HTML for you, like JSF or gwt, but instead use a framework allowing to generate the precise HTML the designer wants
[2009-01-14] Seam / JSF vs Wicket: performance comparison – performance and memory usage comparison of Seam / JSF vs Wicket by Peter Thomas. Quote:
I think we can safely blame JSF for the lion’s share of memory usage [...]
[2009-02-09] The Web Framework Evaluation – Part 03 – article by Sebastian Hennebrueder. Quote:
Do you understand the JSF request phases? On a first look they look simple but in fact it is a nightmare of things happening and being dependent on each other. It is not at all easily to hook in and change the behavior.
You like JSF and you are not convinced? Then try to write a library which caches a part of your component tree to render the page faster and make sure that it works with GET and PUT requests. You will have fun, believe me.
[2009-02-15] Un-Documented JSF: Reference – community contributed list of JSF “gotchas”.
[2009-02-25] JSF 2.1 – similar to the “JSF 2″ page mentioned earlier, another page on the Seam wiki details stuff that needs to be fixed in JSF 2.1 – perhaps these are things that did not make it into 2.0 ?
[2009-04-29] Shale in the Attic – the project that Craig McClanahan (spec lead of JSF 1) started as a supplement to JSF goes “where other projects go to die”. Also see the link dated 2008-05-29 for more background. Quote:
What happened? The answer is quite simple: Craig lost interest and left the community.
[2009-05-01] JSF: Suggestion for Performance Improvement – blog post by Nicholas Hagen expressing concerns with performance implications of JSF state saving.
[2009-05-11] JSF Nonsenses – Matthias Hryniszak starts an entire blog at http://ihatejsf.com dedicated to documenting his struggles with JSF. In his first post, he says:
Welcome to this new place in virtual space where you can express your darkest feelings about the sole nature of JSF (Java Server Faces) and other technologies that are connected to it (Facelets, JSF libraries and the like).
This blog has arose from the need to express my personal dislike for that glorious set of utilities that have made my life a misery.
[2009-05-12] JSF 2 fu, Part 1: Streamline Web application development – IBM developerworks article on the spanking new JSF 2.0. In the beginning of the article, David Geary (JSF EG member) admits that JSF 1.0 wasn’t that great. It is worth mentioning that JSF 2.0 is still not yet approved at the time of this blog post! Quote:
JSF 1 was developed in an ivory tower, and the results, arguably, were less than spectacular.
[2009-05-15] JSF Sucks (Compendium of JSF rants/reviews) – link to this blog post on DZone where there is some active discussion and also do consider voting up this link! The number and ratio of upvotes speaks for itself.
[2009-05-15] Reasons why not use JSF – someone posted a link to this blog post on the Seam forums, some discussion there. Look out for the comments from Francisco Peredo, for example this one.
[2009-05-16] “JSF sucks” on Reddit – wow, that brought a lot of traffic! Some good discussion there as well.
Update:
[2009-11-10] JSF 2 – evaluation and test – very detailed evaluation of the brand new JSF 2.0 reference implementation (Mojarra) by Sebastian Hennebrueder and Holger Brade. Sebastian’s conclusion:
JSF looks like an old castle, where every generation added pieces, towers and buildings. I don’t blame the developers for this, as the code shows, that they know how to do a proper job. I believe that the reason for the current status of JSF is that the features are defined by a specification. The specification is industry driven with a focus on being backward compatible instead of being technology driven. Everything works somehow but always rather complex than simple. Every release makes it worse as nothing is dropped. I am sorry, but I can only see a bad ending for such a strategy.
Pages are extremely verbose. Using it make you feel being unproductive most of the time. JSF 2 brings some innovation but in a lot of areas it doesn’t even catch up with the current status of other frameworks. It is likely to be outdated before it is actually stable.
I wouldn’t use it for new projects and especially not for large enterprise projects.
[...] Go here to see the original: JSF sucks [...]
Pingback by Valuable Internet Information » JSF sucks — May 15, 2009 @ 1:48 am
ok i understood that jsf sucks … but what are the choice then? .. i mean im new with java web … if i dont use jsf what then?
Comment by Akna — May 15, 2009 @ 1:09 pm
My personal favorites are wicket or struts 2
Comment by Mario Klaver — May 15, 2009 @ 1:21 pm
Very few critics about JSF a valid critics. Many of them are related to outdated information, and another part of them doesn’t consider its third party library.
If it’s true that JSF is weak in some point (for example bookmarking), it’s also true that every weakness has already been solved by some third party library.
I don’t agree also with who try to minimize the important of a being a standard. Let’s stay pragmatic. Thanks to being a standard, JSF has a great ecosystem: many IDE support JSF, very important frameworks and libraries are integrating and extending JSF, lots of developer support (forum, mailing list, documentation) is available around there.
Comment by Alberto Gori — May 15, 2009 @ 1:32 pm
Alberto,
You say. “JSF is weak in some point (for example bookmarking)” .
The problem is that JSF is not really RESTful. If it would be RESTFul bookmarks would be no problem. Not being RESTful JSF ignores the fundamental architectural style of the web.
This is not something that can be fixed by just patching it here and there. It’s a fundamental problem.
Caching for example will never work as well as with more RESTful approaches.
Comment by Markus Kohler — May 15, 2009 @ 2:23 pm
As Markus pointed out, the lack of RESTfulness is a big issue.
But for me the biggest issue is just leaky abstractions – if you don’t know the internal workings of the JSF lifecycle intimately, your screwed.
Then again, that is just one of a long list of complaints about JSF..
Also, if you need n third party libraries to make it usable, it’s not that great, is it?
There’s a saying for that sort of phenomena: “if you polish a turd, it’s still just a turd”.
Comment by Wille — May 15, 2009 @ 3:22 pm
I love the part where Craig McClanahan pulls JSF out of a hat, throws it to the crowd, then moves on to develop Rails applications.
http://blogs.sun.com/craigmcc/entry/at_railsconf_2008
I mean, I thought the idea was that ’stateful web’ was such a superior approach.
Comment by Ignacio Coloma — May 15, 2009 @ 5:05 pm
For query, I like Spring + Dreamsource ORM(http://code.google.com/p/dreamsource-orm/) + displayTag(http://displaytag.sourceforge.net/1.2/)
For very complex form, I like Spring + Dreamsource ORM + GWT.
Jim
Comment by Jim — May 15, 2009 @ 5:32 pm
Wicket or GWT. Both known to cater to Java programmers by favoring statically typed code over markup.
Comment by Casper — May 15, 2009 @ 5:35 pm
I agree with Wille. Everything in JSF is done with overloaded POSTs and RPC. And it’s impossible to write neat/clean code in request scope without resorting to a myriad of hacks, most of which revolving around the life-cycle. And then there’s the week, frale yet complex component model.
Comment by Casper — May 15, 2009 @ 5:41 pm
I don’t like JSP custom tags, either.
I find SGML-based notations eye-numbingly ugly (that’s why there are WYSWYG editors for HTML. I don’t want _any_ logic — not even display logic — embedded into an HTML file. Nor do I want my application code to explicitly manipulate HTML strings — I think the framework ought to handle that. I believe a good framework shouldn’t require a developer to use HTML/CSS as anything other than a layout manager or pretty-printer. I believe building a custom component should be no harder than creating a frame subclass in Swing.
For these reasons, I agree with Casper’s response. If you want your display logic to execute on the server, use Wicket. If you want a fat-client application that executes over existing browser APIs (without special plug-ins such as WebStart), then use GWT.
Wicket and GWT give Java significant advantages over every other web technology. If we want Java to own the web (and not lose it to, say, PHP, Ruby on Rails, or ASP.NET), then we have to embrace the superior Java frameworks and not keep trying to patch or wrestle with kludges.
Comment by Frank Silbermann — May 15, 2009 @ 7:58 pm
I don’t think it’s true. JSF allows bookmarking, and has support for GET requests, but its “native” support is not handy.
We could say it has a second class support for bookmarking.
Anyway it’s not too difficult to write a phase listener, or import a third party library (Seam, RestFaces, PrettyFaces, …) to turn JSF in an action framework.
Comment by Alberto Gori — May 15, 2009 @ 11:11 pm
I don’t think you can use Wicket without knowing it very well.
And JSF has a lot of abstraction. All you need to know are its main phases. The most important ones are validation phase, application phase, and render response phase.
You can bind component value to application model very easily thanks to Expression Language.
You can invoke actions simply coding things like #{bean.method}.
Comment by Alberto Gori — May 15, 2009 @ 11:14 pm
Here is another:
http://www.jroller.com/javelotinfo/entry/prefer_rife_stripes_wicket_to
Comment by Frederic Daoud — May 15, 2009 @ 11:20 pm
The comment about JSF not being great because it ‘needs’ a third party library is completely missing the point.
Unlike many others web frameworks, JSF was specificaly designed to allow such extensions. Enabling a rich component Eco system is pretty the whole point of jsf. Thinking that JSF somehow sucks since e.g. Rich faces or ice faces makes it really shine is utterly rediculous. JSF is more of a fundamental meta framework than a closed do-it-all out of the box kind of thing.
The same goes for things like facelets or seam. JSF isn’t ‘fixed’ by those things, JSF was explicitly designed to make something like facelets possible. There are zero dependencies on jsp. Adding a new view description technology is relatively easy, and thus it’s also easy to build a jsf view using plain java. Much of the complexity in developing custom components are for making them usuable in jsp. Drop jsp and creating a plain uicomponent is suddenly pretty easy.
Comment by Peter — May 16, 2009 @ 1:45 am
>Of all the many rants against JSF out there, I would pick this as my favorite. [...]
>A must read. It looks like Ignacio Coloma was so disgusted with JSF that he later decided to create a new Java web-framework called Loom.
Yippie! Yet another web framework. If JSF is so bad and Loom is supposedly so great then (after all the author of Loom surely wouldn’t be so dumb as to repeat JSF’s mistakes), then why on earth isn’t Loom the most popular well known framework out there?
If I search for a book about Loom on say Amazon, it gives me this: http://www.amazon.com/Loom-Knitting-Primer-Beginners-Projects/dp/0312366612/ref=sr_1_1?ie=UTF8&s=home-garden&qid=1242424528&sr=8-1
Makes me wonder how great this Loom thing really is…
Comment by henk — May 16, 2009 @ 2:56 am
>We all know what happened to EJB 1.X / 2.X.
Well, EJB 1.x / 2.x evolved into EJB3, one of the most powerful and easy to use frameworks out there for implementing your business code. Adding transactions to your code is so easy with EJB3 that there’s almost no challenge to it anymore (and rightfully so, writing transactional code should no be ‘challenging’).
> Will JSF go the same way?
I think it will. But it’s also different this time. I agree with the suggestion that JSF 1.x will evolve into something extremely powerful but still easy to use, just like EJB did. However, the difference is that EJB 2.x was fundamentally wrong in some aspects. CMP was flawed at the core, and while stateless session beans by themselves where a good idea, their implementation requirements where over the top. With JSF its just that the current spec is rather limited. At the core JSF is a pretty good meta framework, as someone else pointed out. It’s like a very decent OS kernel that people think they can run as an actual operating system. This is just not the case. JSF 2 will add a lot of ‘userland’ luxuries, but the fundamental core needs far less tweaking since its already quite solidly designed.
Comment by henk — May 16, 2009 @ 3:08 am
>But for me the biggest issue is just leaky abstractions – if you don’t know the internal workings of the JSF lifecycle intimately, your screwed.
To me the JSF lifecycle works pretty decently. It mostly emphasis things you should be doing anyway. One of the first things it does (on a postback) is collect all request values. These values are then converted and validated. After that they are stored in your Java bean and then your application logic is called. After that has happened the rendering is being done.
Seriously, isn’t that exactly what should always happen?
I really hate code that starts getting some request values, then it calls some business logic. In the middle of the business logic some more values are fetched from the request object (which is thus passed on to the business code). Subsequently the code is doing some validation, but because the developer obviously lost track of which values in the code originated from the user and which ones originated from the trusted business code, he or she plainly forgets to validate them all, or the other way around the developer just validates each and every variable in sight, even when it comes from internal trusted layers that have already performed validation (and thus wasting resources, plus making the code even more unreadable).
After all this has happened the code does some rendering, and then some other business code is called, repeating in large lines the steps outlined above. Only this time, the business code fails for some reason or the other. Unfortunately, rendering has already started and data has been sent to the client already. What to do?
All in all I call this pure madness. I’ve seen this happening so often. Debugging or maintaining such code is an absolute nightmare. Nothing less…
Even before JSF I mandated my team members to do exactly what JSF does naturally. Unfortunately, since I had to mandate it, I had to explain this to (junior) programmers time and time again. Worse yet, with ‘just’ being a mandate it’s easy to slip stuff through the cracks. It is simply undesirable and plain impossible to check each and every line of code committed by programmers.
With JSF one is mostly relieved of this burden. The natural way of doing things in JSF is exactly the right way. ALL parameters should be fetched from the request before one even thinks about validating. And ALL those parameters should be validated and converted to their right types before one even thinks of calling any business logic. This is absolutely the 101 of common sense in web programming. The JSF lifecyle does exactly this. I really can’t understand people who thinks that’s bad…
Sure, JSF gives you the power to do it differently. The framework offers many handles to override or supplement (i.e. by using decorators or chain of command) standard behavior. The entire lifecyle itself is a pluggable thing, facelisteners allow you to do cross-cutting or specialized stuff before or after every phase of the lifecycle, viewhandlers allow you to build your component tree in your own specialized way, or through the decorator pattern add some behavior to the default way of building a component tree. The statesave mechanism can be decorated or replaced too. In the overwhelming majority of the cases you wouldn’t need to do that, but if you really know what you’re doing, the power is there. The defaults however are perfectly sensible (as explained above) and teach especially new developers the right way of doing things.
Comment by henk — May 16, 2009 @ 3:32 am
I don’t consider it a “pretty good meta-framework” so long as creation of custom components remains laborious.
Comment by Frank Silbermann — May 16, 2009 @ 4:25 am
Wrong post!
Comment by Hazem Ahmed Saleh — May 16, 2009 @ 8:11 am
Ha, ha, that’s one of the best attempts at spin I’ve seen :)
What you mean to say is that people using EJB 1.x / 2.X were completely screwed and they had to re-learn Java EE and they were faced with the prospect of re-writing large enterprise applications to use EJB 3.0 instead.
All those years project teams spent struggling with entity-bean issues and whatnot ended up being waste. Doesn’t even look good on your CV ;)
Of course most people started using Spring and Hibernate instead but that’s another story.
Comment by Peter Thomas — May 16, 2009 @ 9:18 am
@henk – in your last (overly long) comment you keep talking about JSF, JSF. Shouldn’t you be talking about a particular implementation (e.g. MyFaces, ICEFaces)?
The flexibility of JSF and pluggability of life-cycle phases that you tout as a great advantage of JSF actually means that when you choose an implementation, you get locked-in to all the proprietary stuff in that implementation, tags and all.
That is not necessarily a bad thing, but I wish more people choosing JSF would realize the vendor lock-in implications of JSF. I see many architects mistakenly assume that since JSF is a Java EE standard, it guarantees that you can say switch from ICEFaces to RichFaces whenever you want. That is so *not* true !!
Comment by Peter Thomas — May 16, 2009 @ 9:46 am
@Peter Thomas: completely false. JSF lifecycle and other stuff can be overwritten or decorated in a standard and portable way.
Comment by Alberto Gori — May 16, 2009 @ 1:11 pm
@Alberto – Ha. If I decide to use say ICEFaces for an enterprise application, can I port it to RichFaces without much effort ? Do let me know.
I recently worked on a project using Seam, ICEFaces and Facelets. Something I found interesting is when implementing forms I had the choice of so many tags and it was hell to figure out the *right* one to use. For example:
Facelets <ui:repeat>
JSTL <c:forEach>
JSF <h:form>
ICEFaces <ice:selectOneMenu>
JSF <f:selectitems>
Seam <s:button>
That’s right, SIX different namespaces. WTF !
Comment by Peter Thomas — May 16, 2009 @ 1:33 pm
@Peter Thomas
> you keep talking about JSF, JSF. Shouldn’t you be talking about a particular implementation (e.g. MyFaces, ICEFaces)?
This more or less shows me you really haven’t read enough about JSF to make much valid comments.
For starters, there are only two JSF implementations: Apache MyFaces and Sun Mojarra. These two implement the JSF spec (JSR 252).
ICEFaces, RichFaces, ADF, TomaHawk are mostly component libraries: they basically ship a set of components that you can use with JSF. There are many of such component libraries and the fact that there are so many means JSF has a thriving eco system. If nobody would have ever developed a single third party component library, THEN JSF would have failed miserably.
Seam and Facelets and partly even Spring are examples of extensions to JSF. They take advantage of the extension points offered by JSF. There are many such extensions, and this proved the extension thing was a Good Thing; people are actually using it. Seam and Facelets are very visible and popular public extensions, but I’ve also seen a number of small gems being developed in-house for very specific little situations.
Saying that JSF would somehow be bad because component libraries exists, would be saying that Java is somehow bad since third party libraries (jars) exists. This is an awkward proposition.
Saying that we would somehow have to talk about the third library lib we use instead of the version of Java that we use in similarly awkward. My project for instance uses some of the Apache commons classes. Am I now no longer allowed according to your logic to say that I’m using Java 6?
Comment by henk — May 16, 2009 @ 2:15 pm
>Ha, ha, that’s one of the best attempts at spin I’ve seen :)
Hehehe, well you have to give it to me, it’s the literal conclusion to your statement. EJB2 afterall -did- involve into EJB3, it’s hard to deny that ;)
Comment by henk — May 16, 2009 @ 2:19 pm
@henk – heh, if you want to argue the semantics of “implementation” vs “component library” fine. When it comes to real-life projects, the architect or decision maker who grandly chooses JSF will declare that “thou shalt use ICEFaces!!” as part of the architecture document or something.
I never said that component libraries are a bad thing. All I’m saying is:
- JSF is a half-baked spec that needs extensions to make it *usable*
- because of this when you use JSF in a real-life project, you get locked-in to whatever vendor you choose
- most architecture astronauts who decide to use JSF for a new project are blissfully unaware of the above 2 points
Comment by Peter Thomas — May 16, 2009 @ 2:31 pm
I actually said “attempt” at spin.
But you want it so much, I’ll give it to ya. I present you with the “spin of the year” award ! :P
Comment by Peter Thomas — May 16, 2009 @ 2:49 pm
@frank
Component creation may be laborious, but that’s really only the case when you want them to work with JSP. Nothing in JSF forces you to use JSP, ever.
Secondly, it may be laborious, but it’s never difficult. Having to maintain a tld entry and a taglib wrapper for the component is tedious but not difficult.
Thirdly, look at how many component libraries there are. For a lot of programmers it’s obviously not such a big deal. Especially since many projects provide tools or scripts to take the bulk of tedious work away.
Finally, JSF 2 massively improves on this. Your voice has been heard and a solution is already being worked on :-)
Comment by Peter — May 16, 2009 @ 3:56 pm
@peter Thomas
About the extensions:
Is the Linux kernel half baked since it needs a userland and xserver to run a normal application?
Is Eclipse rcp half baked since it needs JDT and a whole slew of other goodies to function as a Java IDE?
JSF was not designed to be an end solution but rather as a starting point. For a part of the Java core library I think that’s a valid approach.
Comment by Peter — May 16, 2009 @ 4:10 pm
Wonderful. That qualifies as “half-baked” in my book :)
Comment by Peter Thomas — May 16, 2009 @ 4:15 pm
Wow, please don’t ever stop evangelizing JSF. Okay?
Comment by Peter Thomas — May 16, 2009 @ 4:24 pm
Heh. Matt Raible tweeted this as a Quote Of The Day:
http://twitter.com/mraible/status/1806597552
I added this to the post. Thanks !
Comment by Peter Thomas — May 16, 2009 @ 4:45 pm
@ Peter Thomas
About the evangelizing, it’s just that you often hear that it’s supposedly difficult to create custom components. I just wanted to qualify that. The difficulty is not the kind of difficulty that one has to deal with when writing eg a mathematical proof or so. The difficulty is only in the fact that for jsp you have to do some borring repetative work. Eveyone can do it. It’s not difficult in the sense that you need expert ninja coding skills.
A pure jsf component without wrapper tags which does it’s own rendering is no more work then implementing a swing widget
Comment by Peter — May 16, 2009 @ 5:58 pm
Okay, theoretically you are right. Jsf is half baked in the sense of being a half product. Without context however the term has a somewhat negative tone. For software it’s also more common to use the term foundational instead of half product.
Comment by Peter — May 16, 2009 @ 6:06 pm
I agree with the “lock-in” aspect.
The project where I actuzally work is using Spring-faces and now we are locked in that bad implementation of javascript validation.
The validation in JSF is as powerfull as impossible to use. Everytime one need to create a validator, one need three place to put it?
When you want to create a validator that use several fields, you must put the name of the fields in the validator. Great idea…
EVen with Facelets : you do not create independant components just like in Wiket – where the internal behavior is inside the component (and can be extended, by overriding the methods). You need to define the actions outside of the component (in the navigation – we use Spring web flow). And then you duplicate the internal behavior of the component.
The layout of the page is awfull. I am fed up to have so much to write just in order to have … blocks. You know. Divs.
I very like the way Ajax is integrated with a4j (reRender, for instance). Same as in Wicket but in Wicket the logic – where reRender is defined in the Logic of the Component, in the java class, not in some xml.
I am sick with xml development : you can not debug. Where is “Message” when validation is not going right? No stacktrace, no nothing… Half of the problem occurs when an action is not called – because of some “validation” issue. In fact, it was not validation, but Convertion of the value. Whaou…
I don’t say all these problems are impossible to solve, I don’t say jsf is “stupid”, I just say it is too complex. You need to know everything to do something. I just say : why do we have to live with all the problems? Isn’t a framework supposed to make difficult things possible, and easy things easier? With JSF, difficult things stay difficult and easy things become complex. It gives me work. Great…
Sorry, one year of jsf, one year of small fights, one year of frustration…
Comment by Gabriel — May 16, 2009 @ 7:47 pm
I’ve no problem with people defending JSF.
But so many of the arguments to defend JSF are weak. More importantly, is your head in the sand? The “JSF Sucks” link on DZone has 35 up-votes and 5 down-votes. Doesn’t that tell you something?
Do you really think *everyone else* is wrong and you are right?
I doubt a “Wicket Sucks” or “Stripes Sucks” or “Click Sucks” post would have so many more up-votes than down votes.
Personally, I’ve used JSF on a professional application and we had all kinds of problems. Not because we didn’t know how to use JSF. Not because we didn’t try Facelets etc.
We used Stripes instead, reduced our code by 40%, and were much more productive. And it’s not like our app was a blog or something so simplistic. It’s a real-world, professional app.
JSF is a huge disappointment.
Comment by Frederic Daoud — May 16, 2009 @ 7:51 pm
>But so many of the arguments to defend JSF are weak
They really aren’t. Opponents of JSF blog that certain things are impossible to do in JFS for which proponents give a simple solution. It are the opponents that use fairly weak arguments. Take your own one for example:
>Personally, I’ve used JSF on a professional application and we had all kinds of problems.
‘All kinds of problems’. How more vague can you get? C’mon, give some specific example. Were you unable to do a redirect, where you can unable to do some validation. Please be a little bit more specific.
>More importantly, is your head in the sand? The “JSF Sucks” link on DZone has 35 up-votes and 5 down-votes. Doesn’t that tell you something?
Not necessarily. A vote is basically for the article, whether the article makes sense by itself. A downright stupid post consisting of just the line: “JSF is the best thing ever!”, would be voted down by JSF fans too.
This link for example on dzone: http://www.dzone.com/links/game_over_java_server_faces.html got 41 up votes and 21 down votes. It basically says the same as this blog posting. That’s 1/3 vs 2/3. Still a majority, but not as extreme as in this situation for exactly the same argument.
(@peter thomas, the above link is another one to add to your list :P)
The above link is especially interesting for the comments. There’s a bunch of people screaming that JSF sucks, but their arguments are mostly flawed. There is very little substance to it. Screaming “JSF is bad” is easy and can easily attract a crowd to start yelling the same thing, but coming with other arguments than the dreaded “content interweaving problem”, or “JSF == JSP” arguments is quite obviously difficult. Most of the specific arguments against JSF are also easily countered in the comments there.
Comment by henk — May 17, 2009 @ 4:14 am
@Peter
OK, so creating components in JSF involves work that is not difficult, but rather laborious, boring and tedious. I consider that a severe negative. “A pure jsf component without wrapper tags which does it’s own rendering is no more work then implementing a swing widget.” Really. In Swing, I can create a custom drop-down that has its choices predefined merely be defining subclass and a new constructor. Sure, it takes more work if I want to add it to a builder too, but if I’m going to added to my windows using code, I’m done. Tell me it’s that easy in JSF!
Comment by Frank Silbermann — May 17, 2009 @ 9:02 am
JSF can not help with UI generalization. UI generalization is from OOD. JSF has nothing in common with OO. JSF can’t provide workaround with Facelets templating mechanism because JSF expressions are evaluated in different contexts and not at the same time. You will never fix that. It is JSF innate thing.
Since UI generalization as well as adopting OO principles has proven effect – it reduces the cost of the project and helps to deal with growing complexity – we should not ignore that weakness of JSF. But we foolish yourselves and ignore.
Comment by Vladimir — May 17, 2009 @ 3:23 pm
I believe many people just left this page incompletely read due to sorting of the links. Please invert the order.
Comment by Vladimir — May 17, 2009 @ 3:35 pm
@Peter Thomas: you can implement an application using Myfaces and Richfaces, and then port it to JSF RI (Mojarra) and Richfaces.
Icefaces and Richfaces are not implementation of an AJAX specification. Are just AJAX and component library for JSF.
This will change in JSF2.0.
Anyway the ultimate goal is not the portability, but integration between these two component libraries.
In JSF2.0 you could use the components you prefer, picking them from both RichFaces and IceFaces, without any lifecycle conflict.
Comment by Alberto Gori — May 17, 2009 @ 3:45 pm
>OK, so creating components in JSF involves work that is not difficult, but rather laborious, boring and tedious
Have you ever tried to write components using Facelets instead of JSP?
I would like to point out that JSP is no more used in JSF world (a part of idiots). JSF2.0 deprecated JSP in flavor of Facelets that is now part of the specification.
Comment by Alberto Gori — May 17, 2009 @ 3:52 pm
Please give a proof of the fact the Facelets is only a workaround and can’t give us UI generalization.
Comment by Alberto Gori — May 17, 2009 @ 3:54 pm
The fact is the fact. No proof required.
Try to implement something like Attlassian JIRA UI design with JSF. What is especial in JIRA? Nothing. But what is important in this case is that you can customize the page. If you know JSF and Facelets you understand how it is complicated to render dynamic generified UI with JSF, JSF2.
Comment by Vladimir — May 17, 2009 @ 4:53 pm
JSF was designed by a man who is shortseeing and incompetent in web tech. Facelets was designed by Jacob Hoocom. He is capable man but didn’t think about consequences when splitting evaluations into two phases – parsing and rendering.
Comment by Vladimir — May 17, 2009 @ 4:58 pm
>JSF can not help with UI generalization. UI generalization is from OOD. JSF has nothing in common with OO
I’m not sure I follow. UIComponent is definitely a class, an abstract one. You can subclass it, instantiate instances of such a concrete subclass, add those instances to the view root of another UIComponent instance (composite pattern, through the getChildren().add() method defined in UIComponent).
There’s also a convenience implementation UIComponentBase that implements the abstract methods of UIComponent, so your own implementation has to implement very little.
As an example, take UIInput. This functions as a general input component. It has subclasses UISelectMany, UISelectOne and more. UISelectMany for instance has subclasses HtmlSelectManyListBox, HtmlSelectManyCheckbox, etc.
Your code may only care about getting input, or it may care about getting many inputs. The way in which it gets its input is irrelevant. I can thus easily create a HtmlSelectManyTextFields orso, if I wanted to give the user the possibility to provide data via text fields instead of via a list box. I can subclass UISelectMany and only add a few lines of code specific to my way of gathering input.
What part of all of this is not inherently OO? Do you even know what OO actually is?
Comment by henk — May 17, 2009 @ 6:43 pm
>but didn’t think about consequences when splitting evaluations into two phases – parsing and rendering.
What do you mean, parsing and rendering? What do you actually mean with evaluations? Evaluation of what? I assume you are referring to the evaluation of EL expressions, because of this previous comment of you:
>JSF expressions are evaluated in different contexts and not at the same time. You will never fix that. It is JSF innate thing.
I’ve got news for you:
1. It are not JSF EL expressions anymore but “unified EL expressions”. This has been so since 2005. Please don’t live in the past.
2. Unified EL expressions come in two flavors: immediate and deferred (${…} vs #{…})
3. Immediate expressions are parsed and evaluated immediately (hence their name).
4. Because of 3. your statement is plain wrong. You are simply spreading FUD.
Even so, deferred expressions are basically what other platforms know as ‘function pointers’. Deferred expressions are pretty much a variant on that idea. There is a distinction in JSF between pointers to values and methods, but under the hood that’s just syntactic sugar. The main point is that function pointers are not inherently evil, as you apparently try to make them sound. The concept has been around for ages and has been used successfully in countless architectures.
Comment by henk — May 17, 2009 @ 7:06 pm
[...] JSF sucks « Incremental Operations (tags: java jsf revisar) [...]
Pingback by links for 2009-05-17 « sySolution — May 17, 2009 @ 8:00 pm
@the author
I don’t really agree with your points. A lot of those early blogs aren’t valid anymore. How would you like it if a PHP programmer wrote a blog posting named “Java sucks”, and then cited blog entries about Java 1.0? E.g. “Java is purely interpreted. There is no JIT for the JVM”, and “Java does not have datastructures like a linked list or queue in its standard lib”.
You would be angry probably and rightfully so. Java 1.0 is way behind us and saying that Java has no JIT hasn’t been true for a long time. Yet you are doing the exact same thing for JSF.
Be reasonable and please remove all references to blog postings that are about JSF 1.0 or JSF 1.1.
Oh, and me and my fellow developers are using JSF and our code base is much easier to understand than before. For us JSF has been an excellent and very useful framework.
Comment by robin — May 17, 2009 @ 8:10 pm
>The fact is the fact. No proof required.
People who say that are rarely to be taken serious. The earth is flat. That’s a fact. No proof required.
Let me tell you something then: JSF is great. That’s a fact. No proof required.
Acceptable line of reasoning? I think not…
Comment by robin — May 17, 2009 @ 8:21 pm
>Wicket or GWT.
And somebody else says Struts 2 or Tapestry, and yet another person says Spring MVC or Cocoon. Since JSF is the default nowadays, it simply means it catches a lot of attention and people somehow enjoy ranting about the standard.
Remember the EJB3 rants? These were inspired by Spring rants and made by people who hadn’t even looked at EJB3. It’s so easy to say “JSF sucks!” “EJB3 is so heavy!”, but to me this only proves you don’t know what you are talking about.
When Spring fans are actually asked WHY they think EJB3 is heavyweight, all they can come up with it is “because its heavyweight” and “because Rod says so”. It’s a circle argument. When the circle is eventually broken it appears Spring fans have no real arguments and Spring is actually more heavyweight than EJB3.
>Both known to cater to Java programmers by favoring statically typed code over markup.
Do you realize that with JSF you can just as easily assemble a component tree (and thus a view) with statically typed Java code? You just don’t know JSF.
JSP is -a- method of assembling components. Facelets is also -a- method of assembling components. Doing the same thing in Java is absolutely possible and very easy. Its all about public component interfaces. Facelets does not use any hidden or internal JSF functionality. Facelets just calls into a public API. This is the same API that your own code can use too.
For starters, read up on UIComponent and ViewHandler. Stop saying things about JSF that you only think are true.
Comment by robin — May 17, 2009 @ 8:45 pm
> JSF was designed by a man who is shortseeing and incompetent in web tech.
Amen to that. It’s obvious that JSF was not designed by people who actually develop web applications in the real world — it’s just way too painful to use.
Comment by Frederic Daoud — May 18, 2009 @ 3:14 am
>it’s just way too painful to use.
It’s painful to read comments of the level “jsf is bad”, “jsf is painful”. Can you give a more specific reason why you think its painful, or is that too difficult for you?
Comment by henk — May 18, 2009 @ 3:50 am
henk:
You should write a book (or a series of articles) about JSF best practices.
I’m not being sarcastic, here — I mean it, you seem to really know your stuff. It would take a *lot* for me to change my mind about JSF but I’d keep an open mind if you were to write about “JSF in 2009″ or whatever and set the record straight about all these complaints and how they have been fixed.
But, beware: don’t talk about anything that is “planned for JSF 2.0″ or whatever — talk is cheap. I want to read about what works right now, not what is coming up next.
Cheers,
Freddy
Comment by Frederic Daoud — May 18, 2009 @ 6:11 am
henk, RTFM Facelets.
Comment by Vladimir — May 18, 2009 @ 11:25 am
Henk, you are not only guy who heard about OO. Your emotions says that you are just 20. So calm down and listen to what wise men speak about. Do you like this manner of speaking? I don’t. Calm down please.
Concerning OO and JSF. Your example does not meet more important aim of JSF – to be a standard. You are saying that you can subclass. Then you will be tied to particular vendor.
Concerning how you can subclass UIComponent. I again prefer Wicket of GWT because they are much simpler, expressive, reliable and performable. And again, Java coding wasn’t initial aim of JSF.
Hava a look at real-world application and say that it is easy to implement with JSF. As I mentioned, JIRA is a good example.
I have to choose the proper tool when starting the project. And JSF is not the proper tool. It can’t compete.
Comment by Vladimir — May 18, 2009 @ 12:07 pm
Yes you can do almost all with JSF. But you can do the same by coding in machine words. The question what is the cost of implementation and maintenance. JSF sucks in competition with Wicket and GWT.
Comment by Vladimir — May 18, 2009 @ 12:10 pm
To simplify your investigation just read about TagHandler and ComponentHandler.
Again, only you know that there is # $. But only you naively think that you can employ it starting from 05.
Comment by Vladimir — May 18, 2009 @ 12:16 pm
@Vladimir
RTFM Facelets?
Read the f*cking manual Facelets?
Would you care to explain what that utterance is supposed to mean?
Comment by Peter — May 18, 2009 @ 12:24 pm
@Vladimir: your statements are not facts. They need concrete examples and proofs to be accepted as valid points.
I don’t think that UI customization if more difficult in JSF than in Wicket. Surely it’s usually a more difficult task.
Or maybe JIRA implemented it in Wicket in a couple of hours? I don’t think.
Anyway you can generalize a JSF UI using component composition and bindings, etc.
Navigation is easily customizable too.
Comment by Alberto Gori — May 18, 2009 @ 12:41 pm
[...] συλλογή από blog posts πάνω στα προβλήματα της τεχνολογίας JSF. Έιναι [...]
Pingback by Κριτική πάνω σε Java Server Faces « Java Hellenic User Group — May 18, 2009 @ 12:45 pm
Alberto, try to read what you wrote:
>Please give a proof of the fact the Facelets is only a workaround and can’t give us UI generalization.
I mention word “fact” because of that very sentence. This word shouldn’t be used in combination with proof.
JIRA isn’t written using Wicket. You may think whatever. I implemented dynamic interfaces with JSF and I know that it is a pain.
Comment by Vladimir — May 18, 2009 @ 3:16 pm
>JIRA isn’t written using Wicket. >You may think whatever. I >implemented dynamic interfaces with >JSF and I know that it is a pain.
I know it is not written using Wicket.
Anyway, could you explain us because it’s a pain? I don’t see any concrete example in your discussion.
Which approach did you choose to build this UI?
Comment by Alberto Gori — May 18, 2009 @ 3:55 pm
>because of this when you use JSF in a real-life project, you get locked-in to whatever vendor you choose
@Peter Thomas: Again, no.
Once you choose IceFaces and Myfaces as JSF implementation, you can port your application to IceFaces and Mojarra (sun JSF implementation).
Obviously you can’t switch from IceFaces to what ever you want. This is completely nonsense because there is no specification behind IceFaces.
Probably you don’t understand the difference between a JSF implementation and a simply component library.
Comment by Alberto Gori — May 18, 2009 @ 4:02 pm
Someone said JSF appeared to be designed by someone who didn’t build websites. I don’t know whether I’d want a framework that _was_ designed by such a person — that’s how we got JSP. I prefer a web framework that’s designed by someone who has built and used object-oriented fat-client GUI frameworks. The development experience ought not be significantly different merely because we’re using a different low-level protocol.
Comment by Frank Silbermann — May 18, 2009 @ 5:09 pm
“Makes me wonder how great this Loom thing really is…”
Why? Because you did not find any books? How comes everyone is so mad at JSF, if it has so many written books?
I am not evangelizing Loom. We use it to solve our own problems, and we are really happy with it. Period. I have never recommended its use (or avoid using, for that matter) to anyone.
On the other hand, please don’t state your opinion so easily about something you don’t know. Or, if you are going to measure quality by popularity, please switch back to perl.
Comment by Ignacio Coloma — May 18, 2009 @ 7:37 pm
Three years ago I bought big Sun’s book, _Core Java Server Faces_. I read every chapter carefully, and when I came to the chapter on creating your own components I was lost. They treated it as though it were advanced material.
That’s outrageous! That’s like proposing an alternative to C for which you have to be a patient expert just to write a function sub-program! It’s like proposing an alternative to Smalltalk for which you have to be a patient expert just to create your own class definitions. How am I supposed to re-use display logic, except via my own custom components?? Am I to use “include” files???? The “include file” capability is not even as powerful as a macro processor — a modularization technique so primitive we had it even before third-generation languages were invented!
Comment by Frank Silbermann — May 18, 2009 @ 8:55 pm
@Vladimir
Your statement of being tied to a specific vendor if you sub class components is nonsense. All the classes that were mentioned are defined by the spec. They all live in the javax.faces.component package. This shows that you just know much about JSF, yet you feel somehow qualified to bash it.
Also, even it if was true what you said (which it isn’t, but suppose) then it’s still completely beside the point. The point of the matter was whether JSF component creation was OO based or not. The response to that clearly proved it was. Don’t try to divert attention by ignoring such facts and starting to talk about an unrelated issue! (and as mentioned you were even wrong about that unrelated issue)
Comment by Peter — May 18, 2009 @ 10:46 pm
@frank
About thinking that creating custom components as advanced material is outragious, consider the following:
1. How often do you REALLY create a completely new component in say Swing? In the majority of the cases you’re just overriding the constructor to set default values or to make an aggregation of several other components. In others words, you are not truly creating a new widget like eg a gauge or some funky dial. You are just doing configuration and composition. Swing is supposed to be the holy Grail of easy custom component creation, yet very few people actually create their very own custom components and even fewer of them actually look any good.
2. In JSF 2, creating custom components and making compositions is going to be a LOT less work.
Comment by Peter — May 18, 2009 @ 11:08 pm
@peter
“How often do you REALLY create a completely new component in say Swing?”
As a matter of fact, this is a quite common requirement. Off the top of my head, in my last project:
* Component to introduce a date interval. Say I want to use the DateInterval class present in jodatime or any other framework. JSF is particularly hard to manipulate when the component is bound to a composite field (e.g., something that cannot be converted to/from a string)
* Component to introduce a number of minutes as a hh:mm field. I want the java field to be an integer value persisted in the database.
* Component to upload multiple files. Using some ext extensions here would be nice, but I suppose it does not fit well into JSF.
Please notice the following: none of these are a problem with any web framework, but JSF.
Comment by Ignacio Coloma — May 18, 2009 @ 11:24 pm
>Why? Because you did not find any books?
Basically, yes. Like it or not, but the amount of available books is a strong indication of the popularity of some technology. The argument works both way. If a lot of people happen to use technology X, there is going to be a strong demand for educational material. Likewise, if you’re a book publisher you want people to buy your books, so you only publish if you think there’s a certain amount of demand. If the demand is really huge, there’s room in the market for multiple books on the same topic. Since there are quite a lot of books covering JSF out there, the natural conclusion is that JSF is used a lot.
> How comes everyone is so mad at JSF, if it has so many written books?
You’re largely overstating the amount of people being mad at JSF. There are like 5 or 6 people mad in this thread, a few dozens of blogs are quoted here, of which more than half of them are completely and utterly invalid because of their age. Compare this with the hundreds of thousands of people buying JSF books and just happily use the tech to get their work done. Compare this also with the few hundreds of blog postings that a simple query on google will give you that just talk about some aspect of JSF in a neutral way.
I guess that the majority of people using JSF just remember the old saying: “don’t feed the troll” and happily continue with their coding.
Comment by henk — May 18, 2009 @ 11:47 pm
@Peter
In my last project (using Wicket), about half my code base consists of custom panels that configure or assemble (and link together) components into application-oriented panels. The other half of the code-base consisted of the actual web page definitions. The web pages were nothing more than task-specific assemblies of pre-defined custom panels. The panel definitions had all the associated HTML; the final fifty or so web pages were assembled in Java without writing any additional HTML.
The project was a re-implementation of a large ASP.NET system. The ASP.NET system had about fifty reports/pages, each one consisting of a ~3 page unreadable tag file generated by Visual Studio and thirty or so pages of code-behind — written with lots of cut-and-paste, apparently, as I saw the same logic patterns in report after report. In Wicket, after my custom panels were created I had about 3 pages of Java code for each of those reports.
Before learning Wicket I planned to try JSF, but after reading Sun’s text I couldn’t see any _easy_ way to factor out the common aspects that were repeated in report after report. I hope you’re right about JSF 2 making it easier — if I had used JSF intead of Wicket, my skills today would be much more marketable. But I wouldn’t enjoy a job that involved the repetitive creation of redundant XML- and HTML-based tag files, and the debugging thereof.
Comment by Frank Silbermann — May 18, 2009 @ 11:47 pm
>Component to introduce a date interval. Say I want to use the DateInterval class present in jodatime or any other framework
You obviously only see a custom component solution here, but I also see the solution of a simple composite of two regular input fields. Using outdated JSP this amounts to little more then a panelgroup and two input fields. Using Facelets its trivial to re-use such a composition.
>JSF is particularly hard to manipulate when the component is bound to a composite field
Hard is overstating it. In case of the simple composite I mentioned above you just bind each input field to its own property of the backing bean. To validate those two fields together you bind them both (using the “binding” attribute) to UIInput properties of a validator that you return from a method in your backing bean. The backing bean can either create the validator on the fly as an anonymous inner class that only needs to implement the void validate(FacesContext context, UIComponent component, Object value) method, or can return an instance of a normal class if you want to re-use the validator at multiple places.
I agree that multi-field validation is not immediately obvious to implement at first sight when you just start with JSF, but calling it “particularly hard” is really making a mountain of a molehill.
> (e.g., something that cannot be converted to/from a string)
I don’t understand what you mean with this. In a web environment you ALWAYS convert to and from a String. HTML is text, so you convert TO String. A response from the user comes back as a request in text, so you then convert FROM String. If you can’t convert your object to and from a String, you can’t use it in a web environment. This is universal and has nothing specifically to do with JSF.
>Component to introduce a number of minutes as a hh:mm field. I want the java field to be an integer value persisted in the database.
Uhm, maybe I’m totally missing your point, but why would you need a JSF component to store a value as an integer in the database? What has JSF to do with your database at all? It’s e.g. a DAO that talks with a DB and your backing bean may talk with that DAO. A hh:mm field is just a String returned by a regular input field. Using a trivial to write converter you convert a String having that format to an integer. Such a converter is trivially attached to the most basic inputtext component imaginable and an integer field of the backing bean on its turn is bound to that component.
If -this- is your beef with JSF then I really, really question how seriously you have looked at JSF. I’m sure it can’t be more than a couple of minutes…
Comment by henk — May 19, 2009 @ 12:30 am
@henk
“I agree that multi-field validation is not immediately obvious to implement at first sight”
I was not talking about validation but conversion. JSF is designed like I should never develop components that map to more than one field, which is not true if you search for real reuse. Think multiple file uploading (which I would like to map to a list of files), for example.
“Using a trivial to write converter you convert a String having that format to an integer”
Sorry, I may have not expressed myself properly. These were three random examples from my last application, they were not selected to be hard to develop with JSF. The point was “developing custom components is an uncommon need”, which it is not.
Comment by Ignacio Coloma — May 19, 2009 @ 12:55 am
>if I had used JSF intead of Wicket, my skills today would be much more marketable. But I wouldn’t enjoy a job that involved the repetitive creation of redundant XML- and HTML-based tag files, and the debugging thereof.
Frank, I understand what you mean but as has been pointed out a couple of times already: both JSP and Facelets are just extra layers on top of the public, portable and pure Java based API of JSF. Everything that Facelets can do is what your own code can also do. What this boils down to is that you can create highly dynamic or highly abstracted (or a combination thereof) user interfaces using pure Java and without a single line of XML or HTML. If your components don’t need to be usable in XML they can be a simple UIComponent, which is a single class looking something like this:
public class SomeComponent extends UIComponentBase {
public String getFamily() { return null }
public void encodeBegin(FacesContext context) throws IOException {
context.getResponseWriter().write(“How much easier can it be?”, null);
}
}
The above class is a *fully* functional and complete custom component that can be used directly. The bulk of the stuff that people normally complain about is the taglib tag they have to write, the faces-config component registration and the declaration of the taglib tag in a .tld file. All of this is only needed when using JSP however.
I know one guy who has written code to completely generate a rich JSF UI based on annotations on his model classes. This way he generates some 60 web pages, without having a single JSP, Facelets or XML page in his project. Now I personally have my reservations with generating a complete view layer from model code, but it nevertheless demonstrates very well how the JSF API can be leveraged directly from Java. This guy is absolutely not a JSF wizard, but was still able to pull this off. Unfortunately he hasn’t released his project as open source, but if he eventually does and this blog is still open for comments by that time I’ll add a link to it here ;)
Comment by henk — May 19, 2009 @ 1:01 am
> JSF is designed like I should never develop components that map to more than one field, which is not true if you search for real reuse.
Ignacio, this is so not true. For one of the occasions where I really had to write a custom component (a progress bar, which wasn’t available at the time in component libraries), I implemented this component in such a way that it mapped to to multiple fields of my backing bean: one field for getting the progress value (a percentage), one field for (dynamically) specifying the update interval and one field for getting progess text (like ‘now entering stage 1′).
Why do you think this would not be possible? A component is just a class. It can have multiple properties that are given a constant value or a value expression. There is no limit to how many value expressions a component can take. It are just bean properties of a class.
>Think multiple file uploading (which I would like to map to a list of files), for example.
This example is really awkward in this context. A “list of files” would map to a single property of type List, where Something is whatever you want to use to represent your file. This is really a bad example of trying to prove that a JSF component can’t be mapped to multiple fields, since your example is clearly a case of a single field.
Comment by henk — May 19, 2009 @ 1:22 am
p.s.
>A “list of files” would map to a single property of type List, where Something is
The site nuked the angle brackets after type list, but it should have been like this: List[Something] (where a square bracket should be read as an angle bracket)
Comment by henk — May 19, 2009 @ 1:25 am
@henk
> “You obviously only see a custom component solution here, but I also see the solution of a simple composite of two regular input fields. Using outdated JSP this amounts to little more then a panelgroup and two input fields. Using Facelets its trivial to re-use such a composition. … you just bind each input field to its own property of the backing bean. To validate those two fields together you bind them both (using the “binding” attribute) to UIInput properties of a validator that you return from a method in your backing bean. The backing bean can either create the validator on the fly as an anonymous inner class that only needs to implement the void validate(FacesContext context, UIComponent component, Object value) method, or can return an instance of a normal class if you want to re-use the validator at multiple places.”
And do you do all that once for the panel group, or every time you use the panel group?
Comment by Frank Silbermann — May 19, 2009 @ 1:51 am
[...] be a turd May 18, 2009 Posted by Wille in Java, Software Development. trackback I guess this post by Peter Thomas about why JSF sucks is flamebait of sorts, if it wasn’t for it being entirely [...]
Pingback by If you polish a turd, it will still be a turd « Wille Faler’s Buzzword Bingo — May 19, 2009 @ 2:21 am
Anyone who quotes the one sentence from my devworks article where I imply that JSF 1 wasn’t so great (which it wasn’t), and completely ignores everything I said about the great new features of JSF 2 has zero credibility in my book.
Comment by David Geary — May 19, 2009 @ 3:00 am
>And do you do all that once for the panel group, or every time you use the panel group?
Let’s first be clear that -all of that- makes it sounds like it’s really a lot, while in reality we’re talking about 3 tags with some attributes. We’re not talking about tens of lines of markup. 3 tags. Okay?
Now that that’s out of the way, read back what I wrote:
>Using Facelets its trivial to re-use such a composition.
So it really depends, if the panel group is used only once I write it directly on the page. This is the same kind of decision a typical programmer continuously makes: do I extract this code snippet to a method, or do I keep it inline? Do I extract this collection of methods into a new class, or do I keep it in the existing class.
With Facelets as mentioned, creating re-useable components that are a composition of existing components is a breeze using ui:composition. Take a look at this age old article (from 2006!): http://www.ibm.com/developerworks/java/library/j-facelets/ Facelets is not exactly new or unproven or anything. If a piece of markup is particularly long or used at more than one place, I combine them into a composition.
Only in very rare circumstances do I create custom components. This is mostly the case when it really concerns a new kind of component that is not easily or naturally expressed using a composition. The progress bar I mentioned is one such example. This is a completely new kind of component and it makes no sense to try to create with any other technique than a custom component.
Comment by henk — May 19, 2009 @ 3:07 am
@Henk
Stop saying that anyone except you know nothing about JSF. Open facelets documentation and read about warning of using TagHandlers and ComponentHandlers. It is true for Mojarra as well. It makes facelets composition a pain. You certainly has not used them thoroughly ’cause you haven’t come to problems that even is described in the latest doc.
Everyone can take the API and write ViewHandler and compose components in Java. Being young you can think that you are the cleverest guy in the world but expressing that to the left and right is not quite polite.
What stops me from writing JSF views in Java … stop, from starnign a new project with JSF is that the implementation will cost as trice more as with Wicket, and mainteance will be a nightmare. JSF 2 hasn’t came yet so I can’t use it. And even if I could. I studied the draft spec and I denied JSF 2 for forthcoming projects. JSF2 is still slow in development. JSF is slow in execution. I can’t suggest my client to employ JSF. You just keep saying about technical aspects (in which JSF is awful comparing to wicket and gwt) but the problem is not only there.
It is not the problem to start wicket project with just guys who know Swing or SWT and Dhtml. They will learn Wicket within one week and then will be as twice productive comparing to JSF.
If you were working with my team I would give the team a favour by firing you because with your attitude to designing the team will slow down with amount of bugs and refactoring. The experience is your weakness.
Comment by Vladimir — May 19, 2009 @ 10:49 am
@henk
“For one of the occasions where I really had to write a custom component (a progress bar, which wasn’t available at the time in component libraries)”
Again, this is not the case we are talking about. You are mentioning an unidirectional component were no Converter is required. I am meaning a bidirectional one (an input #{…}) bound to a complex property that cannot be expressed as a single text field.
“There is no limit to how many value expressions a component can take.”
Yes there is. Once you set something like #{mybean.dateInterval} intending for input and output, it can be bound to a single HTML field only. Otherwise, you will have to implement the entire JSF burrito from scratch.
“A “list of files” would map to a single property of type List, where Something is whatever you want to use to represent your file.”
I understand by your answer that you have never tried to implement something like this with JSF.
Comment by Ignacio Coloma — May 19, 2009 @ 1:04 pm
@vladimir
I think henk has shown he actually knows a few things about jsf, something I can’t really say about you.
All you say jsf is bad, jsf is painful, but you give no real examples. When some simple and valid solutions to supposed problems are given, all you can say is that it’s still a pain, even when the example clearly shows it isn’t.
If Wicket works so great for you, fine. All the better for you. Please let us enjoy using JSF, okay?
If you have some constructive critism (which is something else than “jsf sucks”, “jsf is a pain”, etc), I’m happy to hear it, otherwise please refrain from posting trolls.
Comment by Peter — May 19, 2009 @ 1:11 pm
@ignacio
What are you talking about? A jsf component can use as many bi-directional bindings as the designer of the component requires.
E.g.
value=#{bean.value}
value1=#{bean.value1}
etc
Alternatively, you can define a complex type and use that to transport data between your component and backing bean.
E.g.
valuecomplex = #{bean.complex}
In this last case, the getCompex() method of the bean would return a value class something like:
public class Data {
String value;
String value1;
}
How is this different from a plain Java method for which you want to return one vs multiple values?
Comment by Peter — May 19, 2009 @ 1:26 pm
@peter
“public class Data {
String value;
String value1;
}”
Peter, in your example there is no Conversion of data. You should try this with fields that are not strings.
About your comment at Vladimir:
“All you say jsf is bad, jsf is painful, but you give no real examples”
But he did. He said that with JSF, performance is a pain. JSF serializes and stores each view that is rendered to the user. This consumes server memory and CPU, and supports using the back button in your browser up to 20 times (by default in the MyFaces implementation).
The alternative is great, state can be sent to the browser with each response which would also consume bandwidth.
No other framework works like this. What people in this thread are trying to say is that with JSF it’s possible to write applications, but we have found easier and more productive alternatives. And it’s not because we don’t know JSF well.
Peace.
Comment by Ignacio Coloma — May 19, 2009 @ 1:59 pm
>>“A “list of files” would map to a single property of type List, where Something is whatever you want to use to represent your file.”
>I understand by your answer that you have never tried to implement something like this with JSF.
Ignacio Coloma, stop spreading FUD!
A value binding can pull or push any Java type, so of course this includes types such as List, Map, Set, arrays, etc.
How do you think a standard ManyListBox works? It binds to a backing bean and pulls and pushes a String[] over that binding. That’s multiple values over 1 binding. Simple as that.
Comment by robin — May 19, 2009 @ 2:09 pm
>But he did. He said that with JSF, performance is a pain. JSF serializes and stores each view that is rendered to the user. This consumes server memory and CPU, and supports using the back button in your browser up to 20 times (by default in the MyFaces implementation).
This is not true. Either the views are stored on the client and then (and ONLY then) they are serialized, OR they are stored on the server and then they are not serialized.
Both approaches have their cons and pros. Storing state on server is more memory intensive, but friendlier for the CPU. Storing state on client is more CPU intensive and costs more bandwidth, but is friendlier for your own server memory.
It’s also not the rendered view (as in the whole HTML page) that is being store, but the state of the involved components.
That said, the entire state save mechanism is pluggable too in JSF. If you really need something else; nothing is stopping you. It’s simply a fact that applications have state. Alternative solutions include storing everything in your session or fetching all your state from a DB on each request. These solutions have their own slew of problems.
I do agree that the default state saving mechanism is not without its faults. There is no distinction between true constants (that can be read from the tag attributes) and dynamic values. Also, the choice between saving state on server and saving state on client is a global setting. It would be great if the default implementation would make this optionally a choice per view.
For many applications I choose to store saving state on server. There is no performance problem in that case and memory demands are rather conservative.
Incidentally, ASP.NET uses the same model as JSF with respect to state saving and this technology is used a lot.
Comment by robin — May 19, 2009 @ 3:08 pm
[...] I read this post at Incremental Operations titled “JSF suck” and I must say that I agree with almost [...]
Pingback by JSF sucks, Wicket rocks? « Paul Szulc’s Blog — May 19, 2009 @ 4:04 pm
O boy! Yet another emouthional kid.
@Peter let Henk speak on his own. I brought an example – JIRA – and obtained a very simple answer – there is no problem to implement. Have you tried? I have and I know.
Yet another example – Compiere (written with GWT).
As a criticism read this http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets become happy and then explain how this very problem is addressed in JSF2. I lost interest in JSF and don’t care about 2.0 anymore. Probably commettee included something new about that. Surprise me by excerpt from newest draft.
I can’t leave discussions right now because many stupid PMs make decision about quality by popularity.
Comment by Vladimir — May 19, 2009 @ 5:34 pm
@Peter
You do can subclass any of UIComponent derived class. But why I don’t do that anymore is because JSF API has a very big contract. JSF2 has a longer contract. You have to implement so much. Including some especial requirements for collections here and there. There are helper classes. But even with them you have to keep in mind the whole contract.
With Wicket it is simple as natural. There are some practices you should keep in mind. But with JSF you can’t do anything valuable without knowing a lot of practices. Those practices mostly was initiated from pains. The amount of them is too much to be a good framework. And it does has effect on productivity.
Comment by Vladimir — May 19, 2009 @ 6:23 pm
@henk:
>>And do you do all that once for the panel group, or every time you use the panel group?
>Let’s first be clear that -all of that- makes it sounds like it’s really a lot, while in reality we’re talking about 3 tags with some attributes. We’re not talking about tens of lines of markup. 3 tags. Okay?
As long as the backing code doesn’t have to be repeated as well, that’s not too bad.
Nevertheless, What I prefer about Wicket over JSF (as well as over JSP and the vast majority of web frameworks) is that I don’t like coding _any_ program logic via the nesting of tags. Maybe it is my inexperience, but I find it much more difficult to grok an overview of what’s going on by skimming a tag file, as compared with skimming a page of programming language code. For example, if Java syntax were, say, an XML schema instead of a C-like notation it would be a lot simpler to write the parser for a Java compiler — but I think I’d find programs much harder to read and write.
This is aside from the fact that making a Wicket component is not laborious at all (although, on the down side, it is not as easy to _use_ components that _must_ be instantiated and configured in code as in Wicket — rather than components which the developer can simply drop onto a form and then fill out property editors as in ASP.NET and, presumably, JSF).
Comment by Frank Silbermann — May 19, 2009 @ 7:31 pm
[...] http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks [...]
Pingback by JSF sucks ball! | petersteinberger.com — May 19, 2009 @ 7:39 pm
I was one of the early JSF triers, but I really wanted pure html design and code separate, so JSF (jsp too) didn’t help me much there. How do teams using JSF keep up with GUI/Design creations or changes?
While I agree that JSF has a place in web-framework space, I’m observing one thing in these replies. Those who are against JSF pretty much say ‘I tried jsf, it just didn’t work so I jumped to Wicket or something else’. So far I have not seen a reply from the ‘jsf camp’ saying ‘I tried Wicket, I did not like it, so I’m staying with jsf alone’. In fact across the blogs, I haven’t seen any negative comments against Wicket.
Comment by vasya10 — May 20, 2009 @ 2:04 am
Well, I’ve seen a few negative comments about Wicket. For a long time there were comments about the lack of professional quality documentation, but this has largely dissipated with the publication of _Wicket In Action_ and a two other books. (I hope they update these books for the API changes that version 1.4 will bring.) I’ve heard negative comments about the small number of Wicket jobs on the employment boards — but this is not an issue for everyone and hopefully will turn around as more people try it and discover Wicket’s advantages. I’ve heard people complain that the heavy use of anonymous inner subclasses by Wicket developers is daunting to many beginners, at least until they realize that the creation of anonymous inner subclasses is simply an easy way of instantiating a generic component along with the desired event-handlers. (Wicket components might have a slightly different API had the Java language offered delegates or closures.) But yeah, if you’ve learned Wicket and are allowed to use it, it is tremendously better than most alternate ways of building web applications. (I would say that only Tapestry, Echo2, and GWT are in its league.)
Comment by Frank Silbermann — May 20, 2009 @ 2:29 am
>‘I tried Wicket, I did not like it, so I’m staying with jsf alone’. In fact across the blogs, I haven’t seen any negative comments against Wicket
That’s a good observation really. To be honest, I indeed don’t have a lot of negative things to say about Wicket. Maybe the only indirect criticism against Wicket is that it’s YET another web framework. Obviously some people in this thread really dig Wicket, but unfortunately there is some other group of people who really like Struts 2 for instance. And there’s also the people who really like Tapestry, and I just learned in this thread that there’s also a Loom and god knows what else is out there.
A little competition is okay to keep everybody on his toes, but too much fragmentation among others leads to a difficult job market. One thing that I love about the Microsoft market is that you can just put up a vacancy for a .NET programmer and you get one that knows .NET. (*) With Java this is far less obvious. If you put up a vacancy for a Java programmer, you literally never know what you’re going get. Because of the strong fragmentation in mainly the web framework area, basically every other guy (and the odd gal) has experience with some other framework. Put them together in a team and arguments start to rise how much better their preferred framework is.
(*)
(I do have to add that ‘they’ have their own little fights with this idiotic VB vs C# war and recently the ASP.NET vs ASP.NET MVC thing.)
One pattern that I see though is that fans of alternative technologies often bash standard technologies, but rarely does it happen the other way around. A legendary example is Spring vs EJB3. If you frequent a site like TSS, you can’t miss the fact that every other EJB3 news item is vandalized by Spring fans bashing EJB3. Now Spring is absolutely a pretty decent framework, but there really is very little to bash in EJB3. The majority of the bashing seems to stem from a habit and nothing more. In those bashing tirades, people yell stuff like “EJB3 is heavy”, “Don’t make me eat the elephant again”, but there’s very little to no real substance to the bashing.
JSF is definitely not without its problems, but I really believe that a lot of bashing here is out of habit. It almost seems that if you are a Wicket user, it’s part of the culture to bash JSF. Maybe if Wicket happened to be the default framework in Java and JSF was an alternative technology, hordes of JSF fans would bash Wicket at each and every opportunity.
Comment by henk — May 20, 2009 @ 2:56 am
@Henk
it seems you are not so certain about JSF anymore %)
My intention is to draw attention that people spent on JSF too much money. As a good PM one should choose appropriate language, platphorm and tools for the new project. And I’m certain that there are a few reasons to choose JSF. It is cheaper and less risky to choose GWT or Wicket. It is bashing for the sake of bashing.
Comment by Vladimir — May 20, 2009 @ 8:40 am
Sorry I write it in a hurry. I mean I argue with JSF not for bashing for the sake of bashing.
Comment by Vladimir — May 20, 2009 @ 10:47 am
As for being “yet another framework” Wicket both is and isn’t. I mean, yes, it’s yet another open-source Java framework for building web applications. But in fact, it is radically different. Most Java web frameworks supplement Servlet/JSP technology by standardizing and re-using code that seems to repeat itself in a great many Servlet/JSP projects. Wicket was conceived by a Swing developer who was assigned a Web project and was absolutely appalled at the things a J2EE web programmer was expected to put up with, and took a completely different approach.
Originally, the only J2EE objects registered in a typical Wicket application’s web.xml file was a single servlet provided by the Wicket framework. Nowadays, it’s not even a servlet — a Wicket application is just a single J2EE filter.
Servlets are based on the premise of writing functions that create strings of HTML. JSP, ASP, JSF, etc. are based on the premise of inserting more powerful capability into HTML files. Wicket is based on building applications in Java; but it executes using web protocols and it uses HTML files in place of AWT/Swing layout managers.
The radical difference is probably why you see so few people trying Wicket — and so few Wicket users who like the most common frameworks. (Most Wicket users respect Tapestry as being almost as good, Echo2 as being just as nice though less flexible, and GWT as a great approach for generating powerful JavaScript applications.)
Comment by Frank Silbermann — May 20, 2009 @ 5:32 pm
>it seems you are not so certain about JSF anymore %)
Vladimir, believe me, I’m still as certain about JSF as I ever was. It’s just that I simply don’t hate Wicket. I actually like the Wicket approach too, and if I would ever find my self in a situation where I wasn’t the lead developer and the lead where I worked for had already chosen Wicket, then I would most likely enjoy developing for it.
Read back all my posts. I never said I hated Wicket. For me the world is just not so black and white. The fact that I enjoy using JSF doesn’t rule out Wicket for me. Likewise, the fact that I’m a Java developer doesn’t mean I hate e.g. C++, C# or .NET. The only thing I really don’t like, but which is a little off topic here, is PHP or using plain JSP with embedded business logic and dynamically build SQL strings in and between HTML tags [shudder].
Comment by henk — May 20, 2009 @ 7:59 pm
@Alberto (comment #70)
Simple YES or NO question:
Is ICEFaces from a vendor ?
Comment by Peter Thomas — May 21, 2009 @ 5:27 pm
>Again, only you know that there is # $.
I think there are a few more people than just me who know about # and $. At least you now know this too :P
>But only you naively think that you can employ it starting from 05.
Uhm, I thus can’t employ it starting from 05? What on earth do you mean with that? Why would I not be able to use it? What’s naive in thinking I can actually use tools that were designed to be used? What’s the rationale behind your reasoning?
Comment by henk — May 21, 2009 @ 6:09 pm
Peter, you didn’t actually delete a comment of me here, did you?
If you did, then I’m simply out of here. You won. I can’t fight you at that level. If you didn’t, then something is wrong with your wordpress installation, since I just posted a comment here and verified that it was there.
Comment by henk — May 21, 2009 @ 6:14 pm
Nope ! Did notice some problems with the new “threaded” comments feature of WordPress. Can you try re-posting ?
Comment by Peter Thomas — May 21, 2009 @ 6:21 pm
You know, Henk, there is something wrong with you. You just skip concrete topics and stay on only those that let you express emotionally. What about TagHandler vs ComponentHandler problem? Have you ever seen it? Please don’t skep. Add your 5 cents.
About deffered vs immediate evaluation. It never works with facelets because TagHandlers evaluates the expression before ComponentHandlers dispite it is # or $. If you need to include or template something basing on relative resource path you must evaluate it immediately.
If you managed to employ Unified EL with Seam please post a Seam Wiki article about your achievement. I encounter some very strange effects and ceased to continue.
Comment by Vladimir — May 21, 2009 @ 8:14 pm
@David (comment #86) – here’s a quote from you way back in 2004 on JSF 1:
And – JSF 2.0 just isn’t ready yet. Sorry.
Comment by Peter Thomas — May 21, 2009 @ 8:20 pm
> And – JSF 2.0 just isn’t ready yet. Sorry
You are right about that, but if you want to peek at what’s coming, there is a public preview available at:
https://javaserverfaces.dev.java.net/servlets/ProjectDocumentList?folderID=10943&expandFolder=10943&folderID=0
There’s also always the nightly build if you want the latest and greatest (just for testing of course).
The spec is also at the proposed final draft stage, take a peek at: http://jcp.org/aboutJava/communityprocess/pfd/jsr314/index.html
So once again, it’s indeed not ready yet and if you want to use JSF today for a production quality application, then it’s JSF 1.2 for you. On the other hand, it’s not like JSF 2 is its early conception stage either. A proposed final draft document will rarely be changed radically for the final release. What you’ll read in there now is pretty much what you’re going to get, so it’s definitely worth a read I think.
Comment by henk — May 22, 2009 @ 2:49 am
Hmmm, that’s awkward. The comment wasn’t that great really ;) I basically said that a very similar thing about the vendor lock in was being discussed in the comments at the dzone link to this page.
Comment by henk — May 22, 2009 @ 2:51 am
Ok. I mean, you have single-handedly posted the majority of comments on this blog post. If I had wanted to “censor” you I would have done so long back :P
As other commenters have pointed out, it does say something IMO, the kind of support JSF is getting here. Why don’t you visit all the links I posted and go and comment there to your hearts content. That would be a much better use of your time :)
Comment by Peter Thomas — May 22, 2009 @ 12:19 pm
@Vladimir
What do you mean with componenthandler vs taghandler? Do you understand that a componenthandler in facelets -is-a taghandler?
As usual you are talking in riddles again, but given the context I can only guess you are talking about the difference between build-time and render-time. This is just a concept. There is simply a difference between building a component tree using code that only helps to build this tree and code that actually becomes a part of the component tree.
Deferred expessions in that context are still deferred. It’s up to the components whether they immediately get or put a value or store the expession for later use.
If some component always gets the value immediately while you expect deferred semantics, then it’s a fault of that component.
Do you also blame the whole of java if one class misbehaves?
Comment by Peter — May 23, 2009 @ 1:47 am
Peter Henk, I brought an url to the article and explained the context. You have to realize the problem on your own.
Comment by Vladimir — May 23, 2009 @ 10:10 am
>I brought an url to the article and explained the context.
Vladimir, did you really understand the problem that was put forward in the linked article? Somehow I doubt that, given the fact your summary of it was less than stellar.
Comment by henk — May 23, 2009 @ 3:37 pm
Stop spreading FUD Vladimir. Stop talking about things you don’t understand. Your URL means NOTHING. The solutions to each ‘problem’ are given in that post.
If you think helper tags vs components is a universal problem with JSF, this AGAIN proves you do not understand JSF and are just posting about supposed problems that you found on forums, but don’t understand yourself.
Comment by robin — May 23, 2009 @ 7:18 pm
Although I agree JSF has some annoying pitfalls, shortcomings and a high learning curve, it’s been out there for enough time to pass for supplement frameworks pop up from under the ground to solve most of these problems.
With the right combination, most classic counter arguments have become obsolete. Maybe it’s time for critics to take JSF as is: incomplete but ultimately making you more productive if combined with the right frameworks.
Comment by Benny Bottema — May 24, 2009 @ 6:38 pm
So what you are saying is JSF has problems but if you combine it with some 5 or 6 other disparate, vendor-specific frameworks it is tolerable ?
Sorry, no thanks.
Comment by Peter Thomas — May 24, 2009 @ 7:54 pm
@Alberto (comment #48)
Nice going, calling all the project teams today not using Facelets “idiots”.
Oh, and I would like to point out that Facelets is not part of the current JSF specification.
Comment by Peter Thomas — May 24, 2009 @ 8:43 pm
My choice is based on the Extreme Programming principles of constant refactoring and the DRY (don’t repeat yourself) principle.
When programming in Java, if I notice that I’ve written the same six lines of code twice, and am likely to do so again, I use the _extract_method_ refactoring to eliminate the redundancy and shrink my codebase; sometimes I’ll do so via a class hierarchy. So, when I see the same nesting of six tags repeated in a web application, I ask what abstraction mechanisms the framework gives me for factoring out that redundancy. Will it let me reduce my application size by writing a custom tag or custom component, or will the necessary effort and resulting boilerplate code make this a bad idea?
I find that with web frameworks in which code or smart tags are embedded into HTML files, the redundant portion has to be pretty darn big before it becomes worthwhile trying to factor out the redundancy — and this is no less true of JSF. What I prefer about the Wicket approach is that even relatively small pieces of redundant display logic are economical to factor out.
I realize that this attribute of Wicket does not impress the majority of programmers who rely on the copy-to-the-clipboard-and-paste method of application development. This may be the reason Wicket has yet to take off in a big way.
Comment by Frank Silbermann — May 24, 2009 @ 9:22 pm
Who knows the cure for the following non-working markup?
<ui:repeat value="#{bean.items}" var="item"> <ui:include src="#{item.src}"/> </ui:repeat>Those who thinks that the problem could be easily solved by replacing ui:repeat with c:forEch, try to fix this:
<h:datatable value="#{beans}" var="bean"> <c:foreach value="#{bean.items}" var="item"> <ui:include src="#{item.src}"/> </c:foreach> <h:datatable>Those who manage to fix this please move on to the next level of overlapping jsf lifecycle scope with three building scope by combining templating, custom components and the non-working examples in the article http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets. Don’t forget the example of # with $.
The above must gave me clear justification that I don’t know the matter I’m speaking about. But for me it does not seem to be be a provement at all. The only thing I learned from your post is that there are some people who behaves too agressive for just regular JSF user. I don’t care what is the reason to be so aggressive. I won’t be surprised if it is connected to your business which can shock if JSF sucks. I don’t care. I have a different tool that helps me to develop more stable application in short time. I like the other people to be encouraged to try.
Comment by Vladimir — May 24, 2009 @ 9:33 pm
Peter, you are wrong. The evaluation cannot be deffered with the current implementation of ui:include and similar tags. The src attribute must be evaluated immediately to include another file in the process of building tree.
When I investigated this I realized that there is certain limitations related to JSF lifecycle. If you would like to change tree as the effect of processing user event received via ajax request you will fail with the JSF 1.2
If you know the way around I’m ready to commit that you are true JSF hackers. But you have to post your working and tested workaround prior claiming that I know nothing about Facelets and JSF.
Comment by Vladimir — May 24, 2009 @ 9:53 pm
>So what you are saying is JSF has problems but if you combine it with some 5 or 6 other disparate, vendor-specific frameworks it is tolerable ? Sorry, no thanks.
Peter Thomas, I read some of your other blog postings and you are obviously a bright guy. I just don’t understand why you keep making such a big point out of this. As part of the Java standard library I’m actually glad that JSF choose not be the end solution of web frameworks and actively encourages third party developers to enhance it. This is not really that different from say Eclipse, where its biggest asset is arguably its plug-in architecture and the extension points offered.
In a way you can even compare this with core Java itself. The JDK does not pretend to be a complete end solution. There are many third party libraries for Java. Some of which should perhaps have been in the core (Yoda time, Apache common HTTP), while others are just excellent third party contributions to the Java eco system.
Why then is it so bad in your view that there are many third party libraries available for JSF? Wasn’t that really the entire idea behind defining a component model, that people would actually build and publish components? Likewise, the fact that JSF included a decoratable ViewHandler, wasn’t the idea behind that that people would actually take advantage of that and provide their own view handlers?
Comment by henk — May 24, 2009 @ 10:51 pm
>Nice going, calling all the project teams today not using Facelets “idiots”.
Maybe Alberto meant that JSP is a rather idiotic technology to use, since it doesn’t really fit JSF at all. In practice I think people only use JSP with JSF when they have severe legacy issues (like an application that is partly converted from being JSP + Scriptlet based to JSF based).
>Oh, and I would like to point out that Facelets is not part of the current JSF specification.
Right you are, but Facelets has been readily available for free for quite some time. As Alberto mentions, JSP is practically already deprecated for JSF 1.2 since it’s deprecated in JSF 2.0. This may sound awkward, but compare this with e.g. the period that the US president Obama was elected but not yet inaugurated. Even though Obama did not have any official power yet and Bush was still officially in full control, there practically was very little Bush could do and few people listened to him anymore. In this story, Facelets is Obama and JSP is Bush ;)
Comment by henk — May 24, 2009 @ 10:59 pm
No, not tolerable. Highly productive!
Here’s my list, with which I’ve succesfully finished enterprise projects:
- JSF (MVC)
- Facelets (Templating, use of XHTML)
- Richfaces (component suite)
- Richfaces A4J (Ajax support)
- Tomahawk (only for file uploads with the Extensions Filter)
- PrettyFaces (for indexable GET urls)
On a sidenote, I’ve been told Seam does all of the above frameworks plus conversation scope and some other things. Maybe exactly what you’re looking for?
Comment by Benny Bottema — May 24, 2009 @ 11:07 pm
Again, maybe it’s time for critics to take JSF as is: incomplete but ultimately making you more productive if combined with the right frameworks.
What you are saying applies to JSF+Facelets which promote factoring out redundancy to a high degree, being a templating framework and all…
Comment by Benny Bottema — May 24, 2009 @ 11:10 pm
>Peter, you are wrong. The evaluation cannot be deffered with the current implementation of ui:include and similar tags.
I don’t think he’s wrong. He specifically mentioned *components* can decide whether to get a value from the expression or store it. Tag handlers are not components. They are just code that helps in building the tree. Since this code disappears after the tree is build, it’s only logical that a deferred expression doesn’t make any sense there.
>If you would like to change tree as the effect of processing user event received via ajax request you will fail with the JSF 1.2
No, it doesn’t necessarily fail, but I do understand what you mean (I think). It’s true that using EL expressions you can not alter the structure of the tree anymore when processing a post back. Using EL you can only disable parts or enable certain parts, since there is no tree building phase anymore at a post back. Tree building happens only for the initial (non faces) request. For the majority of the use cases this is more than enough, but sometimes we want to think a little outside the lines.
Luckily this is absolutely possible in JSF and not even that difficult.
In your backing bean you utilize a simple code fragment such as this:
UIWhatever whatever = new UIWhatever();
// Configure ‘whatever’ in any appropriate way
UIViewRoot root = FacesContext.getCurrentInstance().getViewRoot();
root.getChildren().add(whatever);
Here I just added the new component directly to the root, but any location is possible of course. Using the API you can either walk the tree or find a component by id. The above code fragment could be called as a result of the AJAX call, but it could also be called by a PhaseListener or in specific situations by a decorated ViewHandler.
Comment by henk — May 24, 2009 @ 11:20 pm
>Since this code disappears after the tree is build, it’s only logical that a deferred expression doesn’t make any sense there.
That’s right. This is very logical and if you can’t understand this, how can you understand much more complex business logic?
One thing; JSF can be improved by making the difference between build-time tag handlers and tag handlers that insert components into the tree more obvious. Perhaps just an extra attribute; isAddingComponent() ? Tools can then render the tag a little different and emit warnings when used wrongly.
Comment by robin — May 25, 2009 @ 12:28 am
@henk
One of my points is maintenance. You now have to keep track of multiple third-party projects. Even worse, when you have some issue (e.g. in the infamous JSF phase / life-cycle :) you will be stuck trying to figure out which “extension” is the culprit. I would imagine that when pushed to the wall, each extension would try to blame the other vendor, typical project horror story :P
@Benny Bottema
I have used Seam and you can find one of my comments on the experience above. I’m sure you (or henk) can come up with some argument why using non-java declarative tags with six different (frequently overlapping) XHTML namespaces is a good thing in web-app development. I don’t think it will be convincing though :P
Also see this performance comparison I did.
Comment by Peter Thomas — May 25, 2009 @ 10:40 am
@Alberto
Besides the “tag soup” aspect I pointed out in my comment above, my main point in the comment before is not that JSF extensions and component libraries *should* be portable, but that many architects and technology decision-makers I have interacted with do *not* realize that using JSF in real-life projects locks you into some vendor or the other.
I’m glad that this point is being brought out in the comments here.
Keeping on saying that JSF is portable (where you mean only the spec implementation not the extensions), doesn’t really mean much for real-life projects. And JSF 2.0 doesn’t count, it is not ready yet.
Comment by Peter Thomas — May 25, 2009 @ 10:51 am
Maybe it’s time for you to look at alternatives to JSF ? No harm trying.
Comment by Peter Thomas — May 25, 2009 @ 11:18 am
@Peter
Since JSF is supposed to be a starting point, a base for extension as established earlier (half baked in your opinion), it is only logical there are several namespaces for each extending framework.
In practice I use about four namespaces, but with facelets most of it is tucked away in reusable facelet components I made. At this point I only use h, ui and my own namespace.
It may be annoying to you, but now you are just nitpicking. The important question is: can you be productive with JSF + extensions. Yes, you can.
From the comments here and your reactions to them it sounds like you’re not open to any kind of suggestion, made up your mind and poured it in concrete: congratulations, you’re here to troll.
Comment by Benny Bottema — May 25, 2009 @ 12:21 pm
@peter thomas
I somewhat agree with you on not knowing who to blame in case of problems, but still…
In what way does this differ from a regular Java project or a project for whatever platform. Don’t we always reuse code from tons of sources? Don’t run of the mill applications use at least 6 to 7 separate jar files?
This also holds for the name spaces. Why is there a problem with using 6 namespaces in XML? Your average Java class may utitilze perhaps 20 namespaces or more.
Comment by Peter — May 25, 2009 @ 12:57 pm
@robin
You’re right about that attribute you mention, that would be a very valuable addition indeed.
Comment by Peter — May 25, 2009 @ 1:02 pm
@Peter
Let’s just talk about the UI tier. The point is – there are better web-frameworks than JSF where:
a) you *don’t* need multiple vendor-specific frameworks to get things done
b) you don’t have to deal with declarative / XHTML “tag soup” to construct views
Comment by Peter Thomas — May 25, 2009 @ 1:06 pm
@Benny Bottema
Ha, I leave it to readers to decide who are the trolls here in the comments (if people care to read them that is). My, did you really have to go and call me a troll, can’t we just agree to disagree ?
I’ll just say one thing, look up my blog posts, I have tried Spring MVC / WebFlow, GWT, MyFaces, Seam / RichFaces and Wicket.
I actually used to recommend Spring MVC in the past but then I switched to Apache Wicket.
But yeah, you have to go and accuse me of not opening my mind and having it set in concrete. Oh yeah.
Comment by Peter Thomas — May 25, 2009 @ 2:11 pm
>Let’s just talk about the UI tier. The point is – there are better web-frameworks than JSF where:
This in an opinion. Many people beg to differ. According to Spring fans, Spring is the best thing in the world. EJB3 users disagree with that. Same with JSF, you don’t like it, but me and my friends do.
>a) you *don’t* need multiple vendor-specific frameworks to get things done
If you use Wicket, do you use the rest of Java EE or do you use Spring and Hibernate separately? If the last is true, you are already using things from multiple vendors.
Comment by robin — May 25, 2009 @ 6:51 pm
@robin
Yep. Your opinion is that JSF is the best. And I completely disagree. Let’s just leave it at that.
Of course, readers can look at the list of links and quotes I have laid out and decide for themselves. The number of upvotes on the DZone link can also help readers form an opinion.
BTW your second point doesn’t count because we are discussing just the UI tier as I said earlier.
Comment by Peter Thomas — May 25, 2009 @ 7:02 pm
@ peter Thomas
Regarding the links and quotes that you posted, you have to realize they are not all valid anymore. The majority of these concern jsf 1.0 and 1.2. Jsf 1.2 is the current version. Maybe it’s better to only post links from 2007 or 2008 and later?
Regarding the up votes, this doesn’t necassarily means all those people are against jsf. The vote is for the article and not perse about the statement expressed by the title. If you look at some forums like the sun forums or perhaps javaranch, then you’ll notice a lot of posts from people who are using jsf. If the tech was really bad and universally hated, you wouldn’t see that much discussion going on.
Comment by Peter — May 25, 2009 @ 9:44 pm
@Peter – points noted. All the links look pretty much relevant to me though. I do think it is important for people to know how *consistently* JSF has sucked ever since it appeared in 2004. Well, readers can decide.
Comment by Peter Thomas — May 25, 2009 @ 10:08 pm
>I do think it is important for people to know how *consistently* JSF has sucked ever since it appeared in 2004.
I think that one major mistake Sun made is calling the 2004 version “1.0″. It’s just a number, but numbers do say something to people. By all accounts, JSF 1.0 was a beta version. The first version that was an official part of Java (JSF 1.2) should have been called 1.0.
Comment by henk — May 25, 2009 @ 11:43 pm
robin,
“Do you realize that with JSF you can just as easily assemble a component tree (and thus a view) with statically typed Java code? You just don’t know JSF.”
Of course I realize, in many instances you have no choice but to go through the component tree! Say you are in request scope where an event fire, and you are interested in the value of a support component. You will have to do nasty manual detection by various calls to getClientId, getRequestParameter, null checking and casting.
If you somehow has JSF working for you, congratulations, perhaps you are just that good! But clearly a lot of people find JSF complex and cumbersome: http://www.dzone.com/links/jsf_sucks_compendium_of_jsf_rantsreviews.html
Comment by Casper — May 26, 2009 @ 3:22 pm
I am senior developer in the .NET M$ world and I have recently started a project that will be done in JAVA. In the MS .NET world I have done just about it all; Component development, frameworks for developers, web services, multilayered development, blah blah. I am by no means a junior level developer. That being said I have found that JSF is just about the hardest thing to use. Primarly because of the following:
1. Good luck on tutorials. They are few and far between and many are absolutly useless
2. Simple things are hard. The radio button control is one glaring example.
3. The alphabet soup of additional frameworks needed to do jobs is just flat out confusing. Especially if the date is not correct on the website post.
4. Everything is in a configuration file. Well this sounds like a good point but when you try to do something simple like change a validation message, it gets too complicated for many tasks
5. There is not a learning curve there is a learning cliff. Maybe when you become an expert it is all easy but getting there is like an SnM session after you forgot the safety word.
So far this framework has made me wish for the days of legacy ASP and Php presentation and business logic code jumble. I can’t believe that it really is this hard. But finding the holy grail of up todate tutorials that answer real life web coding questions is pretty darn hard.
Granted alot of .NET projects are just poorly(sloppy) done but this is because it is easy to get moving with it. So you can work and learn at the sametime. Those first designs may not be ideal but they work. This learning experience allows you to move onto the correct way to do things. Then again maybe you never get to refactor but that is life.
I am just so tired of radio buttons, seriously they thought this was good way to do it.
Comment by Dan — May 27, 2009 @ 8:36 pm
What we have here is a class between two approaches to object oriented development. The old approach is to use something like the Rational Unified Process to architect (in UML) a communications framework into which the system logic will be dropped. Struts and JSF are two such architectures developed for the web. The experience using such frameworks is about what you’d expect from this approach.
Contrast that with Extreme Programming. Here, the idea is to grow your system as you add user stories beginning with the simplest possible application. Do not generalize or add functionality until you know you will need it. Refactor continually, eliminating every redundancy whenever it appears. Constant refactoring is made feasible by test-first development and avoidance of heavy-weight frameworks. This is a prescription for NOT using Struts or JSF. In fact, there are very few web frameworks suitable for this approach — Wicket, GWT, Echo2, and Tapestry are the only ones I know about
Comment by Frank Silbermann — May 27, 2009 @ 8:52 pm
@Dan
>I am senior developer in the .NET M$ world
That’s quite interesting really. Did you use C# and ASP.NET or only ‘legacy ASP and Php presentation’?
Comment by henk — May 28, 2009 @ 2:04 am
Thank you for your interesting article. Learned a lot new to subscribe to your news. I would wait for new articles. Good luck.
Comment by Psh — May 31, 2009 @ 9:57 pm
yep! JSF sucks! All these “fancy” ajaxified JSF implementations suck!
And Icefaces is not better… just try with the 1.8.1 Version to export data… and the charts… is this Web 0.5?
And from a designer perspective, with this really slow dev cycles it is so painfull… really.
And it is getting worser if you try to use it in conjunction with portlets – Exception overkill!
Why is it in the year 2009 still a major step forward introducing facelets, which is actually nothing else than xhtml? Damn – maybe we should witch to PHP? Haha.
Comment by Steffen Schuler — July 20, 2009 @ 5:09 pm
[...] } Наткнулся на интересный пост: человек собирает негативные отзывы о технологии [...]
Pingback by О JSF в негативе « Всячина — August 23, 2009 @ 11:25 pm
I know, this is an old article and maybe especially because of that I want to provide my own experience yet August, 2009.
Here you are the comments from a newcomer in Java Web Development:
JSF: I like the JSF WYSIWYG editor in NetBeans. Spending a lot of time developing the GUI this saves me time. That said, when I start using tabs and other elements that makes use of containers, it get’s a pain. Not any near to the cool Matisse Swing Designer in NetBeans.
Anyway, it is quite simple to get started. What I also like is the visual page flow designer. Although several people complain about the back-button not working in the browser I could not experience this (but maybe depends on what I am doing in the page).
GWT: Easy to get started and very intuitive. Only thing I was missing some GUI elements as the core GWT elements seem quite basic. Found GXT (from Ext JS) and SmartGWT. Maybe because of version conflicts with current version combinations of GWT and GXT I was not able to get GXT to work but SmartGWT was quite easy. So the widget problem seems to be solved.
Not having a visual designer (yes, I know, there is already a commercial one) is sad, but I found it not so difficult to code it (remembering GUI coding in the 90ies with C++ or Turbo Pascal).
What was annoying was the long time needed to run/deploy a very basic hello-world type app with some widgets on it for testing. By accident I found other articles and forum posts complaining about compiling performance of GWT compilation. :-( – it looked so good. By building a whole bunch of JavaScript and pushing it to the client I wonder if it is not better to create a Swing application and use WebStart instead. Well, with GWT client does not need a Java runtime installed which can be an advantage because still some don’t have. I also found that combining SmartGWT widgets with vanilla GWT widgets can be an issue – on dynamic widget changes the text and image of a button got separated.
Wicket: When I found it and noticed that there is no XML I was soooo happy, because I hate XML poluting my code. There are such cool and feature rich IDE’s and then I don’t want to throw that away (e.g. debugging) using XML (that’s way I also hate Spring before ever using it in my own applications – because I had to configure a 3rd party app that makes use of Spring and I was shortly before exploding).
I like that clean separation of HTML, CSS and Java Code in Wicket. Yes, I think this approach somehow “gracefully surrenders” trying to trick web limitations by a bunch of JavaScript. I can edit the HTML with any HTML editor – tried that with Kompozer and got span tags with wicket id’s doubled – :-( – back to coding the HTML by hand and the CSS also. – In GWT I was just coding the Java and that was fine, I liked that because I love Java (at least more over HTML and CSS). Unfortunately Wicket is not providing the same cool widget styles out of the box. Yes, I can do my own styles but I have to implement an application, style is secondary but my boss likes the cooler design of Ext JS or SmartGWT.
A friend of mine who goes with .NET asks me, if it is efficient using Java if I struggle around a long time finding an adequate framework. He is using ASPX as the only choice and is happy with it. But hell, I don’t want to go back to ASP times (as there is not that much change apart from having better core libraries). Just not having any other choice makes decision easier but is this putting the head into the sand avoiding to look at potential drawbacks of the approach.
So, but what the hack should I do now? – I already see in the glass sphere that most of you will tell me that it depends on my project what is best to use and on my personal favor.
I can understand that it depends what is best but I would prefer a framework that fits well for 90 % of the projects as I also do want to re-use elements from one project within another and do not want to need re-coding a bunch of things or – worse – trying to mix a lot of different frameworks together.
So I am really torn between the available options. Comparing with .NET I probably would go with JSP. Yes, that is easy and anyway I have to do my HTML and CSS (as in Wicket), so why bother – everything seems to be at least as good as ASPX. But this does not make me happy enough…
Comment by Martin Wildam — August 25, 2009 @ 5:29 pm
Ha, I just noticed that glassfish admiin console is JSF – is that why it is so damn slow?
Comment by Martin Wildam — August 25, 2009 @ 5:54 pm
@Martin:
In GWT you are not suppose to do real deployments, indeed that takes time. Instead you have a “hosted mode” where you see changes immediately. This will be even cooler with GWT 2.0 (to be out soon) since it will work as a plugin to real browsers rather than the current dedicated browser emulating application.
In ASPX you have code-behind, not really that different from JSF backing-beans. In short, .NET developers can be highly productive because they don’t have half the hassle we Java developers do where just agreeing on a logging framework can cause pain.
For simple yet highly scalable and stateless applications, there’s also the Jersey approach. You can use basic templating engines (JSTL/JSP, Velocity) and mix with JQuery. A little low-level, but extremely powerful and good for people lie me, who hate Java’s framework/complexity creep.
I can think of few things I desire as little as using JSF again.
Comment by Casper — August 25, 2009 @ 6:07 pm
I tried now decluttering my web projects, undeployed all the test applications and switched to Glassfish v3 where the admin console is much faster. Then tried to create a new web application using the recent JSF + IceFaces. And guess what: I ran into an error and my hello-world did not start up.
Searched the internet and guess what:
http://www.icefaces.org/JForum/posts/list/14029.page;jsessionid=7C93EA977BD04055CD9BD70A329980ED.jboss1#54456
That really sucks!
Comment by Martin Wildam — August 25, 2009 @ 6:33 pm
[...] werden einfach noch zu viele Projekte mit JSF umgesetzt. Ein zweites deutsches Buch sollte eigentlich Signal genug sein, dass Wicket eine ernst [...]
Pingback by Wicketbuch aus dem dpunkt Verlag | wicket praxis — October 19, 2009 @ 4:45 pm
…when I think of all the good times that’s been wasted using (Ice/Rich/etc.) Faces… argh! Never ever again – after months of suffering using IceFaces…
Comment by Steffen Schuler — October 23, 2009 @ 8:46 pm
Hi – check out my blog about JSF – you might find it interesting :D
Comment by Padcom — October 29, 2009 @ 3:00 pm
Yes, JSF sucks. We’ve been working with it in our Java shop for over a year now. JSF is filled with quirks and incompatibility issues. It’s overly complex for what it does. I mean, drawing some buttons on the screen should not be like writing an assembly language program. I’m also amazed by how Stone Age the tool sets are for developing JSF applications. I ultimately decided to avoid using JSF in a enterprise business application that I’m lead on. I very happy I did too, because other projects in our shop did go with JSF … and are now running into huge cost and time overruns. Aside from this initial cost, I think JSF will add enormous long term maintenance costs to these other projects too. Customers are not going to be happy. In contrast, I started playing around with Adobe Flex the other day. It was so intuitive that within a few hours I building all sorts of commercially useful web 2.0 stuff. Really love the way Adobe has separated development from design, with great cooperative tool sets for both coders and graphics designers. JSF seems stuck in the 1990s as far as design flow goes. To summarize: JSF is like a dog turd on the sidewalk … don’t step in it!
Comment by Roberto — November 15, 2009 @ 8:47 am