做JSF很久了，我也说说JSF的缺点

看了论坛上最近关于JSF的讨论，我也说说JSF的缺点：

1.学习曲线高。也许你会说只有组件开发人员才需要深入了解JSF的声明周期和高级的东西，普通开发人员不需要学习那么多——但是随着开发的深入，你马上就会发现必须要学习这些深入的东西，否则你只能写出呆板和充满隐患的程序。

2.OO。JSF是基于组件事件驱动的，也许你觉得他很像Swing，但其实也很像struts。对于熟悉action base的开发人员可能不太熟悉他的OO方式，而喜欢OO的开发人员反而又觉得它不够OO（还不如Wicket，Tapestry）。——而且OO的人少，都是用OO的工具语言做非OO的事情，不信看看好多JSF写的程序，写着写着就写成了struts，甚至还不如。

3.写一个自定义组件太难。

4.灵活性不够。组件库本来就不够丰富，想实现一个复杂表头？想物理分页?你得找到相关的组件，往往发现这个组件满足你的这个要求，却满足不了那个需求，而满足了那个的又满足不了这个。实在没办法，就得自定义。如前所述，自定义组件有很难，尤其是一个有很多功能的组件。还有就是和其他工具的集成——想用FCKEditor吗？想用一个Office插件吗？想用数字签名的插件吗？找JSF组件吧，没有的话就自定义吧。而action base的MVC框架在这一点上就容易的多。

5.东西太多太乱。要想用好JSF，你的用几个第三方组件库吧——RichFaces，ICEFaces……看看那些组件的属性吧，想短时间弄清楚也够费力的，何况你还得知道他们用了那些css的class……，你还的用facelet吧，甚至Seam也用上……关键是乱七八糟的东西放在一起缺乏一以贯之的统一性。

6.也许IDE可以拯救JSF……也许吧，现在还看不到希望，要是能做出杀手级别的，应该早就做出来了吧……JSf都好几年了。

7.性能不好。做过企业应用或许还凑合吧，但性能确实不好。把manager bean放在session中性能不好，不放的话，你发现你写程序时又像是action base了，甚至还没有action base方便。而不是像教程上那样的OO，因为教程上的例子都是把manager bean放在session中，而且table也是内存分页，所有数据放在一个list中，最终在放在session中——程序确实很OO，但……。

推荐喜欢action base的或页面和性能要求较高的用springmvc和webwork，喜欢组件话事件驱动的用wicket吧。

不过JSF也有一个优点，就是对工具相对较友好——我最近做一个可视化的表现层的产品用的是JSF，这一点体会还很深的，当然我自己做开发的话是不会用JSF的。

 

评论

28 楼 yq81862 2012-05-18  

jsf一开始跟人的感觉是比较麻烦，用多了，发现还是比struts简单的，是挺方便的。
性能到底有没有问题，这个真不好说。
使用richfaces就怕兼容性问题，太难搞定了。

27 楼 marshan 2012-04-07  

楼主很多理解有误，希望没有误导别人吧。所谓乱，是没有厘清，所谓难，是没有掌握学习的方法。就像骑马，你驾驭了，它就顺从了。
所有的基于JSF的faces库都没有太多额外的学习成本，只要把JSF的基础夯实了，后面比较容易深入的。
这么多年了，能成为web开发典范的除了spring就是jsf了，struts确实领导过mvc，但是从技术发展上看，它已经落后了。

26 楼 shunai 2011-05-29  

jsf 上手容易，但是学习深入就陷进去，新手维护困难!

25 楼 imlsq 2010-02-05  

apache click 就非常不错，建议大家看看，个人认为比JSF强

24 楼 ccxw1983 2008-04-23  

是否好用还在于学习的如何。jsf确实难学也是。没有学好或者没有习惯当然就觉得麻烦。
另外，不要什么都想用专有标签做：
1.要么页面设计的简捷点
2.要么灵活运用各种标签和方式，html的、js的方法怎么方便怎么来。

23 楼 rockjava 2008-04-22  

