UIComponent is the base of the RSF "component" hierarchy, for which the entire code appears here (minus comments):

public class UIComponent { 
  public String ID;
  private String fullID;

  public String getFullID() {
    if (fullID == null) {
      fullID = RSFUtil.computeFullID(this);
    }
    return fullID;
  }
  public UIContainer parent;
  public DecoratorList decorators;
}

The extreme slimness of RSF's component hierarchy is one of its core design principles, and where it diverges most strongly from every other web framework that is in any way component-based (i.e. including such component frameworks as JSF, Echo, Wicket and Tapestry, and excluding those pure markup-based frameworks/languages as Struts, PHP, Ruby and plain JSPs).

RSF's components fulfil the minimum function possible, that of encoding the relationship between named regions of the viewable markup, and named locations in the request model. At its base, an RSF component is simply a pairing of (component ID, request EL), together with an associated type. Rather than encoding any behaviour at all, an RSF component simply encodes a mapping - all behaviour is expected to be well out of framework code, held in the request model. Being fully and trivially serializable as an XML document, an RSF component tree really represents an "Intermediate View Language" or IVL, being ideally suited to aggregation (portal) or "late rendering" scenarios.

As a comparison, here is the quantity of framework-coupled code which every component from the following frameworks is obliged to take on as a result of code present in framework base classes (for example in JSF, this is the sum of LOC from both UIComponent.java and UIComponentBase.java):

RSF gets out of the way of user code absolutely as quickly as possible. Note that in the development line stretching from Tapestry towards Wicket this situation is actually becoming *worse* and not better - rather than seeing more streamlining and elegance, we are seeing progressively greater framework intrusion and coupling.

Note that RSF's streamlining is *not* at the expense of application interactivity or dynamism, as can be seen from the extreme ease of integrating AJAX and other event-based technologies. Contrary to the claims of component-framework authors, heavy server components are not a requirement for interactive applications - in RSF interactivity is a choice made by the *developer*, not the framework, who gets the benefit of modelling interactivity where it belongs, in their own business model, and not forced into a model pushed on him by the framework. This means that RSF can easily accommodate every application model between the extremes of a virtually static site with perhaps no dynamic application state at all (Darwin Online) and highly dynamic and stateful applications e.g. NumberGuessing/FlowTalk.

More discussion on RSF components is at Component and ComponentTree. More framework size comparisons are on FrameworkSize, including some warnings on the validity of sheer LOC measures.