Portability

Whatever code the user must write for their Sapling project must be portable elsewhere.

Purpose

Via hooks, the user can write their own arbitrary JavaScript code to be executed for or in tandem with a route. These hook definitions can end up becoming quite complex and important, and containing valuable business logic.

Eventually, some projects may outgrow Sapling, and need to move on to a "proper" framework that does things The Right Way. In these cases, the code in the hook definitions should be as portable as possible, so migration to another framework is as easy as possible.

When deciding whether to adopt Sapling in the early stage of a project, the user shouldn't have to worry about being locked in to Sapling for the foreseeable.

In practice

To make code as portable as possible, the hook definition should be as dry as possible.

The user must have the opportunity to use Sapling's classes to make their lives easier. However, using Sapling's proprietary stuff in a hook must always be optional.

Thus, if the user chooses to keep to their own proprietary code, in theory, it should be possible to copy-paste the code from a hook into any Express middleware and it should work largely out of the box.