I've been using Meteor since this past September. Great to see there's only 1 more update prior to 1.0.
What happens in 1.0? Is it primarily the marketing buzz you're looking forward to, or is there a specific feature?
Meteor 0.8.0: Introducing the Blaze templating engine
11–20 of 50 posts
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#12I've been using Meteor since this past September. Great to see there's only 1 more update prior to 1.0.
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.
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#13Re: Meteor 0.8.0: Introducing the Blaze templating engine
#14I've been using Meteor since this past September. Great to see there's only 1 more update prior to 1.0.
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.
Last line of the blog entry announcing Blaze as the new feature in the 0.8.0 release: "Just one more big item to go before 1.0 now!"
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#15Earlier quoted context omitted.
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.
Last line of the blog entry announcing Blaze as the new feature in the 0.8.0 release: "Just one more big item to go before 1.0 now!"
Ah, OK. I stand corrected. Although I guess my comment isn't exactly incorrect.
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#16Can 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.
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...
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#17I've been using Meteor since this past September. Great to see there's only 1 more update prior to 1.0.
What happens in 1.0? Is it primarily the marketing buzz you're looking forward to, or is there a specific feature?
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.
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#18I 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...
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#19Can 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.
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".
Re: Meteor 0.8.0: Introducing the Blaze templating engine
#20Can 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.
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.