Tag Archives: Handlebars

Introducing Marionette-Require-Boilerplate for Your Single Page Application

Marionette-Require-Boilerplate (MRB) is a simple boilerplate I created to help get Single Page Applications off the ground with a small starter project. It incorporates a number of great tools and best practices to save time in the early stages of a project.

MRB integrates such cutting edge libraries as Backbone, Marionette, Require, Grunt, Jasmine, Bootstrap and jQuery Mobile, among others. These libraries work together to help you start your project off with a rock-solid foundation, with a powerful module system, composite architecture, simple build process, and unit tests. Marionette-Require-Boilerplate is part of the BoilerplateMVC suite, which includes standouts like Backbone-Require-Boilerplate, the inspiration and basis for MRB. Stay tuned for more from the BoilerplateMVC team!

The GitHub repo has more extensive documentation, but in this post I’d like to introduce some of the underlying technologies and explain what makes MRB a great place to start for your SPA.

Marionette

Marionette is a framework that sits on top of Backbone and provides a composite architecture and a set of tools to help you solve some of the most common problems in Backbone applications, including nested views and layouts, memory management and cleanup of zombie views, and event-driven architecture. Backbone is a fantastic library and provides many useful pieces, but its great strength — lightweight flexibility — is also its great weakness. It is not a framework and leaves you to figure out some basic functions, like how best to create and remove views, or how to nest views within each other.

If you are not confident in your ability to competently architect a Backbone JS application, or you’re just looking to save time, then Marionette is the tool for you. Read more about what it has to offer in the Marionette chapter of Addy Osmani’s Backbone Fundamentals e-book.

Require

RequireJS is the most popular implementation of the Asynchronous Module Definition (AMD) spec. It provides a powerful, flexible and consistent way to organize your application into separate modules with clearly defined dependencies. It allows you to load these modules as separate files asynchronously in your code, or use the r.js optimizer to load all of your modules in a single, minified JS file for production builds.

Note: Marionette has a concept of Module that is very different from the RequireJS “Module” concept. Do not confuse the two. In Require, a module is simply a unit of code that is run once and returns a function or object of some kind for use in other modules. In Marionette, a Module is essentially a section of your application that can be started or stopped, serving as a coarse grain method of organizing your code. It would be possible to define a Marionette Module in a Require Module if you like, but your head might explode.

Bootstrap and jQuery Mobile

Twitter Bootstrap is a leading front-end UI framework for building rich web applications. It includes a large set of CSS classes and jQuery widgets that you can add to your markup to transform it into beautiful, sleek and customizable UI elements. It is an ubiquitous framework — popular because it helps developers who lack certain design skills to easily crank out clean, elegant UIs with minimal effort and non-invasive code and CSS. jQuery Mobile is a leading UI framework for mobile applications that builds on jQuery UI and brings a number of mobile-friendly widgets and controls to the table.

Mobile vs Desktop

MRB uses a scheme (borrowed from Backbone-Require-Boilerplate) that detects the user’s browser and loads either Bootstrap or jQuery Mobile accordingly. It also loads either the Desktop Marionette Controller or the Mobile Marionette Controller. In Marionette, a Controller handles a Router’s routes, and is used to instantiate Models and Views and show them in appropriate Regions or Layouts.

In MRB, the Mobile/Desktop Controllers load Views which work with either jQuery Mobile or Bootstrap (for instance, MobileController loads a MobileHeaderView, while DesktopController loads a DesktopHeaderView). This is our strategy for differentiating behavior and UI elements for mobile or desktop. This is just my strategy, and it may or may not work well for you, so take it or leave it. If you don’t want to worry about the mobile/desktop dichotomy up front, you might consider checking out Marionette-Require-Boilerplate-Lite, which eschews this division and skips jQuery Mobile in favor of a purely Bootstrap approach. Whichever you prefer.

Grunt

Grunt is a first-rate build tool built on Node which allows you to run any number of compatible plugins. In MRB, we use Grunt to execute our RequireJS Optimization, minify our JavaScript and CSS, and run JSHint to detect bugs in our code.

Jasmine

MRB uses Jasmine to execute and manage unit tests. Jasmine’s syntax is very readable and makes it an attractive choice for unit tests.

Handlebars

Handlebars is our templating engine of choice. It offers a clean, friendly syntax that discourages excessive logic in your views, and is a popular choice these days over EJS-style templating options like Underscore’s _.template(). In MRB, we use the require-handlebars-plugin to automatically load our templates as AMD modules, pre-compiled (read: big performance boost) and with custom helper methods and i18n support.

Node HTTP Server

