JSF2.0与纯JS框架
2013-11-19 15:15
204 查看
转载于:http://www.oschina.net/question/55364_19575
用了JSF一段时间了,也写了几个组件了,对这个框架多少有了一些了解。另外我也用过EXT这样的纯JS的组件系统,因此我想对比一下。从复杂度上来说,我觉得EXT其实更复杂。它的组件系统是一个比较庞大的体系,但优点在于,它的类结构组织的还是不错的,和swing有些相像,比较容易理解。另外它还有另外一个优点,就是从设计上和传统UI库的概念很接近,也有布局管理的概念。组件也写得很好。缺点是,定制起来是比较困难的,需要花费比较大的力气,才能很如意的使用。EXT的文档写得不好,参考价值不是很高,有些人可能觉得它文档很好了,但是如果你用过QT你就知道什么是好文档了。特别是UI库,文档应当以例子驱动,而不是用模棱两可的语言描述一个让人很晕的概念,看完之后,不知所云,只能自己试。
JSF相对简单,由于是服务器端组件,所以可以很好的利用服务器的特性。整个继承体系比较简单,也容易理解。比如我们写组件的时候一般继承UIInput这个类就可以了。JSF采用的是服务器模板,将整个服务器端的模板渲染成HTML发送客户。因此它生来不是AJAX的,这一点不太符合现在的趋势。如果系统复杂,很难降低服务器的负载。因为整个组件树,都存在服务器上,这些东西本来和服务器是无关的(因为服务器应该更多的负责业务而不是业务无关的界面)。而且响应的数据也很复杂,可能包含一个很大的HTML页面过来。而且由于JSF的组件系统是用servlet这样的机制来模拟过来的,所以感觉很奇怪,而EXT完全和SWING等UI类库一样。所以从这个角度看上去EXT显得封装更优良,更纯粹一些,而且EXT和服务器交互采用JSON数据,可以很好的减少服务器的负载。唯一美中不足的是,EXT设计的太传统,有些复杂,考虑太多,显得有些沉重,学习起来要花费一些力气。
总的来说,我觉得类似EXT这样的纯JS UI应该更有前途。JSF虽然也支持AJAX但是由于它本身的一些限制,这个AJAX显得不是很纯粹,因为无论如何也逃不过服务器渲染这个阶段。因为AJAX逃不过JS因此JSF2.0也有自己的JS库。结果就被分割成两部分了。搞的有些复杂。所以我觉得JSF2.0有些苟延残喘的意思,呵呵。EXT搞得有些深奥,这个是它的一个很大的缺点,也许我们用起来还行,但是不太容易定制自己的组件,而这种情况在开发的时候很常见。因此EXT适合一些快速的任务,不用自己开发自己的组件,否则,就会比较麻烦,要花费一些力气研究。希望看到有很好设计的纯JS
UI组件库的出现。有些人可能会说jquery插件,但是我觉得jquery不是设计用来做组件库的,所以我们可以利用它来开发单独的组件库,但是如果你这么干,可能会发现也很不容易,因为jquery会对你的设计产生比较大的影响。
用了JSF一段时间了,也写了几个组件了,对这个框架多少有了一些了解。另外我也用过EXT这样的纯JS的组件系统,因此我想对比一下。从复杂度上来说,我觉得EXT其实更复杂。它的组件系统是一个比较庞大的体系,但优点在于,它的类结构组织的还是不错的,和swing有些相像,比较容易理解。另外它还有另外一个优点,就是从设计上和传统UI库的概念很接近,也有布局管理的概念。组件也写得很好。缺点是,定制起来是比较困难的,需要花费比较大的力气,才能很如意的使用。EXT的文档写得不好,参考价值不是很高,有些人可能觉得它文档很好了,但是如果你用过QT你就知道什么是好文档了。特别是UI库,文档应当以例子驱动,而不是用模棱两可的语言描述一个让人很晕的概念,看完之后,不知所云,只能自己试。
JSF相对简单,由于是服务器端组件,所以可以很好的利用服务器的特性。整个继承体系比较简单,也容易理解。比如我们写组件的时候一般继承UIInput这个类就可以了。JSF采用的是服务器模板,将整个服务器端的模板渲染成HTML发送客户。因此它生来不是AJAX的,这一点不太符合现在的趋势。如果系统复杂,很难降低服务器的负载。因为整个组件树,都存在服务器上,这些东西本来和服务器是无关的(因为服务器应该更多的负责业务而不是业务无关的界面)。而且响应的数据也很复杂,可能包含一个很大的HTML页面过来。而且由于JSF的组件系统是用servlet这样的机制来模拟过来的,所以感觉很奇怪,而EXT完全和SWING等UI类库一样。所以从这个角度看上去EXT显得封装更优良,更纯粹一些,而且EXT和服务器交互采用JSON数据,可以很好的减少服务器的负载。唯一美中不足的是,EXT设计的太传统,有些复杂,考虑太多,显得有些沉重,学习起来要花费一些力气。
总的来说,我觉得类似EXT这样的纯JS UI应该更有前途。JSF虽然也支持AJAX但是由于它本身的一些限制,这个AJAX显得不是很纯粹,因为无论如何也逃不过服务器渲染这个阶段。因为AJAX逃不过JS因此JSF2.0也有自己的JS库。结果就被分割成两部分了。搞的有些复杂。所以我觉得JSF2.0有些苟延残喘的意思,呵呵。EXT搞得有些深奥,这个是它的一个很大的缺点,也许我们用起来还行,但是不太容易定制自己的组件,而这种情况在开发的时候很常见。因此EXT适合一些快速的任务,不用自己开发自己的组件,否则,就会比较麻烦,要花费一些力气研究。希望看到有很好设计的纯JS
UI组件库的出现。有些人可能会说jquery插件,但是我觉得jquery不是设计用来做组件库的,所以我们可以利用它来开发单独的组件库,但是如果你这么干,可能会发现也很不容易,因为jquery会对你的设计产生比较大的影响。
相关文章推荐
- Alpaca-Spa-2.0 前端JS单页面框架
- Vue.js 2.0 和 React、Augular等其他框架的全方位对比
- 更轻更快的Vue.js 2.0与其他框架对比(转)
- Vue.js 2.0 和 React、Augular等其他前端框架大比拼
- 使用 Vue.js 2.0 框架开发和运行
- Vue.js高仿饿了么外卖App 前端框架Vue.js 1.0升级2.0
- spring3.1+openjpa+jsf2.0框架环境搭建
- JSF2.0 框架应用深度剖释
- Vue.js 2.0 和 React、Augular等其他框架的全方位对比
- node.js express框架文件上传路径
- vue.js 1.x与2.0中js实时监听input值的变化
- jfinal框架页面找不到相关css,js文件404
- js访问jsf的SelectOneRadio组件方式
- 从头编写 asp.net core 2.0 web api 基础框架 (2)
- Ember.js 1.0 RC3 发布,JavaScript 框架
- js框架简明
- js框架地址收集
- JS的完美运动框架
- Spring boot 2.0 结合常用框架搭建(一)
- Vue.js框架路由练习