Sinatra: Up and Running

Chapter 4. Modular Applications

In Chapter 3, we saw that normal Sinatra applications actually live in Sinatra::Application, which is a subclass of Sinatra::Base. Apparently, if we don’t use the Top Level DSL, it is possible to just require 'sinatra/base'. And it shouldn’t be surprising by now that it is common practice to actually do so. If we do, we usually don’t use Sinatra::Application, but instead we create our own subclass of Sinatra::Base.

This style is called a modular application, as opposed to classic applications that are using the Top Level DSL. While classic applications assume a certain style by default and extend Object, starting with a modular application assumes next to nothing about your application setup.

Caution

For some reason, it is a common misconception that modular applications are superior to classic applications, and that really advanced users only use modular style. From time to time it has even been proposed to drop classic style all together. This is utter nonsense and no one on the Sinatra core team shares this view. Sinatra is all about simplicity and if you can use a classic application, you should.

But why would one want to use modular style? If you activate the Top Level DSL (by requiring sinatra), Sinatra extends the Object class, somewhat polluting the global namespace. This is not as bad as it sounds, since all delegation methods are marked private, just like Ruby’s built-in global methods, like puts. But still, especially if you ship your Sinatra ...