Javascript: Phonegap with Backbone and Marionette

We’ve worked with our clients to execute a couple of Phonegap apps lately and in doing so used Backbone and Marionette to structure the apps. For some background, Phonegap, now Apache Cordova, is a project that allows developers to build native iOS, Android, and WP apps using HTML, CSS, and of course Javascript. As a developer, you write some HTML and Javascript, pass it to Phonegap, and Phonegap returns a native app that displays your code inside a WebView without any surrounding chrome. On top of this, Phonegap provides a set of Javascript APIs that allow you to leverage some of the device’s native functions, like the accelerometer or camera.

Writing apps with HTML/JS is great, but it presents some issues particularly that triggering a full page reload for navigation appears “non-native” on mobile. On technique to combat this issue is developing single page Javascript apps. In a single page app, the entire page is never reloaded, instead portions of the DOM are dynamically re-rendered using Javascript. Because of the complexity of managing this process with straight Javascript, several libraries, including Backbone, have been developed to simplify this process. Marionette is a companion library to Backbone which provides a set of features to make managing complex applications easier. So, what were the pros and cons of using Backbone with Marionette to build a Phonegap app?

The Good

Structure: Using a library like Backbone guides you to structuring your code in loosely a MVC design pattern. Coupled with a templating framework, this ends up producing code that’s much easier to follow and maintain. Before Phonegap, I’d already started using Backbone in traditional Symfony2 projects just to get the benefit of better structured code.

It’s familiar: This is a personal preference, but compared to declarative frameworks like AngularJS, Backbone/Marionette apps “look” like regular HTML/JS. Primarily because of the regular HTML templates and use of jQuery, the learning curve for Backbone isn’t very steep. A team member without Backbone experience can quickly grok how things work and make changes quickly.

The Not So Good

“There’s more than one way to do it”: Although flexibility is good, having a generally “well recommended” way usually helps decrease confusion and frustration. With Backbone/Marionette, there doesn’t seem to be much consensus on how to do “standard” things like message passing or even structuring the app as a whole. There’s dozens of StackOverflow answers debating the “best” way to approach things, often with outright conflicting viewpoints. In contrast, Symfony2 and Rails typically have “best practices” for approaching common tasks, even if they’re not appropriate in every circumstance.

Documentation: The documentation for Marionette, and to a lesser degree Backbone, is pretty lacking. The Marionette documentation explains how the individual components work but they didn’t provide much insight to the “big picture”. The docs were also missing some explanation into the “why”, which of course lead to StackOverflow answers and then differing viewpoints. Marionette is also short example apps which Backbone does have. The Backbone documentation is thorough, its just a bit hard to navigate and purposefully introduces the “There’s more than one way to do it” mantra.

Anyway, on the whole using Backbone with Marionette to build a Phonegap app was a positive experience. Unfortunately, our clients’ own the code so we can’t release it. That said, we’ll do our best to build something in-house that we can share.

Posted In: BackboneJS, Javascript

Tags: , ,

  • Give Ember a shot! I think you’ll find it nudges you in a single direction, much more than the libraries in the Backbone ecosystem.

    Ember’s goal is to take the architecture that you would have come up with (if you were an expert Backbone developer), and bake it into the framework.

  • Oh nice! For some reason, I always forget about Ember.

    I’ll definitely take a look!

  • James

    While I agree with you about there being more than one way to skin a cat maybe you should try reading the annotated source code and the documentation there after. Backbone isn’t a framework it’s a toolkit and that’s probably why you consider the documentation ‘lacking’. On that note Marionette isn’t a framework either. If you were looking for something opinionated you could take a look at Chaplin (CoffeeScript) or Thorax.

  • Agreed, characterizing Backbone or Marionette as a framework is incorrect. That said, I don’t think having a consensus way to do something requires that your framework or toolkit be opinionated. For example, “idiomatic Python” or “the jQuery way”.

  • Roman Ganchenko

    Well, in order to get some insight into Marionette, there are dozens of Github projects like https://github.com/thejameskyle/marionette-wires where you can learn of how things are working.

  • James Kyle

    Hey Ashish, core team member of Marionette.js here.

    The team would agree with a lot of what you said here, and we are actively working on addressing them. I’m actually on a train back from NYC to Boston right now where the core team just had a documentation-focused hackathon, we also worked on some cool stuff like a new DevTools panel, and new error handling.

    I actually have to disagree about “More than one way to do it” being an inherently bad thing. Marionette will never try to actively enforce convention. However, We are actively focused on narrowing down what we consider good application structure in 3.0.

    I always love seeing new Marionette codebases because it’s always amazing to me the many ways Marionette applications are built. To say I know better than all these other people just feels wrong on a fundamental level.

    If you want my advice on how to build web apps (Marionette or not), you can always stop by the Marionette.js [gitter channel](https://gitter.im/marionettejs/backbone.marionette/). There’s a lot of really great people there.

    Also, you briefly mentioned there being no consensus about message passing. This is actually something that Core is very opinionated about, which is why James Smith and I have spent months rebuilding Backbone.Wreqr as [Backbone.Radio](https://github.com/jmeas/backbone.radio). Which will ship with Marionette in 3.0 (although you can use it today with or without Marionette).

    Thanks!

  • Hey James – thanks for the insight and the links. Hadn’t seen Backbone.Radio before but it looks great.