Is JSF technology the EJB 2.0 of the web?

[Mihai Lihatchi]

Hello.
I have played around with various Java Web frameworks during my (very short )career . I am trying to learn JSF and more specifically RichFaces (I hate JavaScript and RichFaces seam to protect me from going into Javascript code).
However I am shocked by how complex JSF development can be . 6 phases ? Each component needs an id ? (or you get duplicate id component). Kind of reminds me of EJB 2.0.
By comparing it Struts , Spring MVC and even JSP & servlets directly seem easier to use ?
I have a sample webaap developed with Spring ,Spring MVC and Hibernate which could use some AJAX interactivity but I really am scared to learn Javascript . Or I do not want to .
Regarding jobs .. very very few require knowledge of JSF (at least where I live) so this reminds me a bit about EJB2.0 a technology which though standard got used less due to it;s complexity and developing a JSF component by myself seems to be even harder to achieve (I did develop some JSP tags to practice for SCWCD).
But Sun continues to push JSF as a standard and passing the (new)SCEA architect exam requires you to know JSF so I am interested.
What are the benefits ? (besides standard technology /passing certification)
PS: Sorry for the faults, English is not my native language and I just came home after work.

[Bauke Scholtz]

Mihai Lihatchi wrote:However I am shocked by how complex JSF development can be . 6 phases ? Each component needs an id ? (or you get duplicate id component). Kind of reminds me of EJB 2.0.

How many phases would you like to see it to have and still keep it a MVC framework then?

The phases are nothing more than obvious: restore view, apply request values, validate request values, update model values, invoke action and render response. The same way as you would do with every decent MVC application, even with plain vanilla JSP/Servlet. Maybe expect of the restore view part, but that is the one which makes JSF very robust and hard-to-hack by client. Maybe also expect of the higher level abstraction, but that makes the developer very easy to hook on a specific phase externally.

That each component needs an ID is true. But your complain is maybe related to specifying it yourself for every component and this makes no sense. You can either supply it yourself if need be, or JSF will autogenerate one for you. If you run into "duplicate ID" problems, then either you're using an outdated JSF version (I recall a smiliar bug being fixed around 2006), or you actually assigned duplicate ID's yourself (either statically with same ID in different include files or dynamically with creating components *without* an ID in backing bean).

By comparing it Struts , Spring MVC and even JSP & servlets directly seem easier to use ?
I have a sample webaap developed with Spring ,Spring MVC and Hibernate which could use some AJAX interactivity but I really am scared to learn Javascript . Or I do not want to .

No comment about Struts or Spring. I don't do them.

About Javascript: I like it. The aversion might be a form of misunderstanding the language.

Regarding jobs .. very very few require knowledge of JSF (at least where I live) so this reminds me a bit about EJB2.0 a technology which though standard got used less due to it;s complexity and developing a JSF component by myself seems to be even harder to achieve (I did develop some JSP tags to practice for SCWCD).

I don't know where you live, but in at least India, West Europe, West USA (California) and Brazil there are enough JSF jobs. Checkout Monster.com. I live in the Caribbean and even here there is some market for JSF (although mostly outsourcing to USA).

But Sun continues to push JSF as a standard and passing the (new)SCEA architect exam requires you to know JSF so I am interested.
What are the benefits ? (besides standard technology /passing certification)
PS: Sorry for the faults, English is not my native language and I just came home after work.

Well, it's your choice whether to do the specified exam or not. I can't do anything against that Sun is pushing JSF in it. I don't do Sun certification stuff, so I can't say much about it. About the benefits of JSF, well I would start reading the JSF specification, pick the 1st download link here: http://jcp.org/aboutJava/communityprocess/final/jsr252/index.html If you still don't like JSF, then just don't do it. Make another choice.

[Mihai Lihatchi]

Thank you for your answer. Guess I am just scared of Javascript ;).
Well I live in Eastern Europe (Romania to be more precise). I do not claim my first view of JSF is correct. I want to hear it from people that code using JSF. AND have experience with some other web frameworks.
Regarding certifications .. I passed a few that's why I mentioned this.
I know I am a bit off topic but could you recommend me some JSF books ?

[Bauke Scholtz]

Start reading the JSF specification. If you like it, then continue with "JSF: The Complete Reference" by under each Ed Burns (which is also the lead of the JSF specification). If you don't like it, then maybe "JSF in action" by Kito Mann is more suitable. If you really don't like it at all, well, look for another MVC framework, Struts maybe.

[Bear Bibeault]

