前端的浪潮一疊疊襲來，帶走了jquery，帶走了backbone，帶來了react，帶來了redux，但是面對層出不窮的前端技術，我們應該何去何從呢？近一年來筆者的也發生了同樣的變化，技術棧從.net+backbone+requirejs+grunt變成了nodejs+react+webpack+gulp，一系列的變化也讓筆者對整個過程，整個閉環的工具鏈有了一些自己的感受和理解，於是有了今天此文。
其實react出現得很早，但是筆者所在的喚作「大象轉身」的大公司，所以內部技術的迭代，並不像業務迭代那麼的頻繁，畢竟大多數公司奉行的依舊是技術為業務服務的原則（誠然，技術沒有經濟利益的產出，則沒有理由不信奉，不過這又是另乙個話題，權且按下不表）。不過也就在去年，筆者由於一些工作上的變動，開始全面的接觸起了react起來，於是念上心頭，我們為什麼要用react呢？
其實，談到react，可能最先映入眼簾的就是它對於dom的託管，virtual dom技術的出現也一定程度上封裝了之前紛繁複雜的dom操作，而且也降低了使用門檻（有關瀏覽器內部渲染原理），雖然這也是有***的，但是它相較於backbone，省去了大量的dom互動的過程，對於每位前端er都是一件很了不起的事情；不過，相比之下，筆者其實更中意它的設計中的資料流的思想，資料能夠受到約束之後，頁面的狀態不再像之前的時代那麼混亂無序，一切歸於平靜是多麼美好的一件事情。。但是，這種好日子其實並不長久，在應付小規模應用的時候，有約束的資料流向和傳輸也許並沒有什麼***，但是專案規模擴大之後，一級一級的狀態/屬性傳輸卻顯得特別的臃腫和低效，如下圖：
當我們的元件樹只有1層或者2層的時候，想從最上層透傳屬性還是很容易的事情，但是當元件層級越來越多，比如上圖，從底層父元件傳遞屬性到達最末的葉子元件，整個過程的傳輸在**上就顯得相當的冗餘，而且如果多個元件依賴於乙個共同的屬性，區域性變化引起的全域性變化很容易又會導致狀態**，這也是令人倍感頭疼的問題，所以redux就應運而生。
react官方最先推出的方案是flux，隨後見賢思齊的將其替換為了redux。其實react中強調的單向資料流幾乎是需要依託redux才能實現的，當接入了redux之後，整個資料流動就變成了以下這個樣子:
所有的狀態變化都拘束到reducer(s)中進行，修改統一的資料來源，然後再自上而下的重新分發，減少狀態/屬性傳遞的成本，也從根源上杜絕了狀態**，而且redux將資料從react中分離，則理論上所有的react component都可以是無狀態元件，那麼渲染效能還能夠得到進一步的提公升。
看到這麼精巧的設計，筆者饒有興致的研究了一下原始碼，並且嘗試著自己也實現了乙個簡單的redux，其實redux的原始碼也非常的簡潔：
index.js不過本文意並不在介紹它們的內部原理，讓我們回到正題。說了一大堆redux的優點，那麼它有沒有缺點呢？誠然，事無絕對，必有正反。雖然redux提供了很大的方便也彌補了react的一些機制不足，在技術方案上，似乎並沒有什麼問題，但是在實際使用時，由於它自身的鬆散耦合的特性，導致了實現具體功能時多種多樣的方式，而不同的人的理解又會導致不同的實現，舉兩個筆者所在的團隊的例子：createstore.js
compose.js
combinereducers.js
bindactioncreators.js
乙個是有關資料統計和非同步請求的**究竟應該寫在哪的問題。不同的業務場景不同的人，不同的實際情況，很有可能會讓我們在實際操作時，將action和reducer混淆使用，這樣本來是為了降低維護成本而剝離產生的action卻增加了我們的額外成本，這其實是得不償失的。
另乙個是關於狀態注入時狀態的多少問題。注入少了，之後的需求變更又需要頻繁改變**，注入多了又會導致元件的頻繁更新，且注入方式相當的隨意，對後續維護也是一件非常吃力的事情。。。
其實這樣的例子還有很多，歸根結底redux是一種思想，而且還是一種很靈活的思想，它給了使用者很大的自由發揮的空間，但是在社會化的協同工作時，過多的「自由」卻又意味著「不自由」。
其實時代的變遷，歷史的演進，新舊事物的交替其實是提現了人類思維方式的變化和面對的場景的變化。當初我們只需要dom操作就能完成頁面，所以jquery就足夠了，但是現在隨著前端的不斷發展，體驗要求、功能要求越來越高，越來越多，原始的簡單頁面維度的應用已經不能滿足了，於是，react或者其他的類virtual庫才會應運而生，然後新問題出現了，再去造新的輪子，然後，歷史也便形成了。
但我們仔細想來，就會發現，我們所造之物，其實永遠都不是乙個囊括所有問題答案的方案，我們給出的，不過是針對某乙個歷史時期的某乙個場景的某乙個區域性最優解而已，問題在變化，答案也在變化，不變的，也許只有時間亙古不變的流逝，以及我們那顆需要永遠保持運動變化的心。
為什麼要使用blog
有哥們問我，你為什麼使用blog?我總結了一下，覺得有如下幾個原因。1對自己的督促 有了blog，就會經常記得寫點東西 就會經常翻翻網上的新文章，了解一下新技術，不至於迷失在忙碌的生活中 如果把自己的所感所想所學寫出了，自己對自己也會有個概念，不至於迷迷糊糊 還有，畢竟是掛在網上的文字，心中難免擔心...
為什麼要使用XML
xml 代表擴充套件標記語言 extensible markup language 是由 world wide web consortium w 3c 的 xml工作組定義的。這個工作組是這樣描述該語言的 擴充套件標記語言 xml 是 sgml 的子集，其目標是允許普通的 sgml 在web 上以目...
為什麼要使用Nginx？
有人說這些基準測試是不準確的，因為在這樣那樣的環境下，做的比較不一致。我傾向同意基準測試只是告訴了我們其中一部分情況，你能做的是消除偏見 有人見過所有人都同意乙個基準測試是公平的嗎？我是沒見過。我們投資的一些公司把web平台切換到nginx後，可以顯著的解決擴充套件問題。nginx明顯有效的實現了今...