很高興回答你的問題!
幾年前,還是癡迷java的那會兒,我也曾糾結于前端框架的選擇。試圖找出一套一勞永逸的前端框架繼承到項目架構中。搜遍全網得出以下結論:
各大前端框架可以按照“封裝度”的標準來區分。
設計剛出的一套網頁皮膚,封裝度為0。層層封裝到可以直接用后臺語言寫頁面,封裝度為10。那么我是這樣來區分前端框架的。
1級——純html+css
放5年前,基本就是用Dreamweaver剛排出來的頁面或者網頁查看源代碼扒下來的皮膚。不涉及到js,就是純頁面皮膚。
--------------------------------
2級—— bootstrap系列
bootstrap的出現是一個里程碑事件。發源于twitter,引入了不少html5/css3的特性。由于它對響應式的支持以及良好的體驗,給人一種耳目一新的感覺。其源碼,不管是css還是js都值得學習一下,看后經常會有“原來還可以這樣做”這種恍然大悟的感覺。不過歸根結底是一套ui皮膚+少量js組成的框架,屬于封裝度偏低的框架。經典頁面大概是這樣:
--------------------------------
3~4級—— metronic/adminLTE系列
基于bootstrap或者其他1級框架,然后集成了各種jQuery插件、富文本編輯器等js庫,組成的一個大雜燴工具包和案例庫。皮膚基本是基于bootstrap自定義的一套主題。案例比較詳盡,開發的時候找到需要的組件把前端代碼復制粘貼,再稍微調試一下就能達到良好的視覺效果。根據集成的第三方庫的多少,基本可以劃分到3~4級封裝度這樣的范圍。這個級別的框架的代碼更多的是屬于粘合劑,將各種不同的第三方庫的前端代碼粘合起來。
--------------------------------
3~4級—— metronic/adminLTE系列
基于bootstrap或者其他1級框架,然后集成了各種jQuery插件、富文本編輯器等js庫,組成的一個大雜燴工具包和案例庫。皮膚基本是基于bootstrap自定義的一套主題。案例比較詳盡,開發的時候找到需要的組件把前端代碼復制粘貼,再稍微調試一下就能達到良好的視覺效果。根據集成的第三方庫的多少,基本可以劃分到3~4級封裝度這樣的范圍。這個級別的框架的代碼更多的是屬于粘合劑,將各種不同的第三方庫的前端代碼粘合起來。
-------------------------------
5級—— jQuery-ui
這里要單獨把jQuery-ui拿出來講,并不是因為它的封裝度有多高,而是我認為它是一個分界點。jQuery以下級別的框架,代碼以css為主,自身的js代碼少,框架量級更輕,更靈活,更適合互聯網web產品。jQuery以上級別的框架,屬于前端的重度封裝,通過框架暴露的接口進行開發,開發人員甚至不需要太多前端知識,只需要詳細查看框架的開發文檔即可。jQuery以上級別的框架更適合傳統管理軟件的開發。
--------------------------------
6~7級—— easy-ui/DWZ
easy-ui基于jQuery-ui,不過具有更豐富的組件庫。貌似商業版收費很高。聽說某大型國企花了大價錢購買下來使用。DWZ是國產框架中我認為綜合表現還不錯的,完全免費,有問題可以在他們的QQ群里提。其余的之前還用過金蝶的operamasks-ui,不過現在好像已經不更新了。這一類級別的框架還有一個另外的稱呼——“富客戶端框架”,意思就是重度js框架。使用起來開發效率很高,當年也是一度百花齊放,框架輩出。
8級—— extjs系列
extjs屬于前端框架領域中的龐然大物,封裝程度很高,具有自成體系的元素選擇引擎和瀏覽器兼容方案,js寫法上也有自己的方式。組件很多很全。只看extjs的官方文檔和示例幾乎不必學習任何其他的前端知識就可以做出“很漂亮”的前端頁面。當然頁面很容易“撞衫”。使用時間長了,會對其產生嚴重依賴,離開extjs,幾乎不會寫前端頁面了。
-------------------------------
9級——vaadin/GWT
最后一級,也是封裝度最高的一級,也就是所謂的使用后臺語言寫前端。如果說之前的八級至少前端和后端還是相對分離的,后臺程序在java中寫,前臺程序在html或者js中寫;那么這一級別的框架簡直會顛覆你的認知!只需在后臺使用java寫好了類和對象,并設置好相關的屬性,網頁的元素是自動通過后臺對象生成的。這當然有好處,媽媽再也不用擔心我不會寫js和css了。然而就學一下html/css/js真的那么難嗎?個人認為,盡管GWT有google的這么強悍的背書,但是這種9級封裝的本質上把前后臺耦合得更緊密。一個人做一個項目還可以考慮,但是一個團隊前后臺分離、模塊化開發的時候,使用這種框架是一種災難!所以我是極度不建議使用9級封裝框架的。
--------------------------------
綜上,針對不同的編程方式,給出以下參考:
1 DOP(Deadline Oriented Program,面向截止日期編程)的程序猿們有兩種選擇:a、努力學習html/css/js,使用2~3級框架;b、看不上前端代碼的,6~8級是不錯的選擇。對于業務優先、老板整天嚷嚷時間有多緊、客戶有多急切的項目,你可以直接選b了,我覺得老板是不會給你時間學習html/css/js的。
2 EOP(Experience Oriented Program,面向用戶體驗編程)的程序猿們,大多數做的是追求極致用戶體驗的互聯網產品吧。那果斷選1級封裝度的框架,可適當借鑒2~4級的框架。
3 MOP(Money Oriented Program,面向人民幣編程)對于一直做后臺,趁過年放假想賺個外快的程序猿們,我知道你們也不想在前端領域有多大發展,搞好后臺就足夠一輩子衣食無憂了,所以還是選擇6~8級吧。
此外,需要考慮搜索引擎優化的項目,慎用富客戶端或者重ajax應用。
什么?你還需要考慮ie6的兼容性?出門左轉有一面墻,你可以撞上去了,不送!
最后告訴大家,這些都是幾年前我為了治療自己的選擇恐懼癥而進行的一些分析。
現在,我已經不再糾結各種前端框架了。
因為心中有劍,枝葉、落花皆可為劍。
----------------------------------------
有朋友提到backbonejs/angularjs/reactjs/vuejs這些新興框架,感覺很有必要補充完善一下這個答案。
大約五六年前,前端還是一個邊緣崗位,前端的工作中:css方面的由設計師用dreamveaver等工具順帶就做了;js方面的由后臺程序員寫寫實現了效果就行了。
究其原因,主要還是由于當時在html5尚未大面積支持的情況下,瀏覽器網頁端的表現力有限。為增強表現力甚至還需要依靠flash的支持。近幾年隨著移動端的興起以及html5/css3等技術的推廣,web端表現力日漸豐富,也越來越復雜。
計算機這門學科就是這樣,當一件事物復雜到一定程度就一定有人抽象出各種框架來提高可維護性與可擴展性。
傳輸復雜了,有了osi 7層和5層框架;服務器集群復雜了,有了云計算各種框架;乃至銷售問題復雜了,也有人總結出《銷售技巧xx招》…這種抽象也是人類的一種基本思維方式。
前端崗位正是在網頁前端復雜性逐漸增加的推動下產生的。說實話,很多老程序員以前是是看不上前端行業的,認為無非是一些奇巧淫技而已。而現在,以javascript為基礎的前端技術已經成功逆襲,nodejs的發展更是讓js有了揚眉吐氣的一天。
現在回過頭來看backbonejs/angularjs/reactjs/vuejs系列框架,它們其實并不是給后臺程序員準備的框架。不要輕信它們官網上的提到的“簡單易用快速上手”之類的宣傳語,那不是跟后臺程序員和js初學者說的。如果你對js原型鏈、作用域、異步回調的概念還很模糊,用了這些框架只會讓自己陷入泥潭難以自拔!
雖然你也可以將這些框架簡單粗暴得劃分到7級封裝度左右,但是我并不認為這些“深度前端”框架適合后臺開發者。
當然啦,事無絕對,如果你像我一樣興趣廣泛,喜歡折騰,前后端雙修,那你自然清楚該選什么前端框架,也就不會到知乎上來問這個問題了。
這就是現在的我,有了一定的前端功力,開源社區的森林里那么多豐富的資源,枝葉、落花都是利刃,也無需在框架上糾結了。
我是程序Cow,希望可以幫到你,喜歡我的可以關注一下噢![耶]
前端工具 dw notepad++ hbuilder webstrom后端工具 eclipse myeclipse
技術 :vue uniapp react java springboot等
前端:
前端主要是UI設計,以及根據UI設計圖轉換為Android、iOS上能夠實際跑起來的app,當然這時候沒有任何的業務流程業務邏輯,最多是簡單的點了個按鈕從這個界面跳到那個界面。
后端:
后端可以理解為一個app的保障或者數據支撐。給前端展示提供實際的數據。開發語言很多,php,java,nodejs,.NET等等都可以,一般app的后端會提供RESTFUL接口供前端調用
前端后端結合:
以上都可以理解為獨立的工作,前端做前端的工作,后端做后端的工作,到了結合這一步上邊就要有很多的交流和溝通了。舉個栗子,比如新聞類app:
前端首先需要通過http方式調用后端的接口,拿到我需要展現的新聞列表數據,然后顯示出來。
當我點擊某個新聞想查看詳細的時候,同樣需要調用后端提供的接口,拿到新聞詳細的數據。
當然有時候前端需要傳遞一些數據給后端保存,不如用戶注冊,前端吧用戶輸入的用戶名密碼等信息通過接口給后端,后端處理用戶注冊邏輯完成注冊,下次用戶用這個賬號登錄同樣傳用戶名密碼給后端,后端通過傳來的數據進行判斷邏輯,吧結果返回給前端,然后前端根據結果提現是用戶。
簡單的說前端是一個外衣,是跟用戶最直接直觀的交互和展示,后端是處理前端應該展示什么樣的數據給用戶,或則給前端提供展示什么的一個依據。