Web平臺能從Node.js學到什么
Will Binns-Smith 是一位熱愛JavaScript的全棧工程師，喜歡通過技術來解決實際問題。他開發了Bonobos.com的前端購物車功能。Will喜歡與設計師一對一工作，將PC網站轉換為針對更小的觸摸設備的站點。近日，Will撰寫了一篇 文章 ，談到了Node.js有哪些做法和特性值得Web平臺學習。
作為一名Web開發者，我們會非常感激jQuery之類的庫，因為他們消除了底層平臺的各種不一致與笨拙的情況。曾幾何時，構建一個 XMLHTTPRequest對象需要好幾行代碼，但現在只需一行$.ajax調用即可；通過jQuery與DOM交互很少需要我們針對特定的平臺采取一些非常規手段，因為這一切jQuery都幫我們做好了。
使用過Python或是Java語言的開發者都知道這些語言自帶了標準庫。在瀏覽器端，jQuery就是這樣的標準庫，此外還有諸如 underscore之類的工具集。就像大多數標準庫一樣，我們所編寫的代碼都會嚴重依賴于他們。當越來越多的代碼開始依賴這些APIs時，我們就很難在不破壞既有Web的情況下向前邁進了。不要妄圖為了兼容性而包含進這些庫的多個版本，他們常常會有30KB的大小，而且默認情況下會向全局的window 對象寫入。
過去，我認為這是軟件開發不可避免的一個問題。但現在一切都變了，至少對于我來說是這樣的，因為Node.js生態圈出現了。
小模塊與組合的出現
Node是一個構建在Chrome V8引擎之上的JavaScript運行時，它幾乎沒有多少標準庫。相反，其他生態圈中的那些標準庫都不在其核心平臺中，而是通過npm獲取的。
在npm中，小模塊已經成為了標準，像是 substack 和 Sindre Sorhus 這樣的用戶分別已經發布了685和760個模塊，這些模塊都遵循著UNIX一次只做一件事，并將這件事做好的原則。像是array-union（返回兩個數組的并集）與svg-create-element（提供了用于在DOM中創建SVG的優秀API）這樣的模塊都是非常小的，看起來應該與語言或是平臺一同發布。
Sindre甚至還有一個名為negative-zero的模塊，它只是判斷一個值是否是-0，實現 只有一行代碼 。看起來為這樣簡單的功能創建一個包有些極端，因為用戶可以在自己的代碼中實現這樣的功能，不過通過這種方式，我們可以集中修改代碼，而不必重復實現細節。Sindre對此有個很詳盡的 介紹 ，感興趣的讀者可以看看。
甚至連非常流行的 Express Web框架 也只提供了Web應用的核心功能而已。與諸如Ruby on Rails或是Django這樣的大型框架不同（本身帶有模板、ORMs、csrf防護，以及其他特性），Express本身只提供了托管靜態文件的中間件。相反，應用開發者可以自由使用他們喜歡的這些特性的實現，并將其組合起來創建應用。隨著想法的不斷改進，很多中間件包創建又消亡， 一些發展起來了，另一些則消失了 。這就是Node的哲學。
因此，小模塊（以及由這些模塊所構成的應用）會擁有非常龐大的 依賴圖 （比如說，Bitbucket的前端包含了1000多個JavaScript模塊，其中一些是內部模塊，另外一些則來自于npm）。
這些模塊最棒的一點就是他們并沒有緊密綁定到平臺上：他們不會受到標準庫的影響，借助于 語義版本化 ，他們可以對其API進行迭代而不會對依賴他們的用戶造成困擾。
流介紹
Node包含了流，它是異步流動數據的一個抽象，常常用于連接和轉換I/O源。Node對流的初始實現（隨Node 0.4發布）并不完善， 使用不當會導致數據丟失 。為了解決這一問題，Node 0.10對流進行了修正（也叫做Streams2）。不過，Streams2并不是對流模式的一個簡單迭代，實際上在Node 0.10發布前經歷了很多的變化。在發布時，它與運行在Node 0.8上的應用兼容。
這怎么可能呢？Streams2源自于 readable-stream 模塊，一開始它就是Isaac Schlueter 在2012年7月發布的獨立模塊 ，這距離 2013年3月它隨著Node 0.10的發布 已經相隔很長時間了。它經歷了多次迭代，在這個過程中API與功能也不斷成熟，Node社區發現它非常適合于作為流的實現。
時至今日， readable-stream的最新實現也是作為用戶模塊在npm中維護的 ，可用于Node 0.8及之前的版本中。很多用戶都喜歡 使用用戶模塊而不是綁定的模塊 ，這樣可以實現生態圈的兼容性。
一系列不幸的APIs
與此相反，JavaScript與Web平臺中現有的APIs都是很難改變的。對JavaScript語言的迭代變更（不能有任何的向后不兼容變化以防止現有系統出現問題）必須要通過添加新特性來實現。比如說，在發現Mutation Events API的性能問題后，人們引入了Mutation Observers來解決這個問題；廢棄WebSQL，擁抱更加底層但使用起來卻略顯笨重的IndexedDB；逐步淘汰Application Cache，擁抱更加底層但更通用的ServiceWorker。Object.observe是ES2016的一個提案，通過它可以觀測對象的屬性，不過在React的單向數據流逐步流行起來并為主流所采用后，Object.observe提案則被 撤回 了。
對這些感到困惑么？我們不應該期待著一下子就將事情做對，不過我們需要一個平臺，通過這個平臺可以試錯，然后逐步向好的方向迭代。
平臺演化
可擴展的Web宣言 的支持者們希望Web能夠像Node那樣提供彈性的用戶試錯空間。其使命是讓平臺提供盡可能多的底層構建塊，這樣瀏覽器之外的庫就可以自由嘗試，從而避免正式的標準化流程所經歷的代價高昂且冗長的過程。其中一種這樣的底層原語就是 Web Components 的APIs，它向開發者提供了通過JavaScript來創建動態自定義元素與屬性的能力，這一切都是通過封裝來實現的。一個庫無論大小都實現了對話框功能，不過API的迭代可以交給用戶來完成，一開始無需放在平臺內部實現。借助于底層原語，用戶可以通過小模塊的形式自由探索更高層次的抽象。換句話說，我們 不再需要AppCache 了。
幸好，我們已經看到了這種做法的好處。我們無需再陷入諸如AppCache這種實際使用很少的特性了。相反，我們有了一個 Promises A+ Specification 的標準化實現，npm中的 Q 已經證明了這一點，并且在年初已經成為了ES2015的一部分。WHATWG也在制訂 流的規范 ，在很大程度上它受到了來源于Node的流的演化的影響。
就像平臺的其他方面一樣，這些新標準是很難改變的，不過幸運的是，其想法與APIs都是通過用戶來實現的，這一切都要歸功于Node！