Bruno Borges posted the "Top Ten Reasons I Don't Like JSF," offering these reasons along withe xplanations:

1. Extra step when defining a project's architecture
2. Fragmented Community
3. Fragmented Documentation
4. Component Incompatibility
5. Caveats on some scenarios because of different implementations
6. Designers and developers roles mixed
7. Does not improve usual web development process
8. Non-functional prototype
9. Performance
10. Web is fast, standards are slow

Interesting list, to say the least. It's wierd: if JSF were irrelevant as so many people say it is, fewer people would need to say it's irrelevant. But it also draws a lot of legitimate complaints.

Some of these complaints are related. For example, the fragmented community and documentation and caveats are all related to JSF being a specification and not a product. Different implementations are going to have different strengths because they're designed for different purposes.

And those different implementations aren't going to be able to share documentation.

That isn't to say JSF documents well - there's one book that I like about JSF, and it's ginormous, and even then it's unclear about some things. And the new JSF specification, well, its maddening to try to figure out how to do things with the new spec, which is supposed to have been designed to be easier to use.

The "Does not improve the usual web development process" basically focuses on template technologies like Wicket, which allow designers to literally write usable prototypes. I'm not sure this complaint is super-fair, because facelets do more or less allow designers to write stuff like this; it's a pity facelets isn't better-documented.

The benchmarking problem: how would you answer that, JSF people? Why is it so slow? Why is that acceptable?

Last thoughts: how would you address these issues with JSF? Could you make the same lists for other frameworks? how would they look? Would they be as legitimate?

I think Bruno is just another Wicket Weeny crying for attention and being mad that JSF not Wicket became so popular.

Yes, because clearly anyone who likes Wicket is a "weeney" and couldn't possible have valid criticisms of JSF.

Yes, because clearly anyone who likes Wicket is a "weeney" and couldn't possible have valid criticisms of JSF.

No, it's not that.

There are various ways to sincerely criticize a technique. True constructive criticism aims to make the tech and the overall development landscape a better place. You'll find this daily on the various JSF mailing lists. It comes in the form of bug reports, feature request and honest discussion.

But this 'criticism' uttered by the Wicket fans isn't criticism, it's blind hate and propaganda. How can criticism be valid when the facts are plain wrong or just too vaguely worded to show any insight of the criticizer?

How often do these hate lists contain nonsense like "there are too many incompatible JSF
implementations like Sun/Oracle JSF, RichFaces, MyFaces"?

What's up with that? How can you criticize JSF when you know so little about it that you just don't get the difference between a JSF implementation and a JSF component library? How serious would you take 'critic' that rants again there being too many Java implementations like the Sun/Oracle JDK, Commons-collections, Quartz and the IBM JDK. Seriously!?

And what about the nonsense about JSF being only about state? Or only being about POST? This is clearly not true. It's like saying Java can only handle unicode and no other character set. It's simply not true. Yet Wicket fans keep putting this in their hate lists. They don't seem to care about whether their items are true or valid, every item on the list is one, right?

In particular they typically like posting outdated information. JSF 1.0 had problems. Real problems. But how long ago has this been? How is that still relevant? Who still complains that Java is bad because it's a purely interpreted language? We have hot spot for ages now. Purely interpreted execution is so long behind us that it's completely not relevant anymore.

All this gives me too the strong feeling this 'criticism' is barely about real users being genuinely displeased by JSF, but about Wicket zealots being shocked by the fact their perfect framework is used so little in practice.

For the record, I really like JSF, but I don't think it's perfect. There still is a lot to improve, just see the long list of things being considered for JSF 2.1. But these hate lists... they are just WAY too over the top to be taken seriously if you ask me.

 

I'd have to agree that there looks to be several inconsistent statements in the authors Top 10 Rant.  

But you have been equally guilty of doing the same.  You haven't actually refuted more than a few of the 10 issues he mentioned in his post.  For instance, how long ago was 1.0?  last December was when I believe JSF 2.0 was released.  A year is NOT a long time to forget about the past ills.  How many companies still use JDK 1.4?

Most of your post seems to be attacking the "Wicket" crowd for blasting your chosen framework.  So it seems that you could have added to the technical landscape but you chose instead to sound like a JSF zealot attempting to smack down the Wicket community.  Pretty funny actually.

