自己英語一般，水平有限，獻上原文地址，還有我翻譯的中文地址，歡迎大家勘誤
下面是自己的一點感想
先說一下webpack，我們知道，前端優化有這麼幾步，
第一步
首先呢我們知道，一個應用要依賴好多條js檔案，而瀏覽器載入完一條，要執行完這條才載入下一條，所以呢，就很慢，於是乎我們就得把它們合成一個，
第二步
我們知道瀏覽器是有快取的，那釋出新版本的時候為了防止瀏覽器快取，每次發新版本我們都得和上一版檔名不一樣，所以我們用md5摘要演算法將js檔案生產摘要，作為js檔名的一部分
第三步
可是我們又想利用瀏覽器快取，減少請求，加快載入速度，我們發現我們經常改的是我應用的業務邏輯部分的js，而js的依賴幾乎不該，而且js的依賴體積還不小呢。所以我們把js的所有的依賴放在一個檔案（vendor.js）裡，業務邏輯放一個檔案(app.js)裡，然後分別md5加密
第四步
如果是是單頁應用，而且又是一個比較龐大的應用，一上來就把所有的js 都載入了，，是不是很浪費，因為很多頁面，我們都點不進去啊。所以能我們需要按需載入。只有訪問要載入的頁面時，我們才載入相關js
第五步
還是單頁應用，為了加快第一次載入的速度，我們想如果要是css也能按需載入就好了，我們為什麼不用js動態按需載入css呢，乾脆將css和js 寫一起（我們該怎麼寫就怎麼寫，讓webpack讓他們在一起），載入js就把css 載入了，一條js請求就同時裡面包含css。。這樣css的請求也變少了，而且他倆可以一起用gzip壓縮
第六步
圖示什麼的很多很雜有不大，我們是不是為了減少 請求數將他們合在一起啊。。生成雪碧圖。。對這還不夠完美。要是能和js在一起就更好了。。咋做呢。。用base64 讓他變成字串。然後就能和js在一起了。這樣的話還可以利用gizp壓縮百分之75。不過前提是小圖片或者小圖示。。不然。。。圖片太大的話還是。。
以上這6步。。webpack十幾行程式碼就能幫你實現。demo看這裡m.loutianxia.cn
然後說一下react效能
我覺得效能大資料量高互動的應用，同樣是兩個大牛，分別用react和angular，react會比angular效能好很多。注意我的前提哦，我用了一年半angular，最後還是被他的髒檢查，傷痛了心，我們知道一個雙向繫結就代表一個watch，就代表一串髒檢查，當資料一大的時候。。唉。。。
最後是可維護型
我先說一個結論單向資料流要比mvc強好多，
我會在我翻譯的redux教程中詳細說明
囉嗦這麼多開始教程
教程 0 -介紹
為什麼會有這個教程呢?
當我試著學redux的時候,我意識到通過依賴讀過的文章和個人經驗學習到的有關flux的知識，存在很多錯誤的地方我不是說那些關於flux的文章不好只是我沒有正確掌握這些概念。
最終, 讓我僅僅只是會用不同flux框架(Reflux, Flummox, FB Flux)的文件,和試圖將他們和我讀過的理論概念（actions / actions creators, store, dispatcher, etc）生搬硬套只有當我開始用redux的時候，我才發現這個flux其實比我想象的簡單多了
，這多虧了redux擁有非常精良的設計而且不會向我以前以前用的那些框架一樣，有大量的“anti-boilerplate features”（反 正規化 特徵）現在 ，可以毫不誇張的說 我感覺通過redux學習flux比許多其他框架好多了。
用我自己的話講，這就是為什麼我想把我掌握的和運用的有關redux的flux概念分享給大家的原因，你可能已經知道下圖呈現的是著名的單資料流flux應用
_________ ____________ ___________
| | | | | |
| Action |------------▶| Dispatcher |------------▶| callbacks |
|_________| |____________| |___________|
▲ |
| |
| |
_________ ____|_____ ____▼____
| |◀----| Action | | |
| Web API | | Creators | | Store |
|_________|----▶|__________| |_________|
▲ |
| |
____|________ ____________ ____▼____
| User | | React | | Change |
| interactions |◀--------| Views |◀-------------| events |
|______________| |___________| |_________|
在這個教程我們會逐步介紹給你以上圖表中的概念.我們會分別嘗試理解每一模組存在的理由和扮演著一種什麼樣的角色，
而不是上來就解釋整張圖，這樣大家都會頭大的 一旦你理解了每一部分，就能集齊龍珠，召喚神龍啦，哈哈哈
但是在開始之前, 讓我們先聊聊為啥flux會存在，又為啥我們需要它捏?
假設我們正在開發一個web應用， 那麼它是由啥構成的呢?
1) Templates(模版) / html = View(檢視)
2) 和我們View(檢視層)裡繫結的資料= Models (模型)
3) 取資料的邏輯, 排程切換各種檢視層,響應使用者事件,資料的修改等= Controller(控制層)
這是我們所熟悉的非常經典的mvc模式.想必你心中也有這樣的疑惑，如果在表達上稍作修改，其實mvc模式也很想flux的概念
-
Models 就像 stores
-
使用者事件,資料操作和資料修改就像 “action creators” -> action -> dispatcher -> callback
-
(view)檢視層 就像 React views
所以說，難道flux就僅僅是單詞而已嗎? 不是這樣的.但是這個單詞至關重要，
因為我們可以表達的更精準一些通過這些術語（意思是說，，這麼一比，難道flux僅僅是一個名字而已嗎，
其核心概念還和mvc一樣。不是這樣的,它其實和mvc思想是不同的。但flux的這個單詞也不能小覷哦，
因為它通過提出一些新的術語，可以更精準的描述flxu這一架構），舉個例子, 向後臺請求資料是可以稱為action, 就像一個點選事件也是一個action，
input的change 事件也是一個action …然後我們的操作都可以稱為action，action只是一個名字而已。
flux可以確保所有action都是由一個叫做dispatcher發出的 然後經過我們的stores，最後通過監聽store，發出一個通知。
而不是讓action直接修改你的Model層和View層(意思是說。。任何action,都必須通過dispatcher發起。
然後能引起stores改變，stores的改變會通知，再引起view的改變，而不像mvc那樣，一個事件過來了，
在這個事件的回撥函式直接裡改變model或者修改view)
為了清楚的理解mvc和flux的不同
我們將在mvc應用中寫一個經典的用例
1) 使用者點選按鈕A
2) 按鈕A的點選處理函式會觸發Model(模型) “A”的改變
3) Model”A”的改變，會使監聽Model “A”的函式執行，這個函式會觸發Model(模型) “B”的改變
4) Model”B”的改變，會使監聽Model “B”的函式執行，這個函式會觸發 View B的 重新渲染
在這種環境下想要快速找到bug的源頭，那將是一個巨大挑戰啊.
這是因為View監聽每一個Model，Model有監聽其他的Model，
所以呢資料可以來自於很多地方又有可能因為可多情況被該改變掉(可能是因為views也可能是因為models)
(資料的改變可能來自於多種情況，很混亂，不可預測)
然後 當 用flux以及它的單向資料流架構，上面的例子就變成這個樣子了
1) 使用者點選按鈕A
2) 按鈕A的點選處理函式會dispatch 一個action 出去，然後使 Store “A”接到通知發生改變
3) 用於 dispatch 出去的這個action也會通知其他的store，所以Store”B” 接到通知 也會做出相應的 改變
4) Store “A”，Store”B” 的改變 通知了 View B，使View B 發生重新渲染
所以知道我們如何防止Store A 和 Store B產生直接聯絡了吧 ?每一個store的修改只能通過action，
其他任何方式 都不可以的 （所以這樣就阻止你 watch Store A而直接改變Store B）
一旦和這個 acition有關的所有store 的都做出響應的改變
views 最終也被更新了. 所以呢 資料只能沿著下面這條線傳遞:
action -> store -> view -> action -> store -> view -> action -> …
就像我們的用例是從action開始一樣, 讓我們的教程也從action和建立一個action開始吧
未完待繼續翻譯