>
>
>
> On the other hand, I'll note that the above mentioned fragmentation was
> also very commonplace in the domain of JavaServer web frameworks before
> JSF came along, indicating that an open standard is still possible in
> the space. The only contender I see is W3C web components.
>
Web components define the component model, but not all of the other stuff
you need to build the app. It's pretty much like the UIComponent hierarchy
with some requirements for how it's supported, how you author the
component, and of course standard events (called lifecycle callbacks). It
doesn't include anything like the EL (currently), controllers, etc. What I
see happening is that the JS frameworks will evolve to support web
components (Angular and Ember have already said they would do this).
Polymer provides more of the application plumbing, like data binding and
Ajax integration, although I suspect Angular + web components would be much
powerful.
So, from my perspective there isn't really a contender for a "standard"
JavaScript front-end web framework at this time, since it would likely
include a lot more than pure web components provide.
The opportunity for JSF, from my perspective, is alignment of the
server-side (JSF) and client-side (web components) component models, and
server-side integration. The latter is really a major selling point for
JSF; you don't have to worry about marshalling your objects back and forth.
What would be cool, I think, is the ability to specify whether event
handlers run on the client on server.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
>