At the beginning of the year when we started developing Greenhouse Go Carbon Planner, we were met with complex interwoven relationships we needed to abstract. We chose Backbone and Marionette.js because of their flexibility and lack of assumptions, and we haven't looked back.



Intro to Marionette

To quote the website, "[Marionette] is a collection of common design and implementation patterns found in the applications that we have been building with Backbone, and includes pieces inspired by composite application architectures, event-driven architectures, messaging architectures, and more."

Why We Chose Marionette

Carbon Planner is a web-based application for land developers, consultants and public agencies to forecast greenhouse gas emissions from proposed land development, and plan a mitigation strategy to meet local goals. As such, it's more complicated than just retrieving data from an endpoint and displaying it on the screen. We do quite a bit of calculations for display purposes on the front end, and we wanted to have complete control over how that was rendered.

Marionette focuses on the most commonly used patterns found in complex Backbone applications presents them to you as a tool belt. For us and for Carbon Planner, it was the great medium between vanilla Backbone, and a heavily opinionated framework.

A pivotal reason we chose Marionette over another framework, is that the binding of Model to View was more complex in our application than in most. We had a whole set of calculation classes running in the background calculating emissions, land usage, among other things (these were duplicated on the backend if we needed them there). It would have been really computationally expensive to just let a framework with two-way binding do it's thing. We needed finite control over when the computations should run, keeping performance speedy, and we didn't want to hack anything to do that.