Introducing Blaze Plus: Some New Features to Blaze

announce
1

Hi,

Today, we are releasing Blaze Plus. It’s a attempt to add props and state management functionality. It reduce re-renders in your Blaze templates.

Watch This Video: https://www.youtube.com/watch?v=Gaz6S75Qo6c for a quick introduction.

Give it a try for with your Blaze Templates (Specially, replacing Dynamic Templates)

15 Likes
2

So awesome :smiley: Gonna try this out this right away!

1 Like
3

How well does this work with something like Viewmodel?

2 Likes
4

Not sure. I haven’t use ViewModel.

This is pure Blaze with some minor changes to the Blaze’s lookup function.
We add some additional functionalities to the template instance.

5

Looking forward to read about various flux/redux integrations and possibly immutable.

1 Like
6

Just wondering.

@arunoda, you write:

So, whenever any data changes, the whole dataset will be passed to
the bottom and the children will update themselves accordingly.
This is efficient in React because of its virtual DOM. But in Blaze,
this is inefficient. That’s because, whenever any data changes, the
whole template will be re-rendered. Which leads to cascade re-renders.

@sashko, you write (here):

(…) in Blaze there is actually no performance benefit at all to splitting
things into multiple templates - it does a pretty good job of
rerendering only the smallest part of the page necessary. So often the
result is similar to what React gets via virtual DOM, but with
fine-grained data tracking instead.

If a change in data context doesn’t rerender the whole template, where exactly lies the difference?

7

I think this sentence from @arunoda:

whenever any data changes, the whole template will be re-rendered

can be considered right or wrong depending on the meaning of template re-rendering.

If template re-rendering only means the Blaze sub-task consisting of updating the DOM, then I agree with @sashko: Blaze does a terrific job at updating only the smallest part of the DOM (this is the main reason why I love Blaze). In that sense, I think @arunoda’s sentence is wrong.

If template re-rendering means the full Blaze activity consisting of:

  1. parsing the whole template to determine which DOM elements to update,
  2. calling all template helpers,
  3. updating the DOM.

then @arunoda’s sentence is right. However, in that case the inefficiency is not in Blaze, but in people relying too much on heavy template helpers that will be called again and again whenever data context changes.

1 Like
8

Sashko is correct and so do I.

I mean when passing data context to the template. Either with a dynamic template or using with.
I that case, it anything changes whole templates will be changed.

Since we use dynamic templates on the root of the template TREE, this is a huge issue.

@Steve

I agree. Here issue is not just with Blaze and how we write it.

1 Like
9

I feel the knowledge flowing in me now. Thanks for clarifying guys!

10

I believe that was with Meteor before 0.8… kind of pita at that time with spark.