With the recent release of Primefaces 3.0, JSF finally reaches an unprecedent level of maturity and utility that puts it face to face with other popular Rich Internet Applications (RIA) options, such as Google Web Toolkit (GWT), ExtJS, Vaadin, Flex and others. This open source project also proved to be very active and in constant growing path.

I have been working with JSF + Primefaces since a year ago, when I started the project JUG Management, a web application conceived to manage user groups or communities focused on a certain domain of knowledge, whose members are constantly sharing information and attending social and educational events. JSF is a standard Java framework for building user interfaces for web applications with well-established development patterns and built upon the experience of many preexisting Java Web development frameworks. It is component-based and server-side user interface rendering, sending to clients (web browsers) pre-processed web based content such as HTML, JavaScript and CSS. My experience on this technology is openly available on java.net.

Read the rest of the article at the following URL:

Java Code Geeks: Choosing Between Vaadin and JSF

Hi,

There are some threads that push combination of Javascript MVC + Restful as an alternative to JSF2.x

The main arguments are:

- more natural with the nature of Web

- Javascript is more standard and most frameworks are mature

- Better testability

- Stateless (most use cases in Web) NO component tree

- Scale better than JSF (complex life-cycle, fat server side state ...)

- Ready to go with HTML5

- Increase developer productivity

Did U evaluate these type of alternative.

Tarik

Hi,

There are some threads that push combination of Javascript MVC + Restful as an alternative to JSF2.x

The main arguments are:

- more natural with the nature of Web

More natural to who? To you? Many find a "web" page consisting of only Javascript very unnatural! HTML being served from a Server... this is very natural!

- Javascript is more standard and most frameworks are mature

So is JSF. It's standard, and it's mature. I'm not sure how any one of those can be more "standard" than the other. Something is either a standard or it's not.

- Better testability

In your dreams...

- Stateless (most use cases in Web) NO component tree

Then what's the DOM doing there? 

At any length, JSF can be stateless as well, although this is indeed one of the areas where there's some more work to do.

- Scale better than JSF (complex life-cycle, fat server side state ...)

The life-cycle is not complex! It's complex because people like you continuously repeat it is, and other people parrot that. In reality, you're getting parameters from the request, convert and validate those, store them somewhere and call out to the business logic. After that's done, do rendering.

Now the *funny* part.

When using a client-side UI YOU STILL HAVE TO DO ALL THAT!!!!

A framework like JAX-RS that can back a client-side UI, also has to grab parameters from the request and has to convert them. And you'd better do some validation as well. Thinking the client-side UI code can do all the validation is the first mistake rookies make. And you still have to call out to business logic and still have to render the result.

There's a small difference in rendering, as in the JSF case you'll HTML, while in JAX-RS it's XML. Unless your back-end already works directly with XML, the difference in overhead is rather small here. AJAX responses further muddy the differences.

- Ready to go with HTML5

As is JSF...

- Increase developer productivity

You mean decrease developer productivity? If anything, correctly setup JSF pages that uses templates are MUCH easier to maintain and debug than a massive Javascript spaghetti.

"- Scale better than JSF (complex life-cycle, fat server side state ...)"

This still has a point. JSF is very heavy on Session. It stores all of client side state into it and can potentially impact performance with large number of users and the need of session replication.

I have not worked with JSF myself since I still prefer pure web client approach but would like to see others who have had experience with large JSF projects to dismiss or confirm the above for us.

"- Scale better than JSF (complex life-cycle, fat server side state ...)"

This still has a point. JSF is very heavy on Session. It stores all of client side state into it and can potentially impact performance with large number of users and the need of session replication.

This is not entirely true, but not entirely wrong either.

The truth is a bit more subtle. For starters, the being "very heavy on session state" is a legacy statement. JSF 1.x had a design flaw where much more than needed was stored in the view state (and thus the session if storing state on server). For instance, constant attributes on tags where all stored. This didn't made any sense at all, and was one of the reasons JSF 1.x got a bad name.

This has been fixed some 3 years ago in the massive overhaul that JSF 2.0 was. Currently, only delta changes are being stored, which are typically only a few. This is called partial state saving, and it's what happens by default.

Secondly, state is only saved when forms are used. Not every page and not even every application needs forms. GET is a first class citizen in JSF.

Then, you can opt to store state on the client. This then won't cost you any server session space at all, at the expense of extra CPU power when eventually this state is send back and needs to be de-serialized and of course extra network bandwidth (but this can be very small).

Also, don't forget many other frameworks use this approach. Wicket and Ruby on Rails among others do the same thing.

That said, a better state management is definitely something JSF should address. In some cases individual components are just sloppy with state, storing stuff there that shouldn't be necessarily there (like caching simple values that can easily be recalculated). Also, there should be more options to configure state and this should be possible per page.

At the whole, I've not yet run into a situation where the web layer became the bottleneck. Even though we have an extremely fast DB, with a big raid of the fastest directly attached SSDs and a mostly in-memory DB, the bulk of the processing time is still spent in the DB. E.g. of a 100ms request, 10ms at most is spend in the web layer and 90ms in backend services including the DB. 

- Javascript is more standard and most frameworks are mature

