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

从标题来看，那么也可以说：世上没有B/S系统，只有C/S系统，Browser不也是一种Client？然后，完了。
看了帖子，还不大明白，lz的意思就是B-S之间只能传输数据，而不是行为？

通常情况下 应该避免传递行为
通常情况下 应该尽量以数据为中心

好歹我也深知你全文的精髓啊,你怎么也不吹捧一下我??

想web service， Service端不用知道client端是用什么实现的。。

说白了，还是数据与信息的关系。
数据是信息的载体，单纯的数据不表达任何信息，数据需要某种规则解释为特定信息。
服务器端传来的数据由客户端的浏览器(HTML渲染引擎，JavaScript动态解析）解释成特定的信息展现。如果将解释规则（javascript/html代码）也嵌入到数据中，传递来数据本身就有了信息展现的含义。这造成了数据与信息展现的紧耦合，不符合MVC提倡松耦合精神。
B和S是整个有机系统的两个端点，它们的代码设计如果符合松耦合的设计，那么B和S就既能独立成系统，又可以组成有机系统。如果它们不符合松耦合的设计，比如返回JS/html的做法，就会使得B/S系统的两个子系统难以独立出来。
所以楼主说没有B/S系统，只有B系统和S系统的说法不过是理想情况下，设计良好的系统所具有的特性。

解释的好清清楚楚！！

很赞成的搂主的说法，很多事情的责任要分清楚，不管是B还是S
不过我有个问题就你说js传到rhino是个可怕的事情是怎么回事？
我公司正打算这样做，我虽然不赞成，但是也没有有力的证据

可能我的说法有点误导你了

服务端运行js是完全可以的,但是这段js代码应该在S端内部拼装,并且执行.从客户端得到的应该是拼装js语句所需要的必要的条件,而不应该是拼装好的JS代码.

当然这是理想状态,实际上有时候有些需求 就是要求在客户端写js语句,后台运行客户在前台写的js,那就无能为力了,那就属于我所说的例外.

例如有这样一个需求:
用户在浏览器的textarea框内 写如公式,然后服务器端根据公式来计算结果.
这个最好的做法就是让用户用js的语法写公式,我们后台得到这个公式,用rhnio来执行.如果不这么做,你后台必须要写一个语法解析和编译器了,那就太难了.

所以不是这么做不可以,而是要清除这种做法是所有做法里最合适的了

我理解你的意思差不多就是REST了，如果是这个意思那我同意。以前干过很多用一种语言拼装另一种语言的事情（最变态的是用domino的公式生成html表格，里面还要有一些简单的js脚本），现在想来非常丑陋。

为什么我们会被迫这么做？根子就在于我们把B和S看成一个整体，解耦的不够，导致开发的时候需要一个人同时熟悉两种以上的语言（也就是两种以上的思维习惯），例如java和js，于是很多java程序员就抱怨“js怎么这么难写”。

作为对比，再看看C/S系统，可能server端你要熟悉spring/hibernate，而client端要熟悉swing或者其它什么，实际上也是不同的知识结构，但是一般的设计者都会先明确定义好前后端的接口API，然后就可以让不同的人做不同的方面了──当然，肯定还有互相影响的地方，但是总的来说会简单很多。

http 协议不是通常意义上的传输协议，它定义的是REST（Representational State Transfer），我认为更恰当的说法是我们可以基于http定义B/S的前后端接口API，然后server端和browser端开发人员各司其职。

完全这么做当然是理想化的，但是朝这个方向努力确实会简单许多。

PS：现在的Flex可能更容易达到这种效果，因为它就是c/s开发，只不过是在浏览器上的c/s，这方面不熟，召唤达人补充。

从一个极端到另一个极端的碰撞中，一个技术会找到其生存的空间与位置。