JSF sucks
May 15, 2009 272 Comments
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.
Update: [2010-01-23] – Ed Burns, co-spec lead for JSF has just posted a detailed response to this blog post here:
A Response to Peter Thomas’s JSF Critical Screed
Readers are encouraged to also read the other side of the argument there and form their own conclusions.
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 1:
[2009-07-27] U, I and JSF – still painful after all these years – detailed article by Karl Banke. His conclusion:
[..] it is not a proper component framework, let alone a complete one. It is intrinsically over engineered, yet critically underspecified. As such, it can serve as a powerful basis for a real component framework. Because of the critical parts missing it is essentially impossible to mix JSF components from various providers without including a lot of overhead and loosing a lot of consistency. Frameworks like JSF should essentially make easy things easy and hard things possible. Yet JSF’s standard components, even in JSF 2.0, fail to deliver basic One-O-One web application features from 10 years ago. It is a remarkably complex specification that delivers pretty much nothing out of the box.
[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.
[2010-01-29] What’s new in Alfresco Enterprise 3.2? – some insights into why popular open-source ECM vendor Alfresco is dropping JSF in favor of a more Web 2.0 oriented approach:
Alfresco has been fairly open with the fact that their ‘Explorer’ client which is based on JSF technology is no longer being actively developed. While JSF is still around and actively used at a lot of places, it is a ‘heavier’ technology compared to a lot of whiz-bang Web 2.0 stuff. Alfresco is now investing development cycles in Alfresco Share.
Update 2:
[2010-09-09] RichFaces 4.0.0 Release Plan Updated – the long awaited release of RichFaces 4.0 final (which is supposed to support JSF 2.0) is further delayed to Feb 2011 because of “issues in the JSF specification”. Note that as of September 2010, only ONE production ready JSF 2.0 component library exists. The JSF 2.0 spec was approved well over a year back (May 2009) and was available in a draft form much earlier as is typical in the JCP.
We had hoped to get the final release of 4.0 out before the end of the year, but as mentioned previously we have run into various hurdles: These include identifying issues in the JSF 2 specification, and implementations (JSF RI, MyFaces).
[2010-10-16] RE: Moving from Spring to Java EE 6: The Age of Frameworks is Over – Matt Raible’s observations on “standards” vs frameworks:
Another reason I don’t like JSF: there’s very few developers in the wild happy with it. The major promoters of JSF are book authors, trainers, Java EE Vendors and MyFaces developers. Whenever I speak at conferences, I ask folks to raise their hands for the various web frameworks they’re using. I always ask the JSF users to keep their hands up if they like it. Rarely do they stay up.
Update 3:
[2010-10-22] Java EE, Spring, and why I care – a rant on Java EE vendor FUD by Papick G. Taboada:
Take a look at JSF. JSF is obligatory part of a full stack application server, but JSF gives you nothing. Again, you have a component model, and each vendor will provide the required runtime API. But you won‘t be happy with that, you will need a JSF library like RichFaces, ICEFaces, PrimeFaces, MyFaces, etc.
Take a good look at those. You will realize that, once you start using JSF, you are not standard anymore, you are bound to the JSF library vendor. The programming models for the components are different, the tags have different name. Switching or mixing JSF library ranges from very hard to impossible. So what good is the JSF standard for? Why is RichFaces for JSF 2.0 taking so long and how many people are developing it? Will it be there tomorrow? Will it be continued? JSF surely, but RichFaces, ICEFaces? Who can assure that?
[2010-10-26] JSF Expert Group Disbanded With No Successor JSR – pretty damning when folks outside of Sun / Oracle who have been trying heroically to fix JSF and rally the community – say that they have almost given up. If you thought that the JSF spec would get any better in terms of reducing the need for vendor-specific and proprietary extensions, think again.
According to Balunas, the expert group was still very active in their communication and development, and he doesn’t believe that dissolution of the group was necessary. He says that it will now be “very difficult” to continue supporting the Java Server Faces specification without an official JSF and EG in the JCP, mainly because there are no longer intellectual property and governance guarantees involved in JSF development if there is no current or successor JSR for JSF.
Update 4:
[2010-11-18] “I hate JSF with a passion” – James Gosling speaking at a Silicon Valley JUG event, skip to 47 minutes into the video below or use this direct link: http://www.youtube.com/watch?v=9ei-rbULWoA#t=47m
I hate JSF with a passion. And JSF was done, you know, there are a few things that were done for, I don’t know whether they were stupid reasons, they’re just, it’s just the way the world is, so, Microsoft had this thing called ASF which was angle brackets and percent signs with BASIC code there, then they are [gestures] “in-between”, right, and they go on a marketing campaign saying, “this is the greatest thing since sliced bread”, they get all the journalists to go, “ohh, that’s the greatest thing since sliced bread”, they come to us and they say, “ooh, angle brackets and percent signs and code in between, isn’t that the greatest thing since sliced bread?” What’s your answer to that? And if your answer is “that’s stupid – you know, there’s a better way to do that”, the press by and large can’t parse your sentences. And so we did do JSF as basically a clone to ASF just because it was easier to explain to the press. And then it wouldn’t die.
Update 5:
[2016-06-01] ThoughtWorks on JSF: “We […] are recommending that you avoid this technology”
About Peter Thomas
Incremental Operations 
Pingback: Valuable Internet Information » JSF sucks
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?
My personal favorites are wicket or struts 2
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.
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.
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”.
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.
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
Wicket or GWT. Both known to cater to Java programmers by favoring statically typed code over markup.
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.
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.
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.
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}.
Here is another:
http://www.jroller.com/javelotinfo/entry/prefer_rife_stripes_wicket_to
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.
>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…
>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.
>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.
I don’t consider it a “pretty good meta-framework” so long as creation of custom components remains laborious.
Wrong post!
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.
@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 !!
@Peter Thomas: completely false. JSF lifecycle and other stuff can be overwritten or decorated in a standard and portable way.
@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 !
@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?
>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 ;)
@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
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
@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 :-)
@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.
Wonderful. That qualifies as “half-baked” in my book :)
Wow, please don’t ever stop evangelizing JSF. Okay?
Heh. Matt Raible tweeted this as a Quote Of The Day:
I added this to the post. Thanks !
@ 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
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.
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…
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.
>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.
@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!
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.
I believe many people just left this page incompletely read due to sorting of the links. Please invert the order.
@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.
>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.
Please give a proof of the fact the Facelets is only a workaround and can’t give us UI generalization.
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.
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.
>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?
>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.
Pingback: links for 2009-05-17 « sySolution
@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.
>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…
>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.
> 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.
>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?
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
henk, RTFM Facelets.
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.
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.
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.
@Vladimir
RTFM Facelets?
Read the f*cking manual Facelets?
Would you care to explain what that utterance is supposed to mean?
@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.
Pingback: Κριτική πάνω σε Java Server Faces « Java Hellenic User Group
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.
>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?
>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.
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.
“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.
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!
@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)
@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.
@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.
>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.
@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.
>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…
@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.
>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 ;)
> 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.
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)
@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?
Pingback: If you polish a turd, it will still be a turd « Wille Faler’s Buzzword Bingo
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.
>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.
@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.
@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.
@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.
@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?
@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.
>>“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.
>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.
Pingback: JSF sucks, Wicket rocks? « Paul Szulc’s Blog
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.
@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.
@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).
Pingback: JSF sucks ball! | petersteinberger.com
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.
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.)
>‘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.
@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.
Sorry I write it in a hurry. I mean I argue with JSF not for bashing for the sake of bashing.
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.)
>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].
@Alberto (comment #70)
Simple YES or NO question:
Is ICEFaces from a vendor ?
>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?
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.
Nope ! Did notice some problems with the new “threaded” comments feature of WordPress. Can you try re-posting ?
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.
@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.
> 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.
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.
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 :)
@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?
Peter Henk, I brought an url to the article and explained the context. You have to realize the problem on your own.
>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.
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.
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.
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.
@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.
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.
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.
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.
>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?
>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 ;)
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?
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…
>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.
>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.
@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.
@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.
Maybe it’s time for you to look at alternatives to JSF ? No harm trying.
@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.
@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.
@robin
You’re right about that attribute you mention, that would be a very valuable addition indeed.
@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
@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.
>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.
@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.
@ 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.
@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.
>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.
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
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.
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
@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’?
Thank you for your interesting article. Learned a lot new to subscribe to your news. I would wait for new articles. Good luck.
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.
Pingback: О JSF в негативе « Всячина
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…
Ha, I just noticed that glassfish admiin console is JSF – is that why it is so damn slow?
@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.
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!
Pingback: Wicketbuch aus dem dpunkt Verlag | wicket praxis
…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…
Hi – check out my blog about JSF – you might find it interesting :D
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!
a lot of interesting talk from developers and system architects… but not much from IT managers.
the reality is that when oracle comes and demos their adf extensions and tools… then IT managers are like “where do we sign”!
the fact that this thread alone mentions so many other frameworks is the reason that IT managers are at their wits end! maintaining flavor of the month frameworks is not in an IT managers best interests.
if jsf sucks… then thats too bad. as long as its supported by a vendors extensions and can be maintained by a large community of developers. if one thinks its costly to use then one should try supporting a myraid of systems all using a different framework!
@chuck
Probably the IT managers are all busy playing golf with oracle then, no surprise there.
Oh and maybe you should consider (or maybe already are) using Microsoft .NET or something, just one framework, perfect for IT managers. Life is good.
microsoft is definitely ahead with their rad tools… but they’re server/db offerings are not up to the quality of traditional unix/oracle sytsems.
again, i’m talking the environments that i work in… big E enterprise.
@chuck, oooh big E enterprise, why didn’t you say so before. Allow me to genuflect. Lowly developer folk like me have no place in these kinds of discussions ;)
Pingback: JSF Sucks – agreed! | it-fabrik blog
If you are interested in learning how JSF2 has overcome most of the problems described here, perhaps you should take a second look at it.
Yes, some people are being forced to use old versions of JSF that have known issues, but that’s why JSF2 is here, to fix the problems of the past.
http://www.javaserverfaces.org is the place to get started with JSF2, and to provide constructive feedback.
“… that’s why JSF2 is here, to fix the problems of the past.”
Well it’s better, but it doesn’t really address the emphasis on state-fullness. In that light, I’d still prefer Wicket.
… in case of IceFaces, the problem is not JSF itself, but the components developed by IceSoft… these are really unstable and it feels like developing web apps in 1999 :( be warned!
After a year with JSF I can only agree to the statement, that JAS adds ‘complexity while delivering nothing they can use’. Using Richfaces makes all worse, since RF is badly documented (if at all).
If you need a special functionality, just lok at the live demo of RF. If you don’t see this at 1st sight, it’s likely not available.
I have worked with RAP/qooxdoo (this is Eclipse RCP for the web)
and I’m stunned of how easy and reliable web components can be.
There were almost no issues on browser compatibility, you have nothing to do with AJAX, because
you develop only against the RCP model. The development process is much more productive.
Drop JSF, just drop it!
Pingback: Jacob Heric » Blog Archive » JSF, an RIA retrofit
Dear Mr. Thomas,
I have assembled a comprehensive response to your unprofessional and polemical screed. If you care to respond, I have posted it on my blog at http://weblogs.java.net/blog/edburns/archive/2010/01/22/response-peter-thomass-jsf-critical-screed
Yours sincerely,
Ed Burns JSF co-spec lead.
I’m getting 404 on that link though.
Yes, I am getting that too yet – although I already seen the article about two hours ago.
Sorry, I took it down to clean up the English some more. It’s back up now at
http://weblogs.java.net/blog/edburns/archive/2010/01/22/analysis-peter-thomass-jsf-critical-rant
Thanks Ed. I just posted a comment (first one) on your response at your blog.
– Peter
I have been using JSF and Spring Web Flow in a heavy project over the last year, since the customer demanded it. It has been “ok”, the application is pretty good, but JSF is rediculously bad in some cases. I can’t work in any kind of component orientation since JSF subclassing etc is so extremely complex and undocumented that we just gave it up. And the life-cycle/validation model is impossible in scenarios that are just a little bit more advanced then the most simple.
I would not choose JSF as a framework ever again, if I had a choice, but it is definately possible to make decent applications. It is just tedious and you have to come up with very weird solutions to bypass the lifecycle model.
Mr. Ed Burns, I don’t quite understand why you labeled Mr. Thomas blog as unprofessional. Perhaps you’re taking this blog personally. There are evidences that people are having a hard time using JSF and would prefer using other simpler frameworks to get the job done. Let’s admit that JSF is, by concept, a good framework but in practice the developers still need to do a lot of heavy lifting to get things done.
Unprofessional or not, Mr. Thomas is right. I’ve been burnt so bad by JSF that even though I’m told that 2.0 fixes a lot, I really don’t care – am not going to spend another minute with that ivory tower beast.
We evaluated JSF, Wicket and Click by building a small prototype which included a few db tables, simple forms, ORM and a facade.
Wicket – around 5 hours.
Click – around 4 hours.
JSF – Did not complete since it went past a day and we were caught in exception hell.
We’re now on JSF 2.0 and lately we have expended our team with a bunch of new developers.
When they initially heard that their new job involved working with JSF, some of them were quite upset. Comments like “Isn’t that this technology spawned by the devil himself?”, were not unheard of. One developer even threw a nasty fit and quitted on the spot, even though he later admitted in a talk with our manager that he had never used JSF before.
The rest somewhat grudgingly started building pages with JSF 2.0 and then somewhat funny happened…
Their resent and reluctance disappeared rapidly and within days they were building high quality UI designs and enjoyed doing it. All of them told me that they had been scared off by blogs and articles just like this. In their heads, JSF was already bad without them ever having tried it.
Especially in combination with CDI (especially for the conversation scope), EJB and JPA, complex things can be done very intuitively with a minimum amount of code. Specifically for JSF 2.0, not yet all component frameworks have adopted it yet (RichFaces, which we normally use, has only very recently released a beta), so JSF 2.0 is not yet recommended for all projects. Nevertheless, it can be used on its own already and it absolutely works great!
@henk: given the sheer quantity and kind of comments you posted here earlier, I am not surprised. Being such a hard-core JSF supporter, you must have whipped the hell outa those poor developers or something.
Okay. Just kidding.
If you (and your developers) are happy with JSF 2.0, well, good for you. I’m personally not really impressed by the current state of JSF 2.0 component availability, and as you have yourself noted – “JSF 2.0 is not yet recommended for all projects”.
Your full name is “Henk De Boer” right? The reason I ask is I’ve seen your comments elsewhere, such as under this article:
http://netbeans.dzone.com/articles/develop-java-ee-6-app-jsf2
Yes, that’s me. I thought you still remembered this from our somewhat lengthy discussion at dzone ;)
Indeed, JSF 2.0 component availability is quite low at the moment and everybody, including myself, is still learning about how to best use the new technology and how any new pitfalls should be avoided.
Even without the extra components being available, and even without extensive knowledge about it, we were still able to use JSF 2.0 successfully. I do have to add in all honesty that it concerns a rather new and not very large project. Naturally, using JSF 2.0 at this time for a large legacy project build on JSF 1.2 might be a somewhat different experience.
Our current plan is to strengthen our knowledge about JSF 2.0 on the small project and start migrating one of our larger apps to JSF 2.0 (and CDI/Java EE 6) later this year. The wait for us is primarily for JBoss AS 6 and Rich Faces.
So far working with JSF 2.0 has been nothing but a very pleasant experience. The API feels very mature and almost beyond expectation, all stability and load tests for our new project also pass with ease. The project is mainly done by a group of people inexperienced with JSF, although guided by an experienced JSF 1.x developer (me).
Pingback: Atanas Roussev – J2EE, Java Developer, UI Engineer, Resume – Vancouver » Blog Archive » Java web frameworks
We did a comparison of JSF 1.2 and Wicket and JSF won by a long shot. You have to understand that not all screens are simple like a login screen. If so, why even use Wicket, just use plain html.
The problem is screens like financial wokstation teller setups are complex. It took me roughly a day to convert from Struts to JSF 1.2/ICEfaces. I was even able to add a few nice AJAX/IceFaces components. Moreover, I was able to use Facelets that allowed me to template much of the boiler header and footer.
Wicket unfortunately, is cumbersome. It is extremely difficult to refactor from Struts, Javascript, and JSPs. First, forget prototyping. Wicket is not made for prototyping. Your html and Java code HAVE to match up or it won’t work. You have to start from scratch and slowly add your components. You also must be a HTML master. You get a tag out of place and you’ll spend an eternity looking for it.
I spent 3 days using Wicket and finally got it to work without any Javascript….just plain HTML. With JSF, I was able to add everything in the original screen (minus Struts crap no longer needed) and added a few nice components. I took an 1100 line JSP down to 350 lines nicely formatted.
True, Wicket does improve on that but you have to be patient and take your time adding one component at a time. If your web app is simple with few components, go for Wicket. For complex Java Enterprise applications using XML, Web Services, heavy user interaction, massive database interdependencies, try JSF and ICEfaces or RichFaces.
henk,
That’s true for any framework upgrade. I remember the days when we were using Struts 1.0 and then the new Struts came out. JSF 2.0 really is a nice framework and will get better. It has full backing from IBM, Oracle, ICEFaces, RichFaces, MyFaces, and I don’t know for sure if Wicket will last. If you take the plunge on a 2 million line re-write and Wicket dies, ouch. I don’t see that with JSF because JSF has slowly gotten better. From 1.1 to 2.0, it has gotten so much better.
Use Wicket, but I won’t. I doubt I’ll find many clients wanting Wicket skills vs JSF (or even Struts).
Hey, nobody ever said Wicket was designed for easy conversion from Struts! The easiest conversion from Struts is … to Struts itself — Instant Success with no work whatsoever!
The point is that Struts is a horrible way to work, so you would expect a difficult conversion from Struts to something that is radically different.
The one asking for good choices should read this article: http://www.dzone.com/links/for_the_love_of_vaadin_java_rias_done_right.html
jsf is over-engineered and try to eliminate the knowledge and skills that developers already have. it’s virtually unusable.
JSF, glassfish and those other XML masochist “solutions” are not java solutions…
Well… Check out my latest entry on http://ihatejsf.com about how “beautiful” the code in RichFaces is.
It’s scary that stuff like this gets promoted to anything else than trashcan!
@PJDEZ: I don’t know if you have noticed (probably not) but the way the web works is by using HTML, CSS and JavaScript for presentation and HTTP GET/POST/PUT/DELETE for transportation.
You say that one has to be master in HTML? No way!? Really??? So is it possible to write an entire application in Java without knowing the language?
The sooner one embraces the fact that the web is what it is and what it is not the better and easier to develop it further by any number of “those skilled CSS/JS/HTML guys” coming from all around the outside world (.NET, PHP, RoR, Grails and others).
You say that JSF won with Wicket? Well… that doesn’t surprise me. What does is that anyone wanted to do such a comparison. Why not simply compare the real stuff (RoR or Grails) with JSF?
I get it – JSF has those components of theirs, huge libraries… gorgeous looking controls… yeah.. did you try making it do what you want instead of settling with what has been given by default?
And skinning JSF is such a pain in the ass for anyone I will not even dive into it anymore.
Matthias Hryniszak: “I don’t know if you have noticed (probably not) but the way the web works is by using HTML, CSS and JavaScript for presentation and HTTP GET/POST/PUT/DELETE for transportation.”
Right. Just like computers in general are programmed via punched cards encoded with JCL, macros and assembly language.
hello,
tanks that you also linked (right at the top to the “response post” of Ed Burns.
Your information is valuable but it is also very interesting to read also pro pro statements for JSF.
I think I will defenitely give JSF 2.0 a try.
thanks
jens
i have had to endure a jsf (and richfaces) project… ugh, never again!
it is the worst experience of my life
Pingback: Why ASP.NET (webforms) Sucks. « <CharlieDigital />
Hello Peter,
I seem to recall you presented initially about Wicket at the Great Indian Developer Summit. Well, here’s a post about a JSF presentation at GIDS 2010.
http://softwaretechnology365.com/database/building-web-2-0-uis-with-jsf-realtime-updates-with-jsf-and-ajax-push-taught-at-gids-2010.html
I can’t help noticing that the post previous to the one you linked goes by the title “[Lindsay] Lohan media throng ready and in place“.
Looks more like an SEO / spam site to me. But thanks anyway Ed :P
While i agree that the initial learning curve for JSF is high, in my experience of developing skillrack.com, once we understand it offers ready to use components thanks to RichFaces, PrimeFaces and ofcourse OpenFaces. I also notice PrimeFaces owner Cagatay is rolling out features very fast that even people who where doubtful about JSF will start using it (I am not associated with any commercial aspect of PrimeFaces :) )
Whatever you say Karthikeyan. By the way, all the best with upgrading to JSF 2.0 :)
:) My opinion is JSF might have been bad earlier. But now at least we can make applications with reasonable ease (though issues are galore).
I’m trying to learn JSF but I’m feeling really lost in the complexity of its ecosystem. There are so many frameworks *Faces, which one should I learn ? It doesn’t look like a “ready to use” solution…
I have no problem learning new frameworks; I’ve used them since Struts1.0. Much like a web designer doesn’t need to know Java, I shouldn’t have to be bothered by a crappy FE technology like HTML. Heck, the way I see it, Wicket should generate the HTML content automatically since the Java class follows the HTML file. Now that would be cool if it could do that. Or hey, vice-versa.
I don’t find JSF that difficult to learn, but I agree 1.0 was very difficult to create new components. JSF 1.2 made things a little easier. About the worst thing going about JSF is getting it to work with application servers like BEA, OC4J, etc. It also tends to be quirky but nothing I couldn’t figure out. Not everyone is using JBoss and Tomcat. I haven’t tried JSF 2.0 because I’m busy learning Wicket and Flex. I have to learn Wicket for my job and I wanted to learn Flex for my wife’s print and binding company. I really like Flex and if they tweaked a few things there, adios web frameworks. I was amazed at how easy it is to create web pages and access Java resources. Like I said, tweak a few things (Validators, Formatters, and refactoring) and I won’t go back to any of them:-)
about matt’s hand raising trick: the quote only tells half of the story. The other half:
When asked who uses JSF, an overwhelming majority of people raise their hands (when asked who uses Wicket, typically nobody or at most a few people raise their hands).
Then Matt only asks the question about who likes it for JSF. We thus can’t compare the use / like ratio for the other frameworks. This seems to be intentional. With Spring MVC, the same percentage of hands will probably stay up after the “like” question.
Matt said many hands were raised to the question “Who uses JSF?” but few remained raised when asked, “How many of you like JSF?” Robert replied, “Then Matt only asks the question about who likes it for JSF. We thus can’t compare the use / like ratio for the other frameworks.”
Since few people are forced to use Wicket, I suspect it would not be fair even if asked (those who don’t like it don’t use it.). However, I have heard a great many Wicket users exclaim how much they LOVE using Wicket — which is not something I commonly hear about other web frameworks.
I can at least confirm from the people around me using Java, that everybody who uses Wicket, love it. And most of them used JSF before.
@fsilber
Right, so what does all of this prove?
That people like an underdog that they felt being their own choice, or that they like Wicket?
If I bring together all my friends who’ve chosen to use JSF and ask them whether they like it, you’ll see a perfect 1.0 use to like ratio.
This has very little to do with JSF and Wicket. If some technology becomes popular, there are bound to be people having to use it without haven choosen it. Invariable a lot of them will then say they don’t like said technology.
Additionally you have the problem of many programmers just hating everything. You sometimes wonder why they became programmers in the first place. The amount of programmers actually saying they like something may be fairly constant and relatively independent of whatever they are using.
Matt’s trick is that at first sight it seems like a simple “lots of people use JSF, small percentage actually likes it”, but it’s not as simple as that, not by a long shot!
many devs are forced to use jsf by some misguided architect or manager. probably because they read some article about it being some standard and architects love standard (so they dont have to think about or know about product before hand?)
Steven that’s rubbish. JSF is chosen because it’s one of the best frameworks and has lots of support and resources available.
In bigger teams, not everyone will have had a say on that, and therefor people think they hate it. If they would have been in the position to choose, they might have well use JSF as well and magically they would have liked it.
This is just how human psychology works. Choose a green background for your customer’s site and he wants red, but choose red and he wants green. It’s not about the better color, it’s about the feeling of being in control.
After 2 years of struggling with JSF crap we ported application to Wicket. Sometimes we think about GWT but when we hear about losing productivity in GWT projects we make sure we did right choice.
It is not difficult to guess that most JSF happy posts here are from people who don’t have much JSF experience not saying about Wicket or GWT.
Person who knows how OOD leverages software engineering can’t choose declarative UI frameworks. Choosing JSF is like acknowledgment of lack of OO knowledge and experience (It is known that in mature projects UI source code base is much large than service layer)
@ludo: do you really think the people complaining here are the only people who hate jsf?
i see jsf hate everywhere i go.
it’s a nightmare of enormous state use
@steven do you really think people praising here are the only people who love jsf?
I see JSF love everywhere I go.
It’s a dream come true and all the teams I spoke to using it are very productive with it.
I’ve been forced to do JSF for around a year. I’ve tried really hard to like it, embrace its potential and use it to create the project I was working on.
Here are the facts, you might not be aware of:
– I’ve spent more than a year in a team with 4 developers, 1 architect (that did nothing but break the code) and 2 QA. We went from 40% to about 50% of the complete project in that time.
– I’ve left the team because I felt I was less productive than using core technologies
– after additional 6 months of coding (to the day) they are still below 60% of the complete solution and work it’s not getting any better
– in this 6 months I’ve started from scratch and released 3 production versions of another app (in Grails) that I do in my new team. Up until last month I was the only developer in that project and it was not the only project I was working on.
– compared to analogous solution in one of the parts of the application the amount of code I’ve had to write was around 5-10% of what I’d have to endure in JSF
– integration with other frameworks (Quartz, Melody – just to name a few) was a no brainer – it just works.
Overall conclusion is that working in JSF is like digging a hole with hands in gloves that don’t fit. Doing the same in Grails and using core technologies (html, css and js) for everything else is like having a whole team working with highly efficient automated machines :)
Sometimes I think it’s just not fair for the guys that have to do JSF these days. Wake up, damn it! The world is moving forward and you’re learning vendor-specific framework that does nothing but hurt your productivity!
Me too hate JSF. Too much work for simple things. Things that can be done with soo little effort in e.g. struts2. LIke validation of multiple fields. In JSF you need a backing bean, hence extra config in faces-config. Then you need the backing bean class. Then sometimes you need an extra hidden field to trigger the validation of the multiple fields. Bwah! Terrible! Indeed, there are FAR better alternatives. People who are pro JSF are usually people who have not worked with anything else before. Respectfully, I ask you all to try other web frameworks. You’ll now feel irritated by my comments here but you might thank me if you follow my recommendations! Kind regards
@Matthias Hryniszak : You told my exact story. What you say is exactly how I see it. At my previous client they were suffering JSF too. It just did not run, it crawled sooo slowly! You know what happened? The company decided to move away completely from JAVA and go for .NET in the future, one of the reasons being because they felt progress was too slow… Of course that’s a conclusion based on stupidity: it is not JAVA, it is merely JSF but that’s how it looks to management, who don’t know about technical details… JSF is SOOO unproductive!
Here’s the deal: whenever JSF will take away your calm nature and if you’ll feel frustrated about the sole fact that you are bound to this piece of c***p go to http://ihatejsf.com and get it off your chest!
http://ihatejsf.com
Pingback: Confluence: EMS Online Product Development
Pingback: Confluence: EMS Online Product Development
After read JSF “keeps UI component state in server side”, 5 or so years ago, I stopped. period. Even not tried to write “Hello World!” page with it.
Keeping component state in server side is the one thing I would NOT hold against JSF. Keeping state in the server side is a key aspect of web security these days. Anything you keep on the client other than, say, cookies with encrypted values are subject to hacking.
Hello all,
I am still somewhat new to JSF and have started on a prototype application using JSF 2.0, CDI and the PrimeFaces 2.2RC1 component library.
What makes this a bad decision? I feel pretty productive using this combination. Am I missing something? Is something going to bite me as I get deeper into the development cycle that I am not aware of?
If not this combination then what would be a recommended UI toolset? I could use JQuery and such. The application I am developing does need a rich ui and possibly be able to extend out to iPhone and Android smart phones for some convenience functionality.
Thanks in advance.
John
Yes, if you don’t know how to program then you’ll never understand JSF. Just like every other framework it has its learning curves, but like most of the posts here, if you suck at programming and learning new things then stay away from JSF, and please stop programming too (your better off as a tester or analyst) It sh*tty developers that give frameworks a bad name!!! I see way too many people who think that just because they can put together a HTML page that that makes them a programmer. So if your a sh*ty programmer try .NET, it puts you in a very nice box, that has a nice drag and drop GUI that any moron with a computer can do! However if you are attempting to build a real (enterprise) application make sure you read this first:
http://blogs.computerworld.com/london_stock_exchange_suffers_net_crash
If your a good programmer and like flexibility… you will love JSF!!!!
@Joe
I would like to think all of this is built from experience. A shitty programmer cannot tell the difference between good and bad frameworks, and that is obviously you in this case.
It’s worth noting that from the context Gosling is giving, he’s not talking about JSF. He’s obviously talking about JSP since JSF doesn’t have the angle bracket/percent/code snippet syntax. He merely misspoke when citing the acronym. JSP was the response to ASP, not JSF.
Bunch of FUD still here…
Gosling obviously was misspeaking. This has been all over the net, but despite your many updates you ‘accidentally’ forgot to rectify this. It just would be too nice if he really meant that, wouldn’t it?
The expert group of JSF also has not been ‘dismantled’. Better yet, in the meantime there has been a JSF 2.1 spec update (small maintenance release) and a draft for JSF 2.2 with a very tight schedule has been submitted. If you follow the Mojarra mailinglists you’ll that actual implementation is well underway too.
And what about all these ‘production quality’ JSF 2.0 component libraries that supposedly weren’t there? Take a look again and you’ll notice there are many now, including RichFaces, PrimeFaces, Tomahawk and more. Does say something about the popularity of JSF, doesn’t it?
@John, most dev’s I know who used JSF were not using it by choice. It was usually pushed down upon them by some idiot architect who chose it because it’s “standard”.
@Steven
What do you propose? Let every developer in a team of 12 working on a single project each choose their own web framework? Now that’s crazy!
And who cares that JSF is a standard? It’s a pretty solid, powerful and easy to use framework. That’s all I need to know. If a developer doesn’t want to work with JSF, he’s free to try to get a job at one of the 10 places in the wirkd were wicket is supposedly used.
@John
I propose that Wicket be used by every developer who has the option. Then, the Java Enterprise standard should be modified to become like Wicket — just as EJB evolved to become much more like Spring with Hibernate!
Fsilber, you may propose what you want, but many will not agree with you.
EJB2 was broken, and yes thanks to Spring it got better. That was 2005. In 2011 Spring follows Java EE (type safe injection, no-XML).
JSF 1.1 was broken too. Ed Burns took over with 1.2 and it got a lot better. Now there’s 2.1 and JSF is one of, if not the best web framework. Wicket should take a look at JSF to see how things should really be done. Maybe more developers will use Wicket then.
For those who claim that JSF doesn’t suck, I have a simple question. Let’s say I have a web application with fifty pages. Each page displays a table of data from a different database query. The pages differ only in their titles, the number of columns in the table, and the table column headers.
Implementing this application in Wicket, the table component automatically adjusts the width of each column to be the larger of the column-header width and the widest width obtained from the data rows.
I created a table subclass and table-model implementation such that the number of columns and their names are derived from the JDBC ResultSet. The table model contains an abstract method that is intended to return the text of a database SELECT query as a string.
Every page in my application inherits from the base page and overrides a function that returns the page title and overrides the function in the table model to provide a string containing the SQL query. For each page, no further coding or configuration whatsoever is needed.
Can this be done in JSF? Or for each page would I have to hand-type the number of columns, their names, and perhaps their widths, page after page after page?
Pingback: Sobre JSF não prestar « Rodrigo Galba
Hi,
Ok JSF is not the answer for all use cases in the field of web deveploment and not also the best one but I think there are exist 4 reasons why people think JSF Sucks:
1. They didn’t understand it – may be it is to complex for them.
– If it is to complex then may be this guys better looking for an other job! because software developer is in most cases complex but I think web development isn’t it! Before i started to with Java EE I programming simulation and mobile system in C/C++ and assembler – this is complex! But if you want to be a web developer may be this is something for you: http://w3schools.com/
;-)
2. Political reasons: JSF is a Standard and not handle by a OpenSource community
-> Yes may be Oracle chuck away the existing Standards and everybody do what ever they want and nobody in the industry want to use Java EE anymore – good Idea guys.
3. There are disappointed because they think the JSF Standard implementation can handle all use cases of web development
– mmm the JSF Standard Impl. is not a complete web framework ok -> but this because there exist so a lot of extension component libraries like RichFaces/ICEFaces etc. and I never find frameworks that having such a powerfull integrated ajax architecure (PPR or D2D) like them.
4. It is to slow
– mm ok it is the same discussion if is Java in comparision to C is slow
My old Professor in Unversity said: Java Web Frameworks are design in this way that also housewifes can use it. When I hear it I think it was a Joke but when i read the comments over JSF on this page then I think he was right!!!!
So may be lovely housewifes (and so called programmers) go to H & M buy a new handbag stop programming and everything is fine!
Sorry for this but the most comments are not serious so I cannot be serious too!
Cheers
I looked at JSF recently to see what sort of a component they had for a table that would display the result of a SQL result set. The component I found required the user to encode details about each table column in XML. That sucks.
All the information needed is in the JDBC ResultSet, so I ought to be able to configure the table component to get the layout information from a Java bean. No way, the list of columns had to be hand-coded at design time. I sure don’t have this limit in Swing. Nor did I have a problem like this using Wicket.
Hi,
use the columns-component (RIchfaces or tomahawk myfaces) finish!
-> http://myfaces.apache.org/tomahawk-project/tomahawk12/tagdoc/t_columns.html
with this component there is no need to configure the number of columns!
Greetz
We’re a small, agile custom development shop that uses whatever tools let us get the job done most economically for our clients and profitably for us. These days, unless the gig requires a specifc technology suite (and we’ve used everything) that means using open source J2EE technology.
Frankly, I didn’t know there was a “debate” about JSF until today. And I wouldn’t have known (or cared), except that I spent the last few weeks trying to develop a relatively a small and straightfoward user interface using one of the JSF “value added” toolkits. It was my sheer level of frustration that led me to just Google “JSF sucks” for grins. And now I know I’m not alone
JSF sucks.
Only the very simplest parts of it work in any reliable way. The fancy stuff (and especially the value added libraries out there) only work for the most basic use cases. Try doing anything beyond the demos or putting the “components” together and the stuff breaks at every turn. The coding required to work around the lifecycle issues and just plain quirkiness tends to make your application one big, extremely fragile, hack. Getting answers to the most obvious questions on the forums results in frustration, or borderline abuse.
Now maybe I’m just running up against a bad implementation in the value added library I chose. But somehow I don’t think that’s the whole story. It looks to me like the basic technology platform is hopelessly complex and overengineered, which is the root of it’s unreliability. To be fair, JSF is a valiant attempt to provide a generalized solution to a complex problem, but it’s “engineered by committee” origins are all too apparent.
Going back to raw JSP/servlets is not an option, but I’ll be looking for something simpler and more reliable than JSF the next time I need to build a web UI.
Building web applications _is_ a complex problem. Starting with CGI or Servlets, everything coming from the browser is in the HTTPRequest object — a huge massive block of global data. Everything that goes to the browser in in the HTTPResponse object — another huge massive block of global data. Programming at this level is like going back to COBOL, in which all variables are of global scope! You cannot have a well-structured program unless you have a framework that gives you multiple, more narrowly scoped data to work with. Most web frameworks don’t do this, which is why, IMO, most web frameworks suck.
JSF tries to solve this problem, but it does so via components that are assembled in stupid SGML-based tag notations — XML and HTML — instead of a programming language. That makes their usage rigid and inflexible. (If XML were such a great way of specifying computer behavior, Java would be defined via an XML DTD and every Java source-code file would be an XML file).
The communication between logic embedded in these tag notations and things written in your programming language adds a MASSIVE level of complexity to the whole approach — a leaky abstraction, indeed.
If you want to build a Java web application in which the UI code executes on the client’s computer, use Webstart/Swing or use GWT. If you want the UI code to execute on the server, use Echo2 or Wicket. If you want to add a bit of dynamic behavior to a mostly static website, use one of the more conventional approaches, such as JSP/Struts.
great Article I too feel JSF is clumsy heavy and useless occupying unnecessary memory dangling objects , sessions and unproductive
@Mike Hutton
>Getting answers to the most obvious questions on the forums results in frustration, or borderline abuse.
Which forums did you try? I can highly recommend stackoverflow for asking JSF questions. There are some very knowledgeable JSF users there, e.g. BalusC.
>JSF tries to solve this problem, but it does so via components that are assembled in stupid SGML-based tag notations — XML and HTML — instead of a programming language.
This is not true at all! The JSF core framework fully abstracts from the way components are assembled. JSF views can be created in Java, but also in JavaFX and anything for which you can write a view declaration language. See this how to build views programmatically with Java: http://jdevelopment.nl/authoring-jsf-pages-pure-java/
>The communication between logic embedded in these tag notations and things written in your programming language adds a MASSIVE level of complexity to the whole approach — a leaky abstraction, indeed.
I’m not entirely sure what you mean here. Do you mean there is logic inside the tag implementations? If that’s what you mean, it’s also not true. The same site as above also has an example of what a component looks like: http://jdevelopment.nl/simple-java-based-jsf-custom-component/ The tag implementation is nothing more than declaring that the components exists. If you really wanted, you could build a tag handler in Facelets that indeed contains logic, but for 99.99999999% of the cases this is never needed.
If you use JSP it’s a slightly different story. Here a tag handler is mandatory, but the tag should not contain any logic and just delegate to the component (and even better yet, JSP should simply not be used for JSF).
OK, so let’s say I don’t want to create my view as an XML file; let’s say I want to create my view in Java. What book on JSF or Facelets tells me how to do this?
http://jdevelopment.nl/authoring-jsf-pages-pure-java/
But JSF is not designed to be extensible in Swing way like deriving MyCoolButton class and overriding onClick method. All wiring is done via expression language. All that is very frustrating.
@Joshua Collins
I just remembered one of the comments by “BalusC” I saw somewhere (just looked it up), here:
Ones who says “JSF sucks” are usually ones who started using it with some visual / drag’n’drop editor without having any solid background knowledge (especially JSP/Servlets).
Sorry, I don’t find such statements to be very knowledgeable. Actually the level of discourse in that thread (this used to be the Sun official forum for JSF) horrifies me in many ways. Looks like this is the “standard response” to any criticism of JSF, and here is another example. Although in that case, yes there is a lot of “knowledge” demonstrated, but really, it is knowledge of all the problems that JSF had in previous versions, which got fixed in the next version, and then more things got fixed in another version etc. etc. etc.
One of the points in this blog post, is that to be successful with JSF you need to be *expert* at it. As an example, look at this series of articles: Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude. The article talks about two *experienced* Java developers who implemented a JSF app and then realized performance was pathetic and then had to do all kinds of optimization. Read it and see.
Granted, stackoverflow is indispensable (for lots of stuff, not just JSF) , and BalusC is the most helpful and knowledgeable JSF contributor. It’s just that the kind of JSF questions that seem to get answered in the forums, stackoverflow included, are either concerned with relatively basic use cases, or impart some single use magic trick based on deep/broad knowledge of JSF.
The criticism that you need to be an “expert” in JSF to be successful is well deserved. Yes, anyone can create a simple form based screen scraping application using JSF in short order. Great, if you’re doing your homework for your undergraduate class. But not relevant to real world, where you’re probably using a third party extension library (with its own quirks and community) and trying to implement the kind of interactive user interfaces that are expected these days. That’s when you need extensive knowledge of how JSF works. Otherwise, you’re stuck with trial and error (can you say “attribute interaction Hell”?), debugging from the stone age, and yes, the forums, such as they are. Oh, and you can pay Oracle or your library developers big bucks for support.
@Wicket fan
>But JSF is not designed to be extensible in Swing way like deriving MyCoolButton class and overriding onClick method. All wiring is done via expression language. All that is very frustrating.
I don’t claim to be the absolute expert here, but I think this is not entirely correct.
Expression language can indeed be used to wire things together, but it’s not a living thing by itself. The EL can be used to instantiate a MethodExpression and the button component just invokes it. The code that does this invocation can be overriden.
Although MethodExpression comes from the javax.el package, I guess you could implement one that doesn’t use EL at all. After all, the semantics are just to invoke a method on something.
Then, there’s also a public void addActionListener(ActionListener listener) method, where ActionListener is a simple interface (a sub interface of the well known java.util.EventListener).
In a web environment, you often want to include some scoping information (does the action listener need to come from the request scope, view scope, session scope etc). That’s why EL is often preferred above a simple object pointer, but if the scope is supposed to be view scope I think you can simply use this pointer. Namely, only the component will reference it, and the component is by definition in view scope (view state actually).
@Peter
>Sorry, I don’t find such statements to be very knowledgeable.
I think that for almost any developer who posts on the web it’s possible to pick a single sentence and debate whether it’s knowledgeable or not. For someone who posts as much as BalusC there’s bound to be found something somewhere.
But my point was not that each and every utterance every made by him is a great demonstration of knowledge (that would be absurd really), but that the guy is obviously generally speaking a knowledgeable community member that seems to put a lot of energy into helping people. If you post a JSF question on stackoverflow, you’re very likely to get a good answer from him (but I don’t want to belittle any of the other JSF contributors on stackoverflow who also provide great answers).
>which got fixed in the next version, and then more things got fixed in another version etc. etc. etc.
Isn’t that true for all software? Seriously, who wants to use Hibernate 1.0 or Spring 1.0 these days?
The problems with early JSF were well known and your nice little collection summarizes them perfectly. JSF 1.0 was an abomination, so was 1.1. When Ed Burns took over with 1.2 things got better, but there wasn’t a whole lot of time to get everything fixed for Java EE 5. For Java EE 6, he and Roger Kitain listened extremely well to all problems people had with JSF and the focus was completely on fixing those. Ironically, I think you among others helped with that ;)
The result is that JSF 2.1 is an absolutely fine framework. Like everything it will continue to evolve, and like every piece of software known to man there are undoubtedly some bugs here and there, but overall there are absolutely no deep structural problems.
The fact that you haven’t added new problems to your blog since 2010-10 is telling. And the last two items of your update 3 are silly. The JSF EG has of course continued, in fact it’s more active than ever, and your last item should be removed. It’s well known James meant to say “JSP” and not “JSF”.
@Joshua
Disagree. No point debating this any more with you. Let’s just leave it at that.
Don’t tempt me :P
Seriously though, the fact that comments keep coming in on this blog post is “telling” enough for me.
Peter Thomas SUCKS!
Only basic knowlegment of the Servlet /JSP API and creator of the blog to make everything badly what he does not understand or can. Very Poor of you – may be it is better to create a blog on a scientific even and not on taverns level!
@Tommaz
Now there’s a good example of what I was talking about regarding “borderline abuse” :-)
@Peter
>Disagree. No point debating this any more with you. Let’s just leave it at that.
Maybe not with me, but in this blog you’ve taken it upon yourself to point out why JSF sucks. There’s a very handy collection here for JSF 1.x. But it’s outdated and you know it.
>Don’t tempt me :P
Please do. I’m sure the EG is monitoring your blog and I’m sure they’re willing to fix any serious defects if brought to their attention.
>Seriously though, the fact that comments keep coming in on this blog post is “telling” enough for me.
If you have a little experience with working with programmers, you know they are always complaining about everything. Be it GWT or Wicket, they cry that it sucks if something doesn’t work (most of the time because they are just ignorant, but occasionally because of real problems with the tech).
Since JSF is very widely used, more people are using it and thus for relatively more people something doesn’t work. There’s only a handful of people *really* using Wicket, so in absolute numbers there are just less people running into some problem. If Wicket was used as much as JSF there would be tons of blogs about how much it sucked, believe me ;)
@Joshua
Really not sure why you have to bring up Wicket. This blog post is about JSF. In fact I don’t use Wicket anymore.
EG monitoring my blog eh. Let’s see, the EG lead himself posted a blog entry in response here: An Analysis of Peter Thomas’s JSF Critical Rant.
IMHO that was thoroughly unprofessional and liberally indulged in thinly veiled character assassination, but anyway. If the lead of the JSF community behaves like this, the “borderline abuse” that others commenting here have observed in the JSF community, comes as no surprise.
So, the best the spec lead could do is post responses to the links dating up to 2007, conveniently ignoring all the remaining items. Just like you conveniently ignored the point (and link) I raised about having to be an *expert* in my previous comment (Sep 13).
Also worth noting is the fact that even after I commented, acknowledged, and *immediately* linked to the spec-lead’s response (updating the very top of this blog post), there has been no acknowledgement or link to my blog post from the other side. I guess the esteemed spec-lead really truly cares about (the lack of) my page rank. Oh noes :P
Peter, good story, but back to JSF. The claim that you have to be expert to use it is a little vague. I find JSF very easy to use, so can you substantiate your claim?
@Igor – See my comment from Sep 13. If you consider that as “vague” then I have nothing further to say.
>All wiring is done via expression language. All that is very frustrating.
There’s an update on the above mentioned blog that addresses exactly that issue: http://jdevelopment.nl/single-class-pure-java-jsf-application/
>>All wiring is done via expression language. All that is very frustrating.
>There’s an update on the above mentioned blog that addresses exactly that issue: http://jdevelopment.nl/single-class-pure-java-jsf-application/
No, I don’t buy it. Although it is doable I don’t like the result and the effort required to accomplish it.
> No, I don’t buy it. Although it is doable I don’t like the result and the effort required to accomplish it.
What effort do you mean? The way it’s demonstrated there looks rather simple to me. Just deploying a single class to a server and having a functional app is pretty minimal too.
@Peter
>Seriously though, the fact that comments keep coming in on this blog post is “telling” enough for me.
The result of this vote is “telling” enough for me:
http://it-republik.de/jaxenter/news/Und-das-populaerste-Webframework-ist…-060497.html
Hmmm, JSF is twice as popular as Wicket. Remember, the question here was what people actually liked. Perhaps not everyone is living in the past and heaps of people have discovered that JSF 2.0 is a really good web framework?
Then a bit longer back, but still rather recent there was another vote:
http://www.zeroturnaround.com/java-ee-productivity-report-2011/
Here we see a few of the same numbers, JSF ranked very high. Tapestry and Stripes very much at the bottom. GWT and Wicket somewhere in the middle.
I think this one is telling as well:
http://www.indeed.com/jobtrends/java+jsf%2C+java+wicket.html
Wicket is nothing but a small line on that graph compared to JSF.
And what about this one:
http://stackoverflow.com/questions/tagged/wicket
http://stackoverflow.com/questions/tagged/jsf-2.0%20or%20jsf
Currently only 721 Wicket questions vs 6949 JSF questions.
Seriously Peter, how can you can still claim JSF is hated and not much used, and Wicket so popular when the evidence so overwhelmingly proves you are wrong?
@Joshua – I never claimed anywhere that JSF is “not much used” and that “Wicket is so popular”. Peace.
Pingback: Shaun Abram » Blog Archive » JavaOne: Comparing Java Web Frameworks
everbody of you cries like a baby: “oh jsf sucks ohhhhh” … stop programming kiddies!
The problem is not JSF – The problem is Java!!! JAVA SUCKS.
Go and learn a real programming language… Java is sooo slow in comparision to a real higher programming language – it is more like a scripting language – without JNI – Java will be lost!
Lets cut the story short … for all of you who are cons for JSF … don’t use it, nobody is compeling you to use it … for all of you who are pro then use it.
If you ask me, I’ve used .net technology for 3 years and I found it, unchallenging, so easy to use and it just lacks what a real programmer needs … a real programmer needs challenging tasks.
So for those of you who don’t like JSF … just stick with the easy ones … don’t grow be a novice …
Java Server Faces the best web technology at this time. JSF 2.1 with pimefaces 3 very powerfull. We are developed many JSF application- all success. Who said what JSF is bad, do not know JSF spec.
JSF provide component controll MVC, any other framework like GWT generate components from Java class codes , instead JSF use his components and developer can write busness logic and not every time create buttons objects. JSF 2 have good performance, you can configure it cashe any level of web pages from 1 to billion. Validation, converters, messaging, view scope beans, interated ajax of JSF2.0 have not any alternaties at this time. I know a lot of java frameworks and can say JSF is the best.
@Peter I never had a chance to try out Wicket personally, I’m currently doing some research in purpose of selecting suitable webframework for an internal application engine. The aim is to use it as a templaing/tool suite, capable of creating blueprints for other projects. The other projects seem to share a bit of CRUD.flavour between each other.
I’ve read a lot of good things about Wicket, but I think I’ll be advocating the use of Play! and typesafe stack in general. Besides my views on functional approach (yep, heavily pro-functional) there is probably one special reason that pulls Wicket out of the ‘actually considered’ box. The reason is that Wicket is being marketed as a component framework, and that’s exactly what I’ve been told six years ago, when a person that was my superior back then, informed me about his ‘wise’ choice to go JSF way. I have a hard time expressing the deep hatred I’ve managed to develop towards JSF over the years.
Your blog post is touching the tip of an iceberg, what I’d say is that it gets way worse as things get more complicated. I can’t get it, how did Sun manage to do all these fantastic things, while simultaneously releasing the worst, ugliest software shamozols to reach spec status.
Best regards
Reblogged this on lava kafle kathmandu nepal.
My company’s Enterprise Architecture Group is standardizing approved tools and use of open source software. Wicket is rejected; IceFaces (a JSF implementation) is approved, so I am again trying to learn JSF.
I think one way to take this debate out of the religious sphere and into the scientific sphere is to discuss the extent to which use of a framework is consistent with Test Driven Design, Unit Testing — which motivate the consistent and uniform use of a Dependency Injection engine (e.g. Spring or Guice).
This has always been one of the key complaints about Java Enterprise Edition, and is probably the basis on which JSF 2 should be re-evaluated.
Every time I have to use JSF I feel like telling my client to get someone else. If feel like such a whore for agreeing to use it.
I’m now reading about JSF2. It seems like a huge improvement over JSF1. I’ll have to withold judgement until I learn just what is involved in creating custom components, composite components and dynamic tables and such (which were pretty easy in Wicket).
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
JSF is a terrible design by some people who had never actually built web apps using other technologies or techniques. I really hate JSF with a passion and have used it for a large project and it failed. It is too complicated, too cumbersome, mixes model with GUI code, terrible to debug and so on.
Take a minute and think about designing a large app like JIRA using JSF…….. now clean up all that vomit on your keyboard!
Dear JSF Haters,
Lol, before you begin to bash me, let me tell you my story, I have been in Software Development for close to 9 years and I have been using Java for the same x number of years as my Software Development experience. I’ve been to front and back end, to hell and back with JavaScripts and I have been using JSP, Servlets, Struts and JSF for lots of different times in my project.
To tell you honestly JSF is a Java’s best gift to man kind, why? because it makes your life easy and to those people complaining and saying that JSF is useless and consume a lot of effort and resources, please you don’t know JSF and you just simply don’t have effort to study it that’s why you are spending an awful lot of time complaining in this page.
Just so you know, JSF 2, Spring 3 and Hibernate 4 is a very very good combination mostly because of less configurations thanks to @Annotations. Why I love JSF? because there is no need for scriptlets e.g. if else and for statements, most of all no javascript headaches. These things goes to Struts as well but I love JSF more simply because I fell in love with component based frameworks and mind you those people who say JSF is slow simply don’t know what caching is all about or maybe they don’t know how to lazy load in Hibernate.
For those people who are thinking of using JSF and looking for components to leverage their project especially with using ajax based components can start by using either of the components below which can be used on top of JSF:
1. Primefaces
2. Richfaces
Here is a quick tutorial for JSF:
http://www.coreservlets.com/JSF-Tutorial/jsf2/
PS: For those JSF haters, get a life and grow up :P
Love,
ProJSF
I evaluated JSF 1 back in 2005 and concluded that it sucked. This year I looked again at JSF2.x and decided it was actually pretty good, at least compared with most web frameworks.
I was looking into translating a Wicket application into “standard” Java technology and the only thing I still haven’t figured out how to do in JSF is to replace a portion of the component tree with an arbitrary defined-at-runtime alternate subtree of components in response to a post-back.
(For example, suppose your page contains a table displaying the results of a query, and in the post-back the user has redefined the set of columns to be shown and the order in which they are to be shown. So in the post-back you need to replace your data table with a different dynamically-configured data table. The only think I can think to do in JSF is to re-build the _entire_ page from scratch on each post-back.)
Pingback: Confluence: Data
Pingback: Confluence: Advertising Infrastructure
Dear rockstarsouth21,
But it seems like all of your projects are server-side oriented. Lots of Web 2.0 developers want AJAX heavy applications with lots of DOM manipulation, or other fancy shmancy ideas. JSF simply does not work in those situations.
We used JSF along with RichFaces in 2005 for the development of Next Generation IP Address Management System at Boeing. Needless to say JSF is the web version of Swing and provides great UI components for rendering like DataTable, JTree along with Auto Completion and other great features of Richfaces/Ajax4JSF and ofcourse we used Facelets with JSF instead of JSP’s
If you are evaluating JSF then please just don’t go by blogs or comments , do yourself a favor by developing a quick Proof-Of-Concept with the features you needed in your application and if turns out to meet your requirements then just go for it i.e. fitness-for-the-purpose.
This is exactly what i did while working at Boeing.
Pingback: Confluence: Product Info
Pingback: JSF Sucks – JUGLviv
So what are the alternatives then ?
Add Primefaces on top of JSF and you have some of the best components to develop a web app.
I have not found something yet that can match Primefaces.
Just updated the blog post at the end with the ThoughtWorks Tech Radar opinion of JSF.
First time visiting your website, I like your blog!