Wicket isn't perfect, but for a framework that wasn't given it's blessing by the company who wrote Java, and corporate backing by companies like IBM who have a habit of pushing a technology during their "consulting" ... they've done a pretty damn good job.

And for the record, I am a Wicket fan, I give conference talks about it often.  But I also have an affinity for Grails, GWT, Django, and RoR when I'm feeling like a high-school kid.

To our success!

But you have been equally guilty of doing the same.  You haven't actually refuted more than a few of the 10 issues he mentioned in his post.

I know, but the post was getting pretty long already. Didn't want to push it.

 For instance, how long ago was 1.0?  last December was when I believe JSF 2.0 was released.

No, last December was the release of the overall Java EE 6 platform, which included JSF 2.0. JSF 2.0 itself is from June 2009. A quick glance on the JSF wikipedia page will learn you this ;) http://en.wikipedia.org/wiki/JavaServer_Faces Also, with 1.0 I actually referred to 1.0 not 1.x. 1.0 is from 2004.

 A year is NOT a long time to forget about the past ills.

I'm not 100% sure about this. Of course it's not 1 year but 1 and a half. Okay, big difference. But there's also a little irony here. One of the arguments is that JSF (core) moves too slow. If you look at the history the time between releases is 2 years and 3 years (1.1 -> 1.2 -> 2.0). The argument is thus that 2 and 3 years are too long. On the other hand however, if I mentioned in the past that JSF 1.2 had already been out for 3 years (in reaction to the content weaving problems that 1.1 had), then suddenly 3 years wasn't long at all.

 How many companies still use JDK 1.4?

It's another debate really, but the short answer: surprisingly few. It's a bit of an urban myth that the majority of big enterprises are still on 1.4, while in reality 1.4 has been EOL'ed a LONG time ago and big enterprises don't like running on EOL stuff.

Most of your post seems to be attacking the "Wicket" crowd for blasting your chosen framework.  So it seems that you could have added to the technical landscape but you chose instead to sound like a JSF zealot attempting to smack down the Wicket community.  Pretty funny actually.

Maybe it is. Sometimes giving one a taste of their own medicine is the best rebuke.

... they've done a pretty damn good job.

Technology wise they did. It's just that the adoption rate remains low. We actually tried Wicket and I liked it, but it's just hard to find skilled people for. I know the mantra that one is able to learn Wicket in a few hours at the most, but that's not the same as having deep knowledge and knowing about all or most of the intricate pitfalls that every framework has.

To our success!

Amen to that! :)

This is the second of two articles today that demonstrate a largely emotional, as opposed to factual, basis for hatred of a technology.  When Gosling was caught on video saying he hates JSF "with a passion", it got massively tweeted and retweeted.  However, actually watching the video would lead the observent viewer to a different conclusion: Gosling momentarily confused JSF with JSP (talking about angle brackets with code snippets and how it was a copy of Microsoft "ASF"), and based on his description, it's JSP he hates with a passion.

In this particular blogger's case, most of his list can be chalked up to 1) confusing what constitutes an implementation vs. a component library, and 2) not liking that the different component libraries aren't compatible. The points lack strong rationale.  The big one that I agree with is that the spec isn't improving fast enough -- Sun had been keeping a fairly good pace, but it has become almost glacial now that Oracle's in control.

As far as speed goes, I didn't find any recent articles with enough facts to support the assertion that JSF is a slow, bloated pig. I saw articles from 2009 that showed Wicket and Tapestry being faster, but JSF wasn't far enough behind to be considered slow.

JSF is clearly the product of corporate interests over just the technology. It needed to be backwards compatible with JSP, familiar to Struts, suitable for tooling, an alternative to ASP.NET (which works quite similar). At least, that's what it looks like to me. At the time (still in fact) I was very sad, particularly right after the whole (and similar) EJB debacle because here you got this good language with an awesome environment, and the companies who really could've lifted the Java ecosystem to the next level, but instead damaged it to the point where Java got the reputation for being only for soul-less 'corporate developers' and wizard jockies. Most of the Wicket developers - and I bet most of the developers of lots of other Java web frameworks - got involved *because* JSF was such a dissapointment, not the other way around.

I dislike too JSF, but I'm a fan of Wicket.

I think that the state-of-art for web frameworks is Zk, but this is only my opionion...

...returning to JSF I tried both: RichFaces and ICEFaces, I found both very slow, and I wasted many time to start up the project and make some simple pages.

