B/S是趋势和主流？ 博客分类： 技术话题 大众硬件大众软件网络应用浏览器Flex
程序员文章站
2024-03-22 15:18:04
...
我对B/S是趋势和主流这个问题有过多年的疑问及困惑。
虽然我一直在做B/S的开发，我并不认为B/S相比C/S有什么特别大，不可超越的优势。C/S并不是死的，是可以变化和进步的。
本文中所提到的C/S，不仅是传统的两层结构，包括所有胖客户端+N层服务的结构。
其实两者之间的界限相当模糊，特别是在以Applet为主要界面，至Webstart(可以使用http 80端口自动下载、更新，并可在本地独立启动不需要浏览器)，难以截然区分。
针对常见的几个问题我的思考如下：
1.B/S部署方便，不用安装，自动更新。
B/S天生的优势，但C/S并不是不能做到，天生的特性并不是不能改变的。
不用安装：毕竟是一次性的，若非偶尔看一下的用户，还是可以忍受安装的。如果就是传统的网站，自然落在B/S的饭碗里，不用说了。
自动更新：这个应该更重要。我们用过各种杀毒软件，都可以自动更新，windows也可以。它并不是那么复杂，特别是，如果做成一个相对通用的方案，有良好的封装的话，可以认为这不是一个问题了。
2.采用一般不被封闭的http协议和80端口，穿透防火墙。
若干年前我第一次看到时就觉得有点奇怪。
看看MSN messenger，即使不使用http和80又如何，也没有阻止它发财。或者QQ等其他。
我认为这个因素只对一些面向公众的网站有影响。
3.界面漂亮。
HTML可以方便的使用超文本、图片、样式表等技术，界面可以很漂亮。winamp、mediaplayer等也漂亮，需要更高的技术么？我不清楚，但可以肯定地是，有很多换肤等组件使得漂亮不会太难，而且，在一个商业的应用中，漂亮或者花哨的那种漂亮有很大的作用么？我倒是知道，很多国内客户看软件时，只知道评价好看还是不好看。国外软件的界面一般是比较朴素和实用的。
更多一点，也可以适当的嵌入html引擎（或浏览器组件）以丰富界面。Java Swing中某些地方就可以使用基本的html。一个极端的例子，Dreamwaver的全部界面其实都是html+js写的，用自己写的浏览器引擎解析，有兴趣可以研究一下。
4.操作简单。
这个问题很有意思。以前的web功能比较单一和简单，所以操作当然也简单了，留下这个印象真是一个思维的定势。如果达到一定的复杂程度，比如大量特性的Grid，或者拖放(甚至跨进程的拖放),我看不一定比C/S的简单了，比如bindows之类，按照windows现有的重造了一套界面机制。
看看界面设计一类的书，就知道在B/S里界面交互技术实际上倒退了10年。一切已经存在很久的很成熟的东西又要重造一次，不容易啊，细节是魔鬼，做一套看上“激动人心”的DEMO不难，经得起推敲和大量实际应用检验是很不容易的。
5.客户端可跨平台。
Java也可跨平台。
6.采用三层结构，大部分逻辑在服务端处理。
C/S也可以采用三层结构，中间层可以使用多种技术：EJB，Web Service等。
7.B/S可以做很多(甚至任何！)你想不到的界面控制，可以提高用户体验。
首先，B/S里做的各种高级GUI编码都是对自身弱点的弥补，在做很多年前C/S就有的东西。
其次，B/S的确可以用很多方法"模拟"出各种界面、组件元素，但纯的HTML+Javascript是不能突破砂箱的，本地的API自不用说，访问文件系统也暂不提，光是各种按键（包括ctl、function键)不能自如的控制，模态和非模态对话框不能*定义等等“小”问题就足够降低用户体验了。获在一个并不是那么“上心”的Browser容器里，做一个委屈的二等公民，玩着沙箱。
IE在模态和非模态对话框作了一些努力是不错的，还有上下文菜单，也是系统级别的（用div等物模拟的上下文菜单不能覆盖框架和帧...细节是魔鬼！），但不能指望Microsoft在浏览器上有更多的支持---正如Joel on software里说的，他意识到了这是自己给自己挖坟墓，减弱应用程序对windows API的绑定。
利益集团的角力：
正如前面提到的，Microsoft依靠windows的垄断，使得他不可能在IE浏览器上有更多的支持。而其他公司如Sun、Oracle、IBM等，则会力推B/S应用，以减低应用程序对Microsoft的依赖程度，而获得更大的控制力和利润。
浏览器技术未来发展的畅想：
如果没有上述利益的问题，我认为应当由最有影响力的公司来推动html相关标准的建立(Maybe M$)，web上不应该只有几个基础控件，如Java抽象出来的组件一样，应该有更丰富的内置组件，如combobox,grid等。
并且应该及时响应趋势并支持B/S的发展，象现在搞的Grid之类不应该人人造*。
总结：
B/S会在合适的地方发挥自己的长处，特别是面向大众的软件或网站，但我对目前火热的AJAX等持谨慎乐观态度，它不是一种（套）根基很牢的技术。
针对于内部使用的软件(或可以忍受几分钟安装软件的)：
1)B/S在界面上的劣势会导致高级界面交互技术开发困难。
2)对比B/S的各种优点，可以使用Applet，Webstart (可能需要数字证书做代码签名)加EJB、RMI、Web service等技术的三层结构来替代，以获得胖客户端的好处。做一些努力，使用VB、Delphi、PB也可以局部或全部的拥有这些优点。
这么说并不是说B/S就一定差，只是本人对业界的这样的趋势有点看不懂，让我想起了若干年前什么系统都要用EJB的所谓“趋势”和“主流”。
虽然我一直在做B/S的开发，我并不认为B/S相比C/S有什么特别大，不可超越的优势。C/S并不是死的，是可以变化和进步的。
本文中所提到的C/S，不仅是传统的两层结构，包括所有胖客户端+N层服务的结构。
其实两者之间的界限相当模糊，特别是在以Applet为主要界面，至Webstart(可以使用http 80端口自动下载、更新，并可在本地独立启动不需要浏览器)，难以截然区分。
针对常见的几个问题我的思考如下：
1.B/S部署方便，不用安装，自动更新。
B/S天生的优势，但C/S并不是不能做到，天生的特性并不是不能改变的。
不用安装：毕竟是一次性的，若非偶尔看一下的用户，还是可以忍受安装的。如果就是传统的网站，自然落在B/S的饭碗里，不用说了。
自动更新：这个应该更重要。我们用过各种杀毒软件，都可以自动更新，windows也可以。它并不是那么复杂，特别是，如果做成一个相对通用的方案，有良好的封装的话，可以认为这不是一个问题了。
2.采用一般不被封闭的http协议和80端口，穿透防火墙。
若干年前我第一次看到时就觉得有点奇怪。
看看MSN messenger，即使不使用http和80又如何，也没有阻止它发财。或者QQ等其他。
我认为这个因素只对一些面向公众的网站有影响。
3.界面漂亮。
HTML可以方便的使用超文本、图片、样式表等技术，界面可以很漂亮。winamp、mediaplayer等也漂亮，需要更高的技术么？我不清楚，但可以肯定地是，有很多换肤等组件使得漂亮不会太难，而且，在一个商业的应用中，漂亮或者花哨的那种漂亮有很大的作用么？我倒是知道，很多国内客户看软件时，只知道评价好看还是不好看。国外软件的界面一般是比较朴素和实用的。
更多一点，也可以适当的嵌入html引擎（或浏览器组件）以丰富界面。Java Swing中某些地方就可以使用基本的html。一个极端的例子，Dreamwaver的全部界面其实都是html+js写的，用自己写的浏览器引擎解析，有兴趣可以研究一下。
4.操作简单。
这个问题很有意思。以前的web功能比较单一和简单，所以操作当然也简单了，留下这个印象真是一个思维的定势。如果达到一定的复杂程度，比如大量特性的Grid，或者拖放(甚至跨进程的拖放),我看不一定比C/S的简单了，比如bindows之类，按照windows现有的重造了一套界面机制。
看看界面设计一类的书，就知道在B/S里界面交互技术实际上倒退了10年。一切已经存在很久的很成熟的东西又要重造一次，不容易啊，细节是魔鬼，做一套看上“激动人心”的DEMO不难，经得起推敲和大量实际应用检验是很不容易的。
5.客户端可跨平台。
Java也可跨平台。
6.采用三层结构，大部分逻辑在服务端处理。
C/S也可以采用三层结构，中间层可以使用多种技术：EJB，Web Service等。
7.B/S可以做很多(甚至任何！)你想不到的界面控制，可以提高用户体验。
首先，B/S里做的各种高级GUI编码都是对自身弱点的弥补，在做很多年前C/S就有的东西。
其次，B/S的确可以用很多方法"模拟"出各种界面、组件元素，但纯的HTML+Javascript是不能突破砂箱的，本地的API自不用说，访问文件系统也暂不提，光是各种按键（包括ctl、function键)不能自如的控制，模态和非模态对话框不能*定义等等“小”问题就足够降低用户体验了。获在一个并不是那么“上心”的Browser容器里，做一个委屈的二等公民，玩着沙箱。
IE在模态和非模态对话框作了一些努力是不错的，还有上下文菜单，也是系统级别的（用div等物模拟的上下文菜单不能覆盖框架和帧...细节是魔鬼！），但不能指望Microsoft在浏览器上有更多的支持---正如Joel on software里说的，他意识到了这是自己给自己挖坟墓，减弱应用程序对windows API的绑定。
利益集团的角力：
正如前面提到的，Microsoft依靠windows的垄断，使得他不可能在IE浏览器上有更多的支持。而其他公司如Sun、Oracle、IBM等，则会力推B/S应用，以减低应用程序对Microsoft的依赖程度，而获得更大的控制力和利润。
浏览器技术未来发展的畅想：
如果没有上述利益的问题，我认为应当由最有影响力的公司来推动html相关标准的建立(Maybe M$)，web上不应该只有几个基础控件，如Java抽象出来的组件一样，应该有更丰富的内置组件，如combobox,grid等。
并且应该及时响应趋势并支持B/S的发展，象现在搞的Grid之类不应该人人造*。
总结：
B/S会在合适的地方发挥自己的长处，特别是面向大众的软件或网站，但我对目前火热的AJAX等持谨慎乐观态度，它不是一种（套）根基很牢的技术。
针对于内部使用的软件(或可以忍受几分钟安装软件的)：
1)B/S在界面上的劣势会导致高级界面交互技术开发困难。
2)对比B/S的各种优点，可以使用Applet，Webstart (可能需要数字证书做代码签名)加EJB、RMI、Web service等技术的三层结构来替代，以获得胖客户端的好处。做一些努力，使用VB、Delphi、PB也可以局部或全部的拥有这些优点。
这么说并不是说B/S就一定差，只是本人对业界的这样的趋势有点看不懂，让我想起了若干年前什么系统都要用EJB的所谓“趋势”和“主流”。