Actually, we are big fans of modular libraries. We know that a lot of the code in Derby and Racer is too monolithic, and we intend to restructure as the projects mature. For example, we already refactored out Derby's simple HTML parser (https://github.com/codeparty/html) and our wrapper around Express for routing on the client and server (https://github.com/codeparty/tracks). These are now indendent npm modules that were originally part of the Derby codebase. Also, as you mentioned, the Racer data-syncing and model library can be used separately from Derby.

Derby is an npm module, and developers are in control of their own standard Node.js/Express server files. We use Browserify (https://github.com/substack/node-browserify) to bundle up scripts, so you can use any standard npm module on both the server and the client without modification.

We have a long way to go in terms of customizing Derby; however, it is already very flexible in some ways. For example, Derby apps can be rendered and sent to the client from Express routes or via Derby app routes. There's also a method to simply get a blob of rendered HTML or render a static page using the same templates. Derby includes model-view bindings, but it's simple to bind some things and not others or nothing at all.

Much of Derby and Racer is very different from how web apps are written today, and we are focused on iterating quickly to start. As it matures, Derby will become more of a collection of independent modules. That way, most developers could use Derby out of the box, but others could fork the project and customize or use features of the framework independently. It's a ways off, but that's the long term goal.