TL;DR;

Marionette.js allows to render HTML using Virtual DOM or Incremental DOM libraries. The main benefits are the possibility to define the UI through declarative code and better performance. Some examples of custom rendering can be found here.

Marionette.js is a relatively old JavaScript framework that carries design patterns that are not considered state of the art in web development landscape. One of them is the usage of string template to render HTML.

Since version 2, is possible to customize how HTML is rendered and the recent changes in the framework made easier to override the default rendering strategy. For example, to support incremental-dom is necessary a function with one line of code and to use it another line:

The API design allows to have different rendering strategies in the same app opening the doors to a smooth transition.

When jQuery and Bootstrap meets virtual (or incremental) DOM

One of benefits of Marionette.js is the ability to integrate with jQuery and Bootstrap ecosystem in an straight way, without the need of additional layer or back and fourth code. Being able to build an application on top of one of many themes out there can be the difference, for small teams, to ship or not a product in a timely manner.

With Marionette.js it is possible to get the best of both worlds: the vast UI libraries found in the web and functional UI components based on virtual (or incremental) DOM. They can be used together not just in same application but also in the same view/component, i.e., a jQuery widget in an HTML tree rendered by a Virtual DOM library.

The rating is a jQuery widget. The surrounding HTML is rendered with incremental-dom or snabbdom

The marionette.renderers package contains implementations for a few libraries. It comes with examples (an adaptation of a Rivets + Backbone application with real time UI) for each renderer:

virtual-dom

virtual-dom was one of the first standalone virtual DOM implementations. Development got stuck recently but is a solid library.

The example uses the hyperscript helpers syntax:

snabbdom

snabbdom is a fast and small virtual DOM library. Is actively maintained and is being used by CycleJS.

Try live version.

This example uses JSX, through snabbdom-pragma, to define the components:

inferno

inferno is a small, extremely fast React like library.

This example uses a different approach from the others by nesting functional inferno components instead of using Marionette.js regions to define the UI tree:

The render function of a Marionette View using Inferno components

incremental-dom/handlebars

incremental-bars compiles Handlebars templates into incremental-dom calls. Probably the best bet for those who already use Handlebars.

incremental-dom/superviews

superviews is a incremental-dom transpiler that have a flexible template syntax. By far, it’s the more mature incremental-dom implementation producing optimal code.

Try live version.

A note about rendering performance

The main benefit of using the Virtual DOM approach is the ability to define the UI with declarative code which is easier to test and more predictable. But there’s another potential benefit: better rendering performance, especially for large lists.

The Marionette.js implementation in JS Benchmark uses CollectionView class which, in default configuration, has poor performance for such large list. It is possible to improve performance, matching other frameworks, by removing jQuery as a dependency and doing other advanced techniques.

By just switching the HTML renderer, e.g. to snabbdom, we can get the same or better performance of main contenders keeping the convenience of further Marionette.js features (see implementation here):

Final notes

Marionette.js is a non opinionated development tool providing the primitives to build from small to large applications. It is flexible enough to meet different demands.

Needs to use jQuery plugins? check;

Seamless Bootstrap integration? check;

State based routing? check;

Simple router? check;

No router? check;

Use Handlebars templates? check;

Component based UI? check;

Virtual DOM ? check.

It’s all there to the developer determine what meets more closely his/her needs.