世上没有B/S系统,只有B系统和S系统.

赞同，网速上去了，基本上就没有必要B/S了。

这么多年的项目做下来，居然从来没有用过JSP，也算是另类了，记得01还02年的是招WEB程序员，给新员工讲技术架构，当时还没有AJAX正统的名字，只是自己做程序员的时候对<%%>和服务端生成HTML非常痛恨，那个时候虽然后台是ASP，但在我的努力下应用页面也全是HTML了，利用MSXMLHTTP与后台页面用XML通讯数据。
   种做法非常另类，往往新员工很长时间才能熟悉其中的概念，都是写<%%>太多了，鲜有对前后台分的很清楚的，把B当一个应用，把S端的页面当一个接收POST/GET请求提供业务数据而不管显示的Servive，其实养成这种习惯对后来的WS,SOA的理解都大有好处。后来的系统在前台页面动的比较少的情况下移植到J2EE上，servlet代替了服务页面，也就再也没机会用到JSP了，那段日子最头痛的就是开发人员JS水平普遍太差、以及处理传输过程中的乱码问题。
   在win32平台上作过com+应用的都知道，当服务端com+组件增加或修改接口，由于要重建proxy 和stub 信息，client机上要重新安装类型注册信息，这样的问题在多数服务组件粒度先天设计不良的情况下，系统难以维护，效率低下，所以dwr这种类似的生成js接口代码的方式，只会使前后台代码偶合度更高，而没有站在B\S是两个系统的角度考虑问题，而是在努力使程序员忘记通讯协议，忘记这是一个通讯转发的过程，其做法与com+如出一辙，EJB/cobra的rmi调用也是java世界的同样演绎。
   后来WS横空出世，其实没什么新鲜东西，舞台从LAN搬到了Internet，WSDL就是stub/proxy的描述文件代理了类型文件，client同样是要生成本地语言接口文件，使我这个长期以来使用非标准soap（自定义XML结构）协议的人有点看不惯，当然WS的粒度都先天性比较粗，上面提到的问题会好一点，原本设计方向也主要也是不同机构之间电子商务应用的功能级调用，如果谁在LAN环境下说要利用WS构架做应用开发，也以细粒度来重蹈COM+覆辙，那么恭喜，脑子肯定进水了。说实在的，我到现在都还认为SOAP的前身XMLRPC协议的设计更加简洁而幽雅，比SOAP各个版本升级争先恐后地增加体积（如同prototype的变味）要来的好多了。
   讲了那么多，其实隐约有点离题了，但看到楼主这比较合我心意的论调，只要多说两句，觉得既然WS再这么变本质都会回到臃肿的SOAP协议封装的XML字符串来进行通讯，那么做出上述设计，只能是为了照顾传统习惯了已紧耦合写C/S系统的开发人员，过度时期的无奈之举。但如果让程序员继续懵懂下去，把不同系统的集成来当一个系统来开发，我想跑偏是迟早的事情。
  回到BS系统，传统的几个WEB框架，这里就不署名了，只要是有意模糊MVC里V的那一层，认为是可以在服务端完成的所有事情的，总是会有这样的毛病。那么JSF，最近也参加kingtee的opreamask发布会，这么多评价里认为比较中肯的就是，不要以为什么事情都可以用J2EE的方式来解决，LZ自己作过tag，应深有体会。
   HTML的版本发展历史也是一个痛苦矛盾的过程，一方便想把内容和显示都搞定，一方面又想把内容和显示能分离，于是又无奈中出了CSS。现在就会听到老手的拳拳之言，尽量让CSS来管渲染样式，让HTML更XML一点，更数据一点。那么回到AJAX也可以这么讲，让交互的东西更数据一点，表把HTML/JS代码传来传去，OK?
   这几年重点参与了一些以异构系统信息整合的类EAI平台设计，如果说要有体会，也就协议二字。两个系统之间为了能互相明白对方而做的通讯约定叫做协议，课本里大致这样名词解释的。那么协议就是包含了控制信息的业务数据格式化后的结果，那么回到AJAX系统，PAGE/B端与Server端看作两个系统的话，一个设计良好的WEB系统，重点考虑的部分就是协议的制订，这样就被迫程序员连带着去理解HTTP是这么一种无状态的协议，以前后台两个系统的思维方式来设计WEB系统，应该会事半功倍。可以少犯一些构架上难以补救的错误。

纯技术人员的观点。站在赚钱的角度，简单易用，成本低廉是最佳选择，不会在行你用什么。

看了一点，觉得LZ的意思是C/S化的B/S，中否？

B/S存在的原因不是网速，是运算能力

非常认同楼主的观点！赞一个！呵呵

之前，自己做一个小玩意，由于没有想清楚到底做成B/S or C/S, 所以，两种都作。等于把楼主要说的，想了一遍。。。

对于，S 端提供业务逻辑， B端提供表现， 然后B端提供原始输入，要求得到某些数据，不管B端采用什么，是 Broswer 还是 Swing App 都可以。。

关键就是楼主说的，把B系统与S系统当作两个独立的系统来设计，来考虑！
呵呵，至于楼主所说的，差异化，肯定存在。。

如果有不同意见，呵呵，也是正常的。每个人的经历不同，想法当然不同。。

有点哗众取宠。

要做到B端和S端的零耦合真的很难～！

其实，连Struts的验证框架不是也在服务器端生成 Js脚本，再用<html:javascript/>来在客户端验证的么？

我想我们应该提倡 B系统和S系统 的低耦合。
不是有句话：“存在的都是'合理'的～！”。
基于种种原因，如成本资金、技术实现、性能调优等，实现零耦合短期内是很不现实的～！

0耦合基本没有系统能达到吧,只要把易变的业务隔开就好了啊

经过初期使用浏览器的简单的浏览方式后 所谓的BS的系统也在想CS系统进行回归， 考虑的实际网络情况、性能和外观的需要
对于B端的要求也越来越高，使用AJAX后其功能丰富性也已经不亚于C了。
随着网络操作系统的发展B和C是可以很好的找到的一个融合点，很多应用在根本上都是些本质相同的东西。