• 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

    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:

    • Cloud deployment
      • Horizontal scaling
      • Operations

    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 and Authentication

    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.

    • “Thick Client”
      • View logic in the browser
      • Business logic in the browser!
      • Streaming data endpoints

    Then there’s the whole “Thick Client” problem. As web apps become more interactive, they increasingly update the screen directly in JavaScript, which means view logic in the browser, and even business logic in the browser — which is a bold new world. We also need server endpoints designed for apps that stay open and don’t just fetch data once or once in a while, apps like today’s Facebook, which has live updates and chat, and pulls in some data immediately and then strategically streams in more as you navigate the app.

  • (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:

    • Cross-platform
    • Usable immediately upon discovery
    • Sharable via link
    • Nothing to maintain or upgrade
    • Naturally collaborative (one installation for the world)

    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:

  • JavaScript was around in the 90s, by the way, but as far as I know, it was used for exactly one thing for most of its early life: those navigation menus that drop down on hover. You know the ones. You still see them sometimes, but they were everywhere.

    JavaScript = hover menus

    The problem was that JavaScript was dog-slow, and modifying the DOM was very slow as well. Internet connections were slow too, so even 20K of JavaScript, say, would take a few seconds to load at least. Browsers didn’t support gzip encoding, by the way, so that’s 20K uncompressed. Cross-browser compatibility between Internet Explorer and Netscape was poor. Many people had JavaScript turned off, and websites were expected to work with or without JavaScript.

  • Then, in the mid 2000s, a new era dawned for web apps, the era of AJAX and jQuery, of Internet Explorer 6 and innerHTML, of iframes and cross-browser JavaScript. JavaScript and the DOM were getting decent, and you could do a lot of stuff. Rounded corners were still a bitch, but you could hide and show things and do little animations.

    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.

  • Now, in the last eight years, browsers have only gotten more awesome. JavaScript is everywhere and it’s blazing fast; it’s compiled to assembly code and in some cases rivals native speeds, or at least it’s within a small multiple. The DOM is fast, and graphics are fast — they’re hardware accelerated! And all of this is true on mobile as well.

    JSON is in, XML is out, and we have WebSockets. We’re writing cleaner and cleaner JavaScript, the language is growing up, and pretty soon we’ll be able to ditch IE 6-8 and embrace ECMAScript 5, and even the upcoming ECMAScript 6. Every week or so I find out that yet another magic incantation that I learned five years ago — when it was absolutely necessarily for cross-browser compatibility — has just become, or will soon be, obsolete.

    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:

    • The server has the data
    • The server has the application logic (business logic)
    • The server knows how to generate the HTML
    • The client-side and server-side code are separate codebases in separate languages

    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.

    For example, one of the principles is JavaScript Everywhere — you run JavaScript on the client and the server. Your application logic runs both in the web browser and in a trusted JavaScript environment on the server.

    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.

  • Blaze

    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?

  • We have a very small library JavaScript library called “Deps” that automatically tracks dependencies between functions and data, so we can do some work like rendering a template, and the data sources that the template used are automatically tied to that template. So our first prototype, two years ago, would automatically determine which templates needed to be re-rendered and update them in place, basically by setting innerHTML.

    [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.

    Blaze doesn’t just generate DOM, either. It can be used on the server, in pure JavaScript with no DOM, to generate HTML strings. This is another unique aspect of the design.

    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.

    You can see that the compiled Blaze code uses a little notation for representing HTML, which is a very small JavaScript library called HTMLjs. This data structure instructs Blaze as to what DOM or HTML to generate and how to manage it.

    [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:

    • Reactive templates
    • Automatic dependency tracking
    • Fine-grained updates
    • Pluggable template syntax
    • Integrates with jQuery
    • Renders to HTML or DOM
    • Self-contained (requires jQuery for now)
  • Stand-alone Blaze

    Blaze is currently being used as part of Meteor, but we’re now working to package it as its own JavaScript library that you can use with or without Meteor.

    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:

    blazejs@googlegroups.com

    You can also find Blaze on the web at:

    http://meteor.github.io/blaze/

{"cards":[{"_id":"42dcda4daf91fdb9c200001f","treeId":"42da2697af91fdb9c2000005","seq":10322,"position":0.25,"parentId":null,"content":"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.\n\nI'm going to start with an overview of the Meteor framework, and then I'm going to talk about the design of Blaze."},{"_id":"42dc608daf91fdb9c2000019","treeId":"42da2697af91fdb9c2000005","seq":12387,"position":0.5,"parentId":null,"content":"# Meteor\n\nMeteor is an open-source web framework for making great apps in a fraction of the time.\n\nThe bar for apps these days is set really high. You want to deliver an app that is fast, richly interactive, and collaborative.\n\nMeteor 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.\n\nIn particular, Meteor solves the technical problems that are increasingly faced by new apps and not addressed well by existing frameworks:\n\n* Cloud deployment\n - Horizontal scaling\n - Operations\n\nOnce 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.\n\n* Security and Authentication\n\nSecurity 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.\n\n* \"Thick Client\"\n - View logic in the browser\n - Business logic in the browser!\n - Streaming data endpoints\n\nThen there's the whole \"Thick Client\" problem. As web apps become more interactive, they increasingly update the screen directly in JavaScript, which means view logic in the browser, and even business logic in the browser -- which is a bold new world. We also need server endpoints designed for apps that stay open and don't just fetch data once or once in a while, apps like today's Facebook, which has live updates and chat, and pulls in some data immediately and then strategically streams in more as you navigate the app."},{"_id":"42dcdffaaf91fdb9c2000021","treeId":"42da2697af91fdb9c2000005","seq":10401,"position":0.75,"parentId":null,"content":"(Show examples of apps, like Pintask.)\n\nPintask 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."},{"_id":"42dcea90af91fdb9c2000022","treeId":"42da2697af91fdb9c2000005","seq":10398,"position":0.875,"parentId":null,"content":"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."},{"_id":"42da26adaf91fdb9c2000007","treeId":"42da2697af91fdb9c2000005","seq":8966,"position":1,"parentId":null,"content":"**Web apps started from humble beginnings.**\n\nIf we go back in time twenty years, to the 90s, there were apps, and there was the web.\n\nPhotoshop 3 and Netscape 1.0 in 1995:\n\n![](http://www.guidebookgallery.org/pics/apps/photoshop/workspace/full/304-1-1.png)\n\n![](http://www.informatica.co.cr/internet/research/1994/images/netscape-1.0/main.jpg)\n\nThe 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.\n\nThese 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."},{"_id":"42da5719af91fdb9c2000008","treeId":"42da2697af91fdb9c2000005","seq":12404,"position":2,"parentId":null,"content":"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.\n\n![](http://lh3.ggpht.com/_sQvdFWqMlMg/TLG5ozIaN3I/AAAAAAAADRI/nI-rP2XPiSE/Image307_thumb2.png?imgmax=800)\n\nThis 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.\n\nI 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:\n\n>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.\n\nSo 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."},{"_id":"42da8bffaf91fdb9c200000a","treeId":"42da2697af91fdb9c2000005","seq":12406,"position":3,"parentId":null,"content":"But people made web apps in the 90s, even though they knew the user interface would be a regression to twenty years before *that*.\n\nIt 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:\n\n* Cross-platform\n* Usable immediately upon discovery\n* Sharable via link\n* Nothing to maintain or upgrade\n* Naturally collaborative (one installation for the world)\n\nHotmail 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:\n\n![](https://gallery.mailchimp.com/ea93776b8dbe788ad077049ba/images/HOTMAIL_zpsce0971c4.gif)"},{"_id":"42dab659af91fdb9c200000e","treeId":"42da2697af91fdb9c2000005","seq":12409,"position":3.5,"parentId":null,"content":"JavaScript was around in the 90s, by the way, but as far as I know, it was used for exactly one thing for most of its early life: those navigation menus that drop down on hover. You know the ones. You still see them sometimes, but they were *everywhere*.\n\n**JavaScript = hover menus**\n\nThe problem was that JavaScript was dog-slow, and modifying the DOM was very slow as well. Internet connections were slow too, so even 20K of JavaScript, say, would take a few seconds to load at least. Browsers didn't support gzip encoding, by the way, so that's 20K uncompressed. Cross-browser compatibility between Internet Explorer and Netscape was poor. Many people had JavaScript turned off, and websites were expected to work with or without JavaScript."},{"_id":"42dad29baf91fdb9c200000f","treeId":"42da2697af91fdb9c2000005","seq":9612,"position":3.75,"parentId":null,"content":"Then, in the mid 2000s, a new era dawned for web apps, the era of AJAX and jQuery, of Internet Explorer 6 and innerHTML, of iframes and cross-browser JavaScript. JavaScript and the DOM were getting decent, and you could do a lot of stuff. Rounded corners were still a bitch, but you could hide and show things and do little animations.\n\nThe 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.\n\nFor 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.\n\nPeople 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.\n\nAnd 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.\n"},{"_id":"42db4466af91fdb9c2000012","treeId":"42da2697af91fdb9c2000005","seq":10035,"position":4.375,"parentId":null,"content":"Now, in the last eight years, browsers have only gotten more awesome. JavaScript is everywhere and it's blazing fast; it's compiled to assembly code and in some cases rivals native speeds, or at least it's within a small multiple. The DOM is fast, and graphics are fast -- they're hardware accelerated! And all of this is true on mobile as well.\n\nJSON is in, XML is out, and we have WebSockets. We're writing cleaner and cleaner JavaScript, the language is growing up, and pretty soon we'll be able to ditch IE 6-8 and embrace ECMAScript 5, and even the upcoming ECMAScript 6. Every week or so I find out that yet another magic incantation that I learned five years ago -- when it was absolutely necessarily for cross-browser compatibility -- has just become, or will soon be, obsolete.\n\nWhen 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.\n\nIt'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."},{"_id":"42db4376af91fdb9c2000011","treeId":"42da2697af91fdb9c2000005","seq":10164,"position":5,"parentId":null,"content":"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.\n\nWe'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.\n\nThis is difficult because traditionally:\n\n* The server has the data\n* The server has the application logic (business logic)\n* The server knows how to generate the HTML\n* The client-side and server-side code are separate codebases in separate languages\n\nTraditional web frameworks Rails just don't solve the problems of this new thick client era. That's where Meteor and Blaze come in."},{"_id":"42dc30d2af91fdb9c2000017","treeId":"42da2697af91fdb9c2000005","seq":10469,"position":5.5,"parentId":null,"content":"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.\n\nFor example, one of the principles is JavaScript Everywhere -- you run JavaScript on the client and the server. Your application logic runs both in the web browser and in a trusted JavaScript environment on the server.\n\nAnother 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.\n\nMeteor 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.\n\nI 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."},{"_id":"42dc5793af91fdb9c2000018","treeId":"42da2697af91fdb9c2000005","seq":10556,"position":5.75,"parentId":null,"content":"# Blaze\n\nOne of the cool things we built for Meteor is a template engine where templates update automatically whenever the data model changes.\n\nBlaze 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.\n\nI'm going to explain what Blaze is, how it works, and what makes it so cool.\n\nTemplates 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.\n\nWe thought, wouldn't it be great if you just wrote your templates like your always did, but then the HTML stays up-to-date?"},{"_id":"42dcaa2baf91fdb9c200001a","treeId":"42da2697af91fdb9c2000005","seq":10411,"position":5.875,"parentId":null,"content":"We have a very small library JavaScript library called \"Deps\" that automatically tracks dependencies between functions and data, so we can do some work like rendering a template, and the data sources that the template used are automatically tied to that template. So our first prototype, two years ago, would automatically determine which templates needed to be re-rendered and update them in place, basically by setting innerHTML.\n\n[Quick demo of Deps in the console, with an autorun that sets innerHTML on the body. Then perhaps we add two number Vars.]"},{"_id":"42dcaa80af91fdb9c200001b","treeId":"42da2697af91fdb9c2000005","seq":10424,"position":5.9375,"parentId":null,"content":"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.\n\nThis 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.\n\nDeps 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.\n\nThe 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.\""},{"_id":"42dcd39eaf91fdb9c200001e","treeId":"42da2697af91fdb9c2000005","seq":10462,"position":5.953125,"parentId":null,"content":"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.\n\nHere we're writing a template in a reactive dialect of Handlebars called Spacebars.\n\n[Demo of updating HTML]"},{"_id":"42dd3b20af91fdb9c2000025","treeId":"42da2697af91fdb9c2000005","seq":10450,"position":5.95703125,"parentId":null,"content":"[Event handlers. Multplication demo.]"},{"_id":"42dd4419af91fdb9c2000026","treeId":"42da2697af91fdb9c2000005","seq":10833,"position":5.958984375,"parentId":null,"content":"What's more impressive is when you see how these templates work.\n\nWe 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.\n\nWe 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.\n\nBlaze is the solution to the two problems of 1) supporting pluggable template syntax and 2) performing fine-grained updates.\n\nBlaze 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.\n\nBlaze doesn't just generate DOM, either. It can be used on the server, in pure JavaScript with no DOM, to generate HTML strings. This is another unique aspect of the design.\n\nI 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.\n\nYou can see that the compiled Blaze code uses a little notation for representing HTML, which is a very small JavaScript library called HTMLjs. This data structure instructs Blaze as to what DOM or HTML to generate and how to manage it.\n\n[This page uses Blaze itself, and you can see the code is very short.]"},{"_id":"42ddf20baf91fdb9c2000028","treeId":"42da2697af91fdb9c2000005","seq":10837,"position":5.95947265625,"parentId":null,"content":"[Leaderboard? Demonstrates #each. Like an actual control structure.]"},{"_id":"42ddf294af91fdb9c2000029","treeId":"42da2697af91fdb9c2000005","seq":10853,"position":5.959716796875,"parentId":null,"content":"Features, in summary:\n\n* Reactive templates\n* Automatic dependency tracking\n* Fine-grained updates\n* Pluggable template syntax\n* Integrates with jQuery\n* Renders to HTML or DOM\n* Self-contained (requires jQuery for now)"},{"_id":"42ddeb74af91fdb9c2000027","treeId":"42da2697af91fdb9c2000005","seq":11864,"position":5.9599609375,"parentId":null,"content":"## Stand-alone Blaze\n\nBlaze is currently being used as part of Meteor, but we're now working to package it as its own JavaScript library that you can use with or without Meteor.\n\nThis 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.\n\nThe 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."},{"_id":"42e2aeb1b92f75dc7100001f","treeId":"42da2697af91fdb9c2000005","seq":12371,"position":5.9600830078125,"parentId":null,"content":"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."},{"_id":"42e17d67b92f75dc7100001d","treeId":"42da2697af91fdb9c2000005","seq":11874,"position":5.96044921875,"parentId":null,"content":"If you're interested in learning more about Blaze, sign up for our new mailing list:\n\nblazejs@googlegroups.com\n\nYou can also find Blaze on the web at:\n\nhttp://meteor.github.io/blaze/"}],"tree":{"_id":"42da2697af91fdb9c2000005","name":"Blaze Talk","publicUrl":"blaze-talk"}}