几个Web前端开发框架的比较.docx
- 文档编号:29629475
- 上传时间:2023-07-25
- 格式:DOCX
- 页数:8
- 大小:22.10KB
几个Web前端开发框架的比较.docx
《几个Web前端开发框架的比较.docx》由会员分享,可在线阅读,更多相关《几个Web前端开发框架的比较.docx(8页珍藏版)》请在冰豆网上搜索。
几个Web前端开发框架的比较
几个Web前端开发框架的比较
几个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看jQ官网时有时也会卡,试想他们官网肯定做到很好的优化了吧,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,A也不适合与以上等框架集成,因为A是事件驱动,这些框架都是为消息驱动而生的,勉强应用只会事倍功半,丧失.net本身的优势。
js面向对象编程我一直在提,其实并不难理解,关于这点应该学习下,很有必要。
它涉及到代码复用、功能扩展、对象继承、闭包、优化等很多问题,能省去不少编码,便于维护,还能不改变框架源代码而实现不同的功能。
闲话不多说了,希望能给刚走进前端开发的朋友一点帮助。
以后可能还会就js面向对象编程再写一篇日志,有兴趣可以来看看。
我的QQ是421557193,有兴趣可以与我交流,请注明是IT同行。
扩展阅读:
Web开发框架安全杂谈
Web开发框架安全杂谈
Writebyadminin未分类at202*-03-1522:
21:
03Web开发框架安全杂谈EMail:
wofeiwo#Site:
Date:
202*-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提供了一个拦截器,直接可以在应用逻辑运行前对用户上传文件进行检查。
然而在笔者的代码审计经验中,常常发现程序员只对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前端开发框架的比较:
该篇文章建议您自主创作。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 几个 Web 前端 开发 框架 比较
![提示](https://static.bdocx.com/images/bang_tan.gif)