Reasons to why I'm reconsidering JSF

In December 2010, I wrote a blog post entitled "Top 10 reasons why I don't like JSF", and I would guess that 50% agreed with me, the other 50% did not. No surprise, it's like religion.

I always liked to research products, projects, frameworks and Java technologies in general, but specially in the Web Development area. In 2001, I started coding JSP and Servlets, just a few months after I learned how to program in Java and do OOP . Did my first web application connecting to an Oracle DB with pure JDBC. Learned from the basics, on my own and succeeded.

Later I got a new job, thanks to my experience in Web Development, but my employer was using Apache Struts. I knew about that upfront so I studied it before my interview. Got hired. Struts back then, wasn't that hard for someone already with knowledge about HTTP request/response architecture and the Servlet specification. Then came JSF 1.0. I didn't like it. Complex. Way too much. Struts was much simplier. JSF 1.1? Same thing. Small improvements only.

So I moved to something different. In 2007, I heard about Apache Wicket. Then I became an independent evangelist. I gave several talks in Brazil, for years, spreading my word about Wicket, at every conference my talk was approved. I even created a community, Wicket em Português, for Portuguese speakers. I also offered an online training for it. I was offered a job proposal just because I knew Wicket, in Rio de Janeiro in 2010.

Now, the reason I told you all this is to show you that I'm used to choose what works best for me, at a certain time. I do change my opinion over things. It's something like, readaptation. We all should readapt. Every time. Just to demonstrate: I was born in an island, Florianópolis, then I moved to São Paulo, later I moved to Rio de Janeiro. Now I'm back to São Paulo. My accent changed, thanks both because I like to talk like others to make jokes, but also to feel like a local. By the way, I'm a CouchSurfer. I enjoy traveling and being with, and like, locals.

Now let's get to the real thing: Java Server Faces 2.2. The version that is leading me to readaption.

Before start, I should point that I now work at Oracle and I advocate in favor of Java EE. I'm friend of Arun Gupta, Reza Rahman, Ed Burns and several other folks who are Java EE advocates, also some who are not Oracle employees.

When I wrote about the things I didn't like in JSF, some were technical, others were related to its ecosystem and the market. Things that change, that evolve. And they did.

1. Pure HTML
I talked to Ed Burns several times about the way we design pages in JSF, with tag libraries. At the first opportunity, years before joining Oracle, I told him: "Hey, why don't you make it look like Wicket?". Facelets came at some point between that day and later. Now, in JSF 2.2 it's possible to define a page using pure HTML, letting the browser do the preview without much hassle. Something I enjoy a lot in Wicket and other frameworks. Something I talked a lot at my presentations. So here it is, the community (represented by myself and many others), influencing change in an specification.

2. Implementations
I think that relying on whatever is running on your application server (Mojarra or MyFaces) is better. If you are considering JSF, you should choose a Java EE certificated app server and just use whatever comes within. Life will be much easier this way.

3. Creating custom components
In JSF 1.x, creating a custom component was more difficult than creating YAJWF. Now is a one-file-in-a-directory only. It's very easy to compose a custom, reusable component. This post will give you an idea.

4. Documentation
I used to complain about JSF documentation (fragmentation). Apparently, documentation got a lot better. The Java EE 6 homepage at Oracle offers hundreds of pages of documentation. Of course you can always look somewhere else for docs, but I would go to these first, as these are the "official" docs, much like when you go to SpringSource for Spring MVC documentation.

5. Tooling Support
I've been playing with NetBeans for quite a while and it is a good IDE for Web development. But if you are really into HTML5, then you will like JSF inside NetBeans. The IDE now provides a feature, from Project Easel, that integrates with your browser and provides debugging and many other features. Good for someone doing HTML5 development with JSF 2.2 and JAX-RS. By the way, there is some work going on, according to Ed Burns, on integrating JSF 2.2 and JAX-RS 2.0. So let's keep an eye on that.

6. Other new features
Some otther new features are about to come as well. Here are some tickets in JIRA that are being prioritized, like:

• Loading Facelets through ResourceLoader
• Ajax File Upload component
• Cross Site Request Forgery Protection
• Faces flows

99. Java EE advocate
I always was an advocate of the platform though never of all of its specs. And one of the reasons I took the job at Oracle as Product Manager, was because I have been working with Java EE since... ever. Not with JSF specifically I confess, not always, but I was already considering it since it turned 2.0. And facing the challenges of teaching developers to do non-Java EE development the right way, I had been thinking of adopting it fully, simply because it's easier to find skilled developers of the platform. This is a great deal for employers when their time-to-market is important.

Still... some gaps
If there's something that I still think that happens, is the compatibility between implementations. The TCK does not cover everything, because of gaps in the spec. So it's not guaranteed to say that a project running with PrimeFaces or RichFaces on top of Mojarra will run just fine if you move it to an application server running MyFaces. But this is something that can be fixed, and I'm sure it's being addressed by all parties (JSF EG, myfaces-devs and mojarra-devs).

Also, it would be nice to see more things like server-side UI programming, as it happens with Apache Wicket. Maybe even having support for different languages? It would be nice to have the server-side UI logic in Javascript, for example. :-)

Java EE 7 and the future
Non standard frameworks are good for innovation. Some may not agree, but JCP and standards are not that slow anymore. Of course they still are if you compare to stuff like Node.js, Wicket, Liftweb, Play!, Rails and other great alternatives for web development. But look at JSF 2.2 and Java EE 7. We are about to see the new version of Java EE about the same time as HTML5 comes to a final version. In old days, it could be like having Java EE supporting HTML5 in... what? 2018? Not anymore.

Also, if you want to use JSF with CDI, you should really consider an application server with at least Java EE Web Profile, like Apache TomEE. Oracle GlassFish and JBoss are another option if you are looking for open source solutions. The reason to choose a compliant Java EE app server is that they already offer (and test) these kinds of integrations (e.g. JSF with CDI).

So yes, I look forward to Java EE Platform 7.0, not only as an advocate, but specially as a developer. I'm seeing its value, its improvements, and its readaption to the market.

Openness to Change
Let's not forget, the Adopt-a-JSR program offers the community, a great opportunity to participate, speed up, and improve even more the platform and all of its specifications. So here's your chance to ... why not, fill the gaps? :-)

Cheers!