Moreover, I tried to use Jboss Seam, and it was to me too complicated and , again, slow...much better SWF.

But, in conclusion, I think that the JSF technology is too complicated for the job it does, and the software that other companies build up around it is complicated too.

It is not a surprise that many Java developers abandoned Java for the simpler PHP.

I think that in Java we need more simplicity and less complicated framework for the web: the web is fast, but all this over engineered technologies are slow.

That's the problem!

But the way, JSF 2.0 are better, but still not enough.

The benchmarking problem: how would you answer that, JSF people? Why is it so slow? Why is that acceptable?

Well, let's first start to play the Devil's advocate here. Suppose it would indeed be slow. How much does this really matter? How much does the performance of the middle web layer really impacts the overall application performance?

We're not talking about the actual sockets and HTTP connections here of course. That's in the domain of the OS, Web Server and/or Servlet Container. JSF does nothing with these. Basically JSF is about the controller part and to put it bluntly the HTML generation part.

I'll hate myself in the morning for saying this, but get this. This is exactly the same domain in which PHP operates. As we know, out of all the server side frameworks available PHP is by far the slowest of the whole bunch. On several occasions it executes two orders of magnitude slower than Java code. Yet, despite all the slowness PHP is able to do well. Why is this?

The answer is that the majority of time spent executing a request is not really in the "control and HTML generation" parts. Establishing the low level connection always takes some fixed amount of time already and then the majority of the time always seems to be in the database queries and business logic. Both are basically independent of the web framework being used.

That said, is JSF really that slow? We build quite a lot of web applications and we don't really have any performance problems that can be attributed to the web layer really. On the contrary, the concept of state that's often an attack vector for JSF can actually help a lot with performance.

As one of the comments on the original article mentions; not all applications are running on large clusters serving thousands of users. We build a lot of in-house web applications as well, and they typically run on a single server for the AS. Those applications simply have state. There is no way around that. There are thus three options really:

1. Use a stateless share nothing architecture and retrieve all state afresh with each request
2. Keep the state in hidden encrypted fields, send them to the client, and decrypt them on postback
3. Keep the state in memory on the server

Each of these have their own cons and pros. The "stateless" architecture really isn't stateless in a lot of cases but just moves the burden of keeping state to the DB. This often means at the end of the request state has to be written to the DB and at the start it has to be retrieved from the DB. This too introduces latency. A pro is that it allows you to scale up your web serving nodes rather easily.

Keeping state in encrypted fields also allows you to scale rather easily, as the client becomes part of your distributed memory, but the obvious costs are in sending the state to the client and getting it back and the encryption/decryption or even just encoding/decoding can be rather hard on the CPU.

Finally keeping state in memory has the advantage that a lot of data is right there where it's needed after the postback. No expensive encoding/decoding and roundtrips to the DB are necessary. The disadvantage is that if you have many users that don't do much, this will rapidly eats away your server's memory.

JSF is thought to always force the user into the last model, but this is not true. By default the second one is transparently supported as well (it's a switch) and the first model is also supported. It must be said that the first model requires you to take greater care in choosing your components, but it really is supported. We have for instance built a public kind of FAQ site years ago, when we weren't even that experienced with JSF and it was completely stateless. Binding GET parameters to backing beans has been supported for as long as I know in JSF and JSF 2.0 vastly improved this support.

Depending on the use case, the usage of state in JSF can really speed up the application. We use the (CDI) conversation scope a lot in intranet apps and this prevents a lot of calls to the DB, in effect greatly increasing the overall performance. In that case JSF absolutely does perform way better.

I would be interested in seeing real benchmarks though. (not the ones produced by Peter Thomas were no matter the setting and the competition Wicket always wins for some reason or the other.)

 

 

Each of these have their own cons and pros. The "stateless" architecture really isn't stateless in a lot of cases but just moves the burden of keeping state to the DB. This often means at the end of the request state has to be written to the DB and at the start it has to be retrieved from the DB. This too introduces latency. A pro is that it allows you to scale up your web serving nodes rather easily.

Keeping state in encrypted fields also allows you to scale rather easily, as the client becomes part of your distributed memory, but the obvious costs are in sending the state to the client and getting it back and the encryption/decryption or even just encoding/decoding can be rather hard on the CPU.

)

 

