几个Web前端开发框架的比较
原文在我的博客中，欢迎大家来访交流
强调一下，这篇日志主要还是针对想学前端开发的新朋友写的，不是说我有什么独特见解，而是比较客观的状态，就各种框架的异同和应用场合，需要注意的地方做简单描述，不做具体深入分析，有的地方比较抽象，对于抽象之处大家可以到网上或各大高手博客中深入学习，当然也可以与我继续探讨。
一直以来对Web前端开发兴趣颇深，用过一些框架产品。在JavaEye上看到一些刚接触前端开发朋友的疑问，犹豫这些产品的前景利弊，不知从何入手。想把自己的一点经验分享给大家，如有不到位之处请一起来纠正。
jQuery
1.绝对的万金油，核心js只有50K，占用带宽小，门户网站、管理系统，用在哪都可以。2.jQuery是对js底层dom操作封装最薄的一个框架，没有大量的专有对象，多为提供函数进行dom操作。准确的说，它不是偏重于富客户端的框架，而是侧重于对jsdom编程。下面几种才是完整的富客户端的框架。
3.我认为它最大的三个亮点，一是支持CSS3的大量选择符，想定位或选择一个html元素简直轻而易举。二是灵活便捷的Ajax请求和回调操作。三是事件绑定功能，内部封装了很多事件，想统一为一个页面上的一些元素添加事件很方便，这也提高了复用性和可维护性，避免了页面中出现大量的html属性。合理的编码可以使html与js,css分离开，便于维护。4.此外它也封装了很多常用的操作，例如节点的添加删除、常用的动画效果、逻辑判断比较等等。避免了直接使用domapi进行繁琐的操作。
5.本身提供了可扩展的函数，可以自己编写插件与核心jQuery对象进行集成使用。这也是常用的手段，只要你理解js面向对象编程，熟悉jQueryAPI，就能写出很多定制的插件，复用在各种地方。
6.至于jQueryUI，与其他框架不一样的地方在于，它很少用js去生成html，而是把现有的html通过jQueryUI的API加工成想要的效果，关于这点是好是坏，我觉得就是见仁见智的问题了，没有必要争论什么。7.新生的jQueryEasyUI不错。
8.如果今后的更新都保持现在这种模式，我认为它的前景很乐观，什么时候javascript完蛋了才轮到它玩完。
ExtJS
1.一整套带有UI的js库，封装得很多，很厚，核心js就600多K，这么大的东西门户网站当然就别想了，里面的效果当然也不会运用到门户网站，所以它是专门为管理系统而生的。因为局域网不会有带宽问题。
2.它与jQuery不同，基本上是纯用js来生成html的，页面里只需引入各个ExtJS库和你自己写的js，不会出现很多html内容，body里基本没什么。所以优化就显得重要了，不然会严重浪费资源。
3.UI就不说了，大家都认可，本来就是为UI而生，它可以做出来桌面级程序的效果。一般来说，一个管理系统的项目如果用Ext，基本就从始至终都是Ext做了，不会像jQuery那样，哪想要了就加在哪，很随意。Ext更像一个整体(虽然它也可以拆开用，不过麻烦，不建议)。4.提供了对其他js框架的适配，像对jQuery,prototype等。没实际应用过，就不说了。5.理解js面向对象编程在ext中很重要，如果你觉得用jQuery时了解简单的dom和css即可，那你在这就吃大亏了，Ext处处离不开对象的概念。
6.Ext的UI开发类似C#，有很多控件。不同的是，你要全部自己手写，所以开发量较大。现在虽然有ExtDesigner可视化工具，但其效果并不很好，生成的代码有的往往不是想要的，不易维护，真做起来还是自己写更方便。
7.团队开发时，必须保证做UI的人每人都会Ext，而且深入应用过，因为Ext项目是整体，不适于参杂html替代。
8.Ext项目在IE系列浏览器上不可用，相当卡，我想这不是Ext本身的问题，所谓内存泄露等问题现在早已解决了，而且不是关键所在。我开很多网页同时用IE8看jQuery.net官网时有时也会卡，试想他们官网肯定做到很好的优化了吧，jQuery既是如此，何况Ext。反观其他浏览器，FireFox,Chrome等浏览Ext项目都很流畅，所以应该是浏览器对js解析不同造成的。
9.版权问题，Ext运用在商业项目中是收费的。
Flex[自己也是在学习中，不敢妄言，以后深入应用后再做补充]
1.Adobe平台的，基于ActionScript实现，用在哪都行，但偏重于内网管理系统，用在门户网站就相当于在线玩Flash游戏，loading...
2.与Ext不同，它有健壮的可视化开发工具FlashBuilder，可以同C#一样进行拖拽布局，生成一种xml，也便于维护。
3.编译后生成swf文件直接嵌入html即可，提高安全性，浏览时同flash，需要flashplayer。4.与Ext相同，也是属于一个整体，有丰富的控件库。
5.这条纯属个人观点，HTML5不支持插入对象，也就意味着不能插入swf文件，难道Flex就完蛋了？虽然HTML5不支持Flash是客观事实，但HTML5的统一为时尚远，各大浏览器对HTML5的支持，Adobe是否会有对策，这些会怎么样现在都不好说，HTML5与HTML4并行应该会有很长一段时间，至少Flex在现在是一个名列前茅的好产品，所以我选择了它。
SilverLight
微软平台的，主要是应用在微软系列的语言中，包括CS与BS架构。同样，除了jQuery，Asp.net也不适合与以上等框架集成，因为Asp.net是事件驱动，这些框架都是为消息驱动而生的，勉强应用只会事倍功半，丧失.net本身的优势。
js面向对象编程我一直在提，其实并不难理解，关于这点应该学习下，很有必要。它涉及到代码复用、功能扩展、对象继承、闭包、优化等很多问题，能省去不少编码，便于维护，还能不改变框架源代码而实现不同的功能。
闲话不多说了，希望能给刚走进前端开发的朋友一点帮助。以后可能还会就js面向对象编程再写一篇日志，有兴趣可以来看看。我的QQ是421557193，有兴趣可以与我交流，请注明是IT同行。
扩展阅读：Web开发框架安全杂谈
Web开发框架安全杂谈
Writebyadminin未分类at201*-03-1522:21:03Web开发框架安全杂谈EMail:wofeiwo#80sec.comSite:Date:201*-03-14
From:[目录]0×00起0×01承0×02转0×03合0×00起
最近框架漏洞频发，struts任意代码执行、Djangocsrftoken防御绕过、Cakephp代码执行等等各大语言编程框架都相继暴出高危漏洞，这说明对于编程框架的安全问题已经逐渐走入安全工作者的视线。Web开发框架就相当于web应用程序的操作系统，他决定了一个应用程序的模型结构和编程风格。框架上出了漏洞，就如同当年一个rpc远程EXP就走遍全世界windows的时代。
然而挖掘深层原因，从应用的模型和架构上考虑问题，其实这些框架漏洞都不只是一种偶然，而是一种必然。正是因为框架的模型结构，正因为他们的这种编程风格，才极大的增加了漏洞产生的可能性。0×01承
现代编程框架的几个大特点：
1、将程序代码分为不同层次，业务开发、前端开发、数据库开发人员各司其职，框架根据需要组装代码、调度执行
2、统一化自动化逻辑处理
3、常见功能的代码库封装并高度重用
4、脚手架功能，常见代码组件自动组装生成。如默认用户系统、默认后台。然而就是以上几点广受好评的功能导致了安全薄弱点的产生。1、代码调度
让我们来先回顾一下WEB应用框架所最常见的MVC模型。
用户发送一个HTTP请求过来，框架的入口点（一般是route，路由）分析用户请求的url。然后依照url中蕴含的信息分析出用户所要访问的controller、action，从而分发给相应的controller文件中的action函数，执行之；随后controller再将model中的数据结合用户输入数据依照view层中的代码逻辑填充模板，最后view、controller执行完毕，返回用户最后的HTML。整个生命周期是这样的：
用户请求url->route分发->controller接管处理用户输入及业务逻辑->view层代码执行->controller返回展现结果
从上面的流程发现了什么？
MVC模型就是一个将程序员分散在M、C、V中的代码寻找并整合在一起执行的过程。那这必然就要牵涉到一个代码调度执行的问题。这里route就是一个非常明显的例子。一个框架这么多代码文件，route每一次调用controller，都需要根据用户输入的url进行匹配并执行用户指定的函数。这里就是一个薄弱点，一个必然绕不过去的问题。
对应到现实的例子，一个非常明显的例子就是：struts2框架的动态方法调用（DMI）
当你访问!test.action时，struts会根据你的url帮你映射到名为a的controller中名为test的Action方法。而通过修改test的值，我们可以访问a这个类中的所有方法。如果恰好这个方法中含有敏感的信息，攻击者就获得了一切。结合其他技巧，攻击者能够做到的更多。但这就是框架的功能，框架总是要依靠URL中的内容去匹配执行程序代码。
那么对于PHP的框架呢？仔细想一下，如果PHP需要做分散在不同文件中的代码调度执行，唯一能够实现的方式就是使用require/include函数包含文件。文件名来源于哪里？来源于用户输入的URL。实际上目前市面上的大部分PHP框架也都是这么实现的，Yii，FleaPHP等等。如果对用户的输入没有做好验证，就很容易导致一个本地文件包含漏洞。笔者曾经就在某不知名框架中发现过这样的漏洞，在不涉及应用程序逻辑的情况下，直接获取了系统权限。2、统一化逻辑处理
框架的一大功能就是，通过统一的入口点，可以做一些统一的安全防护、逻辑控制。在软件工程学里的说法，这个叫“面向切面编程”（AOP）。
然而我们并不是说这样的统一控制模式不好，但对于这样的统一控制，如果框架设计或实现的不好，就能直接沦陷所有跑在之上的应用。
这里有一个典型的统一处理导致安全问题的极端的例子：struts2任意代码执行漏洞。
漏洞起因是struts2希望能让用户提交的值能够直接注入到程序中的数据对象，而无需手动类型转换并给内部变量赋值等操作。为此struts2专门设计了一个叫做ognl的表达式。通过它，用户提交的参数就能被自动解析为程序上下文中所存在的变量。
想想为什么能够自动解析？原因是用户提交的参数被当作自定义语言的代码被解析执行了！只是你并没有意识到这一点而已。于是有心人研究了一下，发现ognl表达式除了参数值注入，还能通过它直接调用Java自身的API。于是，一个巨大的通杀0day就这么诞生了。
回想一下，如果struts2没有这么“智能”的自动化、统一化用户输入处理机制，也就不会出现上述的大漏洞了。
前段时间爆出的Django的csrftoken绕过漏洞也是在统一安全处理的设计上出的问题。深究一下，为什么会出现这样的绕过问题？原因就是，框架必须要对所有用户的提交在真正的应用执行前做统一的csrf防范，于是django框架产生的token是保存在cookie中的（老版本和sessionid有关，这个也是保存在cookie中）。对于用户提交的POST请求，表单中增加一项token，框架在获得token值后，与cookie中的正确token值比对，如果相等就通过。然而对于ajax的请求，框架设计者却想当然的认为只要判断X-Requested-With这个Ajax特有的HTTP头即可，根本无需运算比对token。所以，框架对于http头中包含有X-Requested-With域的请求放行。通常情况下，只有ajax的请求浏览器才会带上此自定义域，且浏览器一般无法自定义此字段。
结果被人发现可以利用flash+307跳转可以伪造自定义http头，结果就绕过了此防范，导致统一的csrf防护毫无作用。如果应用程序完全依靠框架的统一安全实现，就会受到安全漏洞的威胁。
其实Django也很无奈，在它的架构设计中，它通过这个自定义头判断ajax思路上也没有什么问题。可惜在目前连黄瓜都不可靠的年代，就没什么是可靠的了。3、常见代码高度封装
代码的高度封装，对外只暴露几个接口，一行说明书。这必然造成一种现象：普通程序员就像是在搭建一个模型，只要按照说明书组建积木就可以了，不需要知晓其原理，不需要知道为什么要这样做。于是这时候就安全问题就产生了。
举一个同样在用户输入参数自动化处理方面的例子：在PHP的ZendFramework中，获取用户输入是调用getParam方法，而不是常见PHP程序中分开来的$_GET、$_POST等变量。那么，如果同时在GET、POST、COOKIE、HEADER中提交相同名字的参数，getParam到底获取的是哪一个的值？先后顺序是什么？如果前后可以覆盖，会不会影响到我们自定义的一些统一安全措施？这是一个值得检查的安全薄弱点。
再举一个struts2的例子：对于常见的文件上传场景，struts提供了一个FileUploadInterceptor拦截器，直接可以在应用逻辑运行前对用户上传文件进行检查。然而在笔者的代码审计经验中，常常发现程序员只对maximumSize（文件大小）和allowedTypes（文件mime-type）进行限制，却放过了最关键的allowedExtensions（扩展名）限制。为什么？笔者检查了一下官方文档，发现在struts2.2之前的文档，都没有给出allowExtensions的说明。或许struts开发者想当然的认为allowedTypes就可以限制上传文件的类型，殊不知只要伪造HTTP包中的mime-type字段，就可以直接上传任意文件。于是开发者也就依照官方的例子，只限制了allowdTypes，从而导致安全问题的产生。
高度代码封装的确解决了“重复造轮子”的问题，但是它解决不了程序员的安全意识和懒惰的习惯。或许它设计的很好，或许它实现的也很好，但是只要它组装的不好，就有可能造成问题。4、脚手架功能
Django的脚手架功能是非常好用的。它默认自带了一些app，只要通过几个简单的命令或配置，就可以在不敲一句代码的情况下搭起一个普通网站的脚手架，自带了用户注册、登陆等系统，甚至还有一个默认的管理员后台。
然而正如上文所说，普通程序员并不了解框架真正做了些什么。他很有可能通过脚手架生成网站后，却直接忘却了程序自带的内容没有去除。当这样的网站上线后。我们发现他是Django所写，那我们就可以直接尝试在url后加入/admin/路径访问，直接猜解后台管理员密码。此外如果框架自带的默认后台出现安全漏洞，甚至可能直接绕过进入后台。
一旦使用框架默认的组件，就得考虑到框架所带来的默认功能的安全问题。其实这问题可以扩大，tomcat自带的后台、fck编辑器自带的上传组件，都可以说属于此类问题。0×02转
框架的应用是软件开发的必然趋势，本文的目的也不在于抵制框架的使用。但对于框架应用后所带来的新安全问题，安全从业人员需要提高重视，紧跟技术发展，更新知识。对于此，我们能够做点什么？1、对于常见的应用场景，如文件操作、命令行操作、数据库操作、用户权限及认证等，我们需要了解框架的实现，给出相应的安全编码范例。
框架文档中给出的例子并不一定就是最好的。安全工作者必须对程序员进行安全意识的培训，让他知道如何利用框架的API去安全的组合出常用功能。2、对于应用漏洞挖掘，我们需要扩充字典。
框架的封装，可能引入更多的危险API或危险特性。在代码审计的过程中，需要将这些内容加入到危险词字典中。
3、对于应用漏洞挖掘，由于框架结构所带入的新的安全薄弱点，需要专门对框架的设计及实现做检查，是否存在问题。
例如PHP框架中代码调度执行的实现、文件上传统一检查的实现、封装的变量获取形式是否可靠等。本文中提到的安全薄弱点只是一个例子，更多的还需要大家的共同挖掘。0×03合
实际上对于一个应用的安全审计归根到底就是个思路问题。笔者一直认为，了解程序员的思路，了解框架的思路，了解应用的思路，这些才是安全审计中最花时间的。而实际上真枪实弹看代码的漏洞挖掘却只占用很小的一部分时间。
只有将这些思路融会贯通，在脑中将审计对象进行抽象建模，了解应用需要保护什么，弱点在哪里，才能更为有效和有针对性的进行代码审计、安全防护。
最后，非常感谢剑心及空虚浪子心之前的研究成果和意见，对本文的帮助极大
友情提示：本文中关于《几个Web前端开发框架的比较》给出的范例仅供您参考拓展思维使用，几个Web前端开发框架的比较：该篇文章建议您自主创作。
来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
公文素材库友情提示：本网站所有内容为共享上传提供，不涉及任何商业利益，本站对此不承担任何保证责任！
Copyright © www.bsmz.net Corporation, All Rights Reserved 共享时代 共享你我他 版权所有