TodoMVC, one app per library

TodoMVC is one small application, a list of todos. Programmers have written it in many frameworks, so that the frameworks can be compared on the same work. Its specification says what the application does, in thirteen points: adding, editing, completing, counting, clearing, routing and keeping the todos. The Amber contributors have written it once per Amber view library, nine times, in the repository amber/amber-todomvc. The pages that follow walk through the nine variants, one page each. The last page sets them side by side.

What every variant shares

Every variant shows the same model, the package TodoMVC-Model. It holds the todos, the filter and the storage, and nothing of the page. TodoMVC with Silk walks through it. Its 61 tests run under Node.js.

Every variant has the same page, the markup of the TodoMVC app template with its two stylesheets from npm. Each page loads a bundle of its own. The variants with snippets keep the item of the template in the page. The Mithril variant keeps nothing but the empty section, since Mithril renders the whole markup.

Every variant passes the same 25 tests, those of TodoAppTest. They drive the view with DOM events, one point of the specification per test, and read what the page shows. Each variant answers one message, which attaches its view to the markup of the fixture. These tests need a browser, so they run in the test runner of Helios, on the page of the variant.

The four axes

The variants differ on four axes, and each page says where its variant stands:

• How the DOM is built. Element by element, from a string of markup, or with tag messages. From a snippet, or as virtual nodes.
• Where the markup lives. In the page, in the code, or in both.
• How events bind. A listener on an element, or a message on a wrapper. An attribute of a virtual node, or a presenter’s block.
• How the view follows the model. The whole view rendered again after every change. Parts refreshed from their data. Or a redraw that the library diffs.

The pages

The pages read in the order of the repository. The Silk page is the full walkthrough, with the model, and the other pages show what differs from it:

1. The DOM alone, the baseline. JavaScript objects and nothing else. Every library is measured against what the DOM costs here.
2. jQuery, through Wrappers-JQuery, Amber’s thinnest wrapper and its idiom before 2015.
3. Web, the canvas and its brushes, and a widget per todo.
4. Web with jQuery. Web builds, and jQuery does the rest.
5. Web with snippets. The markup of a todo comes from the page.
6. Silk, the full walkthrough: the model, the page, the view method by method.
7. Silk with snippets. The markup of a todo comes from the page.
8. Silk with MiniMVP. A presenter per part of the page and per todo.
9. Mithril, a JavaScript library taken from npm as it comes, and what crosses the boundary.
10. The variants compared, side by side on the four axes, with what each library has no word for.

Each page ends with the same table. It sets the thirteen points of the specification against where each is in the code, and what it takes. A point that the model answers is marked so, since the model is the same everywhere.

Running it

Clone amber/amber-todomvc and run npm run init, then amber serve. Open http://localhost:4000/ and pick a variant. Its README says how a variant is built, bundled and deployed, and which third-party code the pages use.