Sunday, August 22, 2010

Java EE Web Development Without JSF

As a Java web development team, we’re frequently asked if we plan to use JSF in our web applications. After some hearings from my developer colleagues about their experiences using JSF, I decided to analyze if JSF is right technology for some problems of web development. After reading specifications, inspecting implementation libraries, I reached the conclusion of not using JSF. Even JSF 2.0 version is not enough to change this result. Here, I’ll try to give my reasons for this decision. Although Sun was pushing this technology by removing the mention of JSP form the Java EE 6 Tutorial, we are expecting JSP to live in the future. JSP technology is simple and direct solution of a certain problem. You can get same functions promised by JSF with JSP and JavaScript with less cost. JSF is a big engineering effort but the problem lies within the nature of web architecture.

I’m not alone for having this point of view. There are many voices having doubts about this technology:

http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/
http://weblogs.java.net/blog/edburns/archive/2010/01/22/analysis-peter-thomass-jsf-critical-rant
http://www.theserverside.com/news/1364127/Rethinking-JSF-The-Real-Problem
http://www.theserverside.com/news/thread.tss?thread_id=43899
http://www.chrislhardin.com/2009/08/java-server-faces-vs-ajax-frameworkswhy.html
http://weblogs.java.net/blog/2006/06/07/programmer-productivity-jsf-and-netbeans

Here are my opinions about the disadvantages of JSF:

1- JSF Introduces A Redundant UI Layer: As I mentioned in my previous posts, complete server-side UI componentization is problematic since in web applications we have 2 runtimes; server-side and client-side. If we use a heavy server-side solution, we won’t have enough energy to develop in client-side. However, same functionality can be achieved with simple JSP and JavaScript code. Some developers tried to ignore client-side and JavaScript but the client-side is a very important part of web applications and can’t be hidden. As the JavaScript engines gets better and HTML gets new exciting improvements (add AJAX move), client-side gets more importance. We need lightweight component libraries with client-side abilities. If we talk about components, we should consider client-side components. MS IE’s HTC and Firefox XBL are some efforts on this direction. In recent HTML specifications, I expect a standard for HTML components (XBL 2.0) but it seems difficult to see widespread browser implementations. We are currently using MS IE’s HTC components for some simple behaviors like number-date-time formatting, AJAX-enabled input fields etc. Some components may be client-only but some big components may also need server-side support (For instance our DataGrid row is posted to server to save its state).

2- Tag Soup: When I see some new tags invented by a web framework, I admit its failure is started. Web standards became successful since they were simple and standard. New element names, new attribute names, new behaviors and new event models terribly increases learning curve without any real benefits. What I say is don’t reinvent current HTML tags. I think current DOM, JavaScript and CSS namespaces are already too extensive that a programmer could learn.

<learnthis:thenlearnthat dontforgetme="doyourememberme()" iamundocumentedsuperfeature />

3- Losing Extensibility and Flexibility: Component encapsulation makes it hard to modify UI behaviors. Let’s say you want to insert some HTML code into 3rd row of a data grid. That may not be available in current API set. There may be many scenarios that were simple in HTML base declarative form. I inspected many JSF list components and they are nothing more than simple HTML tables. Why do we pay extra complexity cost for little earning of encapsulation of HTML? Even most of JSF components are just repetition of current HTML elements. You can find same function set of JSF implementations within JS libraries, nothing is new.

4- Complexity of Binding, Bean Lifecycle, Navigation, Scope and Event Model: To get basic grasp of JSF is much more difficult than request-based server models. MVC simplicity is also lost. You can observe that complexity in increasing development times or difficulties in debugging and fixing problems of applications. Designing UIs is just another story, common denominator between programmer and graphics designer is lost, every programmer should be also good designer. A very strong IDE support is required to hide some complexities like WebObjects did years ago.

5- Performance: I’ve heard some complaints about JSF performance, it may be eliminated but It is a fact that it would anyway consume valuable server resources. As we develop complex components with JSF, their performance degradation would be a new area of bottleneck analysis.


