$[1].flagIf('red',Math.random() > 0.5)
,true));
};
});
精确的抽取不可变量，然后无需虚拟DOM 计算，同时对于真实DOM 还进行了缓存，我们可以看出 memoized DOM 与 虚拟DOM 不同，memoized DOM 是具有实际的性能收益。
imba 框架“虚假”的性能测试
我们在上面看到了 imba 框架的理论基础，那么他是否真的比vue快50倍？当然不是，这也就是在上面说我是标题党的原因。
浏览器的运行机制
浏览器本身只能达到 60 fps( 1 秒刷新了60次 )。当然了，其实对于体验而言，60fps的体验已经差不多够用了，也就是浏览器渲染上大概需要 17ms 去渲染一次。事实上无论是每秒操作dom 5w次还是 1000次，浏览器渲染引擎也只会记录当前的脏数据。然后在需要渲染时候再进行重绘与重排。
真实世界的内存限制
面对 memoized DOM 的缓存优化以及更少 GC 带来的运行时提升，我们需要更多内存来对每一个 dom节点进行缓存。这个在初始化渲染时有大量的消耗。同时我们的浏览器执行速度和渲染速度已经足够快了，虚拟DOM已经完全够用了。
imba 框架与浏览器的畅想
Google io 大会 chorme Portals 技术
单页应用程序（Single Page Applications，SPA）提供了很好的页面交互，但代价是构建的复杂性更高，多页面应用程序（Multi-page Applications，MPA）更容易构建，但最终会在页面之间出现空白屏幕。
Portals 结合了这两者的优势，主要用于改进网页交互体验，目标是无缝导航。它类似于 iframe ，内嵌在网页上，但可以导航到页面内容上。用户在一个页面跳转另一个内容时，虽然 URL 相应地发生变化，但是不需要打开另一个窗口，此时该内容标记的 Portals 会变成原来页面的顶级页面，同时原来页面在其后保持主进程地位。现场演示了这对于购物体验的极大便利，此外还有对漫画这类单页面应用的演示。
js引擎 与 渲染引擎的关联
在之前，浏览器 js引擎和渲染引擎是没有任何关联的，我们去写动画只能通过 setTimeout 或者 setInterval，更加没有办法知道浏览器什么时候处于空闲状态,但是随着时间的发展，我们可以通过 requestAnimationFrame 和 requestIdleCallback。requestAnimationFrame 要求浏览器在下次重绘之前调用指定的回调函数更新动画。requestIdleCallback方法将在浏览器的空闲时段期间对要调用的队列函数进行执行。
那么内置DOM 操作是否能够在js引擎中，是否能够减少过桥的性能消耗或者完全把桥打通。让我们拭目以待。
