寫在前面
年關將近，這年味愈加的濃烈了哈，似乎無心工作，似乎家鄉的叨念從遠遠的方向傳進了你的心里，堅持住哈，馬上，就回家了。
進入正題，首先，我需要先解釋下這個標題所表達的意思，以及它背后引出的具體的問題，前端架構與具體的應用的矛盾 這句話為什么要這么說，相信大部分公司，不論你是創業型公司、外包公司或者是大一點兒的，上市的，在你們的前端技術棧中，react出現的頻率應該不低，vue是更甚者吧，基於webpack、glub構建的應用應該很多了，甚至可以說，這些技術已經占領了前端的半個天下，但是筆者在這里呀，不禁要提出一個問題，那就是，你們的技術棧真的帶給前端更簡單的內容了嗎？ 使用這些技術棧的時候，你們的應用是否會變得學習成本高昂、擴展能力差、依賴高階程序員、文檔不齊全、有沒有測試用例？
架構的本質
我認為架構的本質應該是什么？ 它應該是基於可能面臨的風險構建的一套能夠適應當前業務、擴展未來業務、行為可預測的、高可用性的。在能解決這些問題的前提下，架構應該是高度抽象的吧，一個優秀的架構，它一定要足夠簡單，基於一個或多個抽象的理解上構建出來的。
簡單才是本質，spring為什么那么火，它足夠簡單。一旦你了解了它的抽象思維方式，整個開發極易上手，這就是一個優秀的架構應該有的表現力。如果你正在設計前端架構，我的忠告是，最好結合你的業務實際去實現它而不是去考慮最新的技術棧，盲目的追求渲染速度、組件式等。
前端一定要與業務接軌，一個管理系統，你跟我談什么渲染速度？一個正常的管理系統前端，它甚至都不需要webpack這樣的工具構建，只需要一個裸的vue加上jquery就可以完成，這樣的結構要優於大部分。為什么？ 貼合實際嘛！ 后台系統你一個前端能維護多久呢？大部分時間，后台er在維護這個界面，如果你使用的技術太過復雜，增加了學習成本，還更容易使整個架構逆向發展。
再例如，企業官方網站，企業商城，大型公司的門戶，宣傳網頁，這些東西完全不需要用到打包、甚至vue你都要少用， 為什么？最重要的是它們不利於SEO，然后是不利於快速迭代，設計的再復雜些，vue技術棧全部捅上去，那有什么用嘞？除了給你自己的職業生涯添加一筆，對公司來說這就是技術的債務，公司需要招比你更厲害的人才能理解你寫的這些高級的代碼，而這些代碼一旦在無數個迭代中膨脹，最后的選擇只有推倒重來，改都沒的改。
結合業務再談技術
什么前端路由系統，SPA 框架，你都要結合業務，后台系統使用SPA就是耍流氓。陡然增加前端的復雜性，讓前端變成了一個比后台系統還復雜的系統。這很得不償失。僅僅是為了前端開發的便利性，忽略的整個系統的復雜度，這樣的架構怎么看都是不可取的。
什么時候能夠使用這些技術棧？ 當然是業務允許、風險可以控制的情況下。 例如多終端，移動端，在移動端使用打包工具，SPA框架開發是很明智的，它們帶來的優勢，在渲染速度上，在使用性上，都是一流的。而且真正的實操中，這樣的項目一般是重點維護的。
要結合業務的實際選擇技術，大部分時候，開發時間是有限的，實現的功能很多，盲目追求技術的新、快、是沒有根據的。
一些看法
推薦一些我個人開發時常用的幾項前端架構，它們是我結合平時的開發實際，業務適應程度做出的技術棧調整。
首先，如果項目大小一般，時間很緊急，我會毫不猶豫選擇裸vue+jquery+bootstrap，快速開發完畢。
如果項目中等的話，時間不多不少，我會看團隊中，開發人員的比例，比如這個開發團隊只有一兩個前端，那么我會選擇 require管理我的js模塊，使用sass管理我的css模塊，足夠模塊化，也有組件，同時開發速度夠快，團隊中的其他人理解起來也很快，在項目很趕的時候后台也可以幫一些忙，也不會擔心他們破壞架構。具體到業務邏輯，首先了解業務的流程，例如我這個應用，面向的是企業管理人員，可能需要一些大數據展示，一些圖形化界面。那么我很可能選擇react+react-router+redux。
大型項目需要依靠具體面臨的可能風險，你需要調研清楚目標人群，宣傳方式，例如使用SEO做搜索宣傳，就不能選擇打包技術，微信wap，選擇vue技術棧是明智的選擇等等。
需要注意的是，最終的簡單才是王道。
寫在最后
希望大家一起探討這方面的話題，我的觀點也許是錯誤的，或者是有問題的，討論一下，大家一起提升。