MRB runs a simple Node HttpServer on port 8001. This is not necessary, but since Grunt and the RequireJS optimizer both run on Node, it is a reasonable assumption that the user will have it installed. If you don’t want to run MRB on Node, you can just as easily point a simple Apache web server at the public/ directory in the project. A web server is required; using the plain file system won’t work because of RequireJS’s dynamic loading of resources.

Best Tools plus Best Practices

With Marionette-Require-Boilerplate, I have attempted to bring together a collection of great tools and best practices to help web applications get started quickly and with a firm footing. I hope you find it as useful as I have. I’d love to hear your feedback, so follow me on GitHub or hit me up on Twitter!

On Templating in Backbone

I recently saw a post on Hacker News about adding custom extensions to Handlebars which allow you to call methods on the data that is passed to your Handlebars template. Before I had a chance, someone astutely pointed out that Handlebars is designed for logicless view rendering, but that other templating solutions do offer the ability to include real logic in your templates.

This got me thinking, and I thought I’d share what has been my approach to templating in my own Backbone apps.

Handlebars – beautiful syntax & logic made difficult

Handlebars is designed to be semantically pleasing. It’s hard to beat in terms of syntax:

<h1>{{title}}</h1>
<ul>
  {{#each people}}
  <li>{{this}}</li>
  {{/each}}
</ul>

When it comes to logic though, you are limited to a few basic built-in helpers or are forced to add your own custom helpers. For instance, if you want to check for whether a description attribute is truthy, you can do this:

    {{#if description}}
       <span>{{description}}</span>
    {{/if}}

But if you are looking to check whether an attribute matches a given value, you are out of luck.

Does not work

    {{#if age >= 21}}
        <h1>Drink up!</h1>
    {{/if}}

This is a reasonable thing to wish to do, but to do this in Handlebars would require you to write your own custom extension, like so:

Helper method
    Handlebars.registerHelper('isLegal', function(val, options) {
       if ( val >= 21 ) {
          return options.fn();    
       } else {
          return options.inverse();
       }
    });
Template
    {{#if isLegal}}
       <h1>Drink up!</h1>
    {{else}}
       <h1>Bummer</h1>
    {{/if}}

There is something to be said for forcing you to work hard to implement custom logic in your templates, but we programmers are pragmatic and sometimes you just want something done fast. In these cases, I like to fall back on a much uglier, more powerful templating solution: _.template()

Underscore – ugly syntax & logic made easy

Underscore templates won’t win any awards for elegance. While they may appeal to some Java jockeys coming from JSPs, for most of us it’s a no-brainer which syntax is easier to use.

    <h1><%= title %></h1>
    <ul>
      <% for (var i = 0; i < people.length; i++ ) { %>
      <li><%= people[i] %></li>
      <% } %>
    </ul>

That being, said, logic is easy and you can put as much of it as you like in your Underscore templates!

    <% if ( age >= 21 ) { %>
        <h1>Drink up!</h1>
    <% } %>

I choose… both!

With Backbone, I think people feel like they have to choose between the two ways of templating, each with its own advantages and drawbacks. But I think this is really a false choice – each excels in its own way and with Backbone it’s easy to choose both!

What I have found to be best is a Handlebars-first, Underscore-if-needed approach. You can’t beat Handlebars for syntax, and your project ought to be structured in such a way that your templates don’t require much logic anyway. But in those cases where you really do need something more powerful, there is no harm done in falling back on Underscore. In fact, since Backbone itself depends on Underscore already, it’s already right there waiting for you to use!

Here’s an example of 2 views, one which renders with Handlebars, and one with Underscore:

HandlebarsView
 var HandlebarsView = Backbone.View.extend({
        template: _.template(handlebarsTemplate);
        model: new Backbone.Model({
            title: "Famous Authors",
            authors: ["Hemingway","Hawthorne","Orwell"]
        }),
        
        render: function() {
            this.$el.html(this.template(this.model.toJSON()))
        }
    });
Handlebars Template
    <h1>{{title}}</h1>
    <ul>
      {{#each people}}
      <li>{{this}}</li>
      {{/each}}
    </ul>
UnderscoreView
var UnderscoreView = Backbone.View.extend({
        template: Handlebars.compile(underscoreTemplate);
        model: new Backbone.Model({
            age: 23,
            legalMessage:"Drink up!"
        }),
        
        render: function() {
            this.$el.html(this.template(this.model.toJSON()))
        }
    });
Underscore Template
    <!--Underscore Template-->
    <% if ( age >= 21 ) { %>
        <h1>Drink up!</h1>
    <% } %>

Here we see how little effort is required to swap out your templating engine (something of a contrived example, I know). This can be done on a View-by-View basis and IMHO offers the best of both worlds. I’d love to hear your thoughts, so leave a comment or hit me up on Twitter.