JSF 与 "我的伟大发明" ---- 关于B/S UI开发的胡言乱语

  高级语言替代底层语言一直都是大势所趋，你一定要清楚jsf也是在发展的，其实我对jsf的tag标记库也很不满意，但是tag标记那只是jsf ui端的起点，而不是终点，facelets模板渲染机制的出现就证明jsf的渲染机制可以灵活发展，如果用jsf的UI层去方便的控制js的显示那才是很舒服的事情，但是你一定要说直接用js更灵活，那也是对的，就看划不划算！
  使用jsf的第一要诀就是懂得css对页面进行样式分离，因为jsf的组件块特性决定了css表的控制更利于jsf在页面上的显示逻辑，所以不是你说的没有位置，而是非常重要，我现在的项目中，CSS已经起到了决定性作用，基本抛弃了表格式布局。
  浏览器的发展会朝着浏览器脚本语言统一支持的方向进步，不管对于直接操作浏览器脚本还是通过组件化渲染脚本都是好事！自定义组件的开发是有难度，但不是难上青天，自定义组件也分为验证组件，转换组件，监听组件，标准组件。写一个标准组件进行渲染html也很容易，困难主要集中在开发一个具有交互式意义的标准组件，需要了解组件的族系，但是当你做过以后就会发现组件开发的继承关系，既是一堵墙也是一座桥,就看你熟不熟了！

JSF的初衷不是让使用者开发组件，而是让一些专注于开发组件的公司和组织来开发组件，进而让其他开发者使用，形成一个第三方市场，比如IceFaces。 不熟悉组件开发，而你又非要去做组件，这无异于没有翅膀非要去飞翔的想法。

同意， JSF和 Ext之类的框架，关注的不是同一个方向，目标市场不是同一个市场， 没有很大的可比性， JSF不能替代所有的web开发框架， JSF专注于比较传统的企业级web开发， 需要良好ide支持的快速开发框架。

又想要开发效率高，又不想写javascript,又要得到ajax效果，那就选GWT好了。

to fxy1949:

http://www.iteye.com/topic/185839

我觉得楼主没有真正的指出JSF的弱点，也没有看清楚它的强大。你不过是站在外人的角度去看待它的表面。

我使用JSF开发2年来，觉得最大的弱点在于JSF的性能还很勉强，完全不适用于门户型网站，而且高度组件化造成很难修改具体某点小型是。JSF组件难开发，有一个原因是因为中文资料相对来说非常少，而且组件这个东西本身层次就有点，你得考虑发生的众多情况，改变原本的处理方式。

但是 非常重要的是 ，我们再也不要重复的去操作编写调用一段JS。我们完全站在更高的一个层次上去看待问题，其实你说的AJAX那真的有那么重要吗 ，我记得02还是03年的时候还没有这种概念 我使用FLASH和服务器通讯或者IFRAME，用不用那些看具体情况 可以具体实现 又不是必须的。 我觉得真正理解JSF的人不是不会写JS的人 而是不再想写JS不再想在那么底层做东西的人。

时代发展不就是这样吗，你编辑HTML，编写JS 就好像现在用C去编写程序，虽然你可以精确控制但是却很难操作大局。而且JSF并去反对你在页面中插入那些代码。

首先声明，我对JSF不了解。

楼主所提的B系统和S系统，其实就是C/S架构的另外一种说法，只不过将客户端(C)限定为浏览器了而已。
这里的C/S和原来的C/S最大的差异是在S端，在原来的C/S架构中，S主要是指数据库，而现在的S，指的是能够为客户提供服务的一端。

我是非常赞同楼主强调的客户端和服务器端的解耦，这样才能够最大程度的避免由于服务提供者和服务使用者其中某一方的变化，导致另一方不得不跟随着变更。

之所以我对JSF不了解，是因为JSF给我的第一个印象就是它在服务器端，要对客户端的行为进行约束，而不是对客户端的数据消费方式(C/S数据交换接口)进行约束。当然，也许这是一个错觉，不过为什么它会给我这样一个错觉，而使我不愿意去了解它，也许还有其它的原因吧！

为什么有这么多不了解JSF的人在这里瞎评论JSF?

有很多人看了jsf一眼就放弃了，为什么？难道不值得jsf反思么？

反过来说，我用客户端的框架，一样不用去造轮子，你这么说话，完全就是不了解客户端框架目前的现状，不知道客户端框架目前的生产力到底是怎么样的。

这么说吧，这几天我又想了一下，JSF甚至于其他服务端生成JS的框架，如果我要调试一段JS（你不能保证也不可能保证所有的JSF组件没有BUG，自己开一个总要调试吧），周期太长，从敏捷的角度来说，这个是致命的。