This slogan grew out of various observations that arose during the development of RSF. In two areas, a common pattern emerged through trying to reduce the burden (either conceptual, or practical) that clients of RSF suffered through dependence on it - firstly, in the component tree, and secondly in the data model itself.

In both cases, RSF had examples of previous frameworks that forced some concepts of persistence on their users, by attempting to "manage" the scope of objects of these classes, beyond the immediate domain of the request where they were valid.

For example, a central bugbear with JSF was its insistence on preserving the entire component tree between requests - and although it did provide StateHandler and ViewHandler interfaces where this behaviour could be customised, the rest of the codebase embodied assumptions about its persistence that had to be continually fought.

Tapestry, on the other hand, supports various kinds of scope for entities that it manages, which are in general intrusively specified by means of base classes or interfaces.

RSF, on the other hand, "specifies" that both the component tree and application data model (from its point of view) will be destroyed on request end. It can be seen that destruction and preservation are asymmetric with respect to their dependency burden - while it is perfectly permissible for an application to have "mysteriously" preserved something that was meant to be destroyed, it is semantically invalid for it to attempt to destroy something that the framework insists should have been preserved. In the latter case, it must invoke some framework-specific function or customization point to perhaps get this done, which may not even be there.

It is this destructibility which promises to make RSF extremely extensible in terms of the data models and component producers which it is capable of supporting - at the extreme end, it is even conceivable for it to be backed by a completely persistent and single-instanced data model in environments where the UI is tightly coupled to the back-end (e.g. a desktop GUI). Not that there are any immediate plans for trying such a thing, since it is probably an ill-conceived plan (see Echo for an example of going down this road), but it is good to know that routes of this sort are not closed off by design.