The discussion went mostly around what companies and developers should do before choosing a Web Framework. Although I was willing to move the discussion to another level (eg, poiting these 10 reasons), I decided to just take it easy. And as I stated: there's no perfect Web Framework. But there's a perfect web framework for your case.
But now I think it is the right time and place to share my thoughts. Here are my top 10 reasons (mostly non-technical) on why I don't like JSF.
- Extra step when defining a project's architecture
People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT. JSF is a specification, not a final product.
Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain't cool.
You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you'll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional.
- Fragmented Community
Now, let's say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs.
It is not easy to ask for help on a fragmented community. If you face a problem with RichFaces, when you were used to work with ICEFaces, you might end up asking something stupid, and probability is you will be told of a different solution to the same problem.
- Fragmented Documentation
If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there's the problem of non-standard components. Let's say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There's no such thing. If you are luck, you might find some blog post on Google. Odds you won't find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on.
- Component Incompatibility
Well, there's not much to say on this. JSF 2.0 address some issues, but not all of them. Component interoperability between different components can't be easily documented because of JSF's nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don't care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events.
- Caveats on some scenarios because of different implementations
This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won't find proficient JSF developers.
I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.
With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won't be proficient. They will be regular developers. I'm not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets.
- Designers and developers roles mixed
Oracle said it has set up JDeveloper or some other inside tool with JSF support to their web designers. Now, this is cool. You teach web designers to define templates, UIs, using the Java IDE. In the end you have the view done and all JEE devs need to do is to bind, code and run.
This is one way of doing it. But usually, it is not the case. Most companies have Web Designers working on Mac, with Photoshop and Dreamweaver or some other WYSIWYG editor. They are great designers partly because of great tools.
With JSF, designers and developers mix their work. Designers spend their time templating. Developers spend most of their time fixing broken templates after mixing them with JSF components. Now this, ain't cool at all.
- Does not improve usual web development process
Like I said before, companies are still working with a development process based on: design, template, inject dynamic code, fix design issues, release.
That's how Java Web development works. If you disagree, please comment on that. But I've been developing web applications for almost 8 years and that's how I see it.
All frameworks that mix dynamic code on the HTML or some layer that outputs it, doesn't improve the common web development process. Which sucks, IMO. You have Web Designers to do all the prototype. Sometimes, your company pays to a Design shop to do that. And in the end, you have business developers fixing design issues because a pixel here or there is not correctly aligned with that right border.
Now, there are some frameworks that address this issue quite well. Tapestry is one of them, if not the first. Then there's Wicket, which of course the best practice is to componentize the UI, but it is possible to work only with the prototype. With JSF, you have Facelets. It helps a lot, and I'm sure improves *a bit*. But the development process is beyond working with pure HTMLs and prototypes.
With JSF, the developer does a lot of SOP - String Oriented Programming. If you are not working with a great JSF-supported IDE, you will end up doing a lot of copy-paste of Strings of method names, property names and bean names.
Some may argue that Wicket replaces JSTL with Java. It is true. But consider this: if you are working with Wicket and you've already binded your UI, you don't have to look to your HTML again. With JSF, you must look at your ManagedBean and your page to make sure everything is correctly binded. On Wicket, new properties and methods can be added without modifying the UI, and still with JSF you must edit two files to do that. It is one approach, I know. But that does not changes neither improves the development process if you compare to Struts. GWT improves that, just as Wicket, IMO.
- Non-functional prototype
Ok, not a big deal. But it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?
- Performance
Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... :-(
- Web is fast, standards are slow
Let's take JPA for example. How old is SQL? Since 1974. Hibernate was build based on something that it was already a standard. So it was JPA. It is reasonable to have a specification for that, and totally acceptable to work with. JPA developers won't have problems dealing with different implementations, at least if they do their job right. What about XML frameworks? Mid 90's. My point is. Some specifications are build based on something with limited scope, even though generic, or on something that is already a standard and well-know by the market.
Now let's take the Web. Although HTML is a specification, and old, it definitely has an unlimited scope. And because of its nature, it is open to innovation and creativity. How to standardize that?! HTML5 is almost there, and we are still waiting for a specification that really improves the Web Development Process. Again, JSF2 is a huge step forward, but too late, and just like to what happened with EJB, people are now afraid of it because its previous version. And that's why people started to choose Rails, Python, GWT and other frameworks.
Long learning curve. Slow improvements (thanks to JCP). Everything the Web does not need. Everything Agile methodologies are against to.
Sure it has scenarios or business strategies where JSF is the best option. If there wasn't, Oracle/Sun, IBM, Red Hat and others would not put money on that. For companies that want to make sure they will easily and quickly find a developer to replace another, to keep the work on a JSF project, then, it's a business decision.
Now, from a developer perspective, I prefer to do my projects with something non-standard, while the Web is not standardized, and my customers are not worried about that.
35 comentários:
"there's no perfect Web Framework" -
There is a perfect Java Web Framework. It's name is HybridJava.
The only thing I would point out is that you are not technically correct when you say the different JSF implementations are not-portable. They are.
You've got MyFaces and Mojarra for JSF impls- that's about it. And they are very well portable.
What you are talking about is component libaries, and it makes sense that they would not be portable, because they are each providing a different set of component extensions to JSF: These are the RichFaces, PrimeFaces, MyFaces Trinidad, OpenFaces, etc...
There is a big difference between a JSF implementation, and a Component Library, and nothing says you must use a component library- they are there to be chosen at your discretion. I personally choose not to use 3rd party component libraries for many of the reasons you mention, but I bet my life would be easier if I did.
Cheers, thanks for sharing your thoughts :) Lincoln
@Lincoln You're right, the JSF implementations are quite portable. Libraries aren't.
The only problem is, without libraries, you can't do anything useful, because the JSF standard 'library' is very, very limited. And this is by design! The whole idea of JSF was to create a 'ecosystem' of components and libraries, which didn't really happen. Instead, were created many different, in-/semi-compatible ecosystems.
Well,in the last 6 years i've done more backend and desktop related stuff,but i just started with jsf 2 and it seems pretty easy.
Your article made me think twice,BUT tell me frameworks that do not have this weaknesses you just pointed,argumented.
I agree with Lincoln. There is a big difference between JSF implementations and JSF component libraries.
People who "hate" JSF and compile lists of arguments never seem to get this difference, which in turn makes me wonder how well they really know JSF and whether they are qualified at all to make such lists.
JSF implementations are like JVM implementations. We have a few (Oracle JDK, IBM JDK, etc). Component libraries are like class library. There are many more of these (your own ones, Apache Commons, Google Guave, Javassist, ... you name it).
A JSF component libraries does not -equal- JSF, it's a library of different component that can be used with JSF (hence its name).
That said, I think JSF 2 is one of the best frameworks around. It's really easy to work with and highly productive.
Oh my goodness, Bruno! You've hit the spot with this one :)
I've been forced to do JSF with RichFaces for about a year or so and I hated it with a passion. My passion went even so far I've started a separate blog http://ihavejsf.com.
Just read it :) I was more than pissed off when I wrote it and that is exactly how I felt for around a year working with this crap.
Web is stateless - let's keep it that way!
the address was all wrong in my previous comment - it's
http://ihatejsf.com
@matthias
You're wrong...
1. The web is NOT inherently stateless! Maybe your 1994-esque hypertext document is, but ever since people started to deploy -real- applications on the web there is state.
2. Get your facts right. JSF perfectly well supports stateless GET based request. You could do this way back already, with or without Lincoln's excellent PrettyFaces, and since JSF 2.0 this is directly supported by core JSF as well.
I have been using JSF for some 5 years now and me and all the programmers I worked with are very happy with it. With JSF 2.0 and CDI it's already one of the best things since sliced bread. Once Seam 3.0 will be releases it will be the absolute top productivity platform to work on.
Guys, I understand that some of you think JSF is ok or even great.
PrettyFaces is a bitch to use, to say the least and like it or not HTTP (as well as the web itself) is stateless. Just get over it.
Btw. If you'd like to bitch more about JSF I've setup a shoutbox where you can just get it off your chest.
http://ihatejsf.com
Matthias, please. The web has been migrating from a static, stateless, document only place to a rich and dynamic application delivery platform.
Since HTTP/HTML was originally not intended for this there surely have been some bumps along the way. The original web was a -very- poor place to develop applications for, impossible to compare with the richness of desktop applications of that time.
Increasingly technologies have been added that make the web more friendlier to hosting applications. Examples are Javascript, DHTML, AJAX and HTML5, but also high-level web application frameworks like JSF. The web originally wasn't meant for this, but guess what, it evolved.
JSF is closely following this continued evolvement of the web. Granted, core JSF is not on the absolute bleeding edge. But it doesn't have to. It has a completely open architecture where everything and nothing can be extended or replaced. This paves the way for innovative third party projects that keep seeking the boundaries.
JSF core releases then look at common functionality that had been implemented by these third party projects. Things that are popular and actually work are adopted into the standard.
To me and many others (JSF is one of the most popular Java web frameworks) this has proven to be an absolute winning strategy.
Thanks, I planned to write the same article. As old JSF and new Wicket. I totaly agree with you and I wondreded if jsfc can reduce the gap of web designer ?
Those 10 points are very nice, although being a JSF hater I had never thought about these non-technical points, you made very good points here.
My bad relationship with JSF basically is due to the technical side of the thing.
I don't want to take too much space, my basic disagreements with JSF are: lifecycle and portability across scopes.
1- Why (OMG, WHY??) adding so much complexity to the lifecycle of a webapp? It used to be so simple, the developer was aware of requests, responses, http stuff, in general. With JSF it takes lots of tracing to understand in which point of the lifecycle something is failing. The same method is executed multiple times during the lifecycle of a request, and you need a phase listener to find out in which point you are. That really sucks IMO.
2- write a reaaaaly simple webapp in JSF 1.2 (haven't tried JSF2 yet). Just the usual stuff: a few forms with DB-populated combos, regular validators and so on, put yout beans on session scope... it works fine, right? Ok, now switch the bean scope to request. OMG, it just stops working!!! I'm not wild guessing here, I've seen it happening with my hands on the keyboard! And then, if you want your application to be reasonably scalable, you gotta use extensively and make the HTML rendered to the client a huge chunk of text. So, the portability across scopes issue raises yet another and more critical issue: scalability!
I respect those who like it and are able to be productive with it, like Robert Whane, I mean, there's no point in a virtual argument here, but I can't really like a spec that makes the developer get lost into the lifecycle or crazy about why anything is not working anymore due to a simple scope change.
And about JSF being the most popular thing (spec or fwk), we shall not forget that for good or evil, JSF is Sun (Oracle)'s officialy supported webapp thing, which influences a lot in the choice of the majority.
Please excuse any excessiveness on my words, I didn't mean to be agressive to anyone.
Regards
Hey.
First: I really like JSF, but only JSF 2.0! It is much better than JSF 1.2 and has many improvements to ease development. Because it is a standard, so many tools and addons are available (e.g. the many great widgets of component libraries).
Of course, JSF is not the perfect web framework.
Of course, you should choose another one in many situations. E.g. if you want to create a real Rich Internet Application (RIA), then you should use Adobe Flex, Microsoft Silverlight or JavaFX. If you want to create a CRUD-Application, use Spring Roo, Grails or the Roma Meta Framework for very high productivity.
Many of your arguments are correct. But some of them are not a reason why you should not use JSF 2.0 and its component libraries.
Especially, I disagree with point 1.
As posted already by other guys: There is a huge difference between a JSF implementation and a component library.
Also you cannot compare RichFaces to GWT. You have to compare it to SmartGWT or Ext GWT!
So you criticize that different component libraries are not compatbile? Well, at least there are many component libraries <-- because JSF has a large community <-- because JSF is the JEE standard web framework.
You can name many other web framework such as Tapestry, Wicket, Grails and so on. Besides GWT, none of these has as many good widgets to offer.
If you use e.g. Netbeans and / or Maven, the project structure is also created for you. This was real problem with J2EE 1.4 (and no IDE support). But with Maven, JEE 5 and especially JEE 6 I do not see this problem anymore.
And yes, designers and developers roels are mixed. If your project requires the separation, you should use e.g. Wicket. But in all JEE enterprise projects I have participated yet, the developer and designer were the same person. So your argument is true, but I think it is overrated.
That's my two cents (and my personal opinion)...
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Good blog. It's very detailed. For me, I left jsf long ago to discover the world Wicket.
http://javajeedevelopment.blogspot.com/2010/12/brix-cms-apache-wicket-based-cms.html
@kai
I so much agree with you. Indeed, nobody says JSF is perfect, but then again what is? Certainly Wicket is not the posterboy of utter perfection. And I too agree about JSF 2.0. I personally liked JSF with 1.2 (with extensions), but it wasn't until 2.0 when I really started loving it!
@filipe
Sorry, you're being a little silly. In any web app, even pure servlet ones, if you depent on the session scope to communicate stuff between requests and you change it to request scope, things will break. That sounds like a major "duh" to me! This has nothing to do with JSF and everything with basic knowledge. If you can't understand that, I'm afraid JSF and server side programming in general is not for you.
JSF is an absolutely great framework! With JSF 2.0 it really got a lot better.
Felipe, the JSF life-cycle is about things you should have been doing anyway. It just makes sure you're doing them in an organized way. It's just getting values from the request, converting them to the right type (String to int, that stuff), validating they are correct, calling your business logic and then doing rendering.
There's nothing there that should not be done by any web application. Without a well defined life-cycle, people easily skip this, or they're pushing Strings into their business logic and doing conversion when the input has already reached the DB. Yuck!
I love the way JSF organizes this for me. I don't think the life-cyle is complicated at all. It's just about the basics really.
@john
what part of "simple webapp" didn't you understand? It seems you have a little bit of a problem with reading, so I guess vegetating is more like your lifestyle. I don't think you know what "scalability" means, so we'd better not start an argument.
@dexter
I do agree with you that the lifecycle includes things we always do. I just find it too hard to track when something breaks within the lifecycle. Several times I had problems with combos that were not being re-populated upon a validation problem and I had a hard time tracking down what happened. And sometimes, switching the bean scope from request to session made it magically work, without a change in my source code. That's my main critics against JSF. In my opinion, it unnecessarily puts the developer away from what's going on, and adds a great overhead on development. I really expect JSF2 to be better, we have so many MVC frameworks today that we spend lots of time trying to be up to date, although this in inherent to our profession. If JSF2 gives me productivity, I shall stick to it, due to its integration with JEE6. But today, I stick with Spring tools. I'm actually surprised to see so much Wicket fans. I like it a lot, I never thought there were so much users out there.
Regards
Felipe, my guess is that it has more to do with your understanding of things then it actually being complicated.
I dunno your exact situation, but in the majority of cases if a switch from request scope to session scope 'fixes' things, then there is a problem with understanding how information flows between pages. This almost can't be anything else than a basic error.
In Java EE 6/JSF2/CDI this is really elegantly solved with the conversation scope, or if you're staying on a single page the view scope.
In the old JSF 1.2 days you would use the tomahawk t:saveState tag for this. This very simple but superbly handy component took away 99% of the kind of problems you mention years ago for me.
@felipe
And what part of "JSF supports both" did you not understand?
JSF supports both stateless as well as stateful operation. Virgin Megastore's site springs to mind of an example of a public facing stateless JSF based application. There are more of these. As was said before, JSF 2.0 supports this by default out of the box.
I think you have some trouble with reading there.
And I repeat, the web is not inherently stateless. Do you think Google's apps are stateless? Do you think Google does not scale?
Furthermore, not every application is a Google or a Facebook. We develop a lot of intranet apps, where rich user interfaces are being deployed to give users access to complex business functionalities. Department wide, these apps each only deal with some 200 logged in users and maybe 50 simultaneous requests.
For these cases, scalability really is a secundary concern, while a rich UI is very important. There are thousands maybe millions of such apps used throughout companies in this world. This too is an aspect of the web.
@Alex, HybridJava goes against my #6 and #8
@Lincoln, I know the difference between Component and Runtime libraries. But truth is: you can't use some component libraries because they are so tied to their runtime libraries that it is just impossible to mix them with others. Also there's the documentation problem. Imagine a view with components from three-four vendors? Maybe a 4-monitor desk will help. :-)
@javacodesamples, if you've chosen JSF because it is called "standard", then there goes the first mistake. You should compare it at the same level to other frameworks. Do POCs and quickstarts.
@Robert Whane, if JSF was like JVM implementations, why can I deploy different JSF implementations on the same Application Server within different applications? JSF is not like JDK, because it is not like Swing. And going further, it is not like EJB. You DO have to choose what JSF framework to extend, what runtime library to run, and what components sets to use.
@Matthias, I don't hate JSF. I actually suggest it to some cases. But I always end up saying: "you will be locked to not only JSF, but to one specific implementation and component set of JSF". Same problem of any other framework. So do not consider the "portable" thing as decision-point.
@Ouertani, JSFC is a step forward reducing the mixed roles of designers and developers. But replacing the component tag with a jsfc attribute, and keeping the others attributes, is something that could be done with a Regular Expression replaceAll method.
@Kai Wähner, I ignored JSF 1.2. It is just so. ... "EJB 2". My points are not dealbreakers, like a friend from Oracle told me. And I agree with him. Although, they make you think twice before simply choosing JSF because it is called The Standard. Companies, teams and developers should consider all technical and non-technical points. Choosing the Java Web Framework is like choosing the database. You don't buy Oracle when your team is skilled on DB2. Neither you deploy MySQL just because it is free.
@Dexter, @John and @Felipe, your discussion is going beyond the scope of my list. I think that any proficient developer is able to do things no matter what framework he or she is using. But I agree the life-cycle is complicated and because of it the learning curve of JSF is higher than other frameworks. If you or your company have the money and specially the time to get through it, than fine.
To people who think I *hate* JSF, please. I don't. I just don't like the idea of having to Google for 3 hours, reading documentations of 3 different projects and posting the same message at three forums, just to find a solution to my problem between a core JSF component working with Seam's conversation scope after an a4j event.
And considering how Wicket's Ajax support works compared to JSF, well... Yeah, I prefer the Wicket style.
In other words: JSF became more fragmented than people thought Android could be.
As a lot of people said, I think your understanding of jsf is basic at least.
You are mixing old and new problems, giving the impression that jsf 2 doesn't exist. You can't compare jsf 2 to a 5-year old version of Wicket, so why are you comparing against old versions of jsf?
Also, reading your article gives me the impression that you wouldn't have all the problems you mention with other framework. Would it be easy to mix Tapestry and Wicket components on a page? Why would you want to do it with JSF component libraries? (which, btw, isn't really a problem)
A lot of things you are saying are simply not true (performance, ...).
@Bruno
> you can't use some component libraries because they are so tied to their runtime libraries that it is just impossible to mix them with others.
Components are not tied to a particular implementation of the JSF runtime libraries. What you maybe mean is that some components libraries implement extensions to JSF and those extensions may clash.
This is indeed true, but the emphasis has to be on some. The normal component model perfectly well allows me to mix or replace components from many different libraries. If my backing bean is now bound to a t:input where the user has to enter a date, I can simply change this to a rich:calendar without any worries whatsoever.
The incompatibilities mainly stem from the proprietary AJAX support implemented by many rich libraries.
In JSF 2.0 AJAX has been standardized, so JSF 2.0 AJAX component libraries should be able to mix together much better.
>Also there's the documentation problem. Imagine a view with components from three-four vendors? Maybe a 4-monitor desk will help. :-)
You've got to be kidding with this one? What about regular Java code calling out to classes from three different vendors? Do we need a 4 monitor desk for that? I'm sorry, this is just messed up.
>if JSF was like JVM implementations, why can I deploy different JSF implementations on the same Application Server within different applications?
Uhm... because you can change implementations? That's the entire idea of an implementation. You can change it to something else.
You can run a piece of JSF code on JSF implementation A and that same piece of JSF code will also run on JSF implementation B.
This is similar in that you can run a piece of Java code on JVM implementation A and that same piece of Java code will also run on JVM implementation B.
That a single Application Server can use different JSF implementations is because Java EE itself is pluggable too. It explicitly allows this. Not for all parts though, but JSF and JPA among others can be replaced with alternative implementations. E.g. JBoss AS by default comes with Oracle Mojarra, but I could change this to Apache MyFaces if I wanted.
This too is similar to the JVM. An operating system can come with JVM A, but I can often change this to JVM B. E.g. Mac OS X comes with the Apple JVM, but I can change this to Soylatte or OpenJDK.
>JSF is not like JDK, because it is not like Swing.
???
>You DO have to choose what JSF framework to extend, what runtime library to run
How is this different from choosing a JVM to "extend" (I take it you mean "to use"). I'm not sure what you mean with "what runtime library to run".
>, and what components sets to use.
How is this different from you DO having to choose what class libraries to use when you write a regular Java application?
>you will be locked to not only JSF, but to one specific implementation
You are NOT locked to a specific JSF implementation. Code written for JSF implementation A runs perfectly well on JSF implementation B. Please stop spreading this FUD or try to learn what the difference is between "JSF implementation" and "JSF component library".
@Yannick, I'm not mixing old and new JSF. Most of my complaints are not technical because technical issues can be resolved with time, and readings.
What I don't like is the ecosystem, the process, the day-by-day at work developing with JSF.
Without a great IDE (with drag'n drop support, WYSIWYG editors and component palette like JDeveloper for instance), JSF development sucks. At least for now. I'm sure that will change with better tooling support.
Now, about component libraries. The whole point of JSF, I think, is to enable developers to develop components to be reused. If I can't have a component from RichFaces running fine with an Oracle ADF component, because RichFaces doesn't have a similar option, then what's the point of JSF anyway?
Your example of mixing Tapestry and Wicket components just doesn't work because they are based on different architectures. Seems like you want to add a .NET component to a Swing application.
If JSF is a Swing wanna-be environment, then there's a lot of work to do. I'm hoping that one day, I will not have to pick a JSF framework, rather I can just import and extend many different cool components and not have to face interoperability problems.
@Robert, sometimes a piece of JSF code on implementation A does not run exactly the same way at implementation B. I've seen that, both with JSF 1.2 and JSF 2.0. Like I said: there are caveats. Because every JSF project should be using a JSF framework (Seam/RichFaces, MyFaces Trinidad and Oracle ADF). In theory, it is portable, In the real world is not.
JSF 2.0 added Ajax. Great. Will that stand? I don't think so. Not enough facts, I know. It is just a feeling. Just like others when they talk about non-standard frameworks.
Would I be happier if the way Wicket does its things had been chosen as the JCP standard? Definitely yes. Let Wicket Core be the standard, and all we would have online would be JARs containing components to be plugged with a simple import in Java and a wicket:id attribute in HTML. Still, tooling would be possible with that architectural design. And thank God, no need for a faces-config.xml.
By the way, I don't need Hibernate and TopLink to implement JPA - only one of them. Neither I need two or three different libraries to run EJBs. Or WebServices. Or transactions (JTA). I simply don't have to worry about libraries to work with those specifications.
I'm not spreading FUD. JSF has its place, but certainly is not a standard in my opinion, rather is a thing called "standard" by vendors to justify investment and to masquerade proprietary products.
So let companies, customers and developers fairly compare JSF products to Tapestry, Grails, Spring ROO, Wicket, GWT, ZK and many others at the same level. When you call JSF "the standard", you are the one spreading FUD against "non-standard" frameworks.
@Bruno
>sometimes a piece of JSF code on implementation A does not run exactly the same way at implementation B.
This happens for only a very minor number of cases. Here again it's not different from running Java code on JVM implementation A and JVM implementation B.
Occasionally, but absolutely only occasionally, there are some bugs in one of the implementations that prevent something to work in exactly the same way.
Since the base of our applications are being used by multiple clients, we test all our code on a combination of operating systems, JVM implementations and AS implementations. This thus includes the two different JSF implementations Mojarra and MyFaces. I can tell you that we're seeing very few problems related to JSF implementation differences.
For a lot of projects there is another important aspect. Should any JSF implementation ever disappear for one reason or the other, it's relatively easy to switch to another implementation. If you have never tested on this other implementation before you might indeed run into some slight differences.
A client of us migrated a while back from a custom Tomcat based stack (Tomcat + MyFaces + Hibernate, etc) to JBoss AS, which includes Mojarra instead of MyFaces. We run into a few problems, but they were all fixed within a few hours. We're talking about a massive JSF based application here with many man years of development. It was NEVER tested on Mojarra, yet it run perfectly well in mere hours.
Now try that with migrating to a completely new framework, i.e. from Wicket to Struts...
> I've seen that, both with JSF 1.2 and JSF 2.0.
Sure, they do exist. I'm curious though what specific differences you personally encountered.
>Because every JSF project should be using a JSF framework (Seam/RichFaces, MyFaces Trinidad and Oracle ADF). In theory, it is portable, In the real world is not.
In the real world it is. You can simply take the libraries along with you. How is this different from a regular Java application that makes use of the Apache commons library?
Would you say such particular app is not portable between the IBM and Oracle JVMs, just because it made use of the Apache commons lib?
>The whole point of JSF, I think, is to enable developers to develop components to be reused.
It is, and this DOES work. We have quite a number of our own custom components. They work PERFECTLY well together with Tomahawk, RichFaces and the core JSF components.
As a developer you can also very easily create composite components, which are treated as first class components everywhere. They too work perfectly well with Java based custom components and a lot of other component libraries.
Like said earlier, the problems of mixing component libraries is mostly limited to a few "rich" libraries like IceFaces and Richfaces. They don't mix well, and this is indeed unfortunate. It doesn't mean JSF is rubbish, but this is a situation that should be addressed. I really think the new AJAX standardization will do this. Time will tell...
Nevertheless, some rich component libraries do work great together. OpenFaces for instances is fully compatible with RichFaces.
>By the way, I don't need Hibernate and TopLink to implement JPA - only one of them.
???
You also don't need both Mojarra and MyFaces to run JSF code. And you don't need both the IBM and Oracle JDK to run a Java application. In both cases having only one of them is enough.
What on earth are you trying to accomplish with a comment such as this?
> Neither I need two or three different libraries to run EJBs. Or WebServices. Or transactions (JTA). I simply don't have to worry about libraries to work with those specifications.
I guess you're referring to the component libraries here, not libraries that implement said specs right?
Well, the entire idea of JSF is to create an ecosystem of available component libraries. So naturally it's to your advantage to make use of those libraries.
Nobody is forcing you though. If you want to create your entire application with only the build-in components and your own ones, go ahead!
How is this different from regular Java? You can build your application using nothing but classes from the standard JDK, or you can add libraries like apache commons, google guave etc.
At least Hibernate does have a number of additional libraries as well. Just take a look at Hibernate Search, Hibernate Shards, Hibernate Validator. Nobody is forcing you to use these. Having them around is NOT a disadvantage.
Finally, there could theoretically also be component libraries for EJBs. Just as there are libraries with Java classes. It's just that EJBs normally mainly focus on specific business code, which is far less likely to be useful to different people then general UI components are.
> And thank God, no need for a
> faces-config.xml.
This is simply false. With JSF2, you do not need a faces-config.xml for 80% of the cases. For 20% of the cases you do. People don't complain when other frameworks use the 80/20 rule, but JSF is special in that it is extra fun to complain about,
BB> Extra step when defining project's architecture.
This is true for any standard for which there are multiple impls.
Oracle sees this as a good thing, not a bad thing.
BB> And you'll be locked. It is not easy to move from one to
BB> another. Specially when you have to use those non-standard
BB> components to turn your project on something really functional.
This is precisely why I've been advocating, for years: that we need a
JavaServer Faces Standard Component Library (JSCL).
2. Fragmented community
I don't see any way to avoid this. Vendors use communities as assets,
and view their growth as an important metric of their product's success.
3. Fragmented Documentation
This is what Dan Allen and Lincoln Baxter's www.javaserverfaces.org was
trying to address.
4. Component interop
This was a goal of JSF2, and I'm glad to see he mentions it. I would
want to see some specifics here.
5. Caveats on some scenarios...
This one is a complaint about the proficiency of developers in general.
I would have to refer to him to Andy Hunt's "Refactoring Your Wetware"
book where the author spends considerable time on the notion of the bell
curve of developer proficiency.
6. Designers and developers roles mixed.
BB> With JSF, designers and developers mix their work. Designers spend
BB> their time templating. Developers spend most of their time fixing
BB> broken templates after mixing them with JSF components.
I submit that if you design your templates correctly, you won't run into
this. Refer to mercury interactive and other JSF based consulting
companies. I have interviews I've conducted as testimony, take a look
at my JSF Around the World talk.
7. Does not improve usual web development process
This is the first one on which we actually can make practical
improvements.
BB> On Wicket, new properties and methods can be added without modifying
BB> the UI, and still with JSF you must edit two files to do that.
This is something we can add.
8. Functional prototype
I see this as something that should be addressed at the tool layer, not
the runtime layer.
9. Performance
I need more specifics. Citing the quantity of google search results
isn't enough.
10. Web is fast, standards are slow.
Yes, that's correct. That's how JCP vendors and licensees have stated
they want it.
Two duplicated comments above from Ed Burns were removed.
My reply to this post: http://mkblog.exadel.com/2010/12/my-reply-to-top-10-reasons-why-i-don%E2%80%99t-like-jsf/
you are not alone man, there are many people who don't like JSF, I am one of them :)
Thanks
String vs StringBuffer vs StringBuilder in Java
Postar um comentário