This has really nothing to do with the JSF argument here, but....I don't really agree about your stateless arguments.  The browser, with Javascript, is now a thick-rich client that can hold state locally on the browser.  Since a lot of processing can be done locally, the serialization overhead is pretty much offset by not having to go to the server to get the next/previous page, or to process information for you.  Also, IMO and experience from deploying fat clients in the mid-90s, this CPU hit you talk about for serialization is generally not the issue, the issue is generally I/O: network or DB.

 

This has really nothing to do with the JSF argument here

I agree with you. The argument itself holds for pretty much every web environment, be it Java with any of its numerous frameworks, ASP.NET, PHP, etc...

Just mentioned it because the story about "state" is most typically associated with JSF being slow. If there is any other particular cause I would love to hear it.

 

, but....I don't really agree about your stateless arguments.  The browser, with Javascript, is now a thick-rich client that can hold state locally on the browser.  Since a lot of processing can be done locally, the serialization overhead is pretty much offset by not having to go to the server to get the next/previous page,

Yes, this is indeed a good way. We have implemented a table component (JSF serverside, JQuery clientside) where multiple pages are sent to the client. The client can instantly go to the next page and when he's 1 page from the edge of the 'buffer', the client-code transparently fetches the next X pages via AJAX. I do have to add that we also (optionally) keep a somewhat larger buffer on the server side that works in the same way. Many AJAX requests can therefor directly be satisfied from the server side buffer, and only occasionally a new round trip to the DB is required.

or to process information for you. 

I'm a little less convinced about this. Yes, sometimes this is handy and helps to speed up things, but many of our clients have intricate business rules in EJBs. It would be rather undesirable to compile these rules into JS and send them to the client (if this would even be possible at all, since a number of them make calls to protected external services etc). I do agree that in some situations the simple state that the JSF backing bean now holds could be offloaded to the client.

Also, IMO and experience from deploying fat clients in the mid-90s,

Fat clients are actually still a nice alternative indeed. Yes, theoretically JS could be used to create those fat clients. I used to be very uncomfortable with this, as JS used to be a VERY POOR environment. Lately with advances in the language, major advances in the VM that executes JS and excellent libraries it has become a better place. 

this CPU hit you talk about for serialization is generally not the issue, the issue is generally I/O: network or DB.

yes, it's mostly the network overhead and the DB. But the serialization costs are there, especially when using encryption. Which lots of AJAX requests and state on client we definitely saw a noticeable increase in CPU usage. I can't say it was really problematic for us, but just that it was there ;)

Web is fast, standards are slow

To start with, the author first compares JPA/Hibernate to abstracting from SQL and agrees with that abstraction since SQL is from 1974. It seems to imply that the author thinks SQL has never been changed one bit since 1974. Awkward really...
Then he moves on to the web. He first agrees that HTML is old too, but abstracting from it is now wrong because HTML has an "unlimited scope"??? I'm not even sure what that means. This whole first paragraph is just wasted on me. Maybe the author has a point somewhere but I'm not seeing it.
Then we get more or less to the meat of the section: JSF 2 is too late and thanks to the JCP the improvements happen slowly.
As I commented above, the gap between major JSF releases has been 2 respectively 3 years. This does sound slow, doesn't it? Well, it's only half of the story. JSF has been build as a stable core upon which third party extensions, component sets and even frameworks can innovate at their own pace!
This is a particular point of JSF that seems to be completely lost on the author. Not surprisingly, as he doesn't seem to know the difference between a JSF implementation and a JSF component set earlier in the article.
Almost always you don't want a core to change rapidly underneath you. It's pretty okay that's it's stable for 2 years. Meanwhile, innovative component sets like PrimeFaces and OpenFaces keep pushing out releases with amazing components at a very fast pace.
After some time, the JCP takes a look at what actually works and standardizes that. It's NOT a question of standardizing unproven stuff upfront and then having we as Java developers deal with that for 3 lonely years. It's not at all like that, but it's an image the Wicket fans seem all too happy to paint.

All I know is that I was infinitely more productive writing native UIs 15 years ago with VB and VC++ compared to any web technology we have today in Java, PHP, Perl, Python, whatever...

All I know is that I was infinitely more productive writing native UIs 15 years ago with VB and VC++ 

Agree for VB, not for VC++. Today, Qt are very productive.

But Java is far the most productive, amusing and complete programming environment.

In Java there are many Web framework fast and productive, the most difficult think to do is to choice the best one.

