B/S是趋势和主流？

我对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，或者C/S，也许是个问题。
严格说来，Windows就是一个肥胖无比的客户端，Office也算是巨无霸，SAP靠Client，也变得脑满肠肥。
Google从Web出发，发展到桌面搜索，还得回到Client上来。
形形色色的客户端太多了，很多客户端都统一到浏览器上来，实在BS不了，那就继续CS。

SAP和ORALCE的ERP都是CS的. 但他们都在向BS转, 不过短时间内似乎无法实现.

现在RCP的应用已经很丰富了。

Eclipse/Mozilla/Flex/XAML

还是要看什么应用。安装一次和不需要安装是有本质差别的，比CRM系统，销售成天在外面跑，没有固定的办公场所，但只要记住域名，不管在家里还是随便到哪个网吧，就能用浏览器登陆系统使用，这是非常方便的，如果用C/S无论如何不能做到这种便利程度。

另外，自动升级也不是万能的。任何一个原因导致自动升级失败，比如网络中断、中毒，最终用户可能都会归结为系统有问题。

你说的意思我知道。但是销售是不是一般都有Notepad啊？如果没有，那B/S的确更有优势。


B/S的机器就不会有网络中断、中毒的问题么？B/S的我看在这方面会更脆弱。

在界面友好度上，感觉oracle不如SAP，向BS转，你指的是SAP的EP(Enterprise portal)不？不过，EP还没推呢，SAP也紧跟潮流，开始向C/S B/S比较模糊的rich client转，用的ADOBE的apollo技术。

各大公司用什么结构开发下一代软件，并不足以说明问题。

我在一个微软投资的中国公司做过，那里搞的EAI企业应用集成软件，就真的看不懂，还专门开会给我们演示，我当即提出一个问题说“由于某某原因...我觉得这个东西没什么用处...”当时场面有点乱了，CTO有点急，就说IBM，微软都在做这个，难道他们也错了？

后来有机会听了微软的工程师讲解他们的BizTalk，感觉定位就很准。所以EAI这个东西是有用有前途的，但是不是你做也有前途呢？你理解的都不到位，那能做出什么好东西？

人家错与对，跟你没有必然的联系。也许人家有自己策略，理解的深度比你深，一味跟随很有可能会东施效颦。

坚持独立的思维吧。

是这样的。

不论是软件，还是一般消费产品，都有其合理的定位。如果你在产品研发阶段就能看出其研发的价值，把握住公司的销售思路，OK！你很可能就是等待挖掘的市场人才。

讨论B/S，C/S的发展趋势，其实还是要回归到需求上，对于用户有用户的产品需求，他们是根据自身的业务需求来对软件产品提出要求的。对于公司也有公司的考虑，他们不仅要提取用户的意见，还要根据自身的情况（如技术优势、已有的相关成熟产品、项目经验、人才资源等）来引导用户，量体裁衣，给用户专业意见。还有社会科技发展，如网络软硬件技术的提升，高质量网络的普及程度，安全等等，这些也会对B/S、C/S的发展方向产生影响。

说到两种技术的发展趋势，关键还是在于最根本的“需求”--用户的需求、公司的需求、科学技术的需求。简单的往往是复杂的，而复杂的最后就是简单。