What are the real-world strengths and weaknesses of the many frameworks based on backbone.js?

Question 1

What are the real-world strengths and weaknesses of the many frameworks based on backbone.js?

backbone.js javascript-framework

danikoren · Jun 1, 2012 · Viewed 21.8k times · Source

Answer

Answer

Most of (all of?) the frameworks that you're looking at solve the same problems, but they do it in slightly different ways with slightly different goals.

I think it's fair to say that all of these projects would solve the problems in these categories:

Provide sensible set of defaults
Reduce boilerplate code
Provide application structure on top of the BackboneJS building blocks
Extract patterns that authors use in their apps

Marionette, which I've been building since December of 2011, has a few very distinct goals and ideals in mind, as well:

Composite application architecture
Enterprise messaging pattern influence
Modularization options
Incremental use (no all-or-nothing requirement)
No server lock-in
Make it easy to change those defaults
Code as configuration / over configuration

I'm not saying none of the other frameworks have these same goals. But I think Marionette's uniqueness comes from the combination of these goals.

Composite Application Architecture

I spent more than 5 years working in thick-client, distributed software systems using WinForms and C#. I built apps for desktop, laptop (smart-client), mobile devices and web applications, all sharing a core functional set and working with the same server back-end many times. In this time, I learned the value of modularization and very rapidly moved down a path of composite application design.

The basic idea is to "compose" your application's runtime experience and process out of many smaller, individual pieces that don't necessarily know about each other. They register themselves with the overall composite application system and then they communicate through various means of decoupled messages and calls.

I've written a little bit about this on my blog, introducing Marionette as a composite application architecture for Backbone:

Message Queues / Patterns

The same large scale, distributed systems also took advantage of message queuing, enterprise integration patterns (messaging patterns), and service buses to handle the messages. This, more than anything else, had a tremendous influence on my approach to decoupled software development. I began to see single-process, in-memory WinForms applications from this perspective, and soon my server side and web application development took influence from this.

This has directly translated itself in to how I look at Backbone application design. I provide an event aggregator in Marionette, for both the high level Application object, and for each module that you create within the application.

I think about messages that I can send between my modules: command messages, event messages, and more. I also think about the server side communication as messages with these same patterns. Some of the patterns have made their way in to Marionette already, but some haven't yet.

Modularization

Modularization of code is tremendously important. Creating small, well encapsulated packages that have a singular focus with well defined entry and exit points is a must for any system of any significant size and complexity.

Marionette provides modularization directly through it's module definitions. But I also recognize that some people like RequireJS and want to use that. So I provide both a standard build and a RequireJS compatible build.


MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(No blog post available for this, yet)

Incremental Use

This is one of the core philosophies that I bake in to every part of Marionette that I can: no "all-or-nothing" requirement for use of Marionette.

Backbone itself takes a very incremental and modular approach with all of it's building block objects. You are free to choose which ones you want to use, when. I strongly believe in this principle and strive to make sure Marionette works the same way.

To that end, the majority of the pieces that I have built in to Marionette are built to stand alone, to work with the core pieces of Backbone, and to work together even better.

For example, nearly every Backbone application needs to dynamically show a Backbone view in a particular place on the screen. The apps also need to handle closing old views and cleaning up memory when a new one is put in place. This is where Marionette's Region comes in to play. A region handles the boilerplate code of taking a view, calling render on it, and stuffing the result in to the DOM for you. Then will close that view and clean it up for you, provided your view has a "close" method on it.


MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

But you're not required to use Marionette's views in order to use a region. The only requirement is that you are extending from Backbone.View at some point in the object's prototype chain. If you choose to provide a close method, a onShow method, or others, Marionette's Region will call it for you at the right time.

No Server Lock-in

I build Backbone / Marionette apps on top of a wide variety of server technologies:

ASP.NET MVC
Ruby on Rails
Ruby / Sinatra
NodeJS / ExpressJS
PHP / Slim
Java
Erlang
... and more

JavaScript is JavaScript, when it comes to running in a browser. Server side JavaScript is awesome, too, but it has zero effect or influence on how I write my browser based JavaScript.

Because of the diversity in projects that I built and back-end technologies that my clients use, I cannot and will not lock Marionette in to a single server side technology stack for any reason. I won't provide a boilerplate project. I won't provide a ruby gem or an npm package. I want people to understand that Marionette doesn't require a specific back-end server. It's browser based JavaScript, and the back-end doesn't matter.

Of course, I fully support other people providing packages for their language and framework. I list those packages in the Wiki and hope that people continue to build more packages as they see a need. But that is community support, not direct support from Marionette.

https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

Easily Change The Defaults

