震惊了，用imba框架，搞个比vue快50倍的性能基准

我是头条党吗？是的，但也不是。拍照为证。上图展示了vue、react和imba在todo项目中有60个todoItem，并且进行crud操作的方式不同。可以看到imba实现了每秒5万次以上的操作。如果你也想尝试一下这个测试，你可以访问TodosBench。测试使用了Benchmark.js。imba简介imba是一种可编译为高性能JavaScript的新型编程语言。可直接用于Web编程（服务端和客户端）开发。以下是语法：//自定义标签tagApp//属性propitems//方法定义defaddItemif@input.valueitems.push(title:@input.value)@input.value=""deftoggleItemitem:completed=!item:completed//mountimba.mount(element,into)//如果没有第二个参数，默认挂载到document.body上Imba.mount'add'

foriteminitemsitem:title可见作者喜欢ruby和pug，并且更喜欢缩进风格（个人不太喜欢这种语法风格）。具体语法请参考imba文档。当然，因为可以编译成js，所以也可以将服务器编译成js进行node开发。imba框架极速性能的性能基础。任何性能优化的实现都有其理论基础。那么imba性能快的基础是什么呢？答案是memoizedDOM（内存DOM）。理论基础浏览器的DOM操作可以说是浏览器的终极功能。无论框架是基于虚拟DOM还是基于真实DOM，最终都离不开对DOM对象的操作。HTMLDOM是浏览器定义的访问和操作HTML文档的标准方式。但是操作DOM的接口是JavaScript。但是浏览器通常将js引擎和渲染引擎分开实现。即页面实际渲染部分和解析js部分分离。用《高性能的 JavaScript》的话来说，如果把DOM和js看成孤岛。他们需要一座桥梁来沟通。所以每执行一次DOM操作，就过一次桥。那我们先说虚拟DOM。虚拟DOM的性能提升就是把DOM的对比放到了js层。然后通过比较差异来进行实际的DOM渲染。也就是说，虚拟DOM没有“真正”的性能提升，桥梁仍然存在。只在js引擎需要过桥的那一边，找了聪明睿智的大叔优化限制过桥的人和货（虚拟DOM高性能diff算法，状态批量更新）。那么memoizedDOM是如何做到的呢？将DOM节点的控制权直接放入内存中。类似于这样的优化。functiongetEls(sel){//设置缓存if(!getEls.cache)getEls.cache={};//如果缓存中存在el，直接返回if(getEls.cache[sel]){returngetEls.cache[sel];}//不通过DOM查询constr=document.querySelectorAll(sel||'?'),length=r.length;//缓存并返回元素节点returngetEls.cache[sel]=(length==1)?r[0]:r;}我们可以测试一下。这里我写了一个getElsByDocument和simplePerTest。//直接通过querySelectorAll函数获取节点getElsByDocument(sel){constr=document.querySelectorAll(sel||'?'),length=r.length;returnlength==1?r[0]:r;}//简单的性能测试functionssimplePerTest(fn,el){constfnfnName=fn.nameconsole.time(fnName)//2000次操作for(leti=0,len=2000;i"Welcome"#有50%的几率有redclass0.5)>"IMBA"可以得到下面的代码，详细可以看到imba将变量提取出来放到synced函数中。每次渲染只会执行synced中的数据，所以渲染速度还是会非常快。varComponent=Imba.defineTag('Component',function(tag){tag.prototype.render=function(){var$=this.$;returnthis.setChildren($.$=$.$||[_1('h1',$,0,this).flag('title').setText("欢迎光临"),_1('p',$,1,this).flag('desc').setText("轮盘赌")],2).synced(($[1].flagIf('red',Math.random()>0.5),true));};});精确提取不可变变量，然后不需要虚拟DOM计算，而且RealDOM也有缓存，可见memoizedDOM与virtualDOM不同，memoizedDOM有实际的性能优势。imba框架的“假”性能测试我们已经看到了上面imba框架的理论基础，那么它真的比vue快50倍吗？当然不是，所以我才说我是头条党。浏览器的运行机制浏览器本身只能达到60fps（1秒刷新60次）。当然，在体验上，60fps的体验差不多就够了，也就是浏览器渲染渲染一次需要17ms左右。事实上，不管dom每秒被操作5w次还是1000次，浏览器渲染引擎只会记录当前的脏数据。然后在需要渲染的时候重新绘制和重新排列。现实世界的内存限制面对memoizedDOM的缓存优化和更少GC带来的运行时提升，我们需要更多的内存来缓存每个dom节点。这在初始化渲染时有很多开销。同时我们浏览器的执行速度和渲染速度足够快，虚拟DOM完全够用。Imba框架和浏览器想象谷歌io大会chormePortals技术单页应用（SinglePageApplications，SPA）提供了良好的页面交互，但是以构建复杂度更高为代价，多页应用（Multi-pageApplications，MPA）更容易构建，但最终页面之间出现空白屏幕。Portals结合了两者的优点，主要用于提高网页的交互体验，以无缝导航为目标。它类似于iframe，嵌入在网页中，但可以导航到页面内容。当用户在一个页面上跳转到另一个内容时，虽然URL会随之改变，但并不需要打开另一个窗口。这时候内容标记的Portal会变成原页面的首页，原页面在后面。保持主进程状态。现场演示这对购物体验有多么方便，以及单页应用程序（如漫画）的演示。js引擎和渲染引擎的关系是以前的。浏览器的js引擎和渲染引擎没有任何关系。我们只能通过setTimeout或者setInterval来写动画，没有办法知道浏览器什么时候空闲。但是随着时间的推移开发，我们可以通过requestAnimationFrame和requestIdleCallback。requestAnimationFrame要求浏览器在下一次重绘之前调用指定的回调函数来更新动画。requestIdleCallback方法将在浏览器空闲期间执行要调用的排队函数。那么是否可以在js引擎中进行内置的DOM操作，是否可以降低桥的性能消耗或者完全打开桥。让我们拭目以待。鼓励如果您觉得这篇文章不错，希望您能给我一些鼓励，帮我在我的github博客下star。博客地址：https://github.com/wsafight/personBlog