
Meteor 0.8.0: Introducing the Blaze templating engine - avital
https://www.meteor.com/blog/2014/03/27/meteor-080-introducing-blaze
======
sanityinc
Slightly unfortunate name clash here, since there's also a Haskell HTML
templating system called Blaze: [http://hackage.haskell.org/package/blaze-
html](http://hackage.haskell.org/package/blaze-html)

------
RaphiePS
Can anyone speak to the difference in approach between Blaze and React? Or are
they doing essentially the same thing?

At first glance, this seems much better in terms of programmer productivity,
given that it uses logicless templates rather than embedding HTML inside JS
code. But I'd be curious if it's less performant.

~~~
avital
Hi, I work on Blaze.

React and Blaze both compile templates or components into an intermediate
representation for their HTML structure (React's JSDOM; Blaze's HTMLJS). A lot
of the difference in how they decide what DOM changes are necessary.

React re-renders components when data changes and diffs the resulting JSDOM.
The diff algorithm is fast and has simple hooks to make it faster by letting
you compare state and component properties.

Blaze doesn't diff the resulting DOM structure. Instead, Blaze diffs the data
the components depend on. That data comes from reactive functions built on top
of Deps, our dependency tracking system. When the component first renders,
dependencies are tracked between data sources and rendered DOM elements
(dependencies are automatically cleaned up when the component is taken off the
page). Therefore when data changes, Blaze can directly update the relevant
elements.

There is some overhead in Deps, our dependency tracking system, but Deps has
been intentionally designed for supporting this efficiently (eg batching
updates in a "flush" stage).

As for performance, our benchmarks have generally found that React outperforms
Blaze when many elements change and Blaze outperforms React when few elements
change (which is more common for typical operations on many web apps). We also
have plans to improve performance on initial rendering.

There are some other difference worth noting: While a later version of Blaze
will support easy APIs for re-useable components, React already has one. And
the React component model is well-thought out, complete and in production use
whereas the Blaze component model at the moment is only the implementation
behind templates.

Happy to hear any other perspectives.

~~~
rtfeldman
Not to detract from the positivity of sweet new tech, but it's worth noting
that "React outperforms Blaze when many elements change and Blaze outperforms
React when few elements change" is the same as "React outperforms Blaze in
cases where the user is capable of noticing a performance difference", which
reduces to "React outperforms Blaze."

Nevertheless, seriously appreciate the detailed and informative response. :)

~~~
myhf
I'll have to see how each one handles a big grid of rotating colored circles
with numbers on them in order to make an informed decision.

------
cookrn
I took some time to read through the architecture document[0] on HTMLbars
yesterday and parts of the Blaze description sound very familiar. As a general
observation, both libraries are focused on outputting DOM rather than HTML
strings, which is interesting for various reasons. Maybe I'm missing some of
the history here re: interaction between Meteor & Tilde, but I wonder if
HTMLbars could have been useful in building out Blaze had it been in the works
sooner?

[0]
[https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...](https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE.md)

~~~
avital
Hi, I work on Blaze.

HTMLBars is an excellent project and indeed does share many design principles
with Blaze. They also differ in a few ways. For example, HTMLBars plans to
never support full inline expressions in templates, whereas that is an
explicit future goal for Blaze. So even though parts of HTMLBars could have
been used in Blaze, it wouldn't give us the flexibility needed to take Blaze
in the direction we think is best for our users.

[edit: Also, Blaze is shipped. :)]

------
pornel
They seem to be parsing the structure rather than just gluing strings, kudos
for that!

However, the tricky case they've run into:

    
    
         <template name="hello">
           {{#if bold}}
             <b>Hello {{name}}!</b>
           {{else}}
             Hello {{name}}!
           {{/if}}
         </template>     
    

has been solved in TAL:

    
    
        <template name="hello">  
           <b tal:omit-tag="not:bold">Hello {{name}}!</b>   
        </template>

------
cslarson
I've been working on a project that uses React with Meteor. One advantage that
React has is that it's very easy to render the html on the server side. Once
on the client React only updates this html if and when it needs to. Can Blaze
do this? If not, are there plans to support it in the future?

~~~
swah
But for now you have to adopt a NodeJS to get this benefit, right?

~~~
TylerE
You understand the Meteor execution model, yes? (Hint: You're already running
on NodeJS)

~~~
swah
I was thinking about React. Pardon me for not knowing that Meteor had a single
implementation.

------
malokai
I've been using Meteor since this past September. Great to see there's only 1
more update prior to 1.0.

~~~
xiaoma
What happens in 1.0? Is it primarily the marketing buzz you're looking forward
to, or is there a specific feature?

~~~
TylerE
More the just marketing buzz, imo. I know the IntelliJ guys have said they
will build in first-class Meteor support once it hits 1.0.

------
chm
I want to write a web app, an SPA. After many years of not caring about web
design [1], getting back into the game is very difficult, even if my
programming skills are more than 10x what they were back then.

I'm sold on JS, as to me PHP is very ugly and incomprehensible. My stack
currently looks like this:

Node -> Express+Passport+Mongoose -> Bootstrap + Angular/Polymer + D3

I've only begun my project three weeks ago, but I would have hoped to have a
prototype by now. Admittedly, I'm not working on this 40hrs a week, but still.
I find it very hard to understand how everything fits together.

And then news like this appear, once or twice a week, which make me spend some
hours reading on this or that new framework and how better it performs.

</rant>

[1] I did some flash, html and js about 6-7 years ago. Also learned enough php
to be disgusted by it.

~~~
kawera
Have you looked at Twitter Flight?[1][2]. Quite easy to grasp.

[1] [http://flightjs.github.io](http://flightjs.github.io)

[2]
[https://speakerdeck.com/anguscroll/cal](https://speakerdeck.com/anguscroll/cal)

~~~
chm
Thanks, I had never heard of it!

------
grigio
This is a killer feature! If you are a Meteor developer / user / enthusiast
register on the map

[http://weuse.meteor.com](http://weuse.meteor.com)

------
elsherbini
jquery compatibility is huge, awesome!

I am a new developer. I've used meteor for a couple toy projects, and found it
really easy to get started. past the basics however, I found it really hard to
get answers. I'm currently trying to write a simple backbone + node app to get
my head around all the things meteor does automagically.

Are there any plans for learning resources coming from the meteor team?

~~~
gales
A great learning resource is Discover Meteor -
[http://www.discovermeteor.com](http://www.discovermeteor.com) (purchase
required, but great value for money, as it's been regularly updated since its
release).

The videos on Evented Mind are fantastic to learn from as well -
[https://www.eventedmind.com](https://www.eventedmind.com) (recently
introduced a subscription model, though, some of the videos are still free to
play).

~~~
grinich
Meteor should just use some of that $12MM to give this book away.

