Wow async dom updates is really great. That’s the way we can improve Blaze. That’s why Telescope (specially crater.io) is pretty slow on mobile.
1 Like
You know my only real question at this point is when is MDG going to hire Arunoda?!
4 Likes
They have only $20M )))
2 Likes
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.
1 Like
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.
1 Like
I was wondering the same for long time 
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?
1 Like
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).
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).
@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
It would be very appreciated @arunoda, seems like a great improvement for Blaze! I perceived in Kadira Debug that DOM Creation has been the bootleneck most impacting UX.
Hello,
This looks amazing ! The bottleneck in my app is currently from far Blaze rendering
@arunoda Any update so far ?
1 Like
Hi,
After this I decided to invest more on React and I figure our the Blaze we already having it dying.
BTW: Here’s the code I used - https://gist.github.com/arunoda/9e3997d9c8d8d73a16f7
Here I’m caching most of the views and that might add some Memory leaks in your app.
If you are trying to use this in production try to use something like LRUCache as the cache.
1 Like
Ok thank you for your answer,
Is React really way better than Blaze ? In terms of performance.
Just drop it to your app and use it like it I showed on the video.
Yes. It is.
Blaze can be tuned if needed. But React is always does a better Job,
1 Like