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!
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).
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 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
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).
@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
