10 reason why choose MyFaces Core as JSF implementation for web applications

A common question on the internet about JSF is "... which JSF implementation choose for my web application? ...". Given that there are two implementations of JSF spec (MyFaces and Mojarra), and from a common developer point of view both do the same (both implement a standard specification), it is difficult to see which choice works better for your particular needs. Note this is written on June 2011, and the version we are taking about is the latest ones available 2.0.7 and 2.1.1.

Well, in this blog I'll give you 10 reasons why MyFaces Core should be your choice. After read this, is your choice to decide which one take for your next web project.

1. Community over code: MyFaces community counts with a lot of folks with outstanding knowledge on JSF. Suscribe to user and dev mailing lists are the best way to know what's going on, receive feedback and know other people interested in JSF. This is an important consideration, because sometimes you can find a bug or need to ask something to somebody about JSF.
2. Innovation happens on MyFaces: MyFaces is not just a JSF implementation, it host other projects (Trinidad,Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....) that provides additional functionality not provided by JSF implementation itself. Many of these projects are compatible with both MyFaces and Mojarra, but you should note that those projects helps MyFaces Core to keep code in good shape, because all those projects test against MyFaces Core, and if there is a bug, it is handled more quickly (because everything is handled "in home").
3. MyFaces Core has better compatibility with facelets 1.1.x: Sometimes it is easy to find some use cases with combinations of c:if, ui:include, c:forEach and other tags that causes problems when they are upgraded to JSF 2, because it has some problems with partial state saving. Just set org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param to true and org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE to true, and a special mode will be activated.No c:if tags or c:forEach or ui:include broken anymore, because some parts of the tree are marked to be restored fully, just like on JSF 1.2.
4. MyFaces Core composite component feature is built on top of facelets template client mechanism: special care has been taken to ensure tags like ui:composition, ui:decorate are correctly resolved, even inside composite components and other complex cases. No "component relocation" is used for implement cc:insertChildren and cc:insertFacet like in Mojarra, so that means state will not get lost inside composite components. This issue in Mojarra is really serious, but people are working there to get it fixed. 
5. MyFaces state manager takes into account multiple window cases: Since 2.0.7 and 2.1.1, a new web config param
   org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION was added. This param is only applicable if state saving method is "server" (= default). Indicates the amount of views (default is not active) that should be stored in session between sequential POST or POST-REDIRECT-GET if org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION is true. For example, if this param has value = 2 and in your custom webapp there is a form that is clicked 3 times, only 2 views will be stored and the third one (the one stored the first time) will be removed from session, even if the view can store more sessions org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION. This feature becomes useful for multi-window applications. where without this feature a window can swallow all view slots so the other ones will throw ViewExpiredException.
6. MyFaces server side state saving does not use a buffer to place javax.faces.ViewState token: Before 2.0.7 /2.1.1 and on Mojarra, a buffer is used to store temporally everything before the end of the first found form. Then and algorithm replace javax.faces.ViewState token with the state and the output is flushed. MyFaces uses a clever strategy to that prevents use that buffer when server side state saving is used, reducing memory consumption over requests.
7. MyFaces Core cache EL expressions when necessary: this will be a new feature proposed for 2.0.8 and 2.1.2 (not available yet but you can try on a snapshot), and in few words that means no EL expressions will be created if is not necessary. This have an important impact on memory comsumption and speed.
8. MyFaces Core is "OSGi" friendly: It provides some SPI interfaces to deal with special setups, when you need core control over classloading. A lot of good stuff has been put in this area.
9. MyFaces Core provide uncompressed versions of javascript files: when project stage is development, you can set org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS web config param to true and the base javascript files will be used instead the compiled bundled jsf.js. If it is false, by default the bundled jsf.js but uncompressed will be available. That makes easier find ajax bugs, which usually tends to be difficult to solve.
10. MyFaces Core generates code using myfaces-builder-plugin: these project is a maven plugin that with myfaces-builder-annotations provides a jsf development kit to create multiple artifacts (components, converters, validators, client behaviors) and handle all documentation related in an easier way, minimizing the number of files you need to handle. It uses java annotations to feed all related information, and each myfaces jar using this tool has a myfaces-metadata.xml which contains all meta-information required to build each bundle. This tool can read composite component definitions and build an integrated documentation with your normal components, converters or validators.

These 10 reasons are only the "tip of the iceberg". There are more reasons why choose MyFaces, but I hope the previous ones are good enough to convince you to at least give it a try!.