Bruno wrotes (about the shortcomings of 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."
In my opinion, the part of the problem here lies in the confusion of concepts. If we talk about JSF implementation, we should know that there exists only few implementations of JSF specification. And mentioned RichFaces isn't JSF implementation, but it is a component library. Whereas in fact, MyFaces is an Apache implementation of JSF. JSF implementation implements the JSF API specification and contains at least the standard components to display any of the available basic ("plain vanilla") HTML elements, whereas JSF component library just adds extra components on top of the basic implementation. You can't compare MyFaces and RichFaces, cause it's no sense.
In your projects you will usually use one selected JSF implementation. Generally if you will deploy applications to "full-featured" application server, you will have built-in JSF implementation. Of course you can change default implementations, but why?
In servlet container environment (by example Tomcat) you should select the implementation and add appropriate libraries manually.
Anyway, the main available implementations are:
- JSF RI (Mojarra)
- JBoss JSF
- MyFaces
Worse, when the libraries are not properly designed and interfere with each other. But it is a problem of a different nature...
Generally speaking, I think the above arguments are irrelevant. The only problem I see is, as they say in my country, the problem of wealth.
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... "
I agree, i can be a somte kind of problem, but the case is perhaps somewhat demonized :) Most of the problems which mus be solved during the development is common. Of course there exist large libraries, with complicated components, thus sometimes necessity of deep understanding its specifics is inevitable. But as I wrote, in my opinion it's the problem of wealth.
As regards the comparing MyFaces and RichFaces I wrote earlier.
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... "
We are dealing again with the problem of mixing of concepts. If you have any problem with core JSF, then regardless of the implementation you can solve it in common way. In my opinion JSF is standarized sufficient. You don't need search the solutions in community because you have a lot of documentation, starting from JSF and Java EE specification to the lot of books like "Core JSF","JavaServer Faces 2.0, The Complete Reference", and so on. Whereas, if you have a problem which is specific to (by example) RichFaces components, you should search in RichFaces documentation. But this isn't a problem of poor documented JSF framework but eventual problem of documentation of RichFaces library.
Personally I work in recent years with ADF Faces which is in fact poorly documented. The ADF component library is very huge and often causes some problems:) but I haven't lot of difficulties to distinguish between problems on core, implementation level and problems caused clearly by ADF. And if the problem lies on core JSF level, the solution can be find quite easily and it was because of extensive documentation.
Component Incompatibility
"... 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..."
This is a truth. Some of the components sourced from outside the standard libraries have the problems of interoperability. On the other hand, it is rather a problem of ill-conceived implementation.
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..."
Next problem of wealth:). The libraries of components are sometimes really huge. And there is lot of libraries. But I thought that it proof that JSF is popular and better than others.
Actually there is difficult to find a specialist in everything. But it is not true that it is so difficult to move from one library to another. Basis, the implementation remains the standard.
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.rs..."
Facelets changes a lot, and now this is default view declaration language for JSF. Using facelets you design webpages in "plain" xhtml.
Non-functional prototype
"... 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?"
Facelets (nowe default VDL) has a built-in powerful templating functionality:)
Performance
"Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... "
Hmm. Maybe agree, maybe not. As I suppose most of benchmarks compares old style JSF apps (JSF 1.* and JSP based).
Web is fast, standards are slow
"... 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."
Agree:) The learning curve is not optimal. But when a developer has the necessary experience her/his productivity is really very well.
No comments:
Post a Comment