# Blaze: reactive HTML templates for Meteor applications

> Blaze is the template library bundled with Meteor, where a template compiler turns Spacebars syntax into JavaScript and a reactive DOM engine updates the page automatically from Tracker and Minimongo data. It suits a Meteor application that wants the DOM to follow the database without hand-written update code, and it is tied to Meteor's own reactivity model.

**meteor/blaze** — :fire: Meteor Blaze is a powerful library for creating live-updating user interfaces

- Repository: https://github.com/meteor/blaze
- Website: http://blazejs.org/
- Stars: 544 · Forks: 118
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/meteor-blaze

## The problem Blaze removes

Blaze is described as a powerful library for creating user interfaces by writing reactive HTML templates, and the readme states the comparison directly: compared to using a combination of traditional templates and jQuery, Blaze eliminates the need for all the update logic in your app that listens for data changes and manipulates the DOM.

That is the whole pitch, and it is a pitch aimed at a specific pain. In a traditional server-rendered page plus jQuery application, the developer writes two kinds of code: code that produces the initial HTML and code that watches the data and patches the DOM when it changes. The second kind is where the bugs live, because a view can drift out of sync with the data it claims to show, and the fix is usually another listener.

Blaze removes the second kind. Instead of familiar template directives like {{#if}} and {{#each}} integrating with Tracker's transparent reactivity and Minimongo's database cursors so that the DOM updates automatically. Tracker's transparent reactivity means a computation re-runs when the data it read changes, and a Minimongo cursor is a live query against the client-side database. A template region bound to a cursor re-renders when the cursor's results change, without anyone listening for it.

So the mental model is that the DOM is a function of the data. That is the same model React popularised, arrived at several years earlier and by a different route, and it is worth knowing that Blaze predates that comparison rather than being a React-alike.

The project is from the Meteor organisation, the homepage is blazejs.org, and the licence is one GitHub cannot classify, with the LICENSE file in the repository root.

## Two parts: a compiler and a reactive DOM engine

Blaze has two major parts, and separating them is the key to understanding what it is.

The first is a template compiler that compiles template files into JavaScript code that runs against the Blaze runtime library. The readme makes an analogy that explains the design: Blaze provides a compiler toolchain, think LLVM, that can be used to support arbitrary template syntaxes. The flagship syntax is Spacebars, a variant of Handlebars, and a community alternative based on Jade is already in use by many apps.

That analogy is doing real work. A template compiler as a separate, pluggable stage, with the runtime knowing nothing about the syntax, means the syntax is an implementation detail of the front end. Spacebars is not baked into Blaze; it is one input to the compiler toolchain. If you want a different syntax, you replace the front end and the runtime stays the same.

The second part is a reactive DOM engine that builds and manages the DOM at runtime, invoked via templates or directly from the app. Its features are listed as reactively updating regions, lists and attributes, event delegation, and many callbacks and hooks to aid the app developer.

Event delegation is worth a note, because it is a performance decision rather than a feature checkbox. Rather than attaching a handler to every element in a list, Blaze attaches handlers at a higher level and lets the event propagate, which is the difference between a list of a thousand rows costing a thousand listeners and costing a handful.

The callbacks and hooks are the escape hatch for the cases the declarative model does not cover, such as needing to run code when a region is inserted or removed, or when a template is instantiated.

The readme points at OVERVIEW.md for the details of how these parts fit together, and the repository holds it alongside HISTORY.md, DEPLOYMENT.md, SECURITY.md and CONTRIBUTING.md.

## Distribution, and why it is a Meteor-only package

The Quick Start section is short and it contains the most consequential fact for anyone considering Blaze outside Meteor.

Blaze is a Meteor-only package for now, and soon there will be Blaze on npm so you can use it in your stack. Each new Meteor project you create has Blaze included, through the blaze-html-templates package.

So there are two things to take from this. First, the current distribution is a Meteor package, which means you cannot install Blaze into an existing React, Vue or plain JavaScript application. The npm release is stated as a future intention, with no version and no date.

Second, and more subtly, the Meteor-only distribution is not just a packaging constraint. Blaze's reactivity comes from Tracker and its data binding comes from Minimongo, both of which are Meteor packages. A Blaze template that reacts to a Minimongo cursor needs the cursor, and the cursor needs the client-side database. Even if Blaze were on npm tomorrow, the reactive data source that makes it interesting would still be Meteor's.

That said, the runtime engine is described as invokable directly from the app, not only via templates, which is the part that would travel. A developer using Blaze's reactive regions and event delegation with their own data source would get the DOM engine without the Meteor stack. Whether that is a supported arrangement is not something the readme addresses.

The repository layout supports the multi-package picture: a packages/ directory for the individual packages, a site/ directory, a test-app/ directory for the test application, .gitmodules for submodules, and a publish-all.sh script for releasing the packages together.

The release history shows v2.7.1 from 2023-08-02, v2.8.0 from 2024-01-02 and v2.9.0 from 2024-04-08, while the last push to the repository was on 2026-10-19. So the tree is well ahead of the last tagged release.

## The community around it

Blaze has the infrastructure of a project that expects contributors, and the readme points at all of it.

There is a Slack channel with a badge in the header, a contributing guide at CONTRIBUTING.md, open issues on GitHub with a label for contributions welcome, and issues organised into GitHub projects for a better overview, plus a roadmap expressed as milestones showing the issues needed for the next release.

Funding is arranged through Open Collective, with separate backer and sponsor tiers and a badge for each. The readme describes support as a monthly donation that helps continue their activities. The badge block at the top of the readme lists a long run of backers with avatar slots, which is the visual sign of a project that has had broad community funding at some point.

The readme also points at a support community for general questions and support, and asks contributors to check the contributing guide. The CircleCI badge shows continuous integration was set up on CircleCI, and there is a SECURITY.md at the repository root for reporting vulnerabilities.

One detail in the repository listing is easy to overlook and matters for anyone reading the source: .gitmodules is present, so some parts of the build are pulled in as git submodules rather than vendored directly. For a project with several packages that publish together, that is usually how a shared submodule is versioned alongside them.

The overall picture is of a mature, well-funded, community-run project inside the Meteor ecosystem rather than a standalone library, which is exactly what the Meteor-only distribution implies.

## Where Blaze is the wrong choice

The first limitation is the dependency on Meteor. The readme is explicit that Blaze is a Meteor-only package for now, so a team building on React, Vue or anything else is looking at a promise rather than an option. If you are choosing a UI layer for a new project today, the honest comparison is not Blaze against other template engines, it is Blaze against whether you want Meteor's data layer at all.

The second is the reactivity model underneath. Blaze's automatic updates come from Tracker and Minimongo. That is a real strength inside Meteor, where the data is already reactive, and a real limitation outside it, where you would need a source of reactivity that Blaze knows how to subscribe to. The readme does not describe a generic adapter for other observable sources, which leaves you writing your own integration or living with the Meteor one.

The third is the release gap. The newest published release is v2.9.0 from 2024-04-08, and the last push to the repository was on 2026-10-19. A library whose master branch has moved well past its last tag is a library where you are running unreleased code, and the changelog is in HISTORY.md in the repository rather than in release notes you can rely on.

The fourth is that the community-facing routes are dated. The Slack channel is at slack.blazejs.org, the contribution guide is referenced by a repository-relative path, and the project links a v7 documentation URL for the Meteor Android runtime, which reflects the era in which it was written. None of that is a functional problem, but it does tell you where the project's attention is not.

The fifth is the language choice. Blaze's flagship syntax is Spacebars, a variant of Handlebars, and the alternative in use by many apps is based on Jade. Both are of a generation that is now several years old, and the reactive-template pattern they express has since been picked up by React, Svelte, Solid and Vue in forms with better tooling, better typing and better performance characteristics. Blaze does what it did well, and the ecosystem it was built for has moved on.

## Conclusion

Blaze fits a Meteor application whose data already lives in Minimongo and whose interface can be described declaratively, since Tracker and MiniMongo cursors feed the reactive regions without any update logic of your own, and since the compiler and runtime ship together with every new Meteor project. It is the wrong choice for a stack outside Meteor, because the readme says Blaze is a Meteor-only package for now with an npm release still promised, and it is the wrong choice if you want to swap in a different template syntax without writing a compiler. Before adopting it, read OVERVIEW.md for the component model, and note that the last push was on 2026-10-19 while the newest published release is v2.9.0 from 2024-04-08.

## FAQ

### What is Blaze?

Blaze is a library for creating user interfaces by writing reactive HTML templates. Template directives such as {{#if}} and {{#each}} integrate with Tracker's transparent reactivity and Minimongo's database cursors, so the DOM updates automatically and no update logic is needed in the application.

### What are the two main parts of Blaze?

A template compiler that compiles template files into JavaScript running against the Blaze runtime, with a pluggable toolchain in the style of LLVM that can support arbitrary template syntaxes, and a reactive DOM engine that builds and manages the DOM at runtime with reactive regions, lists and attributes, event delegation, and callbacks and hooks.

### Can I use Blaze outside Meteor?

Not currently. The readme says Blaze is a Meteor-only package for now and that an npm release is planned, and the reactive behaviour depends on Tracker and Minimongo, which are themselves Meteor packages.

### Which template syntaxes does Blaze support?

The flagship syntax is Spacebars, a variant of Handlebars, and a community alternative based on Jade is already in use by many apps. Because the compiler is a pluggable toolchain in the style of LLVM, other syntaxes can be supported without changing the runtime.

### What licence is Blaze released under?

The licence field on the repository records a custom licence that GitHub cannot classify, with the terms in the LICENSE file at the root of the repository. The last push was on 2026-10-19 and the newest published release is v2.9.0 from 2024-04-08.

## Sources

- [Issues](https://github.com/meteor/blaze/issues)
- [meteor/blaze on GitHub](https://github.com/meteor/blaze)
- [Project website](http://blazejs.org/)
- [README](https://github.com/meteor/blaze/blob/master/README.md)
- [Releases](https://github.com/meteor/blaze/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/meteor-blaze