IMHO, JSF is not the best one.

 

All I know is that I was infinitely more productive writing native UIs 15 years ago with VB and VC++ compared to any web technology we have today in Java, PHP, Perl, Python, whatever...

Yeah, right you are! Well, except for VB, I could never be productive with that. But I did VC++ with MFC on Windows using VS5 and VS6 and was VERY productive with that.

If I ever was appalled by anything then it was the way of working in the early days of web programming: JSP pages with HTML mixed with scriptlets. *shudder* Struts, JSF 1.0 and several other web frameworks of the time promised the world but delivered almost nothing. Last few things have gotten much better and I honestly think JSF 2.0 is one of the best out there, but it still does not compare to mid 90-ties native UIs. Go figure!

 

True, but....developing single user, single OS, systems with only a shared database is a much simpler thing to do than a multi-user, multi-tiered application which runs on a multitude of platforms.  I have been using GWT on serveral projects and it is very close to the "old" level of productivity.  JSF and its ilk are way over engineered and needlessly complex.

All I know is that I was infinitely more productive writing native UIs 15 years ago with VB and VC++ compared to any web technology we have today in Java, PHP, Perl, Python, whatever...

Agreed but this mainly due to the underlying technologies : generating everything on the server as with JSF has never made any sense from a architectural point of view. It just wrong and force you to think in a very unnatural way. We were only doing it because asynchronous conversation between the browser and the server was not possible.

Now that it is possible, we face another problem : javascript sucks big time. Without a decent library (Dojo, Gwt, JQuery, ...), javascript development is so cumbersome that is almost impossible to produce a decent and portable Web site in a reasonable amount of time. Hope it gets fix in HTML 5+++.

JSF was made with the idea to enhance JSP capabilities with a new brand "face", with the emergence of AJAX technology new GUI frameworks like zk and gwt show up and make  JSF just an I-will-think-about-it choice.

Top Ten Reaons I Don't Like Top Ten Lists

1. It's lame

2. It's wrong

3. It's gay

4. It's distracting

5. It's useless

6. It's boring

7. It's biased

8. It's egotistical

9. It's dorky

10. It makes me waste time writing another Top Ten Reasons list

Hey, that's exactly the list I was going to write to express my hatred for Wicket!

What a coincidence that is!

1. Extra step when defining a project's architecture
2. Fragmented Community
3. Fragmented Documentation
4. Component Incompatibility
5. Caveats on some scenarios because of different implementations
6. Designers and developers roles mixed
7. Does not improve usual web development process
8. Non-functional prototype
9. Performance
10. Web is fast, standards are slow

How would you address these issues with JSF? Could you make the same lists for other frameworks? how would they look? Would they be as legitimate?

First, apologies for the long post. :-) Before I respond to the author's points, I would like to say I have been so busy doing JSF development the past few years that I have not kept up with the other web frameworks like Wicket, Tapestry, Struts 2, Spring MVC, Stripes, etc. so I have no basis (or need) for comparison. That said, I find it interesting that JSF, fairly or unfairly, is often the subject of criticism in the web frameworks arena.

Here's my 2 cents. (Disclaimer: I am an independent JSF consultant, JSF trainer, public speaker, author on JSF, and my company builds JSF development tools.)

The author makes some valid points about JSF and I can understand where he is coming from.

1. Extra step when defining a project's architecture.

I'm not sure about this point. I agree with others on this thread; the author needs clarification on the difference between the JSF framework and JSF component libraries. To be fair, it's a jungle out there. It takes time and experience to learn the difference between Facelets, MyFaces, RichFaces, and so on. Like other web frameworks, JSF provides a familiar architecture that developers can build on. The more JSF projects you work on, the more familiar that architecture becomes and the easier it is to build JSF applications.

2. Fragmented Community.

Here the author is saying the JSF has no central community. (JSFCentral.com anyone?) He seems to dislike the idea of joining mailing lists, reading forums, and learning to use component libraries. Hey. That's ok. Some people prefer simplicity over choice. With JSF, you can choose between hundreds of UI components to build your project, and this can be overwhelming. Personally I think choice is a good thing. If you're willing to join the mailing lists and get involved in the community it can be a lot of fun.

3. Fragmented Documentation.

I agree with the author that documentation is not centralized, but there are an increasing number of books, tutorials, and reference material available on JSF. Once again the author is confusing the JSF framework and UI component libraries. It helps to have a high-level understanding of how these different technologies fit together. JSF is like a car; UI components are your power steering, V8 engine, heated seats, sunroof, etc.

4. Component incompatibility.

This is a valid point, and I'm glad the author acknowledges that JSF 2.0 is addressing the main interoperability concerns of JSF 1.x components, not the least of which was Ajax library conflicts. Using the car analogy, in practice JSF libraries are more like "conversion kits" that can substantially upgrade your vehicle. There is a certain amount of overlap here, especially when it comes to Ajax. Once again it helps to know your MyFaces Trinidad from your JBoss RichFaces and to understand when, where, why, and how you would use a particular component library and make an informed decision about the right combination of JSF technologies for your proejct.

5. Caveats on some scenarios because of different implementations.

Implementations of what? The two most popular JSF implementations, Apache MyFaces and Sun's JSF-RI (Mojarra), are largely interchangeable. So what we are talking about here is UI component library interoperability. Yes, it helps to know which libraries are compatible but this takes time and experience. Fortunately this is a road that many developers have travelled. It shouldn't be hard to get information and advice from... mailing lists and forums. :-)

6. Designers and developers roles mixed.

Actually, I see JSF as providing an ideal technology for UI designers and developers to work together. I think success in this area comes down to two things: a) having the right mix of talent and experience on a project, and b) having the right tools for the job. As an MVC framework JSF supports separation of concerns and UI design and application development roles can be divided along these lines. I see a lot of opportunity for collaboration between creative and technical people in a JSF environment.

7. Does not improve the usual web development process.

I'm glad the author mentions Facelets here because it does help a lot. JSF 2.0 is based on Facelets, and this is a good indication of where things are heading on the JSF roadmap. Facelets is a perfect alternative to JSP; no more scriptlets, no more spaghetti code, just clean and simple markup. You can author your pages in pure XHTML if you want, or you can use pure JSF markup. It's up to you.

8. Non-functional prototype

You can create non-functional prototypes with HTML and later add jsfc="..." to your HTML tags to convert a static mockup into a dynamic application. Also, prototyping applications requires more than just HTML mockups, e.g. UI design wireframes, UML diagrams, screenshots, etc., so its not resonable to expect a web framework to provide all of this.

9. Performance.

JSF can achieve very good performance and scalability in a clustered environment with caching enabled. Add JBoss Seam on the backend and you have the EJB3 container to help you manage server-side resources more efficiently.

10. Web is fast, standards are slow.

JSF is not an all-or-nothing proposition; you can still use jQuery or YUI or other Javascript libraries in your project. Web technlogies are constantly changing, and JSF is keeping pace. JSF integrates nicely with standard and cutting edge Java, web and RIA technologies such as CSS, XHTML, XML, RSS, REST, Ajax, Comet, Flash, HTML5, and more. The Ajax components in ICEfaces, PrimeFaces, RichFaces, and Trinidad have a lot to offer and there is some amazing work going on out there.

My advice to web developers considering JSF is to do your homework before you dive in. If you want to get some experience with JSF before you commit to overcoming the learning curve, definitely start with Facelets and get a feel for how simple JSF can be. As your knowledge and confidence increases you can explore other component libraries and frameworks that integrate with JSF.

I would start by learning how the standard UI components work, then trying out MyFaces Tomahawk to add some useful and interesting components to your projects. Due to its simplicity, Tomahawk is generally very good at integrating with other JSF libraries. When you want to add an Ajax library, there are many good choices, such as ICEfaces, JBoss RichFaces, MyFaces Trinidad, and PrimeFaces. Keep in mind that these libraries are not all compatible yet, so read the documentation carefully and if you have to go with one library pick the one that suits your project and go with it.

JSF is fun when things are working well. One area I think could really help is testing. There are a few unit testing frameworks out there for JSF (e.g. JSFUnit, Arquillian, and others) and these can really help kick start the development cycle. UI testing or functional testing is also important and Selenium is a great choice in this area.

Cheers,
Ian

--
Ian Hlavats
Author, JSF 1.2 Components (Packt)
JSFToolbox for Dreamweaver - www.jsftoolbox.com

 

Thanks for the interesting reply Ian! This must have taken you some time to write, but it's a good read ;) Hope it helps others too.

The two most popular JSF implementations, Apache MyFaces and Sun's JSF-RI (Mojarra), are largely interchangeable. 

