Java Server Faces Must and Will Die
In his latest Blog/Podcast Tim Shadel shares his team\'s negative experience with JSF. I must admit, I NEVER liked Java ServerFaces. And not only for the reasons mentioned by Tim. Many complaints from Tim may be relevant to Tapestry as well. Yet, I like Tapestry. I think it is a niche framework but I have used it on some projects and do not regret. These projects were intranet, web-based applications, though. I don\'t think I would use Tapestry for web. I would not use Java ServerFaces at all, though.
Here are my two cents why I hate Java ServerFaces:
"Rocket Scientists" who forget about simplicity and tend to build overly "generalized" (bloated is a better word) theoretical models are doomed for failure.
JSF would have never made it, if big vendors did not support it so much. Sun went religious about JSF without any real, objective reason to support specification that nobody ever tried in real life. Usual problem of JSR: coming up with spec before the implementations (Oh, God!). This zealous support will help for a while. But, in the long run JSF has to fail and get replaced by something much simpler/elegant, in Java. Or else - serverside Java will fail with it and everybody will begin using RoR or whatever other crap will be out there at that time. Sad. I really do not like Ruby, as a language (no, I am not static typing fan, I love Python) and I think RoR is not that good, at all. I will miss a vast wealth of open-source Java libraries and frameworks, too.
So, repeat with me and memoiaze, before it is too late - Simplicity is the key!
Rickard Oberg (I think) once said that the value of a framework is not in what it allows but what it does not allow to do.
I think RubyOnRails proved that point very well. And I think, contrary to what Tim Shadel says in his Podcast (even though he has many valid points) the main problem of JSF is not what it does not allow but how much it allows and how bloated it has become because of it.