JSF2.0与纯JS框架

崔钢 发布于 2011/05/05 21:40
阅读 6K+
收藏 3

用了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会对你的设计产生比较大的影响。

加载中
1
约翰高尔特
约翰高尔特
n年过去了,楼主说对了,现在backbone,angularjs这种大行其道,jsf已经没人用了。。。哎。。。javaee标准没落了。。。。。。。。。。。回头看看,真不知道javaee会有今天啊。。。
Credo-Zhao
Credo-Zhao
不见得
0
a
abc_123

简单的才是好用的,一些人用Ajax或者是JS做的一些界面有很多问题,一方面JavaScript脚本难以调试,导致程序不健壮、问题太多,使得浏览器很慢、甚至崩溃,还有就是很多程序员本身水平有限,程序漏洞太多且没有经过规范的测试,JS脚本经常出错,用户使用不方便甚至不愿使用。当用户讨厌一项技术的时候,程序员觉得再好也没用。所以,Web界面技术发展方向决不会完全向JS这种方向发展,只会有限地利用JS的优势,回避JS的缺点。

0
十三郎
EXT这样的纯JS UI应该更有前途  但愿如此,
0
雪兔
雪兔
使用JSF感觉还是比较好的。纯的JS确实很让人头疼,用户一时觉得漂亮,但是提出新的需求的时候,我们的改动就很大
0
刘超71
刘超71
用jsf的话除非特复杂的页面需求需要写js,其他情况直接在服务器端处理了。缺点么就是服务器端做的事情太多,加载组件树、5个阶段等。
0
乌龟壳
乌龟壳
用js就容易碰到兼容性问题和浏览器性能问题,特别是现在很多用手机浏览器访问,就算手机上是chrome,也因为基础的性能不高而会显得界面很笨。
返回顶部
顶部