Blaze virtual DOM?


#1

A virtual DOM library called “Incremental DOM” [1] came out from Google today that:

  • is meant for handlebars-style templating systems
  • uses less memory than traditional virtual DOMs like React’s

Given that Blaze uses such a template format and can use a lot of memory [2], I was wondering whether people who are familiar with Blaze internals could speak to whether this library might be useful to Blaze?

[1] https://medium.com/google-developers/introducing-incremental-dom-e98f79ce2c5f
[2] https://github.com/meteor/meteor/issues/4568


If Blaze improved significantly, would you go back to it?
#2

Found a POC of using a different virtual DOM lib:

Mentions possibility of moving some work to a Worker to stop freezing the UI, which would be fantastic.

cc @gadicc @mitar @slava


#3

TL;DR

Yeah, the POC was designed especially for Blaze, works very well with it, solves UI freezes and opens the way to efficient designs using web workers. Biggest needed decision is how to handle “user” code, like DOM usage in events, lifecycle callbacks, etc – should they operate on / have access to the virtual DOM, real DOM or both… But yes I think this is the logical way to move forward.

Full post:

Yeah, the entire purpose of that POC was to avoid UI freezes. It was designed for famous-views where a freeze of even a few ms will cause jagged animations. It pretty much solves the problem even without using a web worker, although that’s a direction that I think is worth pursuing moving forward, for very “intensive” apps.

The main issue with the freezes is that Blaze runs synchronously (blocking) and constantly touches the DOM (which is super slow). The result is that until we’ve finished drawing up all our templates, the entire thread is frozen.

The POC creates a virtual DOM that Blaze ends up using without even realizing it (no changes were made to Blaze). All we do is queue up all the DOM operations virtually, and then play them back on the real DOM with a timer… once we’ve passed our safety threshold of a few ms, we pause, let (for example) Famous draw a frame, and then resume to carry on writing changes. This essentially makes Blaze asynchronous (non-blocking) and lets us continue smooth animations even while DOM updates are taking place.

This elegantly solves freezes, but doesn’t address performance (yet), since suddenly now performance doesn’t impact on UI fluidity. That is the logical next stage though… with the virtual DOM abstraction we can 1) recycle previously used real DOM elements, 2) diff upcoming work and do the minimal necessary changes. Note, react does that for the entire template, while Blaze redraws entire parts of the DOM but only for areas that were invalidated. That’s why each is faster in different cases. If we do our optimizations well, Blaze will be faster in all cases :slight_smile:

As you also mentioned, our extra layer opens the way up to using web workers. I think this is a direction Meteor should go in moving forward, and hope I can play my part… starting with Blaze but ultimately everything :slight_smile: Doing minimongo queries, etc, in a separate thread would be awesome. This needs to be completely opt-in… where all of Meteor can still all work fine in a single thread, but can be run with multiple threads.

The biggest challenge moving forward is how to handle user code (e.g. event handlers, helpers and life cycle callbacks). Which DOM do they get access to (real, virtual, both?), what would the API look like, what are new danger zones to be aware of, etc. So while we could actually use even the POC code straight away with Blaze, it would break existing apps that touch the DOM directly (i.e. most apps).

A few other semi-related things:

  • See also @arunoda’s post on Making Blaze Faster using template caching (!)

  • You mentioned memory, and in theory a virtual DOM should if anything be using more memory. Google’s “incremental” DOM uses lesses memory than a “traditional virtual DOM” because it creates less stuff virtually. The POC also doesn’t rebuild entire structures before diffing so has a similar advantage, but works quite differently under the hood. But…

  • I can’t see a virtual DOM ever making Blaze need less memory. What you described sounds more like a bug. I’ll post something into the issue.

Lastly, I developed the POC for famous-views, and would like to have it as an officially supported option (although currently most work is on the new version of Famous). But the idea is we can have a group of users who are willing to make a big effort for speed start playing with early code and APIs, and we can later try bring something more tried & tested “to everyone”.


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

Right, sorry – didn’t mean that using Incremental DOM would be less memory than Blaze currently uses, just less than if it used traditional vdom.

Moving everything possible to workers would be great. And then according to browser perf recs, everything that couldn’t be done in worker (or in browsers w/o workers), would either be done in 50ms chunks (when browser idle) or 10ms chunks (when in use). (See https://www.udacity.com/course/viewer#!/c-ud860/l-4138328558/m-4162098744, lesson #2)


#5

That looks like quite a cool online course :slight_smile:

Yeah, exactly. See also https://github.com/DispatchMe/meteor-kernel for regular apps (in famous-views we do something similar but integrate directly with Famous’ timer / loop). This is exactly how it should be done :>


#6

Did you do any further work on your blaze improvement? Is it still compatible with the current version?

I really see blaze using web workers as a great way to going forward


#7

Hey, it’s discontinued. As is the rendering part of Blaze by MDG. See Next steps on Blaze and the view layer.


#8

Related: Web Workers Make React Faster: http://blog.nparashuram.com/2016/02/using-webworkers-to-make-react-faster.html?m=1