So is JSF. It's standard, and it's mature. I'm not sure how any one of those can be more "standard" than the other. Something is either a standard or it's not.

Actually, he's probably miscommunicated his point, JSF is only a "standard" within the Java world and even then not a particularly successful standard considering there are so many other competing options out there still alive and kicking..

Javascript on the other is a "standard" in the sense it is common in all modern browsers.  Also, if I develop UI components in pure Javascript I can use that with .NET backends, Java backends, Ruby backends, python backends, etc, easily.

Hi,

There are some threads that push combination of Javascript MVC + Restful as an alternative to JSF2.x

The main arguments are:

- more natural with the nature of Web

- Javascript is more standard and most frameworks are mature

- Better testability

- Stateless (most use cases in Web) NO component tree

- Scale better than JSF (complex life-cycle, fat server side state ...)

- Ready to go with HTML5

- Increase developer productivity

Did U evaluate these type of alternative.

Tarik

The last time I looked at JSF was when it was 1.0 and after seeing that every request was a POST and the deplorable UI widgets I ran away screaming. A lot seems to have happened with JSF over the years but REST style frameworks and Javascript frameworks have also taken giant leaps. 

I'm curious to see a good non-emotional evaluation of when to use JSF and when not to. I work with Spring MVC and YUI 3 myself and am very impressed with the flexibility and power they provide. I have to admit that on the backoffice side of things I often find I have to do a lot more coding than I would like on boiler plate type CRUD operations. On the front end, I can't imagine that any standard widget would suit my needs as I need speed and customizability without the fatness you tend to find in a "one widget to rule them all". Also, I have a hard time that I would be able to tune the delivery of Javascript for optimal performance to the degree that I can in YUI. But I would be happy to be proven wrong on both counts.

Also, how easy is it to integrate JSF into existing MVC applications? Can it be JSF and MVC or does have to be JSF or MVC?

The last time I looked at JSF was when it was 1.0 and after seeing that every request was a POST and the deplorable UI widgets I ran away screaming.

I don't blame you, in fact that's what everyone did. Even its own designer ran away in agony after seeing what monstrosity he had created!

Luckily around 2005 Ed Burns and his team took over and after quick-fixing some issues for JSF 1.2 in a short-time he got the free hand to largely redesign JSF for 2.0. He listened extremely well to the community and nearly everything the community ever complained about was addressed (in many cases in close cooperation with that community).

Ed Burns isn't shy at all to just accept a community solution instead of building something himself. For instance instead of developing a templating language themselves for JSF, the team just took the existing superior Facelets.

JSF 2.x is just like EJB2 vs EJB3; it's a massive overhaul and it's very hard to find any concrete flaws with it, while in JSF 1.x this was all too easy.

 

A lot seems to have happened with JSF over the years but REST style frameworks and Javascript frameworks have also taken giant leaps. 

I'm curious to see a good non-emotional evaluation of when to use JSF and when not to. I work with Spring MVC and YUI 3 myself and am very impressed with the flexibility and power they provide. I have to admit that on the backoffice side of things I often find I have to do a lot more coding than I would like on boiler plate type CRUD operations. On the front end, I can't imagine that any standard widget would suit my needs as I need speed and customizability without the fatness you tend to find in a "one widget to rule them all".

Well, you can easily build your own components via the composite component feature. This is just a simple template in which you put markup and javascipt. You place this in the /resources folder and it's automatically available as a component.

In other cases you can use default components. There are very basic ones that just mirror the foundational HTML widgets and which are excellent building blocks for usage in composite components, or you can use one of the many great components from existing libraries. Especially the ones from Primefaces are rather good and have plenty of hooks to be customized if needed. (there's a widgetvar atrribute for instance, that gives you full access to the javascript component).

GET is fully supported HTTP verb now, and the integration with EJB, JPA and bean validation is superb. This means that typical CRUD screens are very easy to make. A slim JSF backing bean calls out to an (EJB) service, which returns a JPA entity that is directly passed to the view. You bind properties of this entity to fields. Validation can happen automatically based on Bean Validation annotations or Type converters/validators, or more explicitly by re-usable converters/validators that you attach to these fields.

It's really simple and straightforward.

I also like the power Facelets templates give me. I lot of re-occuring things can be put into master templates and a specific page only fills in what makes that page specific.

 

Also, how easy is it to integrate JSF into existing MVC applications? Can it be JSF and MVC or does have to be JSF or MVC?

JSF *is* a MVC framework. More specifically, it's used to implement the view part. The controller is given (you don't write it), but a backing bean or (optionally) navigation rules augment it. In JSF-speak, the backing bean is already the model, but practically the (EJB) services that it calls out to are more considered to be the model.

An advantage of JSF seems to be that it's now really gaining momentum. The Java web framework space always has been extremely fragmented, and with the exception of Struts around 2000, no framework ever got a leading position. You may be in love with Spring MVC, but the next developer is totally into Wicket and hates Spring MVC, while yet another developer hates you both and advocates using GWT exclusively.

It seems that JSF is the one web framework in Java on its way to a relatively dominant position.

Hello everyone, I'm a freelance writer. I love to watch horror movies. When not writing, I spend my time with friends, roaming in mall is our favorite pastime.