Hi, I’m David Greenspan from Meteor Development Group. It’s my pleasure to talk to you today about what we’re doing at Meteor, and in particular, our reactive templating system called Blaze.
I’m going to start with an overview of the Meteor framework, and then I’m going to talk about the design of Blaze.
Meteor is an open-source web framework for making great apps in a fraction of the time.
The bar for apps these days is set really high. You want to deliver an app that is fast, richly interactive, and collaborative.
Meteor makes it easy to write and deploy apps for web developers and designers like you. You get more out of the box, you write less boilerplate and less glue code, but you can still use the technologies you love.
In particular, Meteor solves the technical problems that are increasingly faced by new apps and not addressed well by existing frameworks:
Once an app goes live, it quickly matters what it’s like to operate and how it responds to load. Ideally your app scales automatically or with the touch of a button.
Security is a concern that cuts through your whole tech stack, and authentication leads to a lot of boilerplate code around OAuth integration, user accounts, and so on.
(Show examples of apps, like Pintask.)
Pintask is a great app. Check it out, it’s fast; it provides good feedback. All of these actions are synchronized in realtime across tabs and between collaborators. Just plumbing the data updates between the interface, whatever local representation we have in the browser, the server, the database, and the other clients generally takes a ton of work without a framework like Meteor, and often it’s systems design work that we have repeat for the different features of our app.
I want to take the time to go into a little history, and explain how we got to where we are today. Frameworks like Rails, Django, and J2EE were designed for a previous generation of apps, but that only becomes clear if you see where we started from and where we’re going.
Web apps started from humble beginnings.
If we go back in time twenty years, to the 90s, there were apps, and there was the web.
Photoshop 3 and Netscape 1.0 in 1995:
The web was not a place for apps, it was a place for text documents. A web browser was an app that was good for one thing, which was taking a URL and giving you a text document. And then you’d click a link and the URL would be used to fetch another text document. URL, text document, URL, text document.
These documents could include forms, and technically it wasn’t just text but also images and tables, and images in tables, and web designers were busy for at least a decade exploring the broad ramifications of being able to put images in tables.
Now, it’s hard to make an app out of screens of text and forms, but it had been done before, particularly in the mainframe era.
This is a screenshot of a terminal interface to a mainframe. The mainframe sent a description of the screen over the network to your video terminal, which knew how to display it and take keyboard input and not much else, and when you submitted the form, it would go back over the network and the mainframe would send you another screen.
I found this image on a blog called mainframes360.com, and the post that accompanies it — which is a modern post, by the way, not written in the 70s — says the following:
A CICS Map is a GUI Screen, just like an Internet Web-page. It can have a Title Header, Display-Only Constant Fields which prompt you what information to type, Input Data-Entry Fields where you can type some input with the keyboard, and Output-Fields where the result of processing may be displayed.
So basically, a mainframe screen is like a web page, or if you prefer, a web page is like a mainframe screen, from the perspective of writing an app.
But people made web apps in the 90s, even though they knew the user interface would be a regression to twenty years before that.
It was actually a revolution, because you could deliver an interactive experience over the Internet, even though it was a primitive one, without the user having to install any software. This led to a number of advantages that are still the reasons we love web sites and web apps today:
Hotmail was an example of a cutting edge web app. Launched in 1996, it was notable for letting you access your email from any computer with the power of HTML, which is highlighted in the original (terrible) logo:
The dream of “Dynamic HTML” was coming to fruition. It started as a marketing term for some new features in Internet Explorer 4 — like, for example, the DOM — but now it meant pages that were alive, that were interactive and animated.
For starters, you didn’t have to replace the entire page when someone submitted a form! You could fetch some new HTML over the network (using an XMLHttpRequest) and only replace part of the page, or you could use a bunch of jQuery to update the page in a sort of manual way instead.
People even wrote widgets — like chat boxes, stock tickers, and image galleries — that didn’t ever change to another screen, they just pulled in new data as they needed it: new chat messages, new stock quotes, and new image thumbnails.
And they worked really, really well. But they were just widgets. They generally weren’t very big or complicated; you didn’t “navigate” to different pages or views in them, or do lots of editing of kind you do in desktop apps. There were some standouts, like Gmail, which was one of the first major apps to use AJAX, around the time the term was coined in 2005. jQuery was first released in 2006. Google launched the first, crude versions of its Docs apps in 2005, 2006, and 2007. It was truly a golden age.
When it comes to user interface in a browser, you can do anything now. The limits are gone. You can show anything in any way you can imagine.
It’s a really exciting time. We can finally have the unique properties of web apps — like being able to jump right into an app without installing software — without relying on this old system where you need to go over the Internet to render the screen.
However, developers are starting to hit a different limit, which is complexity of their apps. There’s only so much you can do with jQuery and AJAX before you just get spaghetti code. Your app buckles under the complexity of all the places you need to fetch data, or check with the server, or generate a view, or update a view.
We’re now entering the era of the thick client, where apps are expected to be highly interactive and must be able to update the screen without always going to the server.
This is difficult because traditionally:
Traditional web frameworks Rails just don’t solve the problems of this new thick client era. That’s where Meteor and Blaze come in.
Meteor provides a modern architecture for rich web apps. It solves the fundamental problems you run into as you build a rich app using a set of simple principles.
Another is Data on the Wire, which means you don’t send HTML over the network, you send JSON. Not only that, we have a system for streaming live updates from your backend database down to the browser, and a client-side model cache that you can read and write to, which is synchronized with the server in a way that ensures security and correctness. It’s miles ahead of stuff like Backbone.
Meteor is database-agnostic, by the way. You bring your database, and we provide live-streaming queries. We do it for Mongo today, and SQL and Redis are next.
I don’t have time to go into all the parts of the Meteor architecture today, but it’s an advanced form of the frameworks that the big guys like Google and Facebook have built in-house. No one has built the go-to open source framework that solves the problems that real apps run into in this thick-client age.
One of the cool things we built for Meteor is a template engine where templates update automatically whenever the data model changes.
Blaze is a library for reactive templates that’s part of Meteor, but we are currently in the process of breaking it out as a separate open source project so that everyone can use it, with or without Meteor.
I’m going to explain what Blaze is, how it works, and what makes it so cool.
Templates are easy to write, because they’re just HTML with some data stuck in in certain places. Normally, though, they just run once. If a template is displaying some data that might change, it’s the app programmer’s job to figure out when that change happens and then update the DOM, usually with jQuery.
We thought, wouldn’t it be great if you just wrote your templates like your always did, but then the HTML stays up-to-date?
[Quick demo of Deps in the console, with an autorun that sets innerHTML on the body. Then perhaps we add two number Vars.]
You can see that once we have a tool like autorun, we have the power to design a system that responds to data updates in a very unobtrusive way.
This is called reactive programming, which basically means programming with values that may change. When you add two reactive numbers — numbers that might change — you get a reactive number as the sum, which might change if either of the input numbers change.
Deps implements reactive programming in a nice concrete way, through the concept of functions that get re-run when their dependencies change. You just write the code to get two numbers and add them together, and the reactivity is automatic.
The best thing about Deps is you don’t have to declare your dependencies, you just use them and they are declared for you in the context of the current “autorun.”
Blaze today is much more sophisticated than that first version that just set innerHTML. Blaze can take a template and generate fine-grained autoruns that update only the DOM nodes that need to change.
Here we’re writing a template in a reactive dialect of Handlebars called Spacebars.
[Demo of updating HTML]
[Event handlers. Multplication demo.]
What’s more impressive is when you see how these templates work.
We set out to make Meteor template-language-agnostic; whatever template language you want to use, Meteor will make it reactive — or more accurately, for each popular template language, there will be a Meteor package that implements a reactive version of it, written by a core developer or other member of the community.
We thought this would require a few hooks into existing template compilers — so that we could put autoruns in the right places, for example — but what we found was that existing template compilers are focused on generating HTML and are not up to the task of fine-grained updates. If your template engine is going to go and “redraw” parts of the DOM by removing them and regenerating them from fresh HTML, it had better not remove a text field the user is typing in! Also, many users combine Meteor’s template updating with third-party jQuery plugins, and they expect that DOM elements will generally be stable unless there’s a reason to believe otherwise.
Blaze is the solution to the two problems of 1) supporting pluggable template syntax and 2) performing fine-grained updates.
Blaze doesn’t compile templates, it runs them! It’s a compilation target, a reactive DOM API that you can use directly or via a template compiler. Spacebars is one such compiler, and a member of the community has written a compiler for Jade-like syntax.
I have an app here that gives you a glimpse of what a compiled template looks like. I type the Spacebars template up here, and the compiled code appears down here.
[This page uses Blaze itself, and you can see the code is very short.]
[Leaderboard? Demonstrates #each. Like an actual control structure.]
Features, in summary:
This was always the plan, by the way. Meteor is designed in modular pieces, many of which are unique and useful in their own right. There are obvious benefits to structuring some of them as independent open-source projects, but it just takes dedicated engineering effort to do so. Blaze is our first, biggest push in this direction.
The great thing is not only can you use Blaze without Meteor, but you can start using Meteor and not worry that your user interface code will have to be rewritten if the rest of the Meteor stack doesn’t meet your needs for some reason. Some people will be in the opposite situation; they will want to use Meteor’s backend but have something specific in mind for the front end, like a native mobile app. For many apps, however, the reactive user interfaces you can write with Blaze are a huge benefit, and Meteor is a great way to get started with Blaze.
Blaze.js is a small download, about the size of jQuery. It currently requires jQuery as well, but mainly to support browsers like IE 8. A version of Blaze could easily be built for modern browsers requiring only a small shim instead of jQuery.
If you’re interested in learning more about Blaze, sign up for our new mailing list:
You can also find Blaze on the web at: