幾個Web前端開發(fā)框架的比較

原文在我的博客中，歡迎大家來訪交流

強調(diào)一下，這篇日志主要還是針對想學(xué)前端開發(fā)的新朋友寫的，不是說我有什么獨特見解，而是比較客觀的狀態(tài)，就各種框架的異同和應(yīng)用場合，需要注意的地方做簡單描述，不做具體深入分析，有的地方比較抽象，對于抽象之處大家可以到網(wǎng)上或各大高手博客中深入學(xué)習(xí)，當(dāng)然也可以與我繼續(xù)探討。

一直以來對Web前端開發(fā)興趣頗深，用過一些框架產(chǎn)品。在JavaEye上看到一些剛接觸前端開發(fā)朋友的疑問，猶豫這些產(chǎn)品的前景利弊，不知從何入手。想把自己的一點經(jīng)驗分享給大家，如有不到位之處請一起來糾正。

jQuery

1.絕對的萬金油，核心js只有50K，占用帶寬小，門戶網(wǎng)站、管理系統(tǒng)，用在哪都可以。2.jQuery是對js底層dom操作封裝最薄的一個框架，沒有大量的專有對象，多為提供函數(shù)進行dom操作。準確的說，它不是偏重于富客戶端的框架，而是側(cè)重于對jsdom編程。下面幾種才是完整的富客戶端的框架。

3.我認為它最大的三個亮點，一是支持CSS3的大量選擇符，想定位或選擇一個html元素簡直輕而易舉。二是靈活便捷的Ajax請求和回調(diào)操作。三是事件綁定功能，內(nèi)部封裝了很多事件，想統(tǒng)一為一個頁面上的一些元素添加事件很方便，這也提高了復(fù)用性和可維護性，避免了頁面中出現(xiàn)大量的html屬性。合理的編碼可以使html與js,css分離開，便于維護。4.此外它也封裝了很多常用的操作，例如節(jié)點的添加刪除、常用的動畫效果、邏輯判斷比較等等。避免了直接使用domapi進行繁瑣的操作。

5.本身提供了可擴展的函數(shù)，可以自己編寫插件與核心jQuery對象進行集成使用。這也是常用的手段，只要你理解js面向?qū)ο缶幊�，熟悉jQueryAPI，就能寫出很多定制的插件，復(fù)用在各種地方。

6.至于jQueryUI，與其他框架不一樣的地方在于，它很少用js去生成html，而是把現(xiàn)有的html通過jQueryUI的API加工成想要的效果，關(guān)于這點是好是壞，我覺得就是見仁見智的問題了，沒有必要爭論什么。7.新生的jQueryEasyUI不錯。

8.如果今后的更新都保持現(xiàn)在這種模式，我認為它的前景很樂觀，什么時候javascript完蛋了才輪到它玩完。

ExtJS

1.一整套帶有UI的js庫，封裝得很多，很厚，核心js就600多K，這么大的東西門戶網(wǎng)站當(dāng)然就別想了，里面的效果當(dāng)然也不會運用到門戶網(wǎng)站，所以它是專門為管理系統(tǒng)而生的。因為局域網(wǎng)不會有帶寬問題。

2.它與jQuery不同，基本上是純用js來生成html的，頁面里只需引入各個ExtJS庫和你自己寫的js，不會出現(xiàn)很多html內(nèi)容，body里基本沒什么。所以優(yōu)化就顯得重要了，不然會嚴重浪費資源。

3.UI就不說了，大家都認可，本來就是為UI而生，它可以做出來桌面級程序的效果。一般來說，一個管理系統(tǒng)的項目如果用Ext，基本就從始至終都是Ext做了，不會像jQuery那樣，哪想要了就加在哪，很隨意。Ext更像一個整體(雖然它也可以拆開用，不過麻煩，不建議)。4.提供了對其他js框架的適配，像對jQuery,prototype等。沒實際應(yīng)用過，就不說了。5.理解js面向?qū)ο缶幊淘趀xt中很重要，如果你覺得用jQuery時了解簡單的dom和css即可，那你在這就吃大虧了，Ext處處離不開對象的概念。

6.Ext的UI開發(fā)類似C#，有很多控件。不同的是，你要全部自己手寫，所以開發(fā)量較大�，F(xiàn)在雖然有ExtDesigner可視化工具，但其效果并不很好，生成的代碼有的往往不是想要的，不易維護，真做起來還是自己寫更方便。

7.團隊開發(fā)時，必須保證做UI的人每人都會Ext，而且深入應(yīng)用過，因為Ext項目是整體，不適于參雜html替代。

8.Ext項目在IE系列瀏覽器上不可用，相當(dāng)卡，我想這不是Ext本身的問題，所謂內(nèi)存泄露等問題現(xiàn)在早已解決了，而且不是關(guān)鍵所在。我開很多網(wǎng)頁同時用IE8看jQuery.net官網(wǎng)時有時也會卡，試想他們官網(wǎng)肯定做到很好的優(yōu)化了吧，jQuery既是如此，何況Ext。反觀其他瀏覽器，F(xiàn)ireFox,Chrome等瀏覽Ext項目都很流暢，所以應(yīng)該是瀏覽器對js解析不同造成的。

9.版權(quán)問題，Ext運用在商業(yè)項目中是收費的。

Flex[自己也是在學(xué)習(xí)中，不敢妄言，以后深入應(yīng)用后再做補充]

1.Adobe平臺的，基于ActionScript實現(xiàn)，用在哪都行，但偏重于內(nèi)網(wǎng)管理系統(tǒng)，用在門戶網(wǎng)站就相當(dāng)于在線玩Flash游戲，loading...

2.與Ext不同，它有健壯的可視化開發(fā)工具FlashBuilder，可以同C#一樣進行拖拽布局，生成一種xml，也便于維護。

3.編譯后生成swf文件直接嵌入html即可，提高安全性，瀏覽時同flash，需要flashplayer。4.與Ext相同，也是屬于一個整體，有豐富的控件庫。

5.這條純屬個人觀點，HTML5不支持插入對象，也就意味著不能插入swf文件，難道Flex就完蛋了？雖然HTML5不支持Flash是客觀事實，但HTML5的統(tǒng)一為時尚遠，各大瀏覽器對HTML5的支持，Adobe是否會有對策，這些會怎么樣現(xiàn)在都不好說，HTML5與HTML4并行應(yīng)該會有很長一段時間，至少Flex在現(xiàn)在是一個名列前茅的好產(chǎn)品，所以我選擇了它。

SilverLight

微軟平臺的，主要是應(yīng)用在微軟系列的語言中，包括CS與BS架構(gòu)。同樣，除了jQuery，Asp.net也不適合與以上等框架集成，因為Asp.net是事件驅(qū)動，這些框架都是為消息驅(qū)動而生的，勉強應(yīng)用只會事倍功半，喪失.net本身的優(yōu)勢。

js面向?qū)ο缶幊涛乙恢痹谔�，其實并不難理解，關(guān)于這點應(yīng)該學(xué)習(xí)下，很有必要。它涉及到代碼復(fù)用、功能擴展、對象繼承、閉包、優(yōu)化等很多問題，能省去不少編碼，便于維護，還能不改變框架源代碼而實現(xiàn)不同的功能。

閑話不多說了，希望能給剛走進前端開發(fā)的朋友一點幫助。以后可能還會就js面向?qū)ο缶幊淘賹懸黄�日志，有興趣可以來看看。我的QQ是421557193，有興趣可以與我交流，請注明是IT同行。

擴展閱讀：Web開發(fā)框架安全雜談

Web開發(fā)框架安全雜談

Writebyadminin未分類at201*-03-1522:21:03Web開發(fā)框架安全雜談EMail:wofeiwo#80sec.comSite:Date:201*-03-14

From:[目錄]0×00起0×01承0×02轉(zhuǎn)0×03合0×00起

最近框架漏洞頻發(fā)，struts任意代碼執(zhí)行、Djangocsrftoken防御繞過、Cakephp代碼執(zhí)行等等各大語言編程框架都相繼暴出高危漏洞，這說明對于編程框架的安全問題已經(jīng)逐漸走入安全工作者的視線。Web開發(fā)框架就相當(dāng)于web應(yīng)用程序的操作系統(tǒng)，他決定了一個應(yīng)用程序的模型結(jié)構(gòu)和編程風(fēng)格�？蚣苌铣隽寺┒矗�就如同當(dāng)年一個rpc遠程EXP就走遍全世界windows的時代。

然而挖掘深層原因，從應(yīng)用的模型和架構(gòu)上考慮問題，其實這些框架漏洞都不只是一種偶然，而是一種必然。正是因為框架的模型結(jié)構(gòu)，正因為他們的這種編程風(fēng)格，才極大的增加了漏洞產(chǎn)生的可能性。0×01承

現(xiàn)代編程框架的幾個大特點：

1、將程序代碼分為不同層次，業(yè)務(wù)開發(fā)、前端開發(fā)、數(shù)據(jù)庫開發(fā)人員各司其職，框架根據(jù)需要組裝代碼、調(diào)度執(zhí)行

2、統(tǒng)一化自動化邏輯處理

3、常見功能的代碼庫封裝并高度重用

4、腳手架功能，常見代碼組件自動組裝生成。如默認用戶系統(tǒng)、默認后臺。然而就是以上幾點廣受好評的功能導(dǎo)致了安全薄弱點的產(chǎn)生。1、代碼調(diào)度

讓我們來先回顧一下WEB應(yīng)用框架所最常見的MVC模型。

用戶發(fā)送一個HTTP請求過來，框架的入口點（一般是route，路由）分析用戶請求的url。然后依照url中蘊含的信息分析出用戶所要訪問的controller、action，從而分發(fā)給相應(yīng)的controller文件中的action函數(shù)，執(zhí)行之；隨后controller再將model中的數(shù)據(jù)結(jié)合用戶輸入數(shù)據(jù)依照view層中的代碼邏輯填充模板，最后view、controller執(zhí)行完畢，返回用戶最后的HTML。整個生命周期是這樣的：

用戶請求url->route分發(fā)->controller接管處理用戶輸入及業(yè)務(wù)邏輯->view層代碼執(zhí)行->controller返回展現(xiàn)結(jié)果

從上面的流程發(fā)現(xiàn)了什么？

MVC模型就是一個將程序員分散在M、C、V中的代碼尋找并整合在一起執(zhí)行的過程。那這必然就要牽涉到一個代碼調(diào)度執(zhí)行的問題。這里route就是一個非常明顯的例子。一個框架這么多代碼文件，route每一次調(diào)用controller，都需要根據(jù)用戶輸入的url進行匹配并執(zhí)行用戶指定的函數(shù)。這里就是一個薄弱點，一個必然繞不過去的問題。

對應(yīng)到現(xiàn)實的例子，一個非常明顯的例子就是：struts2框架的動態(tài)方法調(diào)用（DMI）

當(dāng)你訪問!test.action時，struts會根據(jù)你的url幫你映射到名為a的controller中名為test的Action方法。而通過修改test的值，我們可以訪問a這個類中的所有方法。如果恰好這個方法中含有敏感的信息，攻擊者就獲得了一切。結(jié)合其他技巧，攻擊者能夠做到的更多。但這就是框架的功能，框架總是要依靠URL中的內(nèi)容去匹配執(zhí)行程序代碼。

那么對于PHP的框架呢？仔細想一下，如果PHP需要做分散在不同文件中的代碼調(diào)度執(zhí)行，唯一能夠?qū)崿F(xiàn)的方式就是使用require/include函數(shù)包含文件。文件名來源于哪里？來源于用戶輸入的URL。實際上目前市面上的大部分PHP框架也都是這么實現(xiàn)的，Yii，F(xiàn)leaPHP等等。如果對用戶的輸入沒有做好驗證，就很容易導(dǎo)致一個本地文件包含漏洞。筆者曾經(jīng)就在某不知名框架中發(fā)現(xiàn)過這樣的漏洞，在不涉及應(yīng)用程序邏輯的情況下，直接獲取了系統(tǒng)權(quán)限。2、統(tǒng)一化邏輯處理

框架的一大功能就是，通過統(tǒng)一的入口點，可以做一些統(tǒng)一的安全防護、邏輯控制。在軟件工程學(xué)里的說法，這個叫“面向切面編程”（AOP）。

然而我們并不是說這樣的統(tǒng)一控制模式不好，但對于這樣的統(tǒng)一控制，如果框架設(shè)計或?qū)崿F(xiàn)的不好，就能直接淪陷所有跑在之上的應(yīng)用。

這里有一個典型的統(tǒng)一處理導(dǎo)致安全問題的極端的例子：struts2任意代碼執(zhí)行漏洞。

漏洞起因是struts2希望能讓用戶提交的值能夠直接注入到程序中的數(shù)據(jù)對象，而無需手動類型轉(zhuǎn)換并給內(nèi)部變量賦值等操作。為此struts2專門設(shè)計了一個叫做ognl的表達式。通過它，用戶提交的參數(shù)就能被自動解析為程序上下文中所存在的變量。

想想為什么能夠自動解析？原因是用戶提交的參數(shù)被當(dāng)作自定義語言的代碼被解析執(zhí)行了！只是你并沒有意識到這一點而已。于是有心人研究了一下，發(fā)現(xiàn)ognl表達式除了參數(shù)值注入，還能通過它直接調(diào)用Java自身的API。于是，一個巨大的通殺0day就這么誕生了。

回想一下，如果struts2沒有這么“智能”的自動化、統(tǒng)一化用戶輸入處理機制，也就不會出現(xiàn)上述的大漏洞了。

前段時間爆出的Django的csrftoken繞過漏洞也是在統(tǒng)一安全處理的設(shè)計上出的問題。深究一下，為什么會出現(xiàn)這樣的繞過問題？原因就是，框架必須要對所有用戶的提交在真正的應(yīng)用執(zhí)行前做統(tǒng)一的csrf防范，于是django框架產(chǎn)生的token是保存在cookie中的（老版本和sessionid有關(guān)，這個也是保存在cookie中）。對于用戶提交的POST請求，表單中增加一項token，框架在獲得token值后，與cookie中的正確token值比對，如果相等就通過。然而對于ajax的請求，框架設(shè)計者卻想當(dāng)然的認為只要判斷X-Requested-With這個Ajax特有的HTTP頭即可，根本無需運算比對token。所以，框架對于http頭中包含有X-Requested-With域的請求放行。通常情況下，只有ajax的請求瀏覽器才會帶上此自定義域，且瀏覽器一般無法自定義此字段。

結(jié)果被人發(fā)現(xiàn)可以利用flash+307跳轉(zhuǎn)可以偽造自定義http頭，結(jié)果就繞過了此防范，導(dǎo)致統(tǒng)一的csrf防護毫無作用。如果應(yīng)用程序完全依靠框架的統(tǒng)一安全實現(xiàn)，就會受到安全漏洞的威脅。

其實Django也很無奈，在它的架構(gòu)設(shè)計中，它通過這個自定義頭判斷ajax思路上也沒有什么問題�？上г谀壳斑B黃瓜都不可靠的年代，就沒什么是可靠的了。3、常見代碼高度封裝

代碼的高度封裝，對外只暴露幾個接口，一行說明書。這必然造成一種現(xiàn)象：普通程序員就像是在搭建一個模型，只要按照說明書組建積木就可以了，不需要知曉其原理，不需要知道為什么要這樣做。于是這時候就安全問題就產(chǎn)生了。

舉一個同樣在用戶輸入?yún)��?shù)自動化處理方面的例子：在PHP的ZendFramework中，獲取用戶輸入是調(diào)用getParam方法，而不是常見PHP程序中分開來的$_GET、$_POST等變量。那么，如果同時在GET、POST、COOKIE、HEADER中提交相同名字的參數(shù)，getParam到底獲取的是哪一個的值？先后順序是什么？如果前后可以覆蓋，會不會影響到我們自定義的一些統(tǒng)一安全措施？這是一個值得檢查的安全薄弱點。

再舉一個struts2的例子：對于常見的文件上傳場景，struts提供了一個FileUploadInterceptor攔截器，直接可以在應(yīng)用邏輯運行前對用戶上傳文件進行檢查。然而在筆者的代碼審計經(jīng)驗中，常常發(fā)現(xiàn)程序員只對maximumSize（文件大小）和allowedTypes（文件mime-type）進行限制，卻放過了最關(guān)鍵的allowedExtensions（擴展名）限制。為什么？筆者檢查了一下官方文檔，發(fā)現(xiàn)在struts2.2之前的文檔，都沒有給出allowExtensions的說明�；蛟Sstruts開發(fā)者想當(dāng)然的認為allowedTypes就可以限制上傳文件的類型，殊不知只要偽造HTTP包中的mime-type字段，就可以直接上傳任意文件。于是開發(fā)者也就依照官方的例子，只限制了allowdTypes，從而導(dǎo)致安全問題的產(chǎn)生。

高度代碼封裝的確解決了“重復(fù)造輪子”的問題，但是它解決不了程序員的安全意識和懶惰的習(xí)慣。或許它設(shè)計的很好，或許它實現(xiàn)的也很好，但是只要它組裝的不好，就有可能造成問題。4、腳手架功能

Django的腳手架功能是非常好用的。它默認自帶了一些app，只要通過幾個簡單的命令或配置，就可以在不敲一句代碼的情況下搭起一個普通網(wǎng)站的腳手架，自帶了用戶注冊、登陸等系統(tǒng)，甚至還有一個默認的管理員后臺。

然而正如上文所說，普通程序員并不了解框架真正做了些什么。他很有可能通過腳手架生成網(wǎng)站后，卻直接忘卻了程序自帶的內(nèi)容沒有去除。當(dāng)這樣的網(wǎng)站上線后。我們發(fā)現(xiàn)他是Django所寫，那我們就可以直接嘗試在url后加入/admin/路徑訪問，直接猜解后臺管理員密碼。此外如果框架自帶的默認后臺出現(xiàn)安全漏洞，甚至可能直接繞過進入后臺。

一旦使用框架默認的組件，就得考慮到框架所帶來的默認功能的安全問題。其實這問題可以擴大，tomcat自帶的后臺、fck編輯器自帶的上傳組件，都可以說屬于此類問題。0×02轉(zhuǎn)

框架的應(yīng)用是軟件開發(fā)的必然趨勢，本文的目的也不在于抵制框架的使用。但對于框架應(yīng)用后所帶來的新安全問題，安全從業(yè)人員需要提高重視，緊跟技術(shù)發(fā)展，更新知識。對于此，我們能夠做點什么？1、對于常見的應(yīng)用場景，如文件操作、命令行操作、數(shù)據(jù)庫操作、用戶權(quán)限及認證等，我們需要了解框架的實現(xiàn)，給出相應(yīng)的安全編碼范例。

框架文檔中給出的例子并不一定就是最好的。安全工作者必須對程序員進行安全意識的培訓(xùn)，讓他知道如何利用框架的API去安全的組合出常用功能。2、對于應(yīng)用漏洞挖掘，我們需要擴充字典。

框架的封裝，可能引入更多的危險API或危險特性。在代碼審計的過程中，需要將這些內(nèi)容加入到危險詞字典中。

3、對于應(yīng)用漏洞挖掘，由于框架結(jié)構(gòu)所帶入的新的安全薄弱點，需要專門對框架的設(shè)計及實現(xiàn)做檢查，是否存在問題。

例如PHP框架中代碼調(diào)度執(zhí)行的實現(xiàn)、文件上傳統(tǒng)一檢查的實現(xiàn)、封裝的變量獲取形式是否可靠等。本文中提到的安全薄弱點只是一個例子，更多的還需要大家的共同挖掘。0×03合

實際上對于一個應(yīng)用的安全審計歸根到底就是個思路問題。筆者一直認為，了解程序員的思路，了解框架的思路，了解應(yīng)用的思路，這些才是安全審計中最花時間的。而實際上真槍實彈看代碼的漏洞挖掘卻只占用很小的一部分時間。

只有將這些思路融會貫通，在腦中將審計對象進行抽象建模，了解應(yīng)用需要保護什么，弱點在哪里，才能更為有效和有針對性的進行代碼審計、安全防護。

最后，非常感謝劍心及空虛浪子心之前的研究成果和意見，對本文的幫助極大

友情提示：本文中關(guān)于《幾個Web前端開發(fā)框架的比較》給出的范例僅供您參考拓展思維使用，幾個Web前端開發(fā)框架的比較：該篇文章建議您自主創(chuàng)作。

來源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問題，請聯(lián)系我們及時刪除。

《幾個Web前端開發(fā)框架的比較》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請保留原作者信息,謝謝!
鏈接地址：http://m.seogis.com/gongwen/585518.html

• 上一篇：網(wǎng)頁設(shè)計項目實訓(xùn)指導(dǎo)書
• 下一篇：web前端性能