Yes you basically missed something, this seems to be the entire
intention if the JSF api, to provide a core foundation.
The mechanism you describe, is one of the few aspects of the component
API of JSF, I really like, it is called component pack.
Usually once you have a component pack, you just dump it into your
WEB-INF/lib and be done with it on the backend side.
On the client side you just add the include, thats it.
A component pack is very easy to create once you have the component up
and running.
As for the components themselves, they are hard to implement, and with
hard I mean hard, I never had to deal with an API for ui components
that was that hard to grasp (And I had to deal with quite a lot)
I think, the best way to encourage people to write their own components
would be to simplify things back to a sane level at that part of the API.
Having a pure client side component mechanism would be a first start.
Providing a shortcut which can cover 99.9% of all backend cases, would
also help.
The current state of affairs, with having to deal with 2 config files (3
if you dont roll a component pack) and three classes in the worst case
to roll a single component, and having huge leaks in the base api for
simple things like data traversal between the tag and the component
(which Myfaces fortunately delivers but JSF not)
and having to deal with a mixture of callbacks and config entries for
binding all this stuff together is simply too hard, to have people hop
onto the bandwagon.
What we would need would be to cut away the config file mess (could be
done via meta tags)
provide a clear well documented foundation with good helper methods for
every aspect of component creation at source level and a good set of
howtos to have people do that stuff.
Not having to deal with component group... render group etc... mixtures
on config file and source callback level even would help a lot
either have that stuff on source level or on config file level, but
please not on both, that makes things outright confusing.