The last time we tried that our project crashed for a whole week (it was a quite large code base...). After the architects finished adapting it all to the RI, it was impossible to switch it back.

Granted it wasn't coded according to the best practices or anything like that (we were quite unexperienced back then), but the point is that the two are not that interchangeable in practice (although in theory they should be).

I have been using Spring MVC after stuck with JSF 1.1-1.2 for a while.  Even thought Spring MVC 3.0 is almost perfect, I'm surprised with how JSF developed lately.

JSF 2.0 is clearly moving towards the direction the community is looking for, and so many components are available.

I'm not sure if anyone has used primefaces (based on JQuery UI), it is the best JSF component libraries I have ever seen.  Its look and feel feels better than RichFaces and IceFaces.  

Who says standards need to be slow? They define an API, that's it. Performance is an implementation matter, that has nothing to do with the standard per se. HTTP is also a standard, but who'd claim it is slow?

HTTP is a good keyword. The worst with JSF is that with its session- and POST-prone concepts it works completely against the concepts of the basis it pretends to support (and to facilitate). HTTP is stateless, and uses POST as "last exit".

JSF might be an application protocol that abuses HTTP, but please, don't call it a "web" framework.

-Jürg

HTTP is a good keyword. The worst with JSF is that with its session- and POST-prone concepts it works completely against the concepts of the basis it pretends to support (and to facilitate). HTTP is stateless, and uses POST as "last exit".

JSF DOES NOT and I repeat DOES NOT only only depend on sessions and POST.

That aside, POST is just as much as part of HTTP as GET. There is some insane thinking that the Web and HTTP should only be about GET, but as a matter of fact the Web has many faces. Static hypertext documents are very nicely handled via a stateless architecture and GET. Rich applications might use state and (AJAX based) POSTs. It depends.

Whatever your use case, JSF supports both GET and POST.

Why should GET only apply to static documents? Why should AJAX per se work with POSTs? What means the "Web has many faces"? It is exactly defined what the HTTP verbs are used for.

This just proves to me that the JSF community is so busy in dealing with the complexety and the caveats of its technology stack (e.g. life cycle, component compatibilities...) that it is miles away from what it actually deals with.

I will be ethernally graceful to the Allmighty that I don't need to deal anymore with this cumbersome technology that works largely against the well defined foundations of the HTTP stack.

Why should GET only apply to static documents? Why should AJAX per se work with POSTs? What means the "Web has many faces"?

I means the web is not ONLY about GET!!!

POST is a part of the web just as GET is. static documents are mostly or exclusively GET (hence the name "static document", but GET can of course be used for other resources. I never said AJAX exclusively uses POST, but it often does.

 

And again, and again and again. JSF SUPPORTS GET! Please, get this into your system. It's not a question of JSF = POST and WEB = GET therefore JSF != WEB. This is some kind of FUD you like to spread, or at least seem to imply, but it's just not true.

JSF = POST + GET

WEB = POST + GET

GET it?

This just proves to me that the JSF community is so busy in dealing with the complexety and the caveats of its technology stack (e.g. life cycle, component compatibilities...) that it is miles away from what it actually deals with.

It just proves to me that the Wicket community is so busy with spreading FUD about JSF and its supposed complexity that they actually forget to simply check their facts.

I will be ethernally graceful to the Allmighty that I don't need to deal anymore with this cumbersome technology that works largely against the well defined foundations of the HTTP stack.

Here you go again. JSF supports GET! POST DOES NOT go against the well defined foundation of the HTTP stack. How hard is this for you to understand?

 

My reply to original post: http://mkblog.exadel.com/2010/12/my-reply-to-top-10-reasons-why-i-don%E2%80%99t-like-jsf/

I think that all those frameworks will go away in favour of thin server architecture. At least view part of them. Replace them with JavaScript + AJAX + @Controllers on server side. It is easy to write tests to those parts(Have you tried to test JSF/JSP?) . Not mixed roles: Web Designer, Java Developer, great user experience , comparable to desktop applications.

Çini Silimi ve Karo Silimi i?lerine yo?unla?an firmamiz sizin için mermer ve zemin silimi i?lemlerini de yapmaktadir. Dizayn Restorasyon, Restorasyon Çini bak?m?, temizli?i ve beyazlat?lmasi i?lemleri yapilmaktadir.