Mikado: a template engine that treats HTML as the template format

The pitch, and what is unusual about it

Mikado describes itself as the web's fastest template engine for building user interfaces, carefully crafted to get the most out of the browser, and also as the fastest Express render engine available, with the claim of being super-lightweight with no dependencies. The README's own framing is that rendering has a great impact on application performance, especially on mobile devices, and that Mikado takes templating performance to a new level. The distinctive design decision is the third paragraph of the introduction: server and client share the same template definitions, simply written in HTML-like markup. That is the thing that separates it from a server template engine plus a client framework, and it is why the project talks about hydration as injecting templates progressively within the client's runtime rather than as re-rendering a whole tree.

Keyed, non-keyed and reactive, switchable

The feature set splits into three rendering modes that the README presents as switchable out of the box. Keyed recycling and non-keyed recycling determine how DOM nodes are reused when a list re-renders, with the non-keyed mode being the simpler and faster one and the keyed mode the one that preserves identity across updates at a cost. The reactive paradigm is the third: the template engine can bind values to expressions so that a change updates the DOM rather than requiring an explicit re-render call. Alongside that there is a smart routing feature for event delegation, and full support for web components using the Shadow DOM. The README lists the routing features in the table of contents as event bubbling, an event cache, explicit register event delegation, control of native events and dispatch routes, which tells you the routing layer is a substantial part of the project rather than a thin wrapper over addEventListener.

The compiler and its flags

The template compiler is a major subsystem with its own documentation sections: reserved keywords, compiler flags, auto naming, a prebuilt cache, a watcher for auto-compiling and a runtime compiler. The npm manifest makes the size of the feature surface visible through the build flags, which are named SUPPORT_ and turned on individually: cache, events, DOM helpers, cache helpers, async, reactive, keyed, pools, callbacks, web components, compact template and compile. The build script passes each as an environment variable, and there is a separate debug build that differs by DEBUG and a RELEASE value. So the library ships configurable rather than monolithic: a project that only needs server rendering can leave the reactive and web components support out of the bundle. The package also exposes a command line entry, mikado-compile, pointing at compiler/cli.js, which is how the build step in a project is normally invoked.

Server-side rendering and hydration

The server side approach is described as coming with the fastest middleware render engine for Express available, and the README points at an express directory in the repository alongside src, ssr, compiler, dist, doc, examples, test and task. The manifest makes the packaging clear: the main entry is ssr/index.js and the module entry is the minified browser bundle, with a browser field that maps the server entry to the client bundle so bundlers pick the right one per target. The types entry is index.d.ts at the root, and the project advertises 93 percent typed coverage in its badges. Hydration is described as full support for injecting templates progressively within the client's runtime, which is the mechanism that lets the first paint happen with server output and the interactivity arrive afterwards.

The two ways to write a template

The documentation is organised around the two template sources, and the comment block in the README lists the demo variants. There is a basic example with the runtime compiler using an HTML5 template, and a basic example with the runtime compiler using a string template. Then there are the event examples, one in ES5, one in ES6 modules, and one using development sources. The rest are the TodoMVC application with both source and a built demo, and the js-framework-benchmark suite, where Mikado appears in four separate entries: keyed, non-keyed, and keyed with the proxy variant. That last detail is the one worth noting for an evaluator. A project that enters four separate benchmark categories is being measured in each mode rather than being tuned for one.

Where the API surface goes

The table of contents is a good index of what the library does. The API section covers view creation, mounting views, destroying views and rendering templates, and there is a separate section on views inside it. The expression section covers value insertion, inline JavaScript code, truthy values, escaping values for server-side rendering, HTML contents, a sanitizer and reactive bindings. The routing section covers event bubbling, the event cache, explicit register event delegation, controlling native events and dispatch routes. Then there is the recycling modes section for non-keyed and keyed recycling, and the compiler section with its own subsections. The scale of it is the point: this is a framework in everything but name, and the two recycling modes and the reactive layer are the parts a template library would normally leave to you.

Benchmarks, funding and the project's shape

The README links two benchmarks. One is an internal stress test benchmark, and the other is the js-framework-benchmark site, where Mikado appears in the keyed, non-keyed and keyed proxy categories. The internal benchmark is the one to read with care, since a project benchmarking itself controls the workload. The funding section is also informative about the project's shape: it asks for a personal donation across Open Collective, GitHub Sponsors, Liberapay, Patreon, Bountysource and PayPal, and says Mikado was getting so much positive feedback and also feature requests. A single-maintainer library funded by donations, with the author recorded as Thomas Wilkerling and the copyright as Nextapps GmbH, is a different kind of dependency from a company-backed one, and the README's own framing suggests the maintainer is the risk.

Where Mikado is the wrong choice

Four limits apply. The performance claims are the project's own, benchmarked by the project, and the headline comparison with JSON in the same README is a claim about a workload the maintainer chose. The template format is HTML-like markup, which means the templates are not valid components, not typed against your domain, and will not be picked up by the tooling a TypeScript team expects, so the integration cost lands on the team rather than the library. The feature surface is large enough that a team inherits a routing model, a recycling model and a reactive model, and the 0.8 migration guide in the documentation is evidence that the API has moved before. And with one maintainer, no dependencies to audit and a donation-based funding model, adoption is a bet on that person continuing, which is a fair thing to know and not a reason on its own to avoid the library.

Editorial conclusion

Use Mikado when you want server-rendered pages with client-side reactivity and a single template definition used by both, since the same HTML-like markup drives the server render and the browser runtime. Do not adopt it for a team that wants generated typed components, because the whole design is a template engine with a compiler rather than a component model. Verify first which version you install, since the 0.8 line has moved through several releases and the README points at a migration guide for anyone coming from an earlier version, and that the template compiler step is part of your build, because the compiler, its flags and the prebuilt cache are what make the performance claims hold.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nextapps-de/mikado on GitHub
4. README
5. Releases