In Java EE stack, some standards never got enough adoption and that lead developers to find better, simpler solutions. I think JSF is moving on the same direction with EJB. Some developers may feel themselves comfortable by using JSF; good engineering, clean and structured code but I don't.

So, what is alternative? My suggestion is to use JSPs, servlets and JavaScript libraries. You may use some web frameworks or JS libraries to get ready-use functions. (Note that, some web frameworks have similar problems with JSF) If you still need HTML componentization, you can use XBL in Firefox or HTC in Internet Explorer (later waiting XBL 2.0 standard adoption). In web application architecture, unfortunately we’ve always ignored client computing resources. PCs are getting faster, browser engines are becoming faster. It is time to leverage client-side as much as possible.

23 comments:

İbrahim Demir said...

Hi;

Nowadays I spend some of my time on learning JSF. And also try to get advice from my web developer friends. What they say is JSF is not mature enough.
And my observartion is also on the same way. As Microsoft did for ASP.NET, we did the same mistake.JSF is a way to use Java back-end developers on web projects. But web is another world. Without a good html,css and js knowledge you can not go further with your java experience.

Maybe for small scale projects JSF is ok but not for a complex one.

(And want to add that I really like to read your posts..)

Grzegorz said...

Hi

Great post! First I thought Rod Johnson's writing new book :)

You're 100% right! I think JSF is Sun's (not so good) response to ASP.NET. But now Microsoft is "repairing" component-based web framework with ASP.NET MVC. I've tried to use JSF in one project, as one of its main goals was to let not-experienced developers (experienced only with Oracle Forms) write Java web applications.
Not only the've had problems (tools support or lack thereof), but also I've scratched my head many times trying to add somedynamic behaviour to JSF (JBoss RichFaces) pages.
One simple example - try to add clean rowclick handler to rich:dataTable - a handler that hides some page's fragments and enables some buttons at the client side - impossible. I know some JSF fanatics will do it, but I prefer some JQuery one-liners - they're clean, they're fast and they just work.

With my ~7 year experience with dynamic web applications I came to the same conclusion as you - client's behavior must be implemented at the client-side (JS, particularly JQuery). Simple JQuery $.ajax and $("selector").html(response) gives developers such power and allows for both clean client-side and server-side (my JSF experience ended with huge JSF-layer methods manipulating UIComponents just to add some dynamic behaviour).
At the server-side there is clean Spring-MVC layer - @RequestMapping annotated POJO methods return clean model which is then transformed to HTML by ... JSP.

Yes - after all these years JSPs, or more generally templates (e.g. Velocity) are the best view technology for dynamic web applications. Component based frameworks look great on PowerPoint slides or in "Guess the Number" examples. They require powerful visual tools (in that field Microsoft wins).

The above may be extrapolated (from my point of view) to more general conclusion - JavaEE's success lies only in JavaServlet API (and, as a derivative - JSP). I don't need EJBs, JSF, JavaEE security - Spring gives that in much better quality.

regards
Grzegorz Grzybek

Emanuel said...

All your points: so very true. I've been on a large JSF project for about a year now, and we've encountered all of the problems you've listed; each little one making our struggle to reach the deadline just that much harder.

I even blogged about my complaints a few months back: Generating HTML like it's 1999 (not a technical discussion, just a general 'work is tough right now' rant).

