On this page we compare the code sizes of various popular open source Java frameworks, some full web frameworks and some aimed at only part of the webapp pipeline. The point is to encourage people to get involved with living alongside the RSF source, since it is considerably more compact (and hopefully straightforward in design) than other frameworks. Part of this concision arises from the use of Spring, and other parts from the widespread use of generic (in the pre 1.5-sense) approaches based on reflective mapping rather than repeated boilerplate code. This genericism hopefully feeds through into RSF-written apps as well - the RSF Cookbook app, in contrast to most Java ORM apps contains no boring "DAO"-type code at all, only business logic (actually none in this case) and view-building logic.
|RSF (0.7.2)||JSF (1.1fcs)||RIFE (1.2)||Wicket 1.1.1||Spring 1.2.7||Hibernate 3.0||Tapestry 4.0|
|Total LOC||18,000||60,000(API) + 80,000(RI)||170,000(framework)||76,000||275,000||157,000||128,000(framework)|
Clearly these measurements as with all LOC metrics are somewhat artificial. Neither RSF features nor documentation are yet fully complete - however it's worth noting what there *is* already inside RSF, which is peers for all HTML controls, both JSF and SWF-like navigation systems, a generic XML view renderer (IKAT), and an XML-driven template interpreter. I don't think bringing us to the 1.0 release point will close up the gap to the nearest frameworks considerably, on the LOC front.
Another aspect to look at is how 'little' integration code is required when RSF cooperates with another technology - here is an LOC count for the various integration libraries (the count for Servlets is included in the above):
|Java Servlets (full)||560|
The first is a figure well worth looking at - of RSF's 20k lines of code, only 560 of them have a dependence on HttpServlet. It's this sort of thing which accounts for RSF's easy mobility to other environments. The corresponding figure is 11,000 out of 128,000 for Tapestry, and 36,000/140,000 for JSF! With 36,000 lines of coupled code, it is no wonder that portlet applications of JSF struggle - note that this dependence is also *always* available to all JSF code simply through accessing the ExternalContext member of the "kitchen sink" object FacesContext. RSF selective delivery of dependencies, even at request scope, is one of its strongest architectural successes, resulting in enormously more testable and stable designs.
More discussion of code size, especially with regards to coupling, is on the UIComponent page. Code in component base classes is essentially delivered as a dependency to all the rendering code written by users - RSF is getting on for 2 orders of magnitude better than competitors in this area.
You can post comments and questions on this page using the following blog. Please set your name using UserPreferences before posting.