Backbone vs Marko Widgets

A lightweight view class is provided but there is no default templating method implemented. Because views are minimal it allows for much more freedom to implement views however you would like, and because of this freedom it's possible to write views to more uniquely adapt to a problem.

User interactions are done within an events object that allows these interactions to be segregated from the rest of the view code which makes the behavioral aspect of the view easier to read and manage.

Backbone can be combined with any library of your choosing, giving you the ultimate flexibility in creating customized solutions for unique projects. Even the only two backbone requirements, jQuery and underscore can be replaced with equivalent libraries like zepto or lo-dash.

Backbone has existed longer than most frameworks, and has a large following of users and projects using it as a framework.

Backbone collections and models are extended by underscore.js method allowing you to call underscore methods directly on the Backbone objects.

Backbone provides Model and Collection classes that provide strong analogs to restful resources. These strong analogs allow you to interface more naturally with the API, and makes it easier to write custom behaviors for more complicated API interactions.

Collections provide a variety of powerful manipulation methods that are integrated from the underscore library, that allow you to manipulate, sort, and filter collection data easily.

Because all the state is managed by Models and Controllers, and they are extendable objects, you can isolate all the state logic onto those objects allowing the rest of the application to not worry about it. The app is simplified to just taking in input to modify the Models and Controllers, and updating the views to reflect them, but none of the state needs to be a concern outside of the Model and Controller classes.

There is no “magic” happening below the surface: the source code is clear, readable and well commented. Backbone is also “lightweight” in the sense that it doesn’t require a ton of buy-in to use. It can be easily integrated into an existing page, and you can choose to only use certain components of the library (Views without Models or Collections, for example). While there are many frameworks that seem to be faster to get started with, Backbone’s lack of surprises, clear documentation, speed & flexibility make it a good fit for all types of apps.

Because Backbone is so simple, and the different components are very well isolated, it is very easy to extend the functionality of Backbone. If you're writing your own extended code it's easy to keep it separated out, and share with the community.

The community also has many plugins already available, which you can pick and choose to use to fit your programming style.

All Backbone classes extend an events class that allows for listening and triggering functionality. Because all classes implement events by default it is easier to provide asynchronous communication between objects, and it allows better abstraction of interaction so the event emitting object does not need to know the structure or existence of the receiving object.

Using Marko and Marko Widgets to render UI components on the server was shown to be 10x faster than React. A benchmark application was built using both Marko+Marko Widgets and React and the results of rendering a page of 100 search results on the server was measured and compared. Both the Marko Widgets code and the React code used a very similar UI components-based appraoch.

Marko Widgets supports stateful UI components. Marko Widgets will automatically rerender a UI component if its internal state changes. A UI component's state is stored in the this.state property that is a vanilla JavaScript object. All changes to the state should go through the this.setState(name, value) method (or this.replaceState(newState))

Marko Widgets utilizes the morphdom module for updating the DOM and that module was shown to be very competitive with React and virtual-dom.

Marko Widgets does not rely on a virtual DOM abstraction. Instead, the real DOM is always the source of truth. When updating the DOM, the newly rendered DOM is compared with the real DOM.

Marko Widgets updates the DOM using a DOM diffing/patching algorithm to minimize the number of changes to the DOM when rerendering a UI component due to state changes. The DOM diffing/patching is handled by the independent morphdom library.

The following code illustrates how the render(input) method exported by a UI component's JavaScript module can be used to render a UI component and insert the resulting HTML into the DOM:

require('./app-hello')
    .render({
        name: 'John'
    })
    .appendTo(document.body)

Updates to the DOM are deferred until all state changes have completed for the current tick. That is, changing a widget's state will not cause the UI component's DOM to immediately be updated.

Marko Widgets offers a simple mechanism for declaratively binding DOM event and custom event listeners to widget handler methods. For example:

<button type="button" w-onClick="handleClick">
    Click Me
</button>

And then in the JavaScript:

module.exports = require('marko-widgets').defineComponent({
    // ...
    handleClick: function(event, el) {
        this.doSomething();
    }
});

Marko is a fast and lightweight, general purpose HTML-based templating engine that compiles templates to CommonJS modules and supports streaming, async rendering and custom tags. Marko is used for rendering UI components and Marko Widgets is used to bind client-side behavior to rendered UI components. Marko can be used independently of Marko Widgets and this makes it suitable in all situations where HTML rendering is needed.

When utilizing server-side rendering of a UI, Marko Widgets does not require that the UI be rerendered again in the browser just to bind behavior. Instead, extra information is passed down from the server to the client to allow Marko Widgets to efficiently bind widgets to UI components rendered on the server.

The runtime for Marko Widgets is extremely small. The runtime is very small and this makes Marko Widgets much simpler and easier to understand and debug. Marko Widgets offloads much of the work and complexity to compile time code so that the work required at runtime is minimal.

Marko Widgets supports the concept of "scoped" IDs. With scoped IDs, a nested DOM element or nested widget can be given an ID that is unique within the scope of the containing widget. At runtime the actual ID will be the scoped ID prefixed with the ID of the parent widget. A reference nested widget can be obtained using the this.getWidget(scopedId) method and a reference to a nested DOM element can be obtained using the this.getEl(scopedId) method.

For example:

<div class="my-app" w-bind>
    <button type="button" w-onClick="handleButtonClick">
        Click Me
    </button>

    <alert-overlay visible="false" w-id="alert">
        This is a test alert.
    </alert-overlay>

    <div w-id="clickMessage" style="display: none;">
        You clicked the button!
    </div>
</div>

And then in the JavaScript code:

module.exports = require('marko-widgets').defineComponent({

    // ...

    handleButtonClick: function(event, el) {
        var alertWidget = this.getWidget('alert');

        // Call the `show()` function implemented by the alert widget:
        alertWidget.show();

        var clickMessageEl = this.getEl('clickMessage');
        clickMessageEl.style.display = 'block';
    }
});

Marko Widgets supports efficient event delegation to avoid attaching DOM event listeners to each DOM node. Instead, Marko Widgets attaches event listeners on the document.body event for events that bubble. Events captured at the root are efficiently delegated out to widgets.

The following code illustrates how a UI component can be embedded in a Marko template:

<div>
    <app-hello name="Frank"/>
</div>