在开发期间，我们还花费了将近两周的时间对现在非常流行的react及react-native进行了详细的技术调研，我不得不说，react的开发效率是我目前所见最快速的框架，他的模块化开发思路，虚拟dom的理念都是我非常喜欢的一种方式，并且我们尝试了将它合并进slarkjs框架，开始我们只希望让它来负责view层的重绘工作，但是在实践中我们其实更希望它能负责更多的内容，可惜的是，react来web层面的使用，还有一定局限性，并且需要大量的开发时间来修改一些组件，很遗憾我们暂时停滞了这个项目的开发进度，但react-native在app上的开发，却是一个潜能无限的壮举，在之后的文章中，我们会持续的给大家带来slarkjs框架是如何吸收react-native并融入到app的开发。

从开发的角度来讲，1,3都非常好实现，而第二步，会让大多数的前端开发觉得头疼，这时候我们需要介绍两个很容易被遗忘，并且不会经常用到的属性nodeTpye和childNodes，其实JS有很多属性我们是很少会用到或者说，在我们的业务开发中和技术实现中很少去涉及的，相对来说，这也影响了我们对更深入的技术开发的方向，所以很多时候，我们提倡去看一些开发大拿的代码，其实是去看他们都用到了哪些属性，他们的开发逻辑思维，而并不是去copy他们的代码。

NodeType，它会让我们获得body元素的节点类型。说得简单一些，就是让我们知道当前节点是元素，属性，文本内容等等

ChildNodes会让我们获得body元素的子节点集合，以NodeList对象。简单解释就是返回一个list，里面是当前节点下所有的子节点，包括class，文本，select,option等等。

之后就很好去分析我们的构想了，通过NodeType去获取节点并判断节点属性，当然还要去判断当前页面的节点是否唯一，然后通过ChildNodes去对比节点下属性之间的差异，并且需要增加一些属性作为标记，比如判断当前是否应该修改，修改的顺序等等。

如果你仅仅是去循环判断重复，那你会在第二步的时候，将5变成2，第三步将6变成3，这样是一个很浪费资源的，所以我们需要用距离值去填充，当我们用新数据去循环的时候，我们需要在第一次循环中判断参数是否重复，对重复的参数判断修改值为false，再第二次循环中对非重复的参数用距离值去填充数据，最后得出最简单的list来覆盖。

这样的方式，减少了页面对dom的操作次数，提升页面的加载速率和二次加载速率，但是也是有一些坑的，比如：如果页面dom修改量巨大，在循环中会浪费非常多的时间去循环判断重复项，可能会比单独替换整体dom节点花费更多的时间，所以在domdiff中，需要增加一些判断，去适应大多数的方式。比如：减少循环，如果只是单纯的文本替换，我们并不需要去循环判断它的其他属性，又或者增加阀值，如果运行时间或者数据量超过标准时间进行部分的dom替换，这些都是组件级对代码的严谨性。

domdiff其实是为了浏览器的优化而做，但是也要适应当前的环境而用，它更像是react虚拟dom理念的前身，有好处也有坏处，使用时候还需谨慎，我们会在今后的1,2个月中，对react-native进行详细的分析，并且尝试去融入到我们的框架中，也许会打出分支版，slarkjs-native来支持app的开发，到时候会给大家继续分享进一步的技术体验，希望对h5比较有兴趣的童靴可以加入到我们的team中，体验既拥有Native的用户体验、又保留React的开发效率。