Making Blaze Faster


When I was debugging with Kadira Debug, I saw a similar pattern in Meteor apps.
It takes time to render and destroy templates

In most of the time we utilize a similar set of templates and we are going here and there. One good example is telescope or this forum app.

So, what if we cache tempates just like we are doing with SubsManager. Hmm…

I tried it and it was a successful experiment.


Planning to do a release in couple of weeks.

Blaze virtual DOM?

Looks like a magic! I feel like first time I saw Meteor! Great!


DOM caching is definitely needed in a lot of situations when the template rendering process is heavy (I suggested adding this kind of caching in iron-router a while back). Thank you very much for solving this with a clean API, and by the way SubsManager is awesome I encourage everyone to use it!


Great. Thanks.

I suggested adding this kind of caching3 in iron-router a while back

I didn’t see it earlliar. Nice to hear that.


Very cool, @arunoda :slight_smile:

For famous-views, I had to make sure that template materialization / destruction wouldn’t block animation frames, i.e. couldn’t run continuously for more than a few ms per frame. So I’ve been experimenting with a virtual DOM for Blaze - that simply queues DOM updates and dequeues with a timer (with room for further optimizations in the future).

I haven’t mentioned it before because I haven’t decided yet how far to take, i.e. it supports evertyhing Blaze does but, how would we want to handle the regular dev workflow for events, lifecycle callbacks, etc (which DOM should they have access to and what should be supported). What’s more exciting though is that it opens the way to run a lot of things inside a web worker.

Also, from what I understood from your video, it looks it would work with the template caching with no changes. As you know I’m a big fan of Blaze and squeezing out the best possible performance from it is awesome :> Looking forward to more updates on this.


@gadicc, I like your idea of asynchronous Blaze rendering. Maybe this could be part of a future solution for the problem of Blaze freezing because of too many reactive updates (as commented by dgreensp here).


I’ll never understand how you do so many cool things with meteor, arunoda


Wow async dom updates is really great. That’s the way we can improve Blaze. That’s why Telescope (specially is pretty slow on mobile.


You know my only real question at this point is when is MDG going to hire Arunoda?!


They have only $20M )))


I use this one , is this the same concept?


This is awesome. I think caching for templates and subscriptions should be included in meteor core already! Anyone else agree with this? Both features are must-have functionality when dealing with large data.


Well, now with template level subscriptions you can have caching of data as needed.
It should not be in router.
But some object as single point of truth for current subscription can be put together and described as best practice. With server/client side to support fastrender would be very helpfull.


I was wondering the same for long time :+1:


A virtual DOM for Blaze would be amazing. I definitely like React’s model and it really does seem like the way forward.


Are there memory concerns? How will this work on low memory devices?


I am also curious about memory concerns. I have noticed that my meteor app often becomes sluggish as I refactor and I am constantly having to keep a sharp eye on that. Meteor makes it easy to throw a lot of data around, which can create overhead, so I’m becoming more conscious of how to keep my app feeling snappy. I’ve noticed with Meteor toys Mongol, for instance, that it will often take 3-4 seconds after I hit CTRL-M before the desired panes appear.


Since it’s a DOM/template cache, we will need to have some spare memory. But it’s depend on your app.

It’s a game of CPU vs Memory. Pick one :slight_smile:

My suggestion is to cache commonly use templates. Then there won’t be much memory issues. We will also built it as a LRU + time bound cache. (Just like in subs-manager).

So, in general it’s manageable.


Ok, so the LRU cache will be checked periodically via a timer. Interesting idea. That does solve my concern.

For page with lots of writes, won’t we need to invalidate the template cache?

Also, I wonder if most users will want to have templates auto cached by default (to reduce initial config, but can of course be excluded).

Is Blaze still worth it (supported in the future)?

@arunoda any progress? This is perfectly suited for offline apps, where data is unlikely to change. With this technique we load once and then not worry anymore about rendering