Question

I am using marionette v0.9.10 . Recently i had a problem. So I saw that in new marionette certain functionality is moved to different plugins

Backbone.EventBinder

Backbone.Wreqr

Backbone.BabySitter

I just wanted to know what are advantages of using it over previous version

Answer 1

The purpose of extracting those other repositories from Marionette was two things:

1. provide more value to the larger Backbone development community
2. allow a release schedule for Marionette that is not tied directly to those components in all cases

For the first reason: there are a number of people who have expressed direct interest in each of the areas that those plugins cover. I’ve answered numerous questions here on SO and out in the rest of the community relating to decoupled architecture, child view management, event management, etc. By splitting these chunks of code out in to separate repositories, the larger Backbone community can take advantage of this functionality.

For the second reason: having separate repositories and plugins allows us to make changes to the specific sub-set of functionality and not have to do a full release / version bump of Marionette itself. For example, I can move BabySitter from v0.0.1 to v1.0 without changing any of Marionette’s code. Having the release cycles decoupled allows greater flexibility in delivering updates and fixes.

Lastly, the separation of these libraries provides a better layer of abstraction between the pieces of Marionette. We’re no longer tempted to directly code this functionality in to the objects that want to use it. Instead, we have to use the separate library and incorporate it in to Marionette appropriately. The core Marionette.View is a good example of things gone wrong and why we want to do that. There are too many disparate pieces in Marionette.View – too many things that are not really related, but we wanted it in one of the other views. Splitting apart the library into multiple libraries allows us to fix that problem.

As far as managing these dependencies is concerned, you have at least 4 options.

1. Grab the “pre-packaged build” from http://marionettejs.com – it contains everything to get started (backbone, underscore, jquery, all prerequisites, marionette, etc)
2. Grab a “bundled” build, which contains all of the prerequisites and marionette, in one file
3. Grab the individual pieces and a “core” build – put the pieces together yourself, and manage the versions yourself
4. Use a package manager like JamJS or Bower

Regarding the advantages of using a newer version of Marionette: bug fixes, new features, more stable code, more consistent API, newer and better objects to support development, and support for the current releases.

Sticking with an old release is fine if it does everything you need. There are live apps around the web that are running nearly every .minor version of marionette at this point. Those apps may not need to update, so they stick with what they have. But you won’t get much support for old versions, honestly.

Until v1.0 final drops, backward compatibility and support is almost non-existent. Once v1.0 drops, we’ll provide bug fixes for that for a short time, but will move new features forward in new versions.

HTH