Here is a tiny advertisement for reinventing the wheel.

Many years ago I was faced with the problem of how a large utility
could convert huge amounts of code from one platform to another.

It occurred that a utility of that size could probably afford to
create its own meta programming dialects with application specific
extensions specially for them, and translate it to various platforms.
This would include the scripting JCL  languages. That would keep
hard-to-translate platform-lock-in features out of the codebase and
give them maximum flexibility in selecting new incompatible hardware.

Then they would never be at the mercy of a particular platform, or
language, or package.  It sounds like a very expensive proposition,
but you have to offset that against the cost of conversions.

The idea is less viable now as coding has become more complex.

The other advantage which will never be appreciated until you have
actually done it is when ALL the code is yours, you can always find
bugs rapidly, and further there simply aren't any.if you build
carefully.  So many bugs are actually caused by hooking together
software written by authors who have never met.

The hidden costs of using somebody else's class library include:

1. they can change the price at any time, especially run time
licensing.

2. they can drop the product.

3. they can refuse to fix bugs.

4. you can't fix bugs without source.

5. bugs in your apps are harder to track without source to the
library.

6. you never truly know how the package works without source.

The hidden cost of using your own library include:

1. there are fewer eyes looking bugs. It is up to you to find them
all, more likely in production.

2. there are more minds thinking of ways to improve the product.

3. the product will be more flexible.  It won't be designed just for
one application unable to handle extensions easily.

4. It always takes much longer than you think to write, debug and
maintain a library.  The cost of creating somebody else's code is
shared over all their customers.

5. somebody writing code for the market is likely to have a bigger
time budget to research the latest algorithms.

I've been thinking that the main attraction of JSF
is that it is a blanket abstraction of the Web
dynamicity. Amy Fowler's forcible idea a la
Swing event model.

What kind of abstraction do you want to be added
to the future JSF spec or implementation?