Web Developers Articles

Sort by:


  1. Building a persistent Notes app for Firefox OS

    In this tutorial we will be building a notes app (like Evernote) from scratch and deploy it to Firefox OS! See a live demo.

    A persistent notes app needs a place to store all the notes for a user (so no one else can read it). For this we will use my own backend solution called Sproute. Sproute is a hosted web framework for quickly building dynamic webapps.

    First create an account with a unique subdomain then access the Dashboard through http://<mysubdomain> You must login with the same details used to signup to Sprotue.


    In Sproute there is a concept called Models. A model defines the dynamic data in our app with properties for data integrity. Create a new model called notes with the following fields and properties:

    • body: Text, Required, Min: 1
    • sharing: Text, Allowed Values: public, private, Default Value: private
    The model form filled out for notes

    The model form filled out for notes

    The body field will store the contents of the note. The sharing field will specify whether the note can be viewed by others (with a direct link) or just the owner. This is all the data we need to define, everything else is covered by built-in fields.

    List notes

    We need a way to list the available notes for a user. This can be done with Pages. A page is HTML with embedded template tags for retrieving and processing data.

    Open the index page. This is the home page when people view your space. We will list the notes here. Add the following:

    {{ get /data/notes?sort=_lastUpdated,desc as notes }}

    All data is retrieved through an HTTP interface so the {{ get }} tag must take a URL. The request above is retrieving all notes for the logged in user and stores the results in a variable called notes. We use a query parameter to sort the results by last modified first (An underscore denotes a built-in field).

    Let’s display each note in a list:

        {{ each notes as note }}
            <li><a href="/view/{{note._id}}">
            {{ word note.body 0 5 }}
        {{ / }}

    The {{ word }} template tag will extract the first 5 words from the body content. We link to a not-yet-made page with the URL /view/<id>. note._id is a built-in unique identifier.

    Add the above code in the 'index' page

    Add the above code in the ‘index’ page

    Create a note

    Before creating the view page for a note, let’s make a new page for creating a note. Create a new page called create. Add the following HTML:

    <form action="/data/notes?goto=/" method="post">
        <div><textarea name="body"></textarea></div>
        <div><select name="sharing">
            <option value="private">Private</option>
            <option value="public">Public</option>
        <button type="submit">Create Note</button>

    Simple! As mentioned above, all data is retrieved and modified through an HTTP interface. This means we can use a simple HTML form to create a new note. The goto query parameter will redirect the user to that URL.

    Because this is a new page we need to create a new route so the page is accessible. A route is a pattern for a requested URL that will render a page if matched. There will already be a route for the index page. Click Routes and create a new one with the following:

    • Route: /create, Page: create.
    New route to 'create' page

    New route to ‘create’ page

    User login and registration

    User accounts are built into Sproute but we still need to create a Register and Login page. Thankfully this is also a simple HTML form so create a new page called users and add the following:

    <form action="/api/login?goto=/" method="post">
            <input type="text" name="name" />
            <input type="password" name="pass" />
        <button type="submit">Login</button>

    You may add the Register form on the same page by copying the login form and replace the action attribute to /api/register. Create two new routes with the following:

    • Route: /login, Page: users
    • Route: /register, Page: users

    View and update a note

    Previously we created a link to view a note. This will also be where we let users modify the note. Create a new page called view and add the following:

    {{ get /data/notes/_id/ admin as note }}
    {{ if note.sharing eq private }}
        {{ if note._creator neq :session.user._id }}
            {{ error This note is private }}
        {{ / }}
    {{ / }}
    <form action="/data/notes/_id/{{}}?goto=/" method="post">
        <div><textarea name="body">{{note.body}}</textarea></div>
        <div><select name="sharing">
           <option value="private" selected>Private</option>
           <option value="public">Public</option>
        <button type="submit">Update Note</button>

    We make a request to get the note data for the note that was passed into the URL (through the params object). The query parameter single=true will return just the object instead of a one item collection. admin will run the request with the specified user-type. Next we check whether the note is private. If so throw an error if the user is not the creator.

    The update form is very similar to the create form. We only need to change the action to update notes where the _id matches the one in the URL.

    This page requires a slightly complex route. We need to use a placeholder in the route so that /view/anything will still match the view page and store anything in a variable.

    Create a route with the following:

    • Route: /view/:id, Page: view

    Now you can see where comes from. params is an object for all placeholders in the route and the matched values.


    The last important concept of Sproute is permissions. Permissions are just like routes where a requested URL matches a pattern but instead of pointing to a page, it validates against a required user type.

    Click Permissions and add the following:

    • Method: GET, Route: /data/notes, User: Owner
    • Method: GET, Route: /data/notes/*, User: Owner

    This will make sure the only notes listed will be ones the user has created (i.e. the owner). Because of the second permission, we needed to run the {{ get }} request as admin otherwise it would fail for everyone (except for admins and the creator) even if the note is public.

    Adding a permission to retrieving notes

    Adding a permission to retrieving notes

    Firefox OS support

    Sproute can very easily support hosted apps on Firefox OS by creating a page with the manifest JSON data and the route: /manifest.webapp.

    Create a new page called manifest with the following:

        "name": "{{}}",
        "description": "A persistent notes app",
        "launch_path": "/",
        "icons": {
            "128": "/absolute/path/to/icon"

    Create a Route with the pattern /manifest.webapp pointing to the manifest page.

    We’re done! Test this in the app manager by using the link to the manifest ( Sproute is open-source and on GitHub under the Mozilla Public License v2 so you may clone the repo for private hosting.

    Notes app at mobile width

    Notes app at mobile width

  2. Introducing the Firefox OS App Manager

    The Firefox OS App Manager is a new developer tool available in Firefox 26 that greatly improves the process of building and debugging Firefox OS apps, either in the Simulator or on a connected device. Based on the the Firefox OS Simulator add-on, it bridges the gap between existing Firefox Developer tools and the Firefox OS Simulator, allowing developers to fully debug and deploy their web apps to Firefox OS with ease.


    Additional features made available in Firefox 26 are discussed in this post.

    App Manager In Action

    The App Manager replaces the current Simulator Dashboard and provides an integrated debug and deployment environment for your Firefox OS apps, by leveraging the existing Firefox Developer Tools. You can install hosted or packaged apps and debug them in the Simulator or with a connected device. The App Manager also provides additional information to the developer including the current Firefox OS version of a connected device, the ability to take screenshots, a list of all currently installed apps and a list of all the APIs and what privilege level is required to use each. Here is a screencast of the App Manager showing off some of the features available for Firefox OS Development.

    In addition to debugging your own apps, the App Manager also provides the ability to update, start, stop and debug system level apps. Debugging an app using the Developer Tools is similar to debugging any other Web app and changes made in the Tools are automatically reflected real-time to the app either in the Simulator or the connected device. You can use the Console to see warnings and errors within the app, the Inspector to view and modify the currently loaded HTML and CSS, or debug your JavaScript using the Debugger.

    Developer Tools

    For more information about using the Developer Tools be sure to check out the Developer Tools series on this blog and for the most up to date information take a look at the Developer Tools section of MDN.

    Getting Started with the App Manager

    To get started using the App Manager take a look at the MDN Documentation on Using the The App Manager. Do keep in mind that to see what is shown above you need:

    • Firefox 26 or later
    • Firefox OS 1.2 or later
    • at least the 1.2 version of the Firefox OS Simulator
    • either the ADB SDK or the ADB Helper Add-on

    Details for these are described in the above MDN link.

    Mozilla is very interested in your feedback as that is the best way to make useful tools, so please be sure to reach out to us through Bugzilla or in the comments and let us know what you think about the new App Manager.

  3. Firefox OS Development: Web Components and Mozilla Brick

    In this edition of “Firefox OS: The platform HTML5 deserves” (the previous six videos are published here), Mozilla’s Principal Evangelist Chris Heilmann (@codepo8) grilled Mozilla’s “Senior HTML5 Engineer Angle Bracket Coordinator” Matthew Claypotch (@potch) about the exciting new possibilities of Web Components for Web App developers and how Mozilla’s Brick library, a collection of custom elements to build applications with, can help with the transition. You can watch the interview on YouTube.

    The Why of Web components

    There is a problem with the Web as a platform for applications: HTML, the language that makes it easy to mark up documents and give them meaning doesn’t have enough elements to build applications. There are quite a few new elements in the HTML5 spec, but their support is sketchy across browsers and there are still a lot of widgets missing that other platforms like Flex or iOS give developers out-of-the-box. As a result, developers build their own “widgets” like menu bars, slider controls and calendars using non-semantic HTML (mostly DIV elements) and make them interactive using JavaScript and theme-able using CSS.

    This is a great workaround but the issue is that we add on top of the functionality of browsers instead of extending the way they already function. In other words, a browser needs to display HTML and does a great job doing that at least 60 frames per second. We then add our own widget functionality on top of that and animate and change the display without notifying the browser. We constantly juggle the performance of the browser and our own code on top of it. This leads to laggy interfaces, battery drain and flickering.

    To work around that problem a few companies and standards body members are working on the Web Components specification which allows developers to extend the browser’s understanding of markup with own elements. Instead of writing a slider control and make it work after the browser already displayed the document, you define a slider element and become part of the normal display flow. This means our widgets get more responsive, don’t work against the browser’s rendering flow and all in all perform better. Especially on low spec mobile devices this is a massive win. The whole thing already happens: if you for example add a video element to the document you see a video controller with a timed slider bar, a play button and volume controls. All of these are HTML, CSS and JavaScript and you can even see them in the debugging tools:

    Anatomy of a video element

    Firefox OS, being targeted at low end devices can benefit a lot from widgets that are part of the rendering flow, which is why Mozilla created Mozilla Brick, a collection of custom elements to build applications with. Earlier we introduced the concept using a library called XTags, which powers Brick. Using Brick, it is very simple to create for example a deck based application layout using the following markup:

    <x-deck selected-index="0">
        0<span>I'm the first card!</span>
          These cards can contain any markup!<br>
          <img src="../../site/img/grounds_keeping_it_real_s3.gif">
          <img src="../../site/img/grounds_keeping_it_real_s1.gif">
          <img src="../../site/img/grounds_keeping_it_real_s2.gif">
        2 <img src="../../site/img/thumbs_up.gif">

    The resulting app consists of three decks that can be animated into another without having to do anything but call a deck.shuffleNext(); function.

    Web Components are a huge topic right now and many libraries and frameworks appear each week. We hope that by using Brick we can enable developers to build very responsive apps for Firefox OS quickly and cleanly and leave the pain of making your app perform really well up to the OS.

  4. Mozilla goes to Washington

    Last month, Mozilla Foundation employee Jess Klein was honored by the White House Office of Science & Technology Policy as a Champion of Change for her work with Rockaway Help in the wake of Hurricane Sandy.

    Before the White House event, Mozilla sponsored a Civic Hackers’ Happy Hour in DC at Here’s an excerpt about the event from the Code for Tulsa write-up.

    Mozilla Civic Hackers’ Happy Hour

    We arrived at canvas around noon to arrange all the catering and set everything up. We met fellow civic hackers from Austin to Chicago, Minneapolis to Miami, Oakland to DC, and everywhere in between – hackers and officials representing Code for America, Sunlight Foundation, E-Democracy, United States CTO, Census Bureau, NASA, FEMA, USDA and many others.

    By 8pm we had about 100 people, so we had a few quick presentations – I spoke about Mozilla, Kevin Curry spoke about the Code for America Brigade program, and Garret Miller spoke about Mapbox. Everyone mingled and we learned about some great civic projects going on like the Smart Chicago Collaborative, in Minneapolis, and Keep Austin Fed. We had made a congratulatory card for Jennifer Pahlka, founder of Code for America and recently-appointed Deputy CTO of the US. Everyone had a chance to sign the card, and then… Jennifer showed up! So we presented the card to her in person!

    In my presentation about Mozilla, I discussed how I’ve come to realize that openness, innovation, and opportunity on the web is at the heart of developers improving their communities.

    Cities that think like the web

    In 2011, I found Mozilla Foundation Executive Director Mark Surman’s City of Toronto 2.0 Web Summit presentation from 2008 – A city that thinks like the web.

    Mark tells the story that seems obvious to us now – Mozilla believed that participation could create a better internet, and the tiny non-profit with a global community of volunteers forced open a monopoly browser market with standards and protocols that have created the largest communication platform in the history of the world.

    If openness and participation created a better web, could it create better cities? Mark says yes. After a couple of years hacking my city, I completely agree.

    Tulsa, Oklahoma, USA

    I first started civic hacking in 2011 when our Tulsa Web Devs group took it upon ourselves to put Tulsa Transit on Google Maps. At the time, we knew nothing about transit, and only a little about Google Maps. In a few short hack days with web resources, we taught ourselves everything we needed to convert route shapefiles and schedule csv files into a valid GTFS feed.

    Tulsa Transit GTFS Prototype

    As soon as I saw the prototype working, I was hooked on civic hacking. It was the same feeling I had when I received my first patch for my first open-source project. In a way, my personal journey – from proprietary enterprise software development, to SourceForge, to Mozilla and Code for Tulsa – reflects trends in open technology: open source disrupted proprietary software and brought forth the open web, the open web brought forth open government and civic hacking.

    In Tulsa, we’ve gone on to create civic APIs and apps for citizens, planning organizations, Tulsa Library, Tulsa Fire Department, and the Oklahoma Urban Search & Rescue task forces. Because we build on the web, all our apps are available to every citizen, regardless of device or platform. I jokingly ask, “If we created our Fire Department app for iPhones, would Android users just watch their house burn down?”

    Innovation can come from anywhere

    Here’s the thing – we are just one group (but maybe the best group!) of civic hackers … in Tulsa, Oklahoma. The web enables anyone with a text editor to make these things and deliver them directly to anyone with a web browser. Morgamic says it best in “What do you want the web to be?

    The future of the web won’t be decided by corporations, governments, or shareholders. It will be chosen by people like you and me – passionate individuals with great ideas, who won’t take no for an answer, who won’t settle.

    Having worked with and for corporations, shareholders, and now governments, I know just how true this statement is. On the web, Google’s latest billion-dollar project and Code for Tulsa’s $35 raspberry pi hack are both a single link – a single click. The web platform is the only platform designed to include everyone at an equal level of access.

    Serving the greater good

    Mozilla’s mission is to promote openness, innovation, and opportunity on the web. It’s a lofty goal; sometimes it’s hard to see what that looks like “on the ground.” At our happy hour, I saw it: designers, engineers, programmers, entrepreneurs – hackers experimenting and making amazing things for the betterment of their communities.

  5. New Features in Firefox Developer Tools: Episode 24

    Releases have recently rolled, and there are a slew of new features coming to the developer tools in Firefox 24. Firefox 24 is currently in our alpha channel Firefox Aurora, and will hit the main release channel on September 17th, 2013.

    A little alitteration leads to lots of cool features coming this release. I’m only touching on a few highlights here; to see a comprehensive list of all the new changes to developer tools, check out the full list of bugs fixed since last release.

    Console Clean Ups

    An oft-requested feature, the console will now clear all of the existing logs when you refresh the page. If you need logs to persist across reloads, don’t worry: this behavior is toggle-able in the options panel. Here’s to less clutter!

    Users were also reporting that the “clear” button was confusing. It wasn’t obvious whether it was clearing the logs or the the filter text because the button as adjacent to the filtering search box. We moved it to so that this won’t happen anymore!

    New position of the clear button

    Source Map Sourcery

    Source maps are now enabled by default. If you need to debug the JavaScript generated by your tool or compiler rather than the original source, you can still toggle them on and off in the debugger options.

    Furthermore, because of issues with Internet Explorer, the source map specification was updated so that you link a source map to its script with //#
    rather than the deprecated //@ sourceMappingURL=.... We will still respect the old style, but will warn you that it is deprecated. Here is a summary of the why this change was made.

    Finally, we will load the text of a source mapped source from its source map’s sourcesContent property, if it exists. This property was added to source maps to enable dynamic source map creation, and to bundle your sources into the source map so that you don’t need to juggle extra files on your server.

    Debugger Developments

    Frozen, sealed, and non-extensible objects are now visually distinguished in the debugger’s variables view.

    Frozen, sealed, and non-extensible objects

    Also, when stepping out of a stack frame in the debugger, you will now see either the return value or the exception thrown (depending on why you are exiting the frame) in the variables view labeled <return> and <exception> respectively.

    A stack frame's return value

    A stack frame's exception

    JavaScript-Free Fun

    Need to see how your web page gracefully degrades when JavaScript is disabled? Head on over to the options panel and you can quickly disable JavaScript for the current tab. This persists until either you close the tab or the developer tools.

    Network Monitor Magic

    You can now filter by types of requests in the network monitor. Want to see only requests for stylesheets? Or maybe only XHRs? We’ve got your back. On top of that, there are now total number of requests, file sizes, and response times listed in the bottom that update with you filters, so you can see just how many KBs (or even MBs) of images you are requesting on every page load.

    Filtering only images

    Profiler Pleasantries

    You can now control the profiler from your web app’s code base via console.profile() to start a new profile, and console.profileEnd() to end it. No more trimming your sample range, start and stop profiling in the exact places you want to from your code!

    That’s it for this episode. Keep on hacking the free web!

  6. Speed Up App Development with X-Tag and Web Components

    In the last few years we’ve witnessed an evolution in what ‘app’ means to both developers and consumers. The word app evokes the idea of a rich, task-oriented user experience with highly optimized user interface that responds to its environment and can be used on an array of common devices. In order to make development of rich app experiences easier, native platforms have generated many of their own controls and components that Just Work™.

    For other native technology stacks, extensible components are all but assumed – not so much for the web. Soon, that all changes. We are on the verge of a declarative renaissance that will dramatically advance app development for the web platform, and Web Components will drive it.

    X-Tag and Web Components offer features that obliterate the status quo for layout, UI, and widget development – here’s a few notable Web Component features:

    • Create real custom elements the browser understands
    • Stop the instantiation madness: $$(‘button.super’).initSuperButton()
    • Remove unmanageable HTML widget guts from your app’s view files
    • Work with sharable components, based on standard technologies

    Meet the Web Components Family

    Web Components is a group of W3C specifications, quickly moving toward standardization, that provide a robust HTML component model. You should not assume the following specs are implemented in your browser of choice. While these specifications are in various stages of implementation across browsers, you can use X-Tag (with either Mozilla or Google’s prollyfill) today to create custom elements that work well in recent version of Firefox, Chrome, Safari, and stock mobile browsers. X-Tag is a powerful sugar library primarily focused on wrapping and enhancing one of the draft-state Web Component specs: Custom Elements (document.register). We’ll get to X-Tag shortly – but for now, let’s quickly review the key features of each spec:

    Custom Elements

    Custom Elements provides you a way to create new elements for use in your environment. There are two ways to declare a new custom element, the imperative DOM API – document.register(), and the declarative HTML tag – (whose DOM constructor is HTMLElementElement). After declaration, new custom elements can be created in the same ways native elements are, such as document.createElement, presences in original source (the markup of a page), and innerHTML, etc.

    Here’s an example of what a custom element registration looks like in both the declarative and imperative styles:

    document.register('x-foo', {
      prototype: Object.create(HTMLElement.prototype, {
        readyCallback: { 
          value: function(){
            // do stuff here when your element is created
            this.innerHTML = '<div>Barrrr me matey!</div>';
        bar: {
          get: function() { return 'bar'; },
        // add more properties to your custom prototype
        // ...
    <element name="x-foo">
        if (this !== window) {
            prototype: {
              readyCallback: { 
                value: function(){
                  // do stuff here when your element is created
                  this.innerHTML = '<div>Barrrr me matey!</div>';
              bar: {
                get: function() { return 'bar'; },

    Shadow DOM

    The Shadow DOM allows you to encapsulate structural and supporting elements within components. Elements within nodes remain visible for purposes of display UI (depending on the type of element and your styles), but are hidden from the rest of your application code, unless you explicitly cross the shadow boundary.

    HTML Templates

    HTML Templates bring simple DOM templating and markup reuse to the web platform – which are often shimmed today using the HTMLScriptElement + DocumentFragment hack-pattern.

    HTML Imports

    HTML Imports are external HTML documents that contain declarative component definitions. HTML component documents can by imported using the link element with the rel attribute value import. Imported resources may themselves contain additional sub-imports, which the browser then retrieves and performs automatic dependency resolution upon.

    Web Components + X-Tag = WINNING

    Mozilla’s X-Tag library enhances the imperative (JavaScript) route for creating custom elements. X-Tag’s primary interface is the xtag.register() method – it wraps the soon-to-be standard document.register() DOM API with features and functionality that make development of amazing custom elements effortless.

    Creating a Custom Element

    Here’s a quick example of what registering a custom element looks like using X-Tag:

    xtag.register('x-pirate', {
      lifecycle: {
        ready: function(){
          this.innerHTML = '<blockquote>' +
                             '<img src="pirate-1.png"/>Barrr me matey!' +
      accessors: {
        src: {
          // X-Tag's attribute sugar relays any value passed to the src 
          // setter on to the src attribute of our <x-pirate> and its
          // <img> element (specified by CSS selector), and vice versa.
          attribute: { selector: 'img' },
          set: function(){
            // When a <x-pirate>'s src attribute/setter is changed, we 
            // stop everything to announce the arrival of a new pirate.
            // Ex: doc.querySelector('x-pirate').src = 'pirate-2.png';
            alert("There's a new captain on deck ye scurvy dogs!");
      events: {
        // This is an example of X-Tag's event and pseudo systems. The
        // "tap" custom event handles the dance between click and touch,
        // the ":delegate(img)" pseudo ensures our function is only 
        // called when tapping the <img> inside our <x-pirate>.
        'tap:delegate(blockquote > img)': function(){
          alert("A pirate's life for me!");

    To the Democave Batman!

    We’re actively working on a custom element UI toolkit and style pack that will make development of app interfaces a breeze. It’s still in very early stages, but we have a few demos for you.

    Get the Code

    Head over to and grab the code to develop custom elements of your own. After you get the hang of things, start contributing to our open source effort!

  7. How to Spread The Word About Your Code

    You spent an entire weekend building a library, jQuery plugin, build tool, or other great piece of code you wanted to share far and wide, but after some tweets and a failed attempt to make the front page of Hacker News, your creation languished, unloved, in a GitHub repo. A common situation for many developers nowadays, but one you can avoid.

    As the editor of several programming newsletters, I frequently get two types of e-mails from developers. Those reaching out to ask if I can mention their projects, and those expressing surprise and excitement that their work has been featured. If you’re a developer doing good work but feel more like you’d be in that second group, the three steps in this article are for you.

    Before we get started, there’s a stumbling block we need to kick away. Terms like ‘marketing’ and ‘advertising’ are dirty words for many developers and it’s not uncommon for developers to be reluctant to do much promotion. ‘Build it and they will come’ used to work when exciting open source projects were few and far between but now everyone seems to be working on something and making a noise about it. Few of the successes you see come through pure luck but because developers are actively promoting their work or, at least, making it discoverable. It’s time to join them!

    Step 1: Get your project ready

    Before you can promote your project, you need to make it attractive to potential users and evangelists (including general wellwishers, the media, and other developers).

    A good name

    Ensure your project has a palatable name. It doesn’t need to be clever or even descriptive, but it’s worth avoiding innuendos that may present a problem down the line. For example, the popular Testacular and Authgasm projects, are now named Karma and Authlogic respectively after users raised a fuss.

    You should perform a search for the name you choose to be sure you’re not clashing with anything else that’s popular or trademarked (did you know Firefox was called Phoenix and Firebird prior to Firefox?). The US Patent and Trademark Office has an online trademark search facility.

    A benefit of having a relatively unique or uncommon name is so you can search for it over time (or even set up a Google Alerts notification for the name) and find mentions of your project without many irrelevant results popping up. If you want to have something descriptive but unique, consider joining two words together. For example, when I created a Ruby library to do natural language detection, I called it WhatLanguage and it’s easy to search for.

    An official homepage or project URL

    The term ‘homepage’ is a bit outdated but you ideally need a single ‘home’ URL that you can promote and point people to in relation to your project. You don’t need to splash out on a fancy template or even a domain name, but your project needs a focal point. That could be an entire site with its own domain, such as those for Yeoman or HTML5 Boilerplate, a simple single page on an existing domain, such as that for RoughDraft.js, or even a regular GitHub repo, such as for vague.js.

    If you have the freedom to do so, make sure your site looks good on the major browsers (including mobile), hook up some analytics to your page and ensure the <title> tag is well written. Use a title like “MyProject – A JavaScript Library to X, Y and Z” instead of just “MyProject – About” or a blank title. With social bookmarking, this matters as you can’t guarantee your evangelists will write a good title of their own.

    If you’re not a Web designer, don’t have the time to spend making a complete design, but still want a complete site rather than just a GitHub repo and README, consider using a framework like Bootstrap as it’ll provide a clean layout out of the box and you can forget about many cross browser and device issues.

    Documentation and copywriting

    It’s only just a cliché that developers don’t like to write documentation, but you need something for potential users to fall back on, and time invested in producing useful documentation up front will pay dividends later.

    At a cynically bare minimum, you need to write enough documentation that someone will be confident about sharing your link or promoting your project and not feel like they’re sending their own followers into a black hole of misunderstanding. This means your homepage or README needs to cover a few angles. You’ll need to:

    • Prominently feature a “[noun] is” paragraph. An alarming number of project homepages don’t explain, in simple terms, what the project is actually for or does. If you’ve built a JavaScript library that does language detection, say, you have to say so. For example: “LanguageDetect is a JavaScript library for detecting the natural language of text.”

      An excellent example of this in action is on where it states right up front: “Cinder is a community-developed, free and open source library for professional-quality creative coding in C++.” Perfect!

    • Write clear titles, subheadings, and support copy. At a bare minimum, ensure titles, subtitles, and any sort of writing on your homepage are straightforward and clear. Write for the lowest common denominator on your homepage. You can get more advanced elsewhere.

    • Write a beginner’s tutorial and link to it from your home page. Unless everything’s simple enough to explain on a single page, quickly write a tutorial that covers basic installation and usage and either include it in your README file or put it on the Web and link to it from your README and/or homepage.

    • State dependencies and requirements clearly. Does your library only work on a specific version of Node? Is it a browser extension for Firefox? Does your code require PostgreSQL, Redis, or another specific database? Be sure to include a bulletpoint list of dependencies and requirements for your project to be usable so as not to disappoint potential users.

    • Specify the license for your code. While you could get away with keeping your licensing information tucked away in a LICENSE file in your GitHub repo, specifying what license your code is released under up front and center will help put many developers at ease. Likewise, if your project is commercial is nature and costs money, don’t hide that detail away and mislead visitors.

    • If your project is a library or API, feature some example code on the homepage. Unless your library is particularly complex, let visitors see an example of its usage on the project homepage. If your API is good, this could be a great way to get an ‘easy sale.’ I’m not a huge fan of the code example chosen but the homepage for Ruby shows off this technique.

    Extra materials

    A blog post is a great way to introduce a project that might need more background or have more of a story than it’s practical to tell on a homepage or within documentation. If there’s any sort of story behind your project, a blog post is a great way to tell it. Be sure to link to the post from your project’s homepage and consider promoting the blog post separately to relevant sites within your niche.

    If you have the ability, recording a screencast or other sort of video can help. Could you put together a simple 5 minute screencast of how to install and use your library? Or have you built a game that could be demonstrated in a few minutes of gameplay? Record a simple video, put it on YouTube, and embed it on your homepage. Your accent doesn’t have to be as crisp as a newsreader’s and you don’t even have to appear within the video. All that matters is you get to the point quickly and your audio is tolerable (not muffled, clipping, or drowned in background music).

    As the editor of several programming newsletters, I look at thousands of projects each year, and it’s still uncommon to see simple screencasts, yet they certainly help a project stand out and, as a consequence, make it more likely for me to talk about it. You can see a perfect example on Punch’s homepage. The early popularity of Ruby on Rails also depended upon a popular ‘build a blog engine in 15 minutes’ video, back when the concept of using video to promote an open source project was very novel.

    If you’re sticking to the straight up, GitHub README approach (and it’s certainly not a bad idea for a simple library), a bonus tip is to create a tiny screencast of your code in action and convert it to an animated GIF for inclusion in your README. Richard Schneeman outlines this technique in Use GIFs in your Pull Request for Good, not Evil. The result is striking and could help your README stand out.

    For further ideas on how to make your project stand out before you begin promoting it, check out the great How to Make Your Open Source Project Really Awesome by Michael Klishin. It digs into more detail about versioning, announcements, having a changelog and writing good documentation.

    Step 2: Get the word out

    You’ve polished your project, got a URL to promote, and you’re ready to get the news out.

    A word of caution, however. Don’t use every technique on day one. You could overload your site with traffic or, worse, be subjected to a barrage of online criticism if your work or site is broken. With something like a library or tool, a gentler approach will work well and building up small streams of visitors and users over time will give you a much better time.

    Social networking

    Your own social networking profiles are always a good place to start if you have them. You’ll get more immediate feedback from people who actually know you and if your project is particularly interesting, it could go viral even from a single mention.

    A great example of a simple project going viral was YouTube Instant by Feross Aboukhadijeh. Feross built YouTube Instant quickly, mentioned it on Facebook before going to bed, and woke up to a flood of traffic and press mentions.

    If you like to experiment and have several bucks going spare, you could also consider paying for a promoted post on Facebook. This will give your post more visibility in your news feed, but is best reserved for if your Facebook friends are mostly developers or people likely to be interested in your project. If not, and you’d still like to spend some money, consider an ad on Reddit or a relevant programming blog instead.

    Influencers, bloggers, and niche media

    Whether you’re working on a JavaScript library, Firefox extension, backend app in Rails, or a theme for Bootstrap, your code will fit into one or more niches and every technical niche has a variety of ‘influencers’, people and publications who are popular and well known for the topic at hand.

    Getting a tweet, retweet, or even an entire blog post from an influencer could have a significant impact on your project, as could being invited to blog elsewhere (Mozilla Hacks, for example!). If Brendan Eich tweeted about your JavaScript library, Lea Verou wrote a blog post about a CSS trick you discovered, or Paul Irish mentioned a Web development tool you built in a talk, you would attract a lot of interest quickly. It is key, however, to realize there are many great influencers in every space and you’ll achieve nothing by hounding any one person so be prepared to move on.

    Spend some time working out who the influencers and key publications are in your niche. For Twitter, Followerwonk is a handy tool that searches Twitter biographies for certain words. If you search for “javascript” the first page includes several users who would be useful to reach out to if you had a particularly interesting JavaScript-related release to promote. Reaching out on Twitter can be as simple as a single tweet and many busy folks prefer Twitter as it takes less time to reply than an e-mail. A single tweet from @smashingmag could drive thousands of visitors your way, so consider tweeting them, and other similar accounts, when you have something relevant.

    I’d also advise looking for blogs and e-mail newsletters in your niche. Start with something as simple as Googling for “javascript blog”, “javascript newsletter”, “css blog” or whatever’s relevant to your project. Most bloggers or e-mail newsletter publishers will not be offended by you sending them a quick note (emphasis on quick) letting them know about your work. Indeed, some weeks there can be a shortage of interesting things to write about and you might be doing them a huge favor.

    If you choose to e-mail people (and your project will probably be more substantial than a few hours’ work to justify this), take care not to make demands or to even expect a reply. Many bloggers and influential people have overflowing inboxes and struggle to reply to everything they receive. Make your e-mail as easy to process as possible by including a single URL (to your now superb homepage or README) and include your “[noun] is” paragraph. Don’t take a non-response as an insult but keep moving on to the next most relevant person. You might even consider taking a “Here’s my project that does X, Y and Z. No reply needed, I just thought you might like it” approach. Softly, softly works here, as long as you get to the point quickly.

    How to get attention from internet celebrities by Jason Cohen and How to Write the Perfect Outreach Email by Gregory Ciotti go into more detail about e-mail etiquette when promoting your work to influencers. While you might not need to contact any ‘celebrities’ in your niche, the principles of keeping it short, including a call to action, and ensuring your work is appropriate to the person are really true for anyone you’re sending unsolicited messages to.

    Podcasters are an often forgotten source of promotion opportunities too. While some podcasts don’t cover news or new releases at all, many do, and being on the radar of their hosts could help you get a mention on a show. Smashing Magazine has put together a list of tech podcasts covering the areas of design, user experience, and Web development in general. Again, keep your e-mails short and sweet with no sense of expectation to get the best results.

    User curated social news sites

    As well as reaching influencers and niche media, sometimes reaching the public ‘firehose’ of news can work too, and there are few better examples of these in the modern world of development than Hacker News or Reddit.

    Hacker News in particular is notoriously hard to reach the front page on and ‘gaming’ it by getting other people to vote up your post can backfire. (Indeed, it will backfire if you link people to your post on Hacker News and encourage them to upvote. They have ways of detecting this behavior. Get people to manually find your post instead.) If you do reach the front page of Hacker News, of course, you can certainly expect an audience of many thousands of developers to be exposed to your work, so be sure to try.

    With Reddit, the key isn’t to dive straight into a huge sub-Reddit like /r/programming but to look for sub-Reddits more directly related to your project. For a JavaScript library, I’d post to /r/javascript or possibly /r/webdev. Reddit ads can also perform well if you’re OK with spending some money and these can be targeted to specific sub-Reddits too.

    There are many similar sites that are less well known but which are respected in their niches and can drive a lot of interested visitors, including Designer News (mobile and Web design), DZone (general developer stuff), EchoJS (JavaScript), RubyFlow (Ruby and Rails), and (general hacker and developer stuff). Finding the right site like this and taking time to make an on-topic, well written post will help a lot.

    The mass media / press

    This article is primarily focused on the promotion of open source and front-end projects and these are typically not frequently covered in print or on the TV or radio. If, however, you think the mass media would be relevant for your project, here are some other articles packed with handy tips:

    Step 3: Maintain momentum

    You’ve built up some interest, your GitHub stars, Reddit votes, and pageviews are all rocketing up, but now you want to capitalize on the attention and maintain some momentum.

    User support

    Whether you’ve built an open source project or a cool tool, you’re going to end up with users or fellow developers who want to provide feedback, get help, or point out issues with your work. On GitHub, the common way to do this is through the built-in ‘issues’ tracker, but you might also find people start to e-mail you too.

    Be sure to define a policy, whatever it is. Users won’t feel good about opening issues on your GitHub repo if there are already many unresolved issues there and your project could stagnate. Ensure you respond to your audience or at least make your policy clear within your README or on your site. If you don’t want issues raised or code contributions, make this clear up front.

    Extending your reach

    For many projects, create a dedicated Twitter account, blog, Facebook page, or Google+ page in advance is overkill, but if your project starts to take off, consider these things. They’ll provide an extra way not only for users to remain in touch with your project but also a way for them to help promote it by retweeting things you post or by directing potential new users your way.

    You can also extend your reach in person by going to user groups and conferences and, if you’re really lucky, you can speak about your work too. This is a great way to get new users as people are much more likely to look into your work if they’ve met you in person.

    Avoid being defensive

    If your project does well on sites like Hacker News or Reddit, you’ll be tempted to read all of the comments your peers leave, but be careful. Comments about your work will, naturally, seem magnified in their intensity and critical comments that might not actually be mean spirited may seem as if they are to you.

    It’s hard, but the best policy is to not let any overtly mean comments get to you, duly correct any observations that are wrong, and to thank anyone who goes out of their way to compliment your work. Even if you’re in the right, with the lack of body language and verbal cues, being too defensive can look bad online and result in the post becoming a lightning rod for drama. Engage as best you can, but if it feels wrong to reply to something, listen to your gut.

    Be careful if you go into a new community to promote your work and get negative feedback. Most communities have rules or expectations and merely entering a community to promote your work is frequently considered a faux pas. Be sensitive to people’s environments and try to abide by a community’s rules at all times.

    The long term

    If your project does particularly well, you could be presented with the opportunity of turning it into a business in its own right. Many simple open source projects, often started by a single developer, have turned into long term work or even entire companies for their creators.

    Back in 2010, Mitchell Hashimoto released Vagrant, a Ruby-based tool for building a deploying VirtualBox-based virtualized development environments. In late 2012, Mitchell launched Hashicorp, a company providing Vagrant consulting services to enterprise customers. An even higher profile example is Puppet Labs, a company built around the Puppet open-source configuration management tool and which has taken total funding of $45.5 million so far.

    If your project becomes respected and heavily used within its field, you might also be approached to write a book or article about it or even speak at a conference. This is a good sign that your project has ‘made it’ to some extent as publishers and event organizers are in the business of working out what it makes business sense to present.

    Putting it all together: A checklist

    This has only been a basic introduction to promoting your work and with practice you’ll come up with tons of tips of your own (it’d be excellent if you could share some in the comments here). Based on all of the ideas above, here’s a basic checklist to run through next time you release a new project and want to get some added exposure:

    • Focus most of your efforts on your project’s homepage or README.
    • Check your project’s name doesn’t clash with anything else and is unique enough to find references to your work later.
    • Promote your work to your closest social group first to unbury any problems with your work.
    • Record a screencast or write a blog post about your project if some extra background would be useful for others.
    • Work out a perfect *”[project name] is”* sentence to describe what your project is or does.
    • Use your *”[project name] is”* sentence to give your page a descriptive title.
    • Find influential people, blogs, podcasts, and e-mail newsletters in your niche and send them a short, pleasant note.
    • Post to social news and bookmarking sites. Ensure your title is descriptive.
    • Use your *”[project name] is”* sentence in e-mails and contacts with influencers.
    • Take a positive, “look on the good side” approach to responding to comments about your work.

    Good luck!

  8. – Launch and run free open-source web applications in just 30 seconds – a WebFWD project

    There is no longer any doubt: web apps are the focal point of the cloud. From database-as-a-service to platform-as-a-service to security-as-a-service and beyond, the entire *aaS model has the web app as its center of gravity.

    If you’re a full-fledged developer, then taking full advantage of an app-centric universe is no big deal. Creating new web apps from scratch using frameworks like Ruby on Rails, Drupal, Django, or hundreds of others and then deploying those apps in the cloud is part of your daily bread and butter.

    The mission

    The mission of is quite simply to make it vastly easier for developers and non-developers alike to create and deploy their own web apps with a single click of the mouse. Launcher was founded by me, former AppFog director of product Maciej Skierkowski, and I have taken what I have learned in my time in the platform-as-a-service (PaaS) space and used that knowledge to make app deployment even more dead-simple than a typical PaaS platform does.

    How it works

    So how does it work? Launcher enables you to deploy so-called “jumpstart” apps with a single click. If you’ve signed up for a Launcher account, all you have to do is click on a jumpstart’s button and you’ll be prompted for basic information, and Launcher will do the rest of the work.

    From there, you can manage your app however you like. Frameworks like Drupal, WordPress, or Concrete5 provide you with an intuitive in-browser interface for modifying your app, whereas frameworks like Ruby on Rails, Flask, ActionHero.js, and others will require more in-depth web development knowledge.

    Launcher: great for non-developers

    The benefit for non-developers is that it makes using all of these platforms easier than ever before. Want to start a new WordPress blog? All it takes is signing up to Launcher and clicking a button, and your blog is up and running in the cloud. The rest is up to you. Are you starting a company and want to set up Drupal to run your content management system and ThinkUp for social media analytics? Also a click and a few keystrokes away.

    Launcher: even better for developers

    For developers, the benefits of Launcher involve speedier adoption of new apps and frameworks amongst potential users. Let’s say that I’m a Java developer and I just created the most bleeding-edge CMS currently available. If Drupal is a Cadillac, then my new CMS platform is a fresh-off-the-assembly-line Maserati: it’s blazingly fast, it has a wonderful in-browser console, and it has millions of useful plugins that Just Work.

    If users wanted to use my CMS in a pre-Launcher world, they’d have to do it the hard way: download it onto their machine, run appropriate configs to make it cloud-ready, learn how to use a VPS (or a PaaS, which is a very recent development), and so on. But with Launcher, potential users can give my new CMS a spin in just a few seconds and have it running in the cloud, and making my CMS Launcher-ready provides little to no modification on my part.

    The app landscape is extremely competitive, and anything that can speed potential adoption that quickly is a massive win for me as a developer. Launcher is simply an unprecedentedly direct pipeline to my new SaaS product.

    Under the hood

    Surprisingly enough, Launcher is amazingly simple in how it works behind the scenes. When an end user clicks on a jumpstart, the browser makes an AJAX request to a remote service kicking-off a Resque worker that deploys the app with AppFog or Setting up an HTML page to handle a Launcher jumpstart involves simply loading the jQuery and Pusher JavaScript libraries and inserting a few lines of JavaScript (check out the docs for more info).

    Your app will, however, need to be registered with Launcher to be included in the Launcher App Store. If you’re interested in doing so, don’t hesitate to get in contact with me, as I am looking to expand the range of offerings in the app store in the coming months.

    He’s also looking to expand the number of PaaS providers that support jumpstarts. At the moment, Launcher enables you to instantaneously deploy apps on either AppFog or Cloud Foundry, but Launcher is in principle compatible with any Cloud Foundry-compatible PaaS API. If you’d like to add a new PaaS, simply go to the Providers page, click “Add Provider,” and input a name, API endpoint, and other information.

    More on the way

    Launcher is a new project, and has a great deal more in store for both developers and end users. Jumpstarts for OpenPhoto, Redmine, and SugarCRM, to name just a few are coming soon.

    If you’re a developer, startup, or enterprise looking to take advantage of Launcher, email for more information.

  9. Codebender: physical programming on the web – a WebFWD project

    What is codebender? What problem does it solve?

    Whereas the cloud-based, software-as-a-service development has made it easy to develop by reading some tutorials and start hacking, physical computing is lacking far behind. This used to be in part due to the difficulty of designing hardware, but platforms such as the Arduino have made this a thing of the past. Instead of looking for the right components (out of thousands) and trying to connect them without frying any, there’s a large number of circuits designed to work great with each other.

    We still have a long way to go, though.

    Unfortunately, most of the tools still live in the 90s. New users have to install unintuitive applications or various command-line tools and platform-specific programs. That’s where codebender comes in. It is an embedded development platform with an emphasis on the Arduino and it’s completely web-based, so you don’t have to install, manage and update anything. Essentially, we are bringing physical programming and the physical world to the cloud.

    New development tools for the embedded software developers

    As I mentioned, we start by being completely cloud-based. This essentially starts with storing your code on the cloud, and we also store various settings, libraries and hardware configurations as well. We’re working on storing additional info like circuit schematics and images of the final products as well. So instead of having all these resources scattered around, every bit of your project is bundled together.

    This makes even more sense when coupled with our collaborative and social tools. If you want to build something that’s already out there, you don’t need to reinvent the wheel. You just clone an existing project, and you get the code, the schematics, the instructions and anything else you might need.

    On the coding front, we’re bringing syntax highlighting, indentation, auto-formatting, and soon, code completion. And since you’re bound to make a mistake, we’re topping it up with a state-of-the-art compile output, that lets you identify the issues faster and easier.

    Our next plans are, of course, some kind of versioning, and integration with tools like GitHub, Dropbox, etc. Further down the road, we plan to add more collaboration tools to promote the exchange of knowledge and ideas between users. Things like group projects and project discussions for example.

    The ultimate goal is to empower people to build more

    We aim to promote the maker and hacker culture and get more and more people to look at the world as something to be hacked, modified and transformed. We strongly believe in the open-source ideals and in constructing/developing stuff rather than consuming endlessly. It is important for people to realize their ability to interact with their environment and better their everyday lives (or just build cool stuff) without being professional software/hardware engineers and we hope codebender will help them do that. This is our reason to get up in the morning (and stay up until the morning).

    We also think codebender is a valuable tool in a seasoned developer’s toolkit and a welcoming place for the newcomers that doesn’t scare them off, but rather guides them into the exciting world of physical hacking. In that sense, we want codebender to evolve into a community driven hub of exchanging ideas and knowledge with a diverse audience of makers, developers/engineers, instructors and artists actively participating in what, in our opinion, will be the future of programming embedded devices.

    Our open source projects

    We’ve released a lot of open source projects in the past, both personally and as a team. As far as codebender goes, we’re taking care to design the whole system as a number of independent subsystems. So we have released the cloud compiler, the cloud uploader which allows you to program your embedded devices remotely through the network (TFTP-only for now but other protocols coming soon), the device firmware (bootloader) which adds remote network programming support to Arduino, the browser plugin which allows your browser to communicate with your programmable usb devices, and the code for the website itself. It’s all open source.

    Want to get a better idea of how these projects are use and how they all fit together? Then watch this short screencast:

    codebender tutorial from codebender on Vimeo.

    We also use a lot of other open source projects, and contribute back

    On the front-end, we use jQuery, the venerable javascript library, Twitter’s Bootstrap for the fancy UI stuff, the Ace editor, which is an awesome pure HTML5 editor and beautify.js for auto-formatting code.

    On the backend, we use Symfony 2 for the website and store user’s info and projects on MySQL and MongoDB respectively. As for the compiler, we use gcc-avr, the GCC port for Atmel’s AVR architecture to build the binaries, but we use the state of the art Clang C/C++ compiler to perform advanced syntax analysis. Clang is awesome in that it provides really great error output. Here’s a good example (prepare for I-love-Clang-it-is-awesome rant):

    #include <stdio.h>
    int myfunc(float first, float second)
        return 0;
    int main(void)
        int variable1, variable2;
        if(variable1 = variablr2)
            printf("hello guys")
        myfunc((float) variable1,);
        myfunc((float) variable1, &variable2);

    Let’s explain the errors. First of all, we have a typo (“variablr2″ instead of “variable2″) on line 11. Next, we forgot to add the infamous semicolon on line 14. And finally, on lines 15-17, we are calling myfunc() in 3 wrong ways.

    Here’s what gcc has to say about this:

    test.c: In function ‘main’:
    test.c:11: error: ‘variablr2’ undeclared (first use in this function)
    test.c:11: error: (Each undeclared identifier is reported only once
    test.c:11: error: for each function it appears in.)
    test.c:14: error: expected ‘;’ before ‘}’ token
    test.c:15: error: too few arguments to function ‘myfunc’
    test.c:16: error: expected expression before ‘)’ token
    test.c:17: error: incompatible type for argument 2 of ‘myfunc’

    Pretty decent, right? It finds all the errors, and is kind of helpful in some cases. For example, we can infer that the error in line 11 is a typo, we know the error in line 14 is a forgotten semicolon (except it’s really on line 13), and the errors for lines 15 and 17 do give us some hints. The error report for line 15 is slightly less stellar since there are two closing parentheses, but that’s because of the casting and it won’t take long to figure our the issue (most of the times).

    Let’s see what clang has to say about it:

            if(variable1 = variablr2)
    test.c:10:17: note: 'variable2' declared here
            int variable1, variable2;
    test.c:11:15: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
            if(variable1 = variablr2)
    test.c:11:15: note: place parentheses around the assignment to silence this warning
            if(variable1 = variablr2)
               (                    )
    test.c:11:15: note: use '==' to turn this assignment into an equality comparison
            if(variable1 = variablr2)
    test.c:13:23: error: expected ';' after expression
                    printf("hello guys")
    test.c:15:18: error: too few arguments to function call, expected 2, have 1
            ~~~~~~          ^
    test.c:16:27: error: expected expression
            myfunc((float) variable1,);
    test.c:17:28: error: passing 'int *' to parameter of incompatible type 'float'
            myfunc((float) variable1, &variable2);
    test.c:3:31: note: passing argument to parameter 'second' here
    int myfunc(float first, float second)
    1 warning and 5 errors generated.

    This is really much more verbose, but it’s also much more helpful. For starters, Clang recognized that we have a variable with a really similar name, and suggests that. Not only that, but it assumes that’s what we meant in the first place, and carries on. It’s not uncommon to get 100 false errors from gcc and have them all disappear when you fix the first one. Clangs assumptions greatly help in that, but it would take a huge example to show that.

    Next, we have a warning. One of the most common mistakes both rookies and seasoned developers do is the assignment operator instead of the equality on (“=” instead of “==”). You probably didn’t notice, did you? I thought so :) So, Clang will warn you if you assign inside if() statements. Don’t worry, if you do want to assign, you can either wrap that in another parenthesis (which has no effect in your code) or you can silence these warnings altogether.

    It will also give you a more precise report on the forgotten semicolon of line 13, but that’s a minor improvement. The real fun starts in lines 15-17. The error report on line 15 is quite better, since it gives us the number of arguments needed. Line 16 is more or less the same, but line 17 is a nice improvement. Not only does it state the nature of the error, it also gives us the type of the parameter we are passing, the expected type, and the prototype of the function! Now that’s the kind of stuff people like!

    Users First

    If I would like to end with something, that would be it. You do know the “customer is always right” motto, but it goes way beyond that. In this era, it’s really about the user. If you build something, make sure the people who use it (for example, in the case of a library, other developers) like it, and figure out what they need. I always say, if you’re going to make something, make something people are eager to use every day. Not something they use out of necessity..

  10. The Web Developer Toolbox: Backbone

    This is the fourth in a series of articles dedicated to useful libraries that all web developers should have in their toolbox. The intent is to show you what those libraries can do and help you to use them at their best. This fourth article is dedicated to the Backbone library.


    Backbone is a library originally written by Jeremy Ashkenas (also famous for having created CoffeeScript).

    Backbone is an implementation of the MVC design pattern in JavaScript. It allows you to build applications easier to maintain by strongly dividing responsibility of each application component. Actually due to it’s high flexibility, Backbone is more something like a super controller in the MVC design pattern than a true MVC implementation. It gives you freedom to choose your own model or view system as long as you make sure they are compatible with its API.

    Basic usage

    Backbone is made of 4 core objects that will be used to drive your application: Collection, Model, View, Router. To make things a little clearer here is a quick schema of their interaction:

    The Model objects

    Those kind of objects are the heart of your application. They will contain the whole logic of your application and they will dispatch events each time they are updated. That way, you can easily bind a View object to a model in order to react to any change. Those objects are actually wrappers around your own application business logic (Functions, Objects, Libraries, whatever).

    The Collection objects

    As stated by its name, this type of object is a collection of Model objects with their own logic to sort them, filter them, etc. This object is a convenient way to make the glue between the model and the view because it is some sort of a super Model object. Any change send by a Model object in a collection is also sent by the collection so it makes easy to bind a view to several Model objects.

    The View objects

    Backbone views are almost more convention than code — they don’t determine anything about your HTML or CSS for you, you’re free to use any JavaScript templating library such as Mustache, haml-js, etc. The idea is to organize your interface into logical views, backed by models, each of which can be updated independently when the model changes, without having to redraw the page. Instead of digging into a JSON object, looking up an element in the DOM, and updating the HTML by hand, you can bind your view’s render function to the model’s “change” event — and thanks to that everywhere that model data is displayed in the UI, it’s immediately updated.

    The Router objects

    Those objects provides methods for routing URLs, and connecting them to actions and events on Model objects. It relies on the History API to nicely handle the URLs. For browsers which don’t yet support the History API, it handles graceful fallback and transparent translation to a hash fragments’ URL.

    So as you can see it’s not necessarily a canonical implementation of the MVC design pattern but it allows you to work that way with high flexibility.

    Getting started or Digging into it

    Digging into Backbone is not that simple. As you can see, I haven’t tried to provide some code sample in this article. Even if the documentation is well written it’s sometimes a bit difficult to understand how to use the full API. Fortunately, there is some very good tutorials and projects out there and I recommend the following:

    If you know some other good resources, feel free to add it through the comments ;)

    Limits and precautions

    One of the biggest limitations of backbone is its dependency of two other libraries: Underscore and jQuery (or jQuery like library such as Zepto). The former provide some very useful (and missing) features to JavaScript, the latter is conveniently used to access and manipulate the DOM easily as well as dealing with DOM Events.

    Another point you should take care of is that backbone remains a very low level library that can be hard to deploy and to use easily. This is mainly due to the fact that it’s just a library rather than a full framework with coding conventions. Some aside projects try to make it more user friendly. One of the best known is the Chaplin project.


    Backbone is one of the best libraries to help you build powerful applications. Even if its MVC implementation is somewhat unconventional, it’s a very good way to structure your code and being able to make your code base grow without too much trouble. Of course there are other libraries that do similar things such as Ember or Knockout. If you plan to work on a large application, you really should consider using one of them.