前些天，我在喝咖啡時遇到一個同行朋友。
Saul：最近怎麼樣？
我：疲勞。
Saul：家裡的事？
我：不，是Javascript。
更準確地說，我指的是React和隨之而來的Javascript生態系統。
對於新手來說，不妨看看Pete Hunt問的為什麼React壓得初學者喘不過氣：
太多菜鳥被react的學習曲線壓得喘不過氣。為什麼呢？
如果你用過React，你就會跟Vjeux有同樣的經歷：
設定一個js專案太他X難了，這簡直要殺了我。上次花了我一整晚時間。
React社群中有個主要的問題，挫敗了初學者，也阻礙了專家。
太多工具
剛過去的這個工作季度，我們很痛苦地開始了三個新專案。我之所以說“痛苦”是因為每個專案都需要依據範圍和需要做關於工具的決定。
最終，這問題在於：選擇了React （和固有地 JSX），你就已經不知不覺地選擇了在建立任何東西之前都需要處理一堆令人費解的構建工具、樣板、linter（檢查程式碼風格/錯誤的小工具）和時間片。
樣板和生成器不是答案
Yeoman和Plop可以減少你做專案過程中複製貼上的工作量。
然後，從來沒有也不可能有一對一的匹配生成。
在規模足夠大的專案中， 從一個應用移植特性和改進到其餘應用是極其困難的，因為通用程式碼沒被抽象成一個獨立可更新的依賴關係。
當生成器是解決重複程式碼的好辦法時，那麼更好的辦法就是把它抽象到一個更簡單的API裡。
否則，生成器本身就會因為可能用例的排列而成為一個令人困惑的邏輯不清的應用，永遠處在跟它創造的應用保持相關的競爭中。
我有用過幾個生成器的第一手經歷，包括我自己的evolution/wordpress。
太多API 太多配置
這種情況的例子可見於Mark Dalgleish傑出的react-fetcher, 諸如Redux, React Router, Webpack之類的庫， 而React生態系統通過下移他們的體系結構基礎給使用者已經很大程度上以簡潔的API為代價選擇了離散模組化，從而損害了開發者的總體體驗。
單單而言，API是小的，但是即使不到一小把也會產生一堆對於一個人而言幾乎不可理解的程式碼。
即使包含在一個“模板”專案中，被生成器scaffold，或者被隱藏在一個finalCreatteStorev3SeriousThisTime.js檔案，我們建立了一堆讓WrodPress外掛難堪的連線。
更多抽象 更少程式碼
當然，這些API是基於更小的、解耦的、可測試的和因此更高質量的庫的需要。
然而，我需要介於連線依賴性和生成模板之間的一個抽象中間觀點。
抽象對減少有關工作原理的認知負荷是必要的，因此你才能專注於創新。
跟程式碼行鬥爭
在任何大規模專案的背後都會有大量的程式碼。
應用開發者不必成為庫基礎的專家，只需要使用它就夠了。
所以，檢測工具應該越小越好。
來看看這個草草羅列的替代方案清單：
- 提供一個自認為是對的且作者認可的整合API或者庫給理論上90%的用例。（就多數而言，單單去掉用於React+Router+Redux的模板就是很大的提升。）
- 釋出類似於Babel預置(例如，es2015, react等)的用例預置。
- 充分利用資料夾和檔案命名的慣例以自動發現面向應用的路徑、操作、測試等。（這對於測試（比如Mocha）和服務公共的assets已經很常見，但每個專案或多或少需要一個unicorn配置。）
- 社群驅動的快速應用開發（RAD）工具會延緩對明確配置的需求，直到範圍固定。
直到生態系統的大部分採用了簡潔的API、規範及努力為終端使用者大量減少實現細節時，抽象工具才可能是我們的唯一出路。
RAD工具
按照上面的Twitter執行緒, 很多人理所應當地認為沒有萬能的解決方案。
然而，如果我們僅以建原型為目的開始，潛在的抽象關係就不重要了。
相應地，Vjeux 以開發快速原型設計的工具來挑戰社群，甚至以定製為代價。
同時，我意識到一些現在可以用來快速開始下個專案的選擇：
Javascript已經從限制性的、單一的框架轉移到模組化、避免模板的庫。
很快地，我相信它會穩定於快速發展和定製中間。
事實上，我的一個朋友意識到了同樣的新興模式：
2016 會發展出一個專案、工具和語言特性方面的真正統一的結合，把最好的包/工具/模板融合到更多的樣式化專案中。——Matt Keas在State of the Union.js提到
令人激動的2016就在眼前！:)