In my effort to reduce boilerplate code and provide sensible defaults (which is an idea that I directly "borrowed" from Tim Branyen's LayoutManager), I recognize the need for other developers to use slightly different implementations than I do.

I provide rendering based on inline <script> tags for templates, using Underscore.js templating by default. But you can replace this by changing the Renderer and/or TempalteCache objects in Marionette. These two objects provide the core of the rendering capabilities, and there are wiki pages that show how to change this out for specific templating engines and different ways of loading templates.

With v0.9 of Marionette, it gets even easier. For example, if you want to replace the use of inline template script blocks with pre-compiled templates, you only have to replace one method on the Renderer:


Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

and now the entire application will use pre-compiled templates that you attach to your view's template attribute.

I even provide a Marionette.Async add-on with v0.9 that allows you to support asynchronously rendering views. I continuously strive to make it as easy as possible to replace the default behaviors in Marionette.

Code As Configuration

I'm a fan of "convention over configuration" in certain contexts. It is a powerful way of getting things done, and Marionette provides a little bit of this - though not too much, honestly. Many other frameworks - especially LayoutManager - provide more convention over configuration than Marionette does.

This is done with purpose and intent.

I've built enough JavaScript plugins, frameworks, add-ons and applications to know the pain of trying to get conventions to work in a meaningful and fast way. It can be done with speed, but usually at the cost of being able to change it.

To that end, I take a "code as configuration" approach to Marionette. I don't provide a lot of "configuration" APIs where you can provide an object literal with static values that change a swath of behaviors. Instead, I document the methods that each object has - both through annotated source code and through the actual API documentation - with the intent of telling you how to change Marionette to work the way you want.

By providing a clean and clear API for the Marionette objects, I create a situation where replacing the behavior of a specific object or Marionette as a whole is relatively simple and very flexible. I sacrifice the "simple" configuration API calls for the flexibility of providing your own code to make things work in the way that you want.

You won't find a "configure" or "options" API in Marionette. But you will find a large number of methods that each serve a very specific purpose, with clean signatures, that make it easy to change how Marionette works.

Question 2

Hope that someone can share their experience with some of the latest emerging backbone.js variants out there. I have some good experience with backbone/underscore/require in several projects and I will like to take the next step towards more advanced solutions for complex application structure.

I know the following frameworks are available:

And probably I missed a few.

There is a short introduction about the differences here:

speakerdeck talk link

but it's very general. I was wondering if someone can share their experience with real life applications using these frameworks.

What is the benefit of choosing one over the other? When will marionette be a better solution over chaplin, or why is vetebrae better for certain applications, for example.

Sure, the obvious answer will be "use whats best for your needs", but I lack of the experience with these frameworks to know their strength/purpose/advantages or preferred scenarios.

Thanks!

Edit 1: found this post: Backbone.Marionette vs Backbone-Boilerplate

Edit 2: Answer by Mathias schafer (Chaplin) by mail:

In short, the current structure is close to version 1.0 since it’s already used in production. We’re not planning to add big new feature or breaking API changes until 1.0.

Marionette is for sure the most comprehensive and stable library out there. It addresses several aspects of JS app development with Backbone. For example, it has a strong view layer which Backbone itself leaves completely void. Of course, you will find that some of the aspects won’t meet your demands and you might feel the need to set up a structure around Marionette.

In contrast, Chaplin focusses on a rather small, but very important aspect of Backbone apps, namely the overall app structure and module lifecycle. In this regard Chaplin is very opionated and is more like a framework than a library (like in “your code calls a library, a framework calls your code”). Chaplin provides some central classes which sit above individual application modules and control the overall app state. This gives your app a conventional structure like Ruby on Rails does it for example.

In Chaplin, you declare some routes which map to controllers, and Chaplin starts the controller once the route match. It also takes care of the disposal of old controllers, and the showing and hiding of main views, which a controller is supposed to create. This is the basic idea, but Chaplin takes care of the ugly details to make this run smoothly.

There are two principals which come along with this structure: - Modularization, decoupling and sandboxing - Cross-module communication using Publish/Subscribe and Mediator(s)

Of course these patterns are not new in the software development world, and Chaplin is not the only library which applies them to Backbone.js apps.

Chaplin also provides enhancements for the View layer, for example a highly sophisticated CollectionView, but in total not as much as Marionette with its Regions and Layouts. But it’s relatively easy to write such meta classes using the means Chaplin Views provide.

What are the real-world strengths and weaknesses of the many frameworks based on backbone.js?

Answer

Composite Application Architecture

Message Queues / Patterns

Modularization

Incremental Use

No Server Lock-in

Easily Change The Defaults

Code As Configuration

Related questions