❶ 前端常用的框架有哪些
給你介紹Web前端三大主流框架
React：
1.聲明式設計：React採用聲明範式，可以輕松描述應用。
2.高效：React通過對DOM的模擬，最大限度地減少與DOM的交互。
3.靈活：React可以與已知的庫或框架很好地配合。
優點：
1.速度快：在UI渲染過程中，React通過在虛擬DOM中的微操作來實現對實際DOM的局部更新。
2.跨瀏覽器兼容：虛擬DOM幫助我們解決了跨瀏覽器問題，它為我們提供了標准化的API，甚至在IE8中都是沒問題的。
3.模塊化：為你程序編寫獨立的模塊化UI組件，這樣當某個或某些組件出現問題是，可以方便地進行隔離。
4.單向數據流：Flux是一個用於在JavaScript應用中創建單向數據層的架構5.同構、純粹的javascript：因為搜索引擎的爬蟲程序依賴的是服務端響應而不是JavaScript的執行，預渲染你的應用有助於搜索引擎優化。6.兼容性好：比如使用RequireJS來載入和打包，而Browserify和Webpack適用於構建大型應用。它們使得那些艱難的任務不再讓人望而生畏。缺點：React本身只是一個V而已，並不是一個完整的框架，所以如果是大型項目想要一套完整的框架的話，基本都需要加上ReactRouter和Flux才能寫大型應用。
Vue：
Vue是尤雨溪編寫的一個構建數據驅動的Web界面的庫，准確來說不是一個框架，它聚焦在V（view）視圖層。
它有以下的特性：
1.輕量級的框架
2.雙向數據綁定
3.指令
4.插件化
優點：
1.簡單：官方文檔很清晰，比Angular簡單易學。
2.快速：非同步批處理方式更新DOM。
3.組合：用解耦的、可復用的組件組合你的應用程序。
4.緊湊：~18kbmin+gzip，且無依賴。
5.強大：表達式無需聲明依賴的可推導屬性(computedproperties)。
6.對模塊友好：可以通過NPM、Bower或Duo安裝，不強迫你所有的代碼都遵循Angular的各種規定，使用場景更加靈活。
缺點：
1.新生兒：Vue.js是一個新的項目，沒有angular那麼成熟。
2.影響度不是很大：google了一下，有關於Vue.js多樣性或者說豐富性少於其他一些有名的庫。
3.不支持IE8。
Angular：
Angular是一款優秀的前端JS框架，已經被用於Google的多款產品當中。
它有以下的特性：
1.良好的應用程序結構
2.雙向數據綁定
3.指令
4.HTML模板
5.可嵌入、注入和測試
優點：
1.模板功能強大豐富，自帶了極其豐富的angular指令。
2.是一個比較完善的前端框架，包含服務，模板，數據雙向綁定，模塊化，路由，過濾器，依賴注入等所有功能；3.自定義指令，自定義指令後可以在項目中多次使用。
4.ng模塊化比較大膽的引入了Java的一些東西（依賴注入），能夠很容易的寫出可復用的代碼，對於敏捷開發的團隊來說非常有幫助。
5.angularjs是互聯網巨人谷歌開發，這也意味著他有一個堅實的基礎和社區支持。
缺點：
1.angular入門很容易但深入後概念很多,學習中較難理解。
2.文檔例子非常少,官方的文檔基本只寫了api,一個例子都沒有,很多時候具體怎麼用都是google來的,或直接問misko,angular的作者。
3.對IE6/7兼容不算特別好,就是可以用jQuery自己手寫代碼解決一些。
4.指令的應用的最佳實踐教程少,angular其實很靈活,如果不看一些作者的使用原則,很容易寫出四不像的代碼,例如js中還是像jQuery的思想有很多dom操作。
5.DI依賴注入如果代碼壓縮需要顯示聲明。
❷ 對前端工程化的理解
前端工程化
因為剛剛入門的時候，我們寫頁面會把前端的這三樣放在一張頁面上，工程化就是動態的HTML,CSSS,JS分離出來，將前端當成工程進行分析，組織和構建從而達到項目結構清晰，分工明確，團隊配合默契，開發效率高等目的。
工程化是一種思想，不是某種技術。在只有若干頁面的小項目中，我們只需要把簡單的頁面組織起來，而一個大型的web項目往往要更多的頁面和復雜的結構甚至多個團隊配合才能完成整個項目。我們需要更加嚴謹和復雜的工程化的思維去組織結構。從更高層次的項目組織來看我們的項的各種規范，技術選型，項目構建優化等等，在代碼層次，需要用到js和css模塊化，UI組件等。用句俗話說，工程化就是用工程的思維來做項目，而不是擼起袖子就寫代碼。
❸ 什麼是前端工程化
所謂前端工程化我認為就是將前端項目當成一項系統工程進行分析、組織和構建從而達到項目結構清晰、分工明確、團隊配合默契、開發效率提高的目的。
工程化是一種思想而不是某種技術，前端工程化就是用做工程的思維看待和開發自己的項目，而不再是直接擼起袖子一個頁面一個頁面開寫，所有能降低成本，並且能提高效率的事情的總稱為工程化。
前端工程師是互聯網時代軟體產品研發中不可缺少的一種專業研發角色。從狹義上講，前端工程師使用 HTML、CSS、JavaScript 等專業技能和工具將產品UI設計稿實現成網站產品，涵蓋用戶PC端、移動端網頁，處理視覺和交互問題。
前端工程師，又叫web前端開發，前端開發是從網頁製作演變而來。早期的網頁製作主要內容都是靜態的，以文字圖片為主，用戶使用網站也以瀏覽為主。隨著互聯網的發展，現代網頁更加美觀，交互效果更加顯著，功能更加強大，於是網站開發細分成了前端開發和後端開發。
前端工程師通過前端技術完成界面設計、界面展現，交互效果，頁面維護、網站優化等等。通俗點講，就是設計、製作網頁，實現網頁上各種各樣的特效和功能。
❹ 一般前端做項目，你們會選擇什麼
之所以Web前端框架這個話題熱度那麼高，很大程度上是因為受眾眾多。這一點我要解釋給Web前端小白聽一下，雖然你在剛開始學習的時候往往是從HTML，CSS，JS學起的，但是一個完整的課程最後肯定是少不了Web框架的。因為最後在實際工作的時候，一般都是在框架上搭建網站的，是不會真的從底層開始寫代碼的。
因此框架作為項目接近100%利用率的好工具，也是網站的基礎，他的好壞也就顯得尤為重要了。說到這里大家應該能夠明白，大家嘴裡的三大框架，肯定是平分秋色，各有優劣的。不然這樣激烈的市場，一無是處的框架一早就被淘汰了。
1、Angular
大家眼裡比較「叼」的框架，甚至有人說三大框架中只有她能稱的上一個完整的框架，因為他包含的東西比較完善，包含模板，數據雙向綁定，路由，模塊化，服務，過濾器，依賴注入等所有功能。對於剛開始學習使用框架的小夥伴們，可以推薦這個框架，學會之後簡直能顛覆之前你對前端開發的認知。使用 TypeScript能夠提高代碼可維護性，有利於後期重構。雙向數據流很方便，但是等業務復雜之後，你可能就搞不清楚數據流了。還有令人不開心的臟值檢查，以及directive的封裝並沒有解決視圖與數據關系完全分離，有時候還要用$digist強制觸發檢測。
2、React
這個框架本身比較容易理解，他的結構很清晰，就是由十幾個API組成，然後非同步渲染，我們只需要處理好介面和維護就好了，但是很多人反映上手還是有一定的的難度的。React是單向數據流，代碼寫起來會較雙向數據流的多一些，但是同樣的排查問題時思路清晰很多。
3、Vue
號稱是最簡單，最容易上手的框架，同時也是行內的大趨勢，還可以用來開發最火的小程序。畢竟用這神器，代碼碼的飛快，項目也能快速上線。同時他也是雙向數據流。有些人認為Vue是Angular和React的結合，既有Angular的模板語法也有React的組件化體系。
當你學會其中某個框架之後，你再轉用其他框架的時候，學會是很容易的，因為方法都是大同小異的。具體的使用還是得看公司的項目適合或者要求哪個框架。之前小編在網上暗訪了一下，看看有沒有人這三個框架都十分精通的，但是很遺憾的發現，都用過的人不少，但是真正敢說精通的還是沒有。這些框架學會使用還比較容易，但是裡面的「水太深」，精通還需長久的時間，望大家共勉，一起學習進步呀！
前端框架很多，比如node.js也是很重要的，我們做微信小程序員用的比較多的。
❺ 誰能和我說明一下 前端開發的規范 ： html文件目錄結構 應該時什麼樣的
建議你到這個地址上去看一下
https://github.com/doyoe/html-css-guide
❻ web前端項目的結構是怎樣的
你指的是文件夾結構嗎？
通常包含index.html文件，以及cn/html文件夾（用戶存儲html文件）、CSS文件夾、images文件夾、js文件夾
前面這些都是上線時要有的，如果是自己的項目，還可以增加imageStudio等文件夾用於存儲PSD等設計圖、相關文檔等
❼ web前端項目開發流程
前端前景是很不錯的，像前端這樣的專業還是一線城市比較好，師資力量跟得上、就業的薪資也是可觀的，學習前端可以按照路線圖的順序，
0基礎學習前端是沒有問題的，關鍵是找到靠譜的前端培訓機構，你可以深度了解機構的口碑情況，問問周圍知道這家機構的人，除了口碑再了解機構的以下幾方面：
1. 師資力量雄厚
要想有1+1>2的實際效果，很關鍵的一點是師資隊伍，你接下來無論是找個工作還是工作中出任哪些的人物角色，都越來越愛你本身的技術專業前端技術性，也許的技術專業前端技術性則絕大多數來自你的技術專業前端教師，一個好的前端培訓機構必須具備雄厚的師資力量。
2. 就業保障完善
實現1+1>2效果的關鍵在於能夠為你提供良好的發展平台，即能夠為你提供良好的就業保障，讓學員能夠學到實在實在的知識，並向前端學員提供一對一的就業指導，確保學員找到自己的心理工作。
3. 學費性價比高
一個好的前端培訓機構肯定能給你帶來1+1>2的效果，如果你在一個由專業的前端教師領導並由前端培訓機構自己提供的平台上工作，你將獲得比以往更多的投資。
希望你早日學有所成。
❽ 後端目錄結構與前端目錄結構是分開放的嗎
人生第一次做規劃項目，以前都是跟著前端的老大，他把一切都規劃好了，我跟著做就可以了，這次要自己規劃前端目錄結構，好緊張，參考了眾多文章，結果還是看不太懂，網路前端工具框架–fis，沒怎麼看得懂，所以沒用，還是自己好好想把，我還是主要參考了，我上次做項目時，那個項目負責人是怎麼規劃項目的。
二、前端結構
1、首先我想到需要的功能就是，把js、css、UI組件、庫文件、grunt，等這些工具分開擺放。
2、在不考慮html文件的位置情況下，在任何地方都可以調用到js文件、css文件、UI組件、庫文件。
3、存放壓縮文件的地方。還有一個存放所有完整庫文件、完整UI文件的地方
（1）src為主文件目錄。
（2）bower_components為所有庫文件、UI組件原文件的存放目錄。
（3）dep為刪減過後的所有庫文件、UI組件的存放地址
（4）grunt放置grunt需要的插件，以及配置。
（5）js、css文件用來存放所有的編寫的js文件、css文件。
（6）src_css、src_js為壓縮過後的js文件，以及壓縮過後的css文件。
（7）README.md文件為前端項目說明。
三、這么分類的考慮原因
1、擴展型，不管以後需要添加什麼效果，我只需要在js、css目錄中添加相應的文件就可以了，命名方式我也想好了，可以用html頁面的名字作為前綴，然後在加上相應功能的名字，這樣就可以很好的形成命名空間。
2、復用性，我為什麼沒有考慮html頁面的位置，因為還要和後端程序員合作，他肯定對頁面會有一定修改，這一部分我就不太管他怎麼修改了，我只需保證好html頁面的製作，以及js文件，css文件的引入，我用src做為所有的主目錄就是考慮到和後台合作的原因，所有js、css、庫文件都是單獨的，不會有跟後端有任何交際，刪除掉也是可以的，後期修改也比較方便。
❾ 一名合格的前端工程師的知識結構是怎樣的
入門
在我理解下的基礎知識，就是我們可以寫一些基本的樣式，並能對頁面的元素進行操作。舉例來說，就是我們用Spring和JSP寫了一個博客，然後我們可以用jQuery來對頁面進行一些簡單的操作，並可以調用一些API。因此，我們需要基本的HTML / CSS知識。只是要寫好CSS並不是一件簡單的事，這需要很多實戰經驗。隨後，我們還需要有JavaScript的經驗，要不怎麼做前端呢？ 同時，我們還需要對DOM有一些基礎的了解，才能做一些基本的操作，如修改顏色等等。在這種情況下，最簡單的方案就是使用jQuery這樣的工具。不過，如果可以自己操作DOM是再好不過的了。
中級篇
中級篇就更有意思了，現在我們就需要對頁面進行更復雜的操作。Ajax和JSON這兩個技能是必須的，當我們要動態的改變頁面的元素時，我們就需要從遠程獲取最新的數據結果。並且我們也需要提交表單到伺服器，RESTful就是必須要學會的技能。未來我們還需要Fetch API，ReactiveX這些技能。 除此我們還需要掌握好HTML的語義化，像DIV / CSS這也會必須會的技能，我們應該還會使用模板引擎和SCSS / SASS。而這個層面來說，我們開始使用Node.js來完成前端的構建等等的一系列動作，這時候必須學會使用命令行這類工具。並且，在這時候我們已經開始構建單頁面應用了。
高級篇
JavaScript是一門易上手的語言，也充滿了相當多的糟粕的用法。幾年前人們使用CoffeeScript編成成JavaScript來編寫更好的前端代碼，現在人們有了ES6、TypeScript和WebPack來做這些事。盡管現在瀏覽器支持不完善，但是他們是未來。同樣的還有某些CSS3的特性，其對於某些瀏覽器來說也是不支持的。而這些都是基於語言本來說的，要寫好代碼，我們還需要掌握面向對象編程、函數式編程、MVC / MVVM / MV*這些概念。作為一合格的工程師，我們還需要把握好安全性（如跨域），做好 授權（如HTTP Basic、JWT等等）。
工程化
這個標題好像是放錯了，這部分的內容主要都是自動構建的內容。首先，我們需要有基本的構建工具，無論你是使用gulp、grunt，還是只使用npm，這都不重要。重要的是，你可以自動化的完成構建的工具，編譯、靜態代碼分析（JSLint、CSS Lint、TSLint）、對代碼質量進行分析（如Code Climate，可以幫你檢測出代碼中的Bad Smell）、運行代碼中的測試，並生成測試覆蓋率的報告等等。這一切都需要你有一個自動構建的工作流。
兼容性
雖然我們離兼容IE6的時代已越來越遠了，但是我們仍然有相當多的兼容性工作要做。基本的兼容性測試就是跨瀏覽器的測試，即Chrome，IE，Firefox，Safari等等。除此還有在不同的操作系統上對同一瀏覽器的測試，某些情況下可能表現不一致。如不同操作系統的字體大小，可能會導致一些細微的問題。 而隨著移動設備的流行，我們還需要考慮下不同Android版本下的瀏覽器內核的表現不致，有時候還要一下不成器的Windows Phone。除此，還有同一個瀏覽器的不同版本問題，常見於IE。。
前端特定
除了正常的編碼之外，前端還有一些比較有意思的東西，如CSS3和JavaScript動畫。使用Web字體，可惜這個不太適合漢字使用。還有Icon字體，畢竟這種字體是矢量的。不過Icon字體還有一些問題，如瀏覽器對其的抗鋸齒優化，還有一個痛是你得准備四種不同類型的字體文件。因此，產生了一種東西SVG Sprite，在以前這就是CSS Sprite，只是CSS Sprite不能縮放。最後，我們還需要掌握一些基本的圖形和圖表框架的使用。
軟體工程
這一點上和大部分語言的項目一樣，我們需要使用版本管理軟體，如git、svn，又或者是一些內部的工具。總之你肯定要有一個，而不是 2016.07.31.zip這種文件。然後，你還需要一些依賴管理工具，對於那些使用Webpack、Browserify來將代碼編寫成前端代碼的項目來說，npm還是挺好用的。不過就個人來說，對於傳統的項目來說我總覺得bower有些難用。我們還需要模塊化我們的源碼文件，才能使其他人更容易開始項目。
調試
作為一個工程師來說，調試是必備的技能。大部分瀏覽器都自帶有調試工具，他們都不錯——如果你使用過的話。在調試的過程中，直接用Console就可以輸出值、計算值等等。如果你的項目在構建的過程中有一些問題，你就需要debugger這一行代碼了。 在一些調用遠程API的項目里，我們還需要一些更復雜的工具，即抓包工具。在調試移動設備時，像Wireshark、Charles這一類的工具，就可以讓我們看到是否有一些異常的請求。當然在這個時候，還有一個不錯的工具就是像Chrome自帶的遠程設備調試。對於移動網站來說，還要有Responsive視圖。
測試
我遇到的很多前端工程師都是不寫測試的，於是我便把它單獨地抽了出現。對於一個前端項目來說，正常情況下，我們要有單元測試、功能測試，還有要一些UI測試來驗證頁面間是否可以跳轉。對於依賴於第三方服務的應用來說，還要有一個Mock的服務來方便我們測試。如果是前後端分離的項目，我們還需要有集成測試。
性能與優化
要對Web應用進行性能優化，可能不是一件容易的事，有時候我們還知道哪些地方可以優化。這時候人們就可以使用Yahoo的YSlow，或者我最喜歡的Google PageSpeed來檢測頁面的一些問題，如有沒有開啟GZip、有沒有壓縮、合並、Minify JS代碼等等。 我們還應該藉助於NetWork這一類的工具，查看頁面載入時，一些比較漫的資源文件，並對其進行優化。在一些情況下，我們還需要藉助如Chrome的Timline、Profiel等工具來查看可以優化的地方。
設計
前端工程師還需要具備基本的UI技能。多數情況下拿到的只是一張圖，如果是一個完整的頁面，我們就需要快速分割頁面布局。而依賴於不同的頁面布局，如響應式、網格、FlexBox布局也會有不同的設計。而有些時候，我們就需要自己規劃，製作一個基本的線框圖（Wireframe）等等。
SEO
如果以搜索引擎作為流量來源，我們還需要考慮頁面的內容，除非你用的是競爭排名。像Sitemap可能就不是我們考慮的內容，而我們還要考慮很多點。首先，我們需要保證頁面的內容是對於搜索引擎是可見的，並且對應的頁面還要有基本的Title、Description和Keyword。然後在一些關鍵的字體，如欄目標題等等可以用H2之類的大字的地方就不要放過。同時在頁面設計的過程中，我們還需要考慮一些內部鏈接的建設。
它即可以提供頁面的可見度，又可以提高排名。最後，如果你是面向的是Google等支持結構化數據的搜索引擎，你還需要考慮一下MicroData / MicroFormat這一類東西。
❿ 電商前端架構設計
什麼是前端架構
說到架構，很容易拉出一系列的概念知識點，像系統架構、軟體架構、框架等等，這些不是今天探討的重點，大家可以下去網路來理解。架構的本質是什麼？其實也是一種管理。通常我們所說的管理，都是指對於任務和人員的管理，而架構管的是機器和代碼。比如說，機器的部署屬於運維的物理架構，SOA屬於服務架構，那麼，前端的架構指什麼呢？
長期以來，前端所處的位置是比較偏應用層，很薄的一層，而架構又要求深度和廣度，所以之前在前端裡面做架構，好比在小水塘里游泳，稍微撲騰兩下就到處碰壁。但最近這幾年來，隨著一些列新的技術和概念的出現，前端的范圍被大大拓展了，所以這一層逐漸變得大有可為。
單純從語言的角度來說，html、js、css是最簡單最容易上手的開發語言，不考慮模塊化、工具、壓縮優化，任何人都可以快速上手，完成一兩個功能簡單的頁面。在規模很小的項目中，前端技術要素彼此不會直接產生影響，因此無需架構相關的思考。由於前端語言這種靈活鬆散的特點，使得前端項目規模在達到一定規模後，工程問題凸顯，成為發展瓶頸，原來孤立的技術要素開始彼此產生影響，各種技術要素彼此之間開始出現關聯，要用模塊化開發，就必須對應某個模塊化框架，用這個框架就必須對應某個構建工具，要用這個工具，就必須對應某個包管理工具……這個時候，需要有人從比較高的角度去梳理、尋找適合自己團隊的集成解決方案。而這一系列解決問題的工具和手段就是所謂的前端架構。
架構不等於框架這一點很好理解，相信大家都能夠很深入的說明這里的差別，框架是架構的重要組成部分，架構決定框架的選型，框架決定架構的技術路線。架構圍繞框架進行一系列的流程工具建設，從而形成完善自動的開發體系。
+框架不等於類庫，這里就是很多人困惑的點，你用的什麼框架？jquery、underscore、linq、seajs、requirejs等等，每個人都能夠列舉一大堆。但這個是不準確的，一套編碼框架是有一系列的元素組成：開發模式，我們如何來實現代碼的職責分離。以前整個前端是mvc中v這一層，而現在前端內部也進行了mvc的邏輯細分，Javascript的MVC框架現在很多，有的強化m、有的強化c。每一個框架其實都有其特點的，並且有越來越多的創新改造，比如現在最流行的是mvvm。有angular、react等等。我們是為了引入mvvc才把他們納入到我們的開發體系，而不是因為他是一個好用的類庫。
通訊，模塊化、組件化是前端在推進開發模式過程中的一個過程產物，為了有效的進行組件隔離和獨立，現在有各種各樣的通信模型出來，不過由於實現簡單，代碼少，他往往是合入到某個類庫裡面，但本質也是一個類庫。比較成熟的比如：消息匯流排、事件模擬、緩存中轉、flux模型等等。
模板，我們用什麼樣的方式來集中的處理數據往html的轉換過程，這里就不用多展開，這種類庫現在太多了，光我們公司就有很多套，大家在代碼行、緩存管理、預編譯、運算性能、強大的語法等等各個維度不段追求各種極致。
基礎類庫最後才是傳統類庫，相信現在已經沒有同學會在項目中去約束團隊中的dom操作、常用函數、方法、非同步化等等各種很基礎東西，這個時候我們一般就是引入jq、zepto、underscor這些封裝好的東西就行了。核心就是為了改善編碼生產力。
對於框架的選型要從兩面看，一是看該框架的本領，二是看你們團隊的能耐。從經驗上給幾個點建議：
這里也可以順便展開聊一下現在前端產品的形態分類：
從這些分類裡面，我們這些年派生出了所謂全端和全棧的概念。但本質上怎麼走還是要由所在產品的形態來決定。
內容型Web站點 側重渲染方面的優化，前端邏輯比重小
操作型B/S系統 以數據和邏輯為中心，界面較規整
hybrid內置型，要處理緩存和一些本地介面，包括PC客戶端和移動端。現在的本地應用，基於很多考慮，都變成了混合應用，也就是說，開發這個應用的技術，既包含原生的代碼，也包含了嵌入的HTML5代碼
Web游戲，前端的邏輯非常重，在代碼結構上要求非常高的可管理性和更復雜的設計模式。
桌面應用型，現在有一些PC端的混合應用開發技術，比如node-webkit和hex，前者的典型應用是XDK，後者的典型應用是有道詞典，此外，豌豆莢的PC客戶端也是採用類似技術的，也有一些產品是用的qt-webkit。這類技術可以方便做跨平台，極大減少開發工作量。
大工程應該盡量避開谷歌產品，他的很多技術開源項目都是玩票性質的，GWT、Closure、Darty就是前車之鑒。曾今提出過很多的新技術，到現在還是獨家的，變出太大。包括現在angular，喜歡做斷崖式升級，做做運營後台系統問題不大，如果是線上系統的話，每次升級就是一次人月神話中的典型焦油坑。
關注應用場景，像剛才說到的boss後台是一種；另外我的平台是否有沉重的歷史包袱，需要兼容ie6，還是可以輕裝上陣；產品對於seo是什麼樣的態度？是否需要考慮自適應？或者我的團隊足夠大，能夠各搞一套？；產品特徵是強內容還是強交互或者是游戲性。這些都是選擇不同框架的主要出發點。
沒有最好，只有最適合自己的，基本上，針對每個平台，我們都可以列出一些主流框架，但不意味著你們都能駕馭得住。小馬過馬，老牛沒過膝，松鼠淹個半死，就是這么回事。但無論我們選擇什麼框架或決定自己動手造輪子，都勿忘初心，技術必須讓我們工作生活更為輕松愉快——我們只選擇我們能駕馭住的框架，我們不能保證它在一年後是否會過時落後。
而且按照我個人這么多年的經驗來看，任何框架都會過時，往往不是因為他不夠好，而是因為一定有更好的出來。我們再選擇一個框架或者一個類庫的時候就要想好，未來我如何拋棄他。至少不能成為我們引入新的框架的絆腳石。現實的工作中很多的團隊往往會陷入到年復一年的用今年的新框架去重構去年老框架代碼的歷史循環中去。對於引入框架如何盡量延長他的生命力，我個人的意見是選擇框架時去追求概念，而不是潮流，當我的架構可以接受新的設計概念的時候才去考慮引入新的框架。用設計理念的選擇代替框架的選擇。之所以這么說是因為我觀察到我們部門的後端架構的開發理念跟我進公司的時候是差不多的。更多你可以參考成都網站建設
架構的組成
組件框架