1 2 Previous Next 20 Replies Latest reply on May 19, 2009 5:06 PM by vladimir.kovalyuk

    Reasons why not use JSF

    vladimir.kovalyuk
        • 1. Re: Reasons why not use JSF
          kukeltje.ronald.jbpm.org

          Articles from 2004? Comparing some new technology to an old one? Many issues are addressed in JSF2.0, so I would be really interested in a real comparison.

          • 2. Re: Reasons why not use JSF

            Well, I disagree, first, because the article has links to other articles that go from 2004 to 2009, and second because JSF 1.x  is still relevant and is still not relevant JSF2.0. Why? because Seam/Richfaces is not currently compatible with JSF 2.0.

            • 3. Re: Reasons why not use JSF
              gonorrhea

              JBoss 5.0.1.GA ships with this version of JSF:


              Implementation-Version: 1.2_10-b01-FCS


              So Francisco has a point.


              Final approval for JSF 2.0 is not even complete:


              http://jcp.org/en/jsr/detail?id=314


              But I'm looking forward to using it :)

              • 4. Re: Reasons why not use JSF
                vladimir.kovalyuk

                We just get used to read temporal lists that sorted in descending order. But the collection itself contains many helpful articles that might come in handy to them who already work with JSF and struggling with some holes.


                From my perspective JSF is not very good as a framework. Its design is a book how not to design applications. JSF 2.0 just tries to address some weaknesses but how it does makes me cry. I wrote on this forum about that.


                The declarative approach in UI design never works. You always will want to do more. Read about Gavin's proposals to JSF. And even don't think about subclassing. JSF is not capable.


                If you know that the project will survive two or three releases and will significally grow in functionality you should use GWT (for JS-enabled environments) or Wicket (for mixed or HTML only environments). You will save a half of money invested into your project.


                If you decided to use JSF you will once understand that implementing new requirements costs you as twice as it was one year ago. And stabilization stage lasts three months at the time it lasted one month a year ago. We all know what to do with that - use OOD, OOP, implement MVC or better DCI (java is not capable :) ), use test-driven process and so on. But it is impossible at all with JSF (even if possible it becomes a nightmare). JSF 2.0 address nothing in this respect.


                IMO it does not make sence to compare JSF vs Wicket and GWT. The result of comparison is obvious. If you have concerns - be honest with yourselves - most probably you know a few about those frameworks and OOD.


                I'm upset with the fact that JSF becomes so popular. It usually is chosen just because it is popular. I'd like to pay your attention to that it is not evidence to JSF maturity. From the other hand by choosing JSF you makes a clear evidence of your maturity :)

                • 5. Re: Reasons why not use JSF
                  demetrio812

                  Clearly a lot of people saying JSF is bad don't event know about it, I'm not referring to you but to some comment and all the votes to that article on DZone.


                  You say there are also new articles, it's true (at the end) but why talking about problem of the first JSF versions or problems that you can fix using facelets and seam? (that soon will become a standard too).


                  So if I want to speak about Java I have to talk about Java 1.0 too? or just about the latest versions?


                  I'm not saying JSF has no problem or it's the best framework (I don't like those kind of discussions) I'm just saying that it's not that bad as you (and others) say...


                  The problem of JSF is the learning curve but after you learned (and know very well the other related technologies like EJB, JPA, Seam, Facelets, RichFaces or ICEfaces) all is very fast to implement...


                  That's my point...


                  Demetrio

                  • 6. Re: Reasons why not use JSF
                    vladimir.kovalyuk

                    Demetrio, the problem of JSF 2.0 (and most probably 2.1 as well) is that it has several very bad architectural solutions that can't be fixed without breaking compatibility.


                    I tend to think that most people who defend JSF either has to defend the investments of their employer or don't have good JSF practice.


                    After we had moved to Wicket we encountered just one case when we had to work around the problem. And solution was found after less than half an hour just by reading the forum. When working with JSF 30% of our time was devoted to struggling with problems. Taking into account that productivity has rosen about 3 times I would say that JSF is nervously smokes aside watching how Wicket is good.


                    All those who use JSF are in stone age of software development. I were there. By giving up object oriented principles you will obtain all shit that development suffered with before inventing OO. Taking into account that UI code is a certain part of application (I used to think that it is not less than 50% including reports) I tend to think that people who decide to use JSF don't know well how, why and for what purpose OO was invented. For those web applications that don't need object oriented approach in UI Java technologies are overkill. New PHP suites better and costs cheaper.


                    JSF is a standard. Okay. When or where you're planning to switch JSF vendors? I understand it when people discuss payed RDBMS or Java application server. That servers are bought by client and your application have to work on them. What about JSF? Hibernate had always been a standard de-facto when we had entity beans. Now JSF/Wicket looks for me like EJB/Hibernate ORM that days.

                    • 7. Re: Reasons why not use JSF
                      arshadm

                      People keep taling in generalisations and claiming that JSF is rubbish and Wicket is the future. Can we have some concrete examples of where Wicket is superior, the only thing I can think of is that some things JSF makes looks like components when they are not (probably comes from old JSP days and jsp:include, et al).


                      Now, I have read Wicket in Action by Manning and I can't see where Wicket is so superior when you combine JSF/Facelets and Seam. Without Seam I would agree that JSF is a pain in the ass (with all that XML crud in components.xml and faces-config.xml, etc). But Seam solves most of those problems (and you can even use EJB's as form backing beans).


                      From, what I understand Wicket has a very similar pipeline to JSF in request processing (I mean you've got to parse, validate and update the model in every application).


                      How exactly do you use Seam managed persistence contexts in Wicket, it has no notion of conversation. Should you keep the entity manager open throughout the session? How do EJB's fit into Wicket? I couldn't find an answer to these two questions thereby putting a stop to any attemp to port my application to Wicket.


                      Don't get me wrong, Wicket makes development more like normal Windows forms programming which is very familiar to more of us. I am not sure I want to program like that any more.


                      Regards.



                      • 8. Re: Reasons why not use JSF
                        vladimir.kovalyuk

                        You can employ OOD with Wicket and it is the killing example. I understand that there are many people who don't think that OOD should be used in Web UI. They are free to think anything. OOD still works. It saves money and helps to deal with growing complexity. It is not only a technical question. It is the subject of project management.



                        How exactly do you use Seam managed persistence contexts in Wicket, it has no notion of conversation.

                        We do use SMPC. The Seam-Wicket integration works in this regard. SeamFilter performs appropriate initialization.
                        If you are concerned about absence of notion conversation in Wicket - that has never been a problem. It is easy to put all the conversation data into a single class and have a type-safe conversation. What you can't do with Seam is to have two similar conversations derived from base conversation.



                        Should you keep the entity manager open throughout the session? How do EJB's fit into Wicket? I couldn't find an answer to these two questions thereby putting a stop to any attemp to port my application to Wicket.

                        Wicket is just a library for designing a presentation layer. Why do you want an integration from it? If you like Seam then use its integration with Wicket.(I like a lot about Seam and I still use it). And you will obtain your session beans just like in JSF. If you miss the capability to call EJB from method binding you should hear to Martin Fowler. People invented layers not just for fun. If your application is so simple why not to write it in PHP?


                        I'd add that from what you wrote it does not seem that you have read the book from cover to cover. And try  better to understand how Seam-Wicket integration works and you won't ask those simple questions. At least if you have such questions just ask them as questions but not as the prooving of JSF-Seam combination strenght.

                        • 9. Re: Reasons why not use JSF
                          arshadm
                          Hi,

                          Please forgive the tone my last message, I really want to understand why some people think Wicket is great, because from what I can tell it's abstractions are the same as JSF (i.e. postback, parse-validate-model-action, etc.).

                          I appreciate you like it's OO features, by which I assume you mean the ability to create re-usable panels and parts pages via normal Java inheritance. I have to be honest I don't make hundreds of components (maybe a shopping cart, header/footer) and it's pretty easy with facelets too.

                          The vast majority of the code is CRUD forms, and I don't see how it makes a massive difference either way. I think it is easier to write #{bean.property} and #{actionBean.save} than to create new Label("prop", PropertyModel(this, "property")) or a button submit action via an anonymous class.

                          As for using EJB's as form backing actions. It's probably bad form, but if all you are going to do in the code is lookup the EJB and then set the properties and call save you might as well let JSF do it. As a side effect you might get a more scalable app (clustering, etc.).

                          I am not an expert in seam or wicket so perhaps somebody with more knowledge such as Dan or Pete would give us their point of view. I just think people give JSF a bad press much of which is now not deserved, and wicket is proposed as a fantastic solution which again is not wholly deserved.

                          It will be interesting what the guys who have to maintain wicket code make of it.
                          • 10. Re: Reasons why not use JSF
                            nickarls

                            I, too, am interested in what the several very bad architectural solutions in JSF 2.0 are that can't be attributed to tradeoffs etc.

                            • 11. Re: Reasons why not use JSF
                              vladimir.kovalyuk

                              Robert, your JSF excerpt should have been quite longer if you use s:decorator tag, so comparison is not fair :) If you mostly design simple CRUD forms and even don't use s:decorator you are not from my target audience :) Now I understand why you don't see the difference. And please note that JSF is famous of its capability to make simple things complex :)


                              Wicket-RAD is a good example of how things becomes not the same in Wicket and JSF. http://sites.google.com/site/wicketrad/


                              Niklas, I remember proposing some improvements for your excel integration regarding relative positioning elements to worksheet. Although the library was very helpful in most parts, at the same time it was a nightmare to calculate the relative positions by absolute ones. We crossed our fingers and wished that users don't ask us to change anything in reports.


                              Why I'm mentioning that? Because it has the same sympthoms as JSF. The architecture is designed with simple applications (use cases) in mind. Moreover with just an excerpt from an extent of simple applications. When project grows developers tend to generalize common things, otherwise they will never control how many source files they have to fix due to new requirement or defect. JSF does not allow us to do it directly. It is the first architectural fault. JSF 2 includes Facelets to address templating mechanism. Don't mix it with incapsulation and polimorphism, Robert. It is not so difficult to put some boring and annoying parts of UI to templates. But they work just in simple cases. It stops to work when you try to design dynamic instantiation of components. Why? You should know because documentation states it. Your components is just markups templates. JSF 2 introduces markup components that are the same markup templates with their own COMPONENT scope. Some things becomes better. Okay. But it is still solves simple cases cause now EL is the problem. You will never control when and in which context the expression is evaluated. Here is the second architectural weakness. Your markup contains expressions that are at the same page and near each other. But they calculated at different time and against different contexts. And you will never control over that (except your forms are stupidly simple). Components just allow you to combine markup and EL, but expressions are not incapsulated data, they are more closures. Facelets just adds yet another context. Markup looks simple but does not work. WTF is the reqular question. You would like to push developers to think about contexts every time they changes expressions? Pure you.


                              They was the main problems of JSF. There are many others for instance it is pretty difficult to make your site capable with static web principles. Again it is one of most claimed problem.


                              What is the applications I'm talking about? Take for instance Atlassian JIRA. It has many examples of dynamically instantiated components. You are able to make custom searches and extend existing classes of defects. You can control how your custom properties are displayed. Such requirement is addressed in Wicket-RAD. Now try to think what you would do if you decided to implement Compiere with JSF. It is the example of real-world application. With the approaches like Wicket-RAD you can just past entity class as a parameter and render the whole form dynamically. With JSF 1.2 it is impossible (impossible to stabilize, I was clever enough to make it work some times). I don't know how it would with JSF 2, I'm just know that you will be struggling with context-related problems. Compiere performance is not good althought it is written in GWT. With JSF I'm certain it will be slow like hell. Hence the third problem - JSF expressions could be the cause of bad performance. Again not in simple cases. When you will have so many nested and complex custom markup components you will stuck in cycles of expression evaluations.


                              Now I would like to add that I like my developers to think more about business related things when designing user interface rather than thinking how to implements it with freaking JSF. The productivity of team would be better when using Wicket. Significally. It is the primary reason to choose Wicket. All the mentioned above is just technical speach meaning not very much for PM.

                              • 12. Re: Reasons why not use JSF
                                vladimir.kovalyuk

                                Nicklas, I'd like to add to the written above that JSF separates many things. But there is the only thing that has a lifecycle described - the request. I used to program in C++ more that 12 years and I knew that the only way to omit memory leaks and NPE was very deep understanding in which context and scope the instance of class lives and what its lifecycle is. Java allows us think about that in less cases when implementing something. But when we design framework or library we are not allowed to forget to think about contexts and lifecycles. JSF does not have  clear vision what are the contexts and lifecycles of components, expressions, listeners and so on. It shades some light on it but the vision is not clear and the implementations are inconsistent in this regard. It is true for many frameworks (and it is true for my sources as well) but it hasn't so many consiquences like in JSF.
                                That's why I'm saying that JSF has a very big inconsistency in the architecture. I see nothing in this regard in JSF2.

                                • 13. Re: Reasons why not use JSF
                                  agori

                                  JSF does not have  clear vision what are the contexts and lifecycles of components, expressions, listeners and so on. It shades some light on it but the vision is not clear and the implementations are inconsistent in this regard.


                                  Really, this means nothing. Retry with a little more concrete example of JSF architectural inconsistency.

                                  • 14. Re: Reasons why not use JSF
                                    nickarls

                                    OK. Could you give an example where this lack of vision in JSF regarding contexts and lifecycles of components, expressions, listeners and so on despite the help of a framework (such as Seam) on top has hindered development?

                                    1 2 Previous Next