BabbageFaces 1.0 RC2
My guts tell me BabbageFaces is ready to be released into the wild. Most of the time that's a reliable measure. Today I've tested it with the new PrimeFaces 5 showcase. BabbageFaces passed the test without problems. There's also a decent showcase example containing most of the elements of a typical business application, running both on Apache MyFaces and Mojarra. I'm optimistic all that's missing is a couple of source code comments, tidying and documentation to call it a final version.
The showcase demo also shows BabbageFaces allows you to stop scattering ids all around your JSF code just to make AJAX efficient. BabbageFaces compares the response with the current DOM tree and sends only the minimum set of changes to the clients. If network load is giving you headaches, BabbageFaces may be your tool of choice. It reduces network traffic. At the same time, it simplifies the programming model.
Stability vs. performance
As for the current version, I decided to trade some efficiency for stability. Among other things I dropped the <insert> command. This command allows for very efficient AJAX if something's added to the HTML page. Unfortunately, it's also suffering from a couple of compatibility problems. For instance, the syntax of the <insert> command differs between JSF 2.0, JSF 2.2, Apache MyFaces and PrimeFaces 5. I hope I can re-activate the feature in a future version of BabbageFaces.
Another feature I may introduce in a future version is optimized ids. BabbageFaces inserts a lot of ids in the HTML code to make optimizations possible. In general, you don't need most of them, and they bear long names. A future version of BabbageFaces may be configurable to give you a say in which ids are generated, and it may generate shorter ids. It can even replace every id by a shorter id, thus reducing the size of almost every JSF response. However, this can only be done if there's no Javascript relying on the ids, so this feature has to be configurable.
Statistics
Optionally BabbabgeFaces now displays some statistics in development mode. All you have to do is to insert a special div in the JSF page:
I suppose the showcase is more or less representative for real-world applications. By that measure BabbageFaces cuts response sizes in half in average, while adding roughly 40% to the rendering time. In most cases this extra time can be neglected: usually business logic takes much more time than the JSF renderer.
Limitations
However, applications that don't do much AJAX or that contain a lot of manually optimized AJAX don't benefit from BabbageFaces. This is the case with the PrimeFaces showcase. A few requests are optimized, but most responses simply are bigger than the original responses. That's OK: The intention of BabbageFaces is not to be better than a clever programmer (albeit it often is). It allows the developer to concentrate on the business logic. It relieves her or him from thinking about technical stuff such as ids. If need be, the developer can optimize the application later - but even if the developer doesn't, BabbageFaces already delivers a decent optimization.
As a rule of thumb I suggest to always use update="@form". My examples use update="@all", but that's nothing I recommend in a real-world application. I've implemented the examples such that they put BabbageFaces under stress (and show it at its best). Among other things, update="@all" is wasting CPU resources (aka performance). On the other hand, the advantage of update="@all" is you can update the title of the page in an AJAX request without using Javascript.
Visit the showcase!
I've put two versions of the same demo on the
Check out the jar file at the Maven Central.
Now it's your turn!
Now it's up to you. Take BabbageFaces to the test and show me the bugs I've missed :). If you find a bug, please leave a comment so I can fix the bug.