It's true to say that JavaServer Faces came to standardize the way developers build user interface, defining a common API to facilitate the creation of components for web development (and other things). For those who don't know, JSF 1.0 (or JSR-127) had Craig McClanahan as Co-Spec Leader together with Ed Burns.
Let me address one point here: I know Ed and he is cool, and I had a cheap talk with Craig at BrasilOne 2005. Both are cool and their work with the community is great. But I must say: JSF was born with the wrong Co-Spec leader.
So, what's the problem of having McClanahan as spec leader? Well, as you may noticed if you had some time with JSF already, the View tier is basically... Struts (version 1). And what's the problem with that? The web development process with Struts is painful, and for large projects can achieve a high level of difficulty and maintainability, by dealing with huge struts-config.xml files, Action Forms and, let's not forget, JSPs bloated with tags (libraries). How do I call this? The Triple Alliance.
Let's understand, from the developer perspective, what this mean. (this will require a flashback of Struts 1)
While coding, the developer has to look and take care of, at least, three files at the same time. And how these three files are connected? With SOP - String Oriented Programming. Yeah. He/She has to create an ActionForm (Java) and/or an Action (Java), declare it in struts-config (XML) and code/maintain the webpage (JSP: Java, Tag Libraries, HTML, etc...). And all properties, names, etc, are binded by typing their names/ids in fields, like:
struts-config: [..] name="myProperty"
Java: getMyProperty()
JSP:
And this is the same process with JSF. You have to code JSP pages with Tag Libraries (XML), you have to code
Managed Beans (Java) and you have to declare a lot of things within
faces-config.xml. All that with SOP... Triple Alliance! Ok, you can develop JSF with tools, auto-completion, hints and many other features. But why should you need a tool to develop a JSF web application? We want simplicity in the first place, not
toolability.
Why I say Struts is not cool
anymore and why JSF followed the wrong idea? Because the developer has to know
a lot of things, has to control
a lot of artifacts, do SOP coding and been dependent of tools. The conclusion: Struts solved several issues but created new ones (JSF). But I must agree, Struts had market acceptance in the past because it was simple to start developing web applications with it. And addressed a hole of ideas and solutions (MVC) that were needed at that time. Craig, contratulations, really. You did an outstanding work here.
I liked Struts, I worked with it for 2,5 years. But, it wasn't a standard. So, let's recapitulate: if we need a standard [
to sell tools, training, courses, books, facilitate the introduction of vendors,
and not forgetting the ease of components customization], why not stick with what already is a [
market] standard? That's why Struts is the base of JSF's View tier. Is this cool? No it isn't!
They took a market standard and turned that into a specification.
Tapestry 3 was there,
Echo 1 too and both with
very cool ideas. Shouldn't Ed and Craig took a look at them? Yes for sure! If JSF 1.0 was a compilation of Struts 1, Tapestry 3 and Echo 1, I think I wouldn't be here. Now, let's talk about the present...
JSF 1.2 (
JSR 252) is targeted for JavaEE 5.0. And I don't even see JEE 4 in every customer I go, just like JSE 5, so try to imagine
when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including
Wicket, are improving faster than JSF since that time.
OSS frameworks, specially Web Frameworks, keeps demonstrating that the key for a good software is innovation. And from innovation, comes productiveness, because everybody wants to do more with less time. But, to get to innovation, speed is important. Bureaucracy is the enemy!
What JSF 2.0 (
JSR 314) offers, and will deliver only next year (target: JavaEE 6, after April 2008), you can get from any framework
today.
Google Web Toolkit is an example of that. Wicket is another good example. These frameworks grown up faster than anything else, because they aren't standards. They doesn't has to wait for a series of other specs to be launched.
[
I can't forget to show you why I think Wicket is cool]
To have productiveness, there must be simplification in the development process and, from the developer perspective, simplification of coding. There's no Triple Alliance in Wicket. There is some SOP, yes, but not in the same way. There aren't tag libraries and no XMLs. It's pure Java and pure HTML.
Take a look.
Ed, one advice: invite Eelco, Matijn and the hole crowd of Wicket commiters to a
small talk! :D
Post note:You may think this post is just
FUD, you may even think it's just to promote other frameworks like
Wicket, which I post about sometimes. But believe me, it's not.
The purpose of this post is to share with you, my ideas and thoughts of why JSF is not cool [
yet], why it doesn't has the productiveness I want [
and need] and why you should consider moving to some Non-Standard OSS Web Framework. Still, I hope newer releases of JSF, like 2.0, brings ideas from the frameworks I mentioned here.
Link para este post
10 a 12 de Setembro de 2008
O dia começa, e preciso iniciar um projeto. De costume, chamo o 
