Imba claims to use an "imperative, memoized DOM" as opposed to a VDOM. Apparently it looks like they still use a VDOM (i.e. a wrapper around the DOM). The difference is that, at compile time, they attempt to unmix the dynamic parts of a template from the static parts, then they memoize the static parts for you automatically.

Sure, there are issues with existing VDOM implementations that do not do these compile-time optimizations:

  1. Returning new JSX elements from every render
  2. Building key indexes for every subdiff

The first issue can be solved with application-specified memoization in render. The second issue is pretty hard to avoid if you want to avoid matching elements based on indexes (naive subdiffs). Implicit and explicit keys are there for a reason, namely that moving elements is assumed to be a much less expensive operation than unmounting and re-mounting them. The O(N) trash memory overhead per subdiff incurred due to key indexes is justified, in my opinion. If using an algorithm like LCS, you'll incur more time/space cost, but you will even further minimize the edit path.

If I'm not mistaken, Imba would have to use something similar to key indexes if they want to avoid unnecessary unmounting and re-mounting for templates which are composed of large dynamic lists.

I'm not sold on Imba's value proposition. The value proposition is compile-time memoization for static elements, so you avoid re-creating those templates during renders. That's great and all, but how much of SPA webapps are purely static elements? For example, consider the the following JSX template:

  <ul>
    {this.state.bigList.map(i => <li>${i}</li>)}
  </ul>

I don't think Imba would perform much better than these other libraries for templates which are 99% dynamic (like this one), and so the dominating term here is the subdiff term, where you will end up either:

  1. Creating at least O(N) trash memory (e.g. key indexes)
  2. Doing unnecessary mounts and unmounts