Meteor 0.8.0: Introducing the Blaze templating engine(meteor.com)
meteor.com
Meteor 0.8.0: Introducing the Blaze templating engine
https://www.meteor.com/blog/2014/03/27/meteor-080-introducing-blaze
49 comments
Slightly unfortunate name clash here, since there's also a Haskell HTML templating system called Blaze: http://hackage.haskell.org/package/blaze-html
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.
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.
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.
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.
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. :)
Nevertheless, seriously appreciate the detailed and informative response. :)
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.
Does it mean that, theoretically, Blaze will still outperform React on a long series of small quick updates conducted by a lot of disconnected events?
That might be true, but it doesn't automatically follow. Java often gets dinged for startup time that it might make up for on longer runs and browser vendors seem to be sniping that their rivals are focussing on long term benchmarks at the expense of realistic workloads.
If you use `shouldComponentUpdate`, then React outperforms Blaze on the circle benchmark for both single and large number of updates. See Andrey Popp JSFiddles: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj...
React by default is fairly fast but what makes it stand out is that it gives the tools to make the bottlenecks faster without having to drop the nice abstraction.
React by default is fairly fast but what makes it stand out is that it gives the tools to make the bottlenecks faster without having to drop the nice abstraction.
Popp's fiddles don't use shouldComponentUpdate, as far as I can tell. They replace using props (application state) by components-local state and an animation prop. I'm not entirely certain that his semantics map to the original ones (in terms of expectations).
My bad :x JSFiddle is unusable on mobile and I assumed it was using shouldComponentUpdate. Anyway, the conclusion still holds, you can refactor your code to be performant while keeping in the React paradigm.
You have a lot less control over the performance of your app with data binding.
You have a lot less control over the performance of your app with data binding.
> Blaze doesn't diff the resulting DOM structure. Instead, Blaze diffs the data the components depend on. […] Therefore when data changes, Blaze can directly update the relevant elements.
FWIW this is available to React as an optimisation if desired/necessary: by default React just renders the whole component tree on data changes[0] and diffs the result tree before updating the DOM — which is simple and usually performs well — but components can implement shouldComponentUpdate[1] to skip re-rendering if unnecessary[2].
[0] a React component could depend on non-react data, React is conservative and does not assume components depend only on data it can track
[1] http://facebook.github.io/react/docs/component-specs.html#up...
[2] and React provides ReactComponentWithPureRenderMixin[3] which can be mixed into any "pure" component whose output depends solely on application and component state, to get a free shouldComponentUpdate
[3] well "provides" may be excessive, it's in the repository but seems to be neither in the react distribution nor in the react-with-addons distribution. YMMV.
FWIW this is available to React as an optimisation if desired/necessary: by default React just renders the whole component tree on data changes[0] and diffs the result tree before updating the DOM — which is simple and usually performs well — but components can implement shouldComponentUpdate[1] to skip re-rendering if unnecessary[2].
[0] a React component could depend on non-react data, React is conservative and does not assume components depend only on data it can track
[1] http://facebook.github.io/react/docs/component-specs.html#up...
[2] and React provides ReactComponentWithPureRenderMixin[3] which can be mixed into any "pure" component whose output depends solely on application and component state, to get a free shouldComponentUpdate
[3] well "provides" may be excessive, it's in the repository but seems to be neither in the react distribution nor in the react-with-addons distribution. YMMV.
I have to say I'm pretty excited, since it now looks like there is a non-hacky way to use jade templates, which as far as I'm concerned are a big win. Any more details to shed on that aspect?
They are trying to solve the same problem: gatekeepers to any mutable data that affects your DOM -- but they do it in pretty different ways: (1) under the hood, Blaze tracks the DOM changes and applies them directly whereas React diffs the resultant HTML and applies the difference. (2) Blaze uses declarative templates for injecting HTML; React requires HTML to be built using virtual DOM elements in javascript.
Here is one of the React core developers (Pete Hunt) on React integration with Meteor: http://www.youtube.com/watch?v=qqVbr_LaCIo (note this is before Blaze)
Regarding performance: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj...
Here is one of the React core developers (Pete Hunt) on React integration with Meteor: http://www.youtube.com/watch?v=qqVbr_LaCIo (note this is before Blaze)
Regarding performance: https://groups.google.com/forum/#!topic/meteor-core/-px_AGhj...
Looking through the Blaze wiki I'd say that Blaze is more concerned with calculating updates based on changes in data (either by user action or networked bindings) and React is more concerned with managing the entire lifecycle of an element.
React will probably be easier to reason about down the line (despite the initial learning curve), while Blaze will "just work".
React will probably be easier to reason about down the line (despite the initial learning curve), while Blaze will "just work".
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...
[0] https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...
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. :)]
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. :)]
They seem to be parsing the structure rather than just gluing strings, kudos for that!
However, the tricky case they've run into:
However, the tricky case they've run into:
<template name="hello">
{{#if bold}}
<b>Hello {{name}}!</b>
{{else}}
Hello {{name}}!
{{/if}}
</template>
<template name="hello">
<b tal:omit-tag="not:bold">Hello {{name}}!</b>
</template>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?
Blaze will support server-side rendering.
I've been using Meteor since this past September. Great to see there's only 1 more update prior to 1.0.
Now that I've had time to check out the update in depth, I can say that this update actually affects my project in a huge way. It'll require refactoring probably around 500 of lines of code because of the elimination of {{#isolate}, {{#constant}} and preserve-inputs, and the new template.rendered functionality.
What happens in 1.0? Is it primarily the marketing buzz you're looking forward to, or is there a specific feature?
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.
I'm looking forward to a more stable API. I think a lot of things are solidified by this 0.8.0 release, but working up to it I've had to deal with a lot of upstream changes that forced me to refactor a lot of code. Of course, its all in the name of progress and the Meteor community is super helpful and friendly, so no big whoop.
The last major hurdle for 1.0 (as I understand it) is final integration work with Atmosphere and updates to the package management system. While this is no small feat, it is far less of an engineering hurdle than either Blaze or the opLog tailing which was implemented in 0.7.0.
I'm looking forward to each template having its own local reactive state so that I can get away from storing everything in session variables, which are global.
Without this feature, it's hard (or harder than it should be) to create reusable user interface code.
Without this feature, it's hard (or harder than it should be) to create reusable user interface code.
[deleted]
Maybe you're kidding but I'm not sure that's really how it works. I'm sure they will do as many updates as necessary prior to a 1.0 regardless of current numbering.
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.
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.
Have you looked at Twitter Flight?[1][2]. Quite easy to grasp.
[1] http://flightjs.github.io
[2] https://speakerdeck.com/anguscroll/cal
[1] http://flightjs.github.io
[2] https://speakerdeck.com/anguscroll/cal
Thanks, I had never heard of it!
Well maybe it would be worth trying Meteor for you.
I've tried something similar, that is Rails + Ember.js, and I find using Meteor.js easier.
I've tried something similar, that is Rails + Ember.js, and I find using Meteor.js easier.
The app I want to build would be data driven. I want it to be as fast as possible (it will have to plot graphs) and I thought I made a good choice with my current stack. The big difficulty is understanding where each library/framework shines, how to couple it with the others and when two frameworks have some overlapping functionality, which one to keep.
The reason I didn't go with Meteor at first was that I didn't really understand how everything fits together. I needed to build a stack block by block. But that was three weeks ago, I will definitely read more about Meteor and maybe give it a try.
One thing's sure, I have to make up my mind sometime soon or else I'll never have a prototype!
The reason I didn't go with Meteor at first was that I didn't really understand how everything fits together. I needed to build a stack block by block. But that was three weeks ago, I will definitely read more about Meteor and maybe give it a try.
One thing's sure, I have to make up my mind sometime soon or else I'll never have a prototype!
Unless you're going to be wildly successful the moment you launch, you're better off picking one stack that you understand, creating a working version, then iterating to improve on it. If you try to do it perfectly or make it as fast as possible from the start you may never finish - and you'll never be able to test your idea.
but on other side, Meteor itself just for quick prototyping, it's quite easy to learn
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
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?
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?
Discover Meteor is great - another recommendation.
Recently rebuilt a client app in Meteor, ran into a few hurdles that I think are just part of the learning curve.
A few times I have come to the github wiki page & found some helpful tips: https://github.com/meteor/meteor/wiki
http://www.meteorpedia.com/ is in pretty active development, lots of links and the guys who run it are active on the Google Group also.
Recently rebuilt a client app in Meteor, ran into a few hurdles that I think are just part of the learning curve.
A few times I have come to the github wiki page & found some helpful tips: https://github.com/meteor/meteor/wiki
http://www.meteorpedia.com/ is in pretty active development, lots of links and the guys who run it are active on the Google Group also.
A great learning resource is Discover Meteor - 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 (recently introduced a subscription model, though, some of the videos are still free to play).
The videos on Evented Mind are fantastic to learn from as well - https://www.eventedmind.com (recently introduced a subscription model, though, some of the videos are still free to play).
Meteor should just use some of that $12MM to give this book away.
Also a Pluralsight course.
http://pluralsight.com/courses/meteorjs-fundamentals-single-...
I will try it out this weekend.
http://pluralsight.com/courses/meteorjs-fundamentals-single-...
I will try it out this weekend.
EventedMind is an excellent resource when you're ready to master Meteor. Chris goes into a lot of depth on each topic.
Another hearty recommendation for Discover Meteor.