We even use RichFaces - tag soup upon tag soup :(

Toi said...

Hi all JSF haters,

First, I have to say that I don't like JSF either. Second, could you guys tell me how to solve this problem, which JSF sovles very easily?

The problem is: I have a Person instance containing first name, last name, birth of date... and tens of other information. All these information are stored in the database and displayed on a web browser. Now, I would like to click a button on a web page to have these information on that page updated from the database. With Spring MVC and jQuery, I have to send an ajax request using jQuery and receive a JSON object. Then I have to use jQuery to update tens of Person information on the web page (that needs tens of jQuery javascript lines because you need at least one line to update one information). Am I right?

Now with JSF, all I need to do is specifying the id of the block that contains all the Person information in the request to the server. When the response comes back, JSF automatically update that block. I don't need to write a single jQuery line in this case. Do you agree that JSF is much better than Spring MVC + jQuery in this simple case?

If you have any idea, please feel free to post here.

Anonymous said...

Hi All,
As we all know now JSF is a part of Java EE specification and there are great people behind Java EE 6 specification development like Rod Johnson,Galvin King and more.With Java EE 6 development JSF 2.0 has becoming better and will be better with every release.
JSF is a specification. Thus, you must use an implementation, such as the one provided by Sun( Now Oracle ), or the one provided by Apache (MyFaces) and there are a lot of component libraries like Richfaces,Primefaces,Icefces and performance also depends upon these component library. JSF makes development faster and saves a lot of time that why my vote go for JSF.

Cay Horstmann said...

If you want to bang out a straighforward web application that gets form input from the user and reacts to it, JSF or ASP.NET is hard to beat. If you want a lot of glitz and client-side UI effects, JSF isn't so good because you have to integrate your client-side activity with JSF on the server, which isn't always a natural fit and definitely requires expert knowledge.

If you consider JSF, pick a component set that can deliver the look and feel that you want to achieve. Then JSF should work fine. But if you have the urge to write lots of client-side JavaScript, then JSF may not help and may be in your way.

Fair disclosure: I am a coauthor of a JSF book, and I use it for my work--as long as I can work with it, not fight it :-)

Grzegorz said...

@Toi
[quote]
With Spring MVC and jQuery, I have to send an ajax request using jQuery and receive a JSON object. Then I have to use jQuery to update tens of Person information on the web page (that needs tens of jQuery javascript lines because you need at least one line to update one information). Am I right?
[/quote]
No - who told you you have to receive JSON object? You can receive HTML generated by JSP/Velocity/FreeMarker/manually and use $("#block").html(response).

@Cay, @Anonymous

I know there are good implementations and great people behind them, all I'm saying is that when you have to do something different (and absolutely normal - because the customer want it), some client-side HTML/JS operation - you're stuck. If you want to generate some parts of UI - you're end up writing lots of UIComponent-aware code.
My conclusion - to generate (based on e.g. database configuration) UI, use template engine, not component trees.

regards
Grzegorz Grzybek

mrtrombone said...

I recently completed my first enterprise project using Stripes (admittedly coming from a .Net MVC background rather than JSF) and found it a pretty straight forward and solid experience. I am surprised there does not seem to be more buzz about it.

Dani said...

Indeed, stripes is an excellent framework (action based), that just gets the job done. I switched from spring mvc to stripes not long ago.

Anonymous said...

My objection will be on the client side improvements efforts.

If you are saying that "oh browsers are very powerful nowadays and we should use them more" I should say it is not a brand new invention. It is called client-server paradigm and thick client approach and is used for decades.

Actually it is the main reason behind the design of java at first place I mean the java applets. You can embed anything within a browser using a java applet safely and without any loss of performance caused by those ajax calls. Yes Http was designed thinking in mind those http and ajax calls so it is very inefficient for this.

If performance loss is your argument then you should use java applets. What JSF brings into web development is not just another layer to UI development but another level of abstraction to UI development. It is like why we don't code in assembly or C for web development these days..

Franklin said...

Mentioning , componentization is problematic might be too much of a generalization. Frameworks such as Apache Wicket are component oriented and still very much easy to integrate with client side. They also shine in terms of Ajax-fied fields and components. However, yes JSF seems to be an overkill

Altug Bilgin Altintas said...

Great artical first. JSF makes web development very hard; JSF goes to Tag Oriented Development and tags are not part of OOP. Am i right ?

Lets look wicket.apache.org. Great way (i mean simple) to develop web applications.

Anonymous said...

you do not need JSF in order to pickup and use components. Is not it?

Jose María Arranz said...

Ibrahim, this is not a black (server-centric) and white (client-centric) selection.

Take a look to ItsNat, it is basically DHTML in the server, it solves many of your JSF complaints and remain server-centric.

ItsNat's Home

Rostislav Hristov said...

