Execution flow


Boomla was designed around a simple and likely familiar concept.

Locate target file

Boomla is built on a filesystem. When a request is made, Boomla will look up the file matching the URL of the request.

In the traditional world, when a visitor goes to index.php, the PHP interpreter will be executed due to the file extension being php.

In the Boomla world, there are no file extensions, instead files have a type property. The file type determines the app that shall be executed.


There are some built-in interpreters, like html-1 for templating and sjs-3 for running server side JavaScript code. If the type of the target file is one of these, the code in the target file will be interpreted much like it would be in case of an index.php file in the traditional world.

Alternatively, the file type may specify a user space app, which is either written by you or someone else. Let us come back to this later below.

What makes Boomla stand out is how easy and clean it is to delegate work. Again, see below.

Format response

Boomla does some post-processing before returning the response to the visitor. This mostly affects text/html responses. Boomla does stuff here that most people don’t care about - but benefit from having solved centrally.

Examples of what happens:

  • Authentication code is injected if required.
  • Boomla Toolbar and other client-side tools are injected.
  • Browser security is configured (Content-Security-Policy header).
  • The result is compressed if possible.
  • Resource URLs are modified for caching.

That’s it! It is almost too simple, so naturally you may wonder how this helps building rich websites.

Building rich websites

Web pages have contents. Imagine drawing circles on logically separate stuff on a page. It could be a menu, a header, a footer, some main text block and maybe a comment area. In Boomla, these are called contents and they are stored in individual files. Your page file is simply a template with placeholders for the contents. This could be a valid page tempalte the html-1 interpreter understands:

header.js and :c:1 are selectors that match one or more files on the filesystem. :c filters for contents, :1 filters for files in placeholder 1.

Once those files are selected, they are executed and the result embedded into the template in place of the <? inline(..) ?> code snippet.

There are some tricks though. For example, contents may also return <head> tags. Boomla will collectively embed all the required head tags into the head of the page template. This allows you to fully decouple the content from the page.

User space apps

You will typically have a few page templates and no more. Storing the template code in the page file itself is a bad idea, as editing in a single place is easier. To support this, you can turn any code into an app.

In its simplest form, a page-template app may contain the following files:


The .Request would contain the relevant code. If you are familiar with object oriented programming, the layout will look familiar. .Request is a method of the app that is executed when a request is to be served. Similarly, there is an .Inline method that is executed for inlining contents in pages.


Before embedding contents into pages, Boomla will look for any stylesheets associated with them. These stylesheets may be stored in the content file directly or in their associated apps, for example at .Inline/.Style. It is optional to use .Style files, but they are automatically namespaced for you to avoid naming conflicts - read more on this if you are interested.