June 10, 2009 3:00 PM by Daniel Chambers
Updated on 2009/06/12 & 2009/06/13.
Today I'm going to do a little no-holds-barred comparison of ASP.NET MVC and JavaServer Faces (JSF) based on my impressions when working with the both of them. I worked with ASP.NET MVC in my Enterprise .NET university subject and with JSF in my Enterprise Java subject. Please note that this is in no way a scientific comparison of the two technologies and is simply my view of the matter based on my experiences.
ASP.NET MVC is the new extension to ASP.NET that allows you to write web pages using the Model View Controller pattern. Compared to the old ASP.NET Forms way of doing things, it's a breath of fresh air. JSF is one of the many Java-based web application frameworks that are available. It's basically an extension to JSP (JavaServer Pages), which is a page templating language similar to the way ASP.NET Forms works (except without the code-behind; so it's more like original ASP in that respect).
It is probably easiest if I start with what is wrong with JSF and what makes it a total pain in the arse to use (you can tell already which slant this post will take! :D)
In years past, the world went XML-crazy (this has lessened in recent years). Everybody was jumping aboard the XML train and putting everything they could into XML. The Faces-Config.xml is a result of this (in my opinion, anyway). It is basically one massive XML file where you define where every link on (almost) every page goes to. You also declare your "managed backing beans", which are just classes that the framework instantiates and manages the lifecycle (application, session, or per-request) of. In addition, you can declare extensions to JSF like custom validators, among other things.
All of this goes into the one XML file. As you can probably see, it soon becomes huge and unwieldy. Also, when working in a team, everybody is always editing this file and as such nasty merge conflicts often occur.
In JSF, you need to define where all your links go in your faces-config.xml. You can do stuff like wildcards (which lets you describe where a link from any page goes) to help ease this pain, but it still sucks.
Not only that, but every page link in JSF is a POST->Redirect, GET->Response. Yes, that's right, every click is a form submit and redirect. Even from a normal page to the next. If you don't perform the redirect, JSF will still show you the next page, but it shows it under the previous page's URL (kind of like an ASP.NET Server.Transfer).
It seems like a simple thing, but JSF just doesn't have any page templating support (called Master Pages in ASP.NET). This makes keeping a site layout consistent a real pain. We ended up resorting to using Dreamweaver Templates (basically just advanced copy & paste) to keep our site layout consistent. Yuck.
In JSF, it is awkward and difficult to communicate data between pages. JSF doesn't really support URL query string parameters (since every link is a POST), so you end up having to create an object that sticks around for the user's session and then putting the data that you want on the next page in that, ready for the next page to get. Yuck. There are other approaches, but none of them are really very easy to do.
Communication between "managed backing beans" is awkward. You end up having to manually compile a JSP Expression Language statement to get at other backing beans. Check out this page to see all the awkward contortions you need to do to achieve anything.
So enough JSF bashing. It's all very well to beat on JSF, but can ASP.NET MVC do all those things that JSF can't do well? The answer is yes, yes it can.
Other than the web.xml file, where you initialise a lot of ASP.NET MVC settings (like integration with IIS, Membership, Roles, Database connection strings, etc), ASP.NET MVC doesn't use any XML. The things that you do have to do in the web.xml are likely things you'll set up once and never touch again, and so are unlikely to cause messy merge conflicts in revision control. Even user authorisation for page access is not done in XML (unlike JSF, and for that matter, ASP.NET Forms); it's done with attributes in the code.
ASP.NET MVC has a powerful URL routing engine that allows (and encourages) you to use RESTful URLs. When you create page links, ASP.NET MVC automatically creates the correct the URL to the particular action (on a controller) that you want to perform by doing a reverse lookup in the routing table. No double page requests here, and if you change what your URLs look like you don't need to update all your links, you just change the routing table.
ASP.NET MVC inherits the concept of Master Pages from ASP.NET Forms. Master pages let you easily define what every page has in common, then for each page, define only what varies. It's a powerful templating technology.
Communication between pages is easy in ASP.NET MVC since it fully supports getting data from both POST and GET (URL query string parameters). It also provides a neat "TempData" store that you can place things in that will be passed on to the next page loaded, and then are automatically destroyed. This is extremely useful for passing a message onto the next page for it to display an "operation performed" message after a form submit.
As much as I dislike JSF, it does have a few things going for it that ASP.NET MVC just doesn't have.
One of the biggest criticisms of any .NET technology is that it only runs on Windows. And while I may be a big fan of Windows, when it comes to servers, other operating systems can be viable alternatives. JSF gives you the flexibility to choose what operating system you want to run your web application on.
JSF is a standard, so there are many different implementations of the standard. This means that you can pick and choose which particular implementation best suits your needs (in terms of performance, etc). This encourages competition and ultimately leads to better software.
JSF can run in many different application servers, which gives you the choice of which you'd like to use. Feeling cheap? Use Glassfish, Sun's free application server. Feeling rich and in need of features? Use IBM WebSphere. Feeling the need for speed and no need for those all enterprise technologies like EJBs? Crack out Tomcat.
Like it or not, Java has a massive following and open-source ecosystem. If you need something, it's probably been done before and is open-source and therefore you can get it for free (probably... if you're closed-source you need to watch out for GPLed software).
JSF is free, Java is free, and you can run it all on free operating systems and application servers, you can get a JSF web application up and running for nothing (excluding programming labour, of course).
So how does ASP.NET MVC weigh up against the pros of JSF? Not too well.
ASP.NET MVC will only run on Windows, since it runs on the .NET Framework. You could argue that Mono exists for Linux, but the Mono .NET implementation is always behind Microsoft's implementation, so you can never get the latest technology (and ASP.NET MVC is very recent).
ASP.NET MVC runs in only one application server: IIS. If IIS doesn't do what you want, or doesn't perform like you need it to, too bad, you've got no choice but to use it.
Update: A friend told me about how you can actually run ASP.NET in Apache. However, that plugin (mod_aspdot) was retired from Apache due to lack of support. Its successor, mod_mono, allows you to run ASP.NET in Apache using Mono. However, at the time of writing I see multiple tests failing on their test page. I don't know how severe these bugs are, but it's certainly not the level of support you receive from Microsoft in IIS.
Most people probably would have assumed I would bash the .NET ecosystem for not being very open source and that is true, up to a point. However, in recent times the .NET ecosystem has been becoming more and more open-source. ASP.NET MVC itself is open source! All this said and done, Java is still far more open-source and free than .NET.
Although you can download the .NET SDK for free, you really do need to purchase Visual Studio to be effective while developing for it. You'll also need to pay for Windows on which to run your web server.
Other than all the sweet stuff I mentioned above, what else does ASP.NET MVC have to offer?
ASP.NET MVC makes it very easy to write neat, clean and well designed code because of its use of the Model View Controller pattern. JSF is supposedly MVC, but I honestly couldn't tell how they were using it. My code in JSF was horrible and awkward. ASP.NET MVC is clearly MVC and benefits a lot from it. You can unit test your controllers easily, and your processing logic is kept well away from your views.
Web 2.0 is a buzzword that represents (in my mind) the use of JavaScript and AJAX to make web pages more rich and dynamic. ASP.NET makes it pretty easy to support these technologies and even comes with fully supported and documented jQuery support. JSF doesn't come with any of this stuff ready and out of the box and due to its awkward page navigation system, makes it difficult to incorporate one of the existing technologies into it. The JSF way is most definitely not the Web 2.0 way.
Although you have to pay for Visual Studio, it is an excellent IDE to work with ASP.NET MVC in. NetBeans, the IDE I used JSF in, was quite possibly one of the worst IDEs I have ever used. It was awkward to use, slow, unintuitive and buggy. Visual Studio has an inbuilt, lightweight web server that you can run your web applications on while developing. You just build your application and, bam, it's already automatically running. In NetBeans, you have to deploy the application (slow!) to GlassFish and sometimes it will bollocks it up somehow and you'll just get random uncaught exceptions that a clean and build and redeploy will somehow fix. That sort of annoying, time-wasting and confusing stuff just doesn't occur in Visual Studio. You really do get what you pay for.
In conclusion, I feel that ASP.NET MVC is a far better Web Application Framework than JSF. It makes it so easy to code neat and well-designed pages that generate modern Web 2.0-style pages. JSF just ends up getting in your way. While coding ASP.NET MVC, I kept going "oh wow, that's nice!", but while developing JSF I just swore horribly. And that really tells you something.
Update: I've been told that JSF 2.0 (as yet unreleased at the time of writing) fixes many of the problems I've mentioned above. So, it might be worth a re-evaluation once it is released.
Submit Comment | Comments RSS Feed
Unknown (google)
July 11, 2011 11:17 AM
Hi,
Its been a very nice article comparing the 2 technologies based on logic and features.As JSF 2.0 is released now. Do you still believe asp.net mvc is better than jsf 2.0. If yes than pls. comment why?
voidlogic
August 04, 2011 10:29 PM
>>Faces-Config.xml
IDE's like Netbeans but a GUI front end on this. Also, as of JSF 2.0 a lot of this can be done with annotations.
>>No Page Templating Support
JSF has the <include that can be used to add your common headers, footers and navigation columns... If you are copy and pasting you are not using this directive right.
>>Awkward Communication Between Pages and Between Objects
This is just wrong. I have a very small facesLibrary class I wrote and use on every project that lets me access parameters and beans with nothing more than a getParam("Param Name");
>> Visual Studio
Its no Netbeans.... :(
Robert Whane
October 17, 2011 5:43 PM
Hi, interesting to read your comparison. There are a few things not entirely correct, let me explain:
>All of this goes into the one XML file.
This is not true and never had been true. From the beginning one could use the javax.faces.CONFIG_FILES parameter to specify multiple different files. You could have one xml for your managed beans, one for your navigation rules etc.
In JSF 2.x the faces-config.xml files are largely redundant. In JSF 2.1 (current version) there isn't any kind of XML configuration file required if you are satisfied with the defaults (not even web.xml). See e.g. http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config/
Validators, managed beans, and a lot more are now recommended to be declared using a simple annotation (metadata) on the class in question. Navigation can make use of implicit rules, which means you don't define any rule but use the page (view) name directly.
>JSF is a POST->Redirect, GET->Response.
Well, there always has been the h:outputLink, and you could of course use the plain html a href. The downside of these were that you had to specify the full URL. In JSF 2.0 there's the h:link and h:button that support GET based navigation. There's also first-class support available to process GET based requests.
>No Page Templating Support
Also not entirely true. Facelets solves this and has been doing it for quite some time. Three years prior to writing your article, this one appeared: http://www.ibm.com/developerworks/java/library/j-facelets/
It was a separate download back then, but there was very little reason not to use it. Nowadays in JSF 2.0 JSP has been completely deprecated and Facelets is the default templating language.
>In JSF, it is awkward and difficult to communicate data between pages.
For communication between requests to the same page, there is now the view scope. For communication between different pages there are various tools, like The Flash (inspired by RoR, like TempData), GET requests and because JSF can easily piggyback on CDI (new in Java EE 6), the conversation scope. Various extension projects (Seam 3, Apache CODI) allow you to very easily add additional scopes for communication between pages.
>JSF doesn't really support URL query string parameters (since every link is a POST)
As explained above, you could always use plain links or output links. The GET support in JSF 2.0 has first class support for query parameters and the redirect mechanism also allows one to use query parameters.
Please see the updated version of the page you linked wrt communication between beans: http://balusc.blogspot.com/2011/09/communication-in-jsf-20.html
>JSF doesn't come with any of this stuff [AJAX/JS]ready and out of the box and due to its awkward page navigation system, makes it difficult to incorporate one of the existing technologies into it.
Again not entirely true. Among others the a4j (ajax4jsf) library demonstrated very early on how AJAX could be used with JSF. This was actually quite easy. You just put the a4j:ajax tag around any existing non-ajax-aware component and it was ajaxified. This approach has been incorporated into the JSF standard in 2.0.
You could also always use javascript on your JSF views. There was no specific restriction that prevented this.
Hope this helped to clear up things a little ;)
Sujai
February 14, 2012 12:53 AM
I think the blog post needs a revisit as many things have changed now.
I would suggest you to have a look at
JSF 2 (You get the master page and more from this)
Primfaces 3 (http://primefaces.org)
Pretty Faces (http://ocpsoft.com/prettyfaces/)
This fixes most of all what you need. Most of the other things are already explained by Others in previous comments.
We have both .Net team and Java Team, while the JSF team with primefaces delivers faster than the .net team in most scenarios. The widgets in primefaces are amazing, the xhtml file is clean and makes developers comfortable in implementing AJAX too, no javascript code is required except any 3rd party usage comes to the game.