JSF自定义组件确实太麻烦了

22 楼 pf_miles 2008-04-21  

下一步JSF应该努力降低自定义组件开发成本。

21 楼 indexchen 2008-04-21  

java开发Ajax当然是GWT，JSF并非为Ajax而生

20 楼 lgx522 2008-04-21  

要想以Java的习惯用Ajax的，就用JSF吧。

19 楼 Joo 2008-04-19  

现在OpraMasks又出来抢市场了呵呵
不过利用注解进行JSF开发还真的比JSF RI要方便很多

18 楼 rockjava 2008-04-19  

对于JSF的争议就一直没有停过，各有所见吧。

17 楼 nbaertuo 2008-04-18  

jsf的组件驱动肯定要比struts好，但是原始的jsf组件驱动get方式获得组件值,效率太低，如果再使用ajax的话，你会发现一个请求要查询很多次，当然这跟JSF的生命周期有关，JSF推荐的是使用SESSION，但是并没有很好的管理SESSION，在JSF新的搭档上jboss seam解决了这些问题。支持JBOSS SEAM 顺带支持JSF

16 楼 打倒小日本 2008-04-18  

SEAM + RichFaces能极大提高Ajax应用的开发速度
我们现在的项目都是基于JSF的

15 楼 ray_linn 2008-04-18  

JSF- 一个失败的ASP.NET?

14 楼 upheart 2008-04-18  

引用

如果你用richfaces特别是其ajax特性。非常好用。

richfaces的ajax部分就是以前的ajax4jsf，确实做得不错。richfaces的很多组件做的也很强大，但是……

• 我觉得richfaces的皮肤太难看了，虽然提供了很多个skin，但是没一个好看的，当然按照jsf说秉承的优良传统，richfaces的皮肤也是可以自定义的，文档也挺详细，但是那么多的样式，自定义太难。
• 组件虽然多，但不灵活。richfaces挺强大，组件很丰富，但是你会发现这么多组件还是有很多问题解决不了，需要自定义组件，这说明了什么？这是否意味着不管什么东西都用组件来封装的做法本身是不是有问题呢？何况随着组件库的膨胀，学习的难度和成本就会很高。

这一点通过一个例子和wicket（或Tapestry）对比一下。比如你想实现一个复杂表头且固定表头的table，你用jsf的table怎么办呢？我觉得不太好做。richfaces怎么做呢?他提供了一个复杂的table组件，你可以通过设置一堆的属性来合并单元格之类的拼出一个复杂的表头来。而要用wicket甚至jsp（jstl）你的表头用html作就可以了，怎么加js、css都随便吧，你在dreamweaver里做出来就可以了。
这只是一个例子而已，你会看到在jsf的世界里，会充斥这各种各样类似的组件，比如一个table会有n个厂商提供属性各异功能各异的组件，但好像没有一个好用的。

13 楼 maku 2008-04-18  

    是啊，用JSF我们就可以不用直接面对那么多页面上的东西,可是就像upheart说的，JSF不是表面上那么简单，学习成本很高啊。
另一条路是从js 学起，一路上css、prototype、ext等等，学习成本也不低啊。

12 楼 chxkyy 2008-04-18  

引用

页面一般的我还用JSF干什么.现在已经开始放弃JSF了 一般应用用grails的GSP 复杂的用EXT 再复杂用FLEX

你写一个项目能用多少种方法写页面？

11 楼 chxkyy 2008-04-18  

看来楼主还是没真正很深入的用过jsf。
如果你用richfaces特别是其ajax特性。
非常好用。

10 楼 xiao0556 2008-04-17  

我也用JSF一年多了,确实问题太多了.特别是列表方面 还有性能也是个问题.开发自定义组件成本太高.现在都没办法给JSF定位了 页面太复杂做不了(很吃力).页面一般的我还用JSF干什么.现在已经开始放弃JSF了 一般应用用grails的GSP 复杂的用EXT 再复杂用FLEX

9 楼 mreay 2008-04-17  

myGWT的demo我在firefox3中不能打开。