Sean Schofield wrote:
I think a big problem for JSF is that there are some crucial things
missing that most web developers take for granted. Most of that is
being addressed in JSF 1.2 but that is a long ways off.
I think there were three big areas
clientId was one of them
the second one were several APIs crucial to early success with to few
documentation on how to make things easier.
The overly complicated (although I can see why things have to be that
way) component API did not help to bring out huge component sets early on.
Although there were shortcuts, it was the lack of documentation in
combination with the openness and difficult component API which stopped
a huge number of components in the beginning stages probably.
That did not help the adoption.
The Struts bridges were clearly missing to a big extent.
It did not give additional value on the first sight over other existing
frameworks.
A clearly well documented component API from day one with best practices
reachable by anymore would have been a major plus.
Adding some kind of scope system with dialog scopes would have been a
clear + for anyone using JSF on the first sight (one of the points
discussed in the excellent article someone posted on this list a while ago)
Good Struts bridges from day one would not have been critical but would
have helped to move people over.
Two big ones jump to mind. The clientId problem was big for me.
That's why I added forceId. Nobody wants a framework changing their
element ids when trying to write complicated javascript. Also, the
verbatim thing is really awful. Once that's fixed you will get lots
more people jumping onboard. I understand its a complicated problem,
but the JCP folks also need to understand that will be a major turn
off to many web developers.
I like to work with the cutting edge stuff and there is plenty of
benefit to using JSF now. But if you are less adventurous, you may
want to wait until JSF 1.2. There will also be a lot more components
to use by that point.
