JSF2.0与纯JS框架

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