jadum

Works just like jade, except that the CLI compiles views producing a syntax like below.

module.exports = function (model) {
// view rendering...
}

The other difference is that the traditional Jade compiler inlines partials when it finds include statements, whereas jadum uses require statements to reuse partials, saving precious bytes in client-side code.

Install

npm install -S jadum

CLI

The CLI works the same way as the one in jade, but it always compiles views for the client-side, as Common.JS modules.

jadum views/**/* -o .bin

API

The API is the same as the API in Jade, but it produces require statements instead of inlining include statements.

Comparison

Take as input these two files: listing.jade and item.jade.

h1 This is some awesome listing!
ul
each item in ['a', 'b', 'c']
include item

li
span Here comes item:
span Note that this is quite a big template file
span But it's included everywhere, because Jade!
span So that's awesome... but compiling becomes an issue...
span=item

As the item.jade template grows, every template that depends on it will grow twice as much, as the included template (item.jade)is inlined twice in its parent (listing.jade) template! Here is the output of jade.

If we use jadum, however, we don't have these issues. We'll always have a fixed size determined by the length of the path passed to require statements. Pretty neat! Since jadum understands Browserify it won't hope for the best, in terms of expecting the Jade runtime to be globally included in your code. That's why there's the extra require at the top for the runtime. Browserify will take over when compiling the template, making sure it's only included once. Furthermore, if you use thee template in various places, then it will only be included once. That's where you save the vast majority of bytes.