Hmmm, isn't this a bit like walking into a biker bar and bad-mouthing Harleys?

There are many proponents of JSF, and there are many detractors (personally I think it's a cantankerous, over-complicated, Rube Goldberg contraption that should have never made it past the conception stage), but in order to find out which side of the fence you come down on, you should give it a fair shot (I can't tell from your original post how far you've gotten into it). The resources Bauke listed are a good start.

I'lll also agree with Bauke that most people who say "I don't like JavaScript" say that because they don't know JavaScript. It's actually quite a powerful and interesting language. You may be reacting not to JavaScript, but to the HTML DOM (which is a monstrosity) but if you're going to be working on the web, there's little getting around that.

If you want to create RIA's, you're going to need to wrap your head around something that'll do it for you (no thanks) or around JavaScript and Ajax. Perhaps adopting a JavaScript library like jQuery that makes JavaScript development a whole lot easier (including abstracting a lot of the DOM madness away) might lessen your JavaScript aversion.

[Mihai Lihatchi]

Good comparison with the Harley's ;) but it's more like going to a Harley's bar with a Suzuki and claiming it's faster. Of course you get flamed on ;).
Sorry if it sounds like bad mouthing it is just my impression (right now). I admit I have no experience with JSF (If I had I probably would not have posted this question). As for Javascript . guess I had some bad experiences in the past.

[Tim Holloway]

There's nothing essentially wrong with JavaScript, but there are a number of reasons I prefer to avoid it. JavaScript does late binding, so like all late-binding languages, you can write code very fast.

But then it blows up in production when it turns out you had an unusual case come up where you assigned an object of type Squirrel to a variable that was supposed to be of type Fruitfly. Java doesn't give as much Instant Gratification, but you don't see as much of this, because its early binding catches stuff like that at compile/design time. Unless you do a lot of indiscriminate casts.

Debugging JavaScript in a web browser can be especially annoying, since the browser constrains your debugging environment somewhat.

Finally, JavaScript is prone to browser-specific differences, which require a lot of extra testing and workarounds. Sometimes even that isn't enough. I'm having a major problem with some of my Google Maps apps. I'm 99% sure it's a synchronization issue in the Google JavaScript, but that's code that's complex, cumbersome, unreadable, and (last, but not least) under my control so I can't fix it. All the end-user knows is that to actually display the map, you have to go to the page, wait 10 seconds, then hit the "back" button. Not my idea of professional.

RichFaces and similar frameworks can be a big help. RichFaces writes a lot of the grunt code for you, and in the process does the browser-specific work as well. You end up writing little or no JavaScript, but still get the benefits. And the JavaScript you do write will usually be a lot simpler, more portable and easier to manage.

You do not have to assign unique IDs to JSF tags. If you don't, one will be generated for you. But for the major tags, it's better if you do, since a bug will cause a JSF error page to display with the offending tag's ID in it. And since it's very hard to predict which ID will be assigned to what control, you'll waste a lot of time. Better to give the tag an explicit ID.

[Mihai Lihatchi]

I started to take a look at Javascript and Javascript frameworks (JQuery) and continue to study RichFaces (so I will stll have a look on this forum).
Unfortunately I do not think we can abstract away the Javascript .
GWT and RichFaces are nce attempts but without knowing how Javascript works underneath you cannot be effective with these technologies.Besides maybe I will use Javascript knowledge while coding in other (simpler) web technologies (like PHP).
If you can't beat them join them .

[Tom Fulton]

Java and JavaScript are quite different. As a Java developer, I dislike JavaScript for a number of reasons, but chiefly because it is a weakly-typed language (what others here are calling "late binding).

On the other hand, I really enjoy working with JSF. I find it quite easy to work with, for the most part. And unlike a famework like Seam, I think it does a reasonable job for many web applications. It is as complex as it needs to be, and only occasionally is way too complex for its own good (like the creation of custom components). Most J2EE developers can learn Struts or JSF.

Seam, to be honst (although it has a lot of very nice features) is very, very complex...possibly more complex than the average J2EE developer is willing to tolerate.

I would not recommend reading the JSF specification first. Most specifications are not written to be approachable at an entry level. JavaServer Faces: The Complete Reference is, possibly, the worst reference book I've ever read (it has, for example, the most anemic index for a reference book in history), but is actually a very good tutorial book. Core JavaServer Faces is quite good. JavaServer Faces in Action suffers from the fact that it covers only JSF 1.1, while the previous two books cover JSF 1.2 (and the Complete Reference book calls out the differences between 1.1 and 1.2 nicely).