Your thoughts about JSF are valid. I have used it extensively for about 3 years and there are problems. On the other hand there are nice features like Facelets, composite components and partial rendering. I'm using only these in a brand new library that enables a very simple but powerful Spring style MVC presentation layer. It will be soon open sourced and in the meantime any comments or beta testing are appreciated. Check it out at http://www.asual.com/summer/.

Alexander said...

my vote for pure web. then i've seen first time amount af data requird by richfaces just to switch tab with dummy content i was shocked. if you take a look at the most visited sites today - none of them created with jsf ui, just because jsf it's always compromise between your needs and lazy brains

Anonymous said...

Mate, sorry disappoint you, though JSF come to stay. If you want go out and hunt you own food it's a right that you have, though you can go to the near butcher and buy the meat that you want, simple and easy. If you don't understand completely JSF go for other framework or read more and understand better, just don't go thinking that 99% of world is wrong.
JSF is very productive, and the EL is pretty good, may you don't work with tight schedule and still don't have one why to use it, and want use the old JSP. But I don't think that you really know what you talking about, because pure JSP sucks a lot, it's just can't keeping remembering those scriptlets in the middle... is hard task to maintain it, crazy things. By the way you can use GWT instead.

Toi said...

Hi Grzegorz Grzybek,
No - who told you you have to receive JSON object? You can receive HTML generated by JSP/Velocity/FreeMarker/manually and use $("#block").html(response).

Let me clarify this: so if I need to have 5 blocks (e.g. div) which can be refreshed in an ajax way, I need 5 more jsp pages for them?

Grzegorz said...

@Toi
[blockquote]
Let me clarify this: so if I need to have 5 blocks (e.g. div) which can be refreshed in an ajax way, I need 5 more jsp pages for them?
[/blockquote]
If you have 5 not related divs (say: status, error messages, banner, ads, quote-of-the-day) which must be changed after one ajax call you have to think what is the original cause. If you're clicking a button which sends a form to a controller, then you have one hit to the server and one chance to get a response. Of course you may hit the server five times to invoke 5 controllers and receive 5 JSP/Velocity generated responses, but you may also:
- refresh the entire page
- use portlets
- update the containter DIV
- return one HTML and then pick (using JQuery's $("#section-x").html() without parameters) all needed fragments and put them (using html("#target-x")) wherever you want

That's the case where with pure JSP (or better - template approach) you have more freedom than with JSF - ask the same questions the JSF guy :)

Anonymous said...

>Let me clarify this: so if I need
>to have 5 blocks (e.g. div) which
>can be refreshed in an ajax way, I >need 5 more jsp pages for them?
you can have one, of course. And your controller could be JSP too (it is also servlet by the way)
And sure, you can use Ajax components in JSP (many of them, e.g. Coldtags suite)

bringie said...

1. you can write your own components
2. sry, jsf tags are complex but they arent tousands, i think you are lazy and frustrated :)
3. u can write your pages as html, and integrate jsf with other frameworks
4. you need only experience, JSF lifecycle is easy to understand, and google mistakes on code design..
5. i dont think that a performance ist the big problem .. you have milions of posibilities how to solve it, ajax injection (regioning, targeted reRendering),
forms optimalisation, back beans with simple getters and setters and so on

I think JSF has more disadvantages (unreadable html code on client, overhead on components restyle..) but I think JSF is great for large-scale Projs, not for small,
because its component based framework (ease to replace, ease to understand .jsp file) and no giant heap of php-like code

enjoy JavaServerFrustrations :)

Anonymous said...

What about using php/ror/python etc. with j2ee, jsp(f)'s replacement?

Best Regards

Ibrahim Levent said...

Thank you for your comments. Of course this is not a white or black selection. Every team has different background and tendency that may affect their decision about JSF. I wanted to share my point of view because I used some component suites (also tried to develop) for web in the past but I didn’t feel myself productive. Yes, JSF is a solution, it has even some advantages but its benefits don't outweigh the costs for me. Java means freedom; just adopt one of the numerous options that best suits your needs. It is very important to evaluate even standards because we invest time, money, and energy. In this post, I just wanted to point out some probable problem areas. Additionally, I wanted to give a voice that plain old JSP and Servlet are still alive and a valid option.