隨著用戶規模的日益增大，web應用的內容和功能也變得越來越豐富，各大應用對于用戶的體驗，流量，內存，性能優化也越來越高，人們不僅僅要看到自己需要的內容，還對響應速度，動畫的流暢性，瀏覽網頁的等待時間都提出了非常大的要求。在網頁首屏優化上，我們盡量采用異步加載頁面數據的方式來提升用戶的流暢性，也增加了一些離線模板的技術規劃，而在代碼的底層組件，我們引入了一下新的方向，去減少用戶點擊事件之后對頁面DOM節點的操作，從而提升用戶體驗。
我們希望slarkjs是一個簡單的，通用的，易了解和使用的框架，而我們的組員也保持著平常心的心態去豐富我們的框架，我們希望slarkjs是很多初級的h5開發希望去了解的，去熟悉的，以下我會用很多非常白話文的概念思路去解析我們的框架組件，給一些對h5有興趣，對slarkjs有興趣的前端開發童靴去了解組件化的開發思路與框架的理念。
正常情況我們只有兩種方式，第一種，替換整個ul節點，第二種，將你想要變成的數據循環inner進去，這樣我們就有了4次的刪除和5次的添加，但是我們覺得這些dom操作太多了。
其實真實的情況，我們最需要把第四個li中的數據替換，并且在后面添加一個
在開發期間，我們還花費了將近兩周的時間對現在非常流行的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的開發效率。
文章轉載請保留網址：http://waterplane.cn/news/solutions/1562.html
