任何事情都使用B/S是一件非常“愚蠢”的事情，在做企业开发的过程中，相信很多开发人员深受其害，为了所谓的“零部署”然后给企业用户吹嘘B/S如何如何，一无所知的客户到后来也就形成了一个错觉，所有都B/S，B/S是万金油，这样一来痛苦的还是开发人员，因此在CSDN的WEB版块总是有人问一些我们以为”愚蠢“却不得不面对的问题，比如无刷新，比如文本留痕，比如无提示关闭用户窗口等等，这样的问题不只一次的被问到，更加糟糕的是，即使你在这个版本解决了，在下一个浏览器的Update中，微软可能基于XX安全的原因，修复了一个”错误“，我们到头来被这些问题搞的晕头转向。
   
    Bindows可以说解决了很多WEB开发人员需要解决的所谓UI问题，但是是否是Web开发人员最终的福音呢？在这里我似乎要对Erik说No了，使用过Bindows开发或者阅读过源代码的朋友应该都会很佩服，也认为做的太棒了，这点到现在我也不曾经怀疑过。不过欣赏归欣赏，Bindows具体真正的应用还是有很长的一段路需要走，也许也走不到那天，毕竟IE的开发计划已经停止，剩余的我们也只有等待Longhorn下面的Avalon带来的XAML。在Bindows 0.93发布的时候已经将IE内置的功能开发的淋漓尽致，包括Filter，包括xmlhttp，包括web service，包括vml，剩余所做的只是一些错误的修正及其代码的一些性能调整，但是IE本身的停止更新决定了Bindows不太可能有根本性的改变，因此，教学意义似乎更加重于商业意义，我不知道有多少的公司在做B/S应用的时候在WEB UI方面会真正的采用Bindows?

    本质上来说，Bindows无法大量商业应用的主要原因在于效率还有平台的高度绑定要求（必须是IE6。0才支持全部功能），目前MB Technologies已经发布了Bindows 1.01，这个最新的版本似乎需要Money了，所以也无缘一见，我读过0.93这个版本大部分的源代码，因为也就以此版本为例，阐述几个我认为Bindows无法真正走入应用的理由。

    1。JavaScript是采用Object-Based的方式实现对象的继承,任何Custom Class都可以指定prototype，也就是这个对象的原型实现，而且任何对象允许在运行时期修改prototype指向特定的对象实例。为了保持所谓的继承关系,大部分都是采用

code:
--------------------------------------------------------------------------------

function BaseObject(){
//Base Object Implement
}
function SubObject(){
//Sub Object Implement
}
SubObject.prototype=new BaseObject();

这样的代码来实现对象继承的 ，而Object-Based的方式决定了每次有一个”子类“继承，都必须有一个预先的对象作为”子类“的prototype，虽然这个预先对象可以用无名对象和登记对象，但是无论如何，prototype指定的对象是必须存在的，因此JavaScript OOP编程中有点忌讳使用太深的对象继承树，因为为了维持这些对象关系的层次，我们不得不使用太多的对象。而Bindows恰恰如此，从下图我们可以看到为了实现一个ColorPicker，太多了如此多层的继承，那么初始化这个类库最起码的工作也需要创建5个对象，使这些父类的prototype不至于不知所从。

分析Bindows  Javascript库文件，这样的对象继承比比皆是，从某种意义来说就加大了不不必要的加载。

    2。不知道Erik是基于怎样的考虑，包括在他原先的WebFx中的代码也有这样的问题，他喜欢那种一次全部载入的方式来实现脚本库，使用过Bindows都会发现，在窗口的加载期，总是需要一个漫长的等待过程，我这里说提的漫长是针对于其他本地文件而言，脚本的下载固然是一个方面，按照V0.93，脚本文件的大小是600多K,理论来说不应该那么慢，所以说根本原因在于加载的慢，在于那些继承对象的初始化，在一个普通的Web应用中，我们更多时候不会用到bindows的全部功能，因此一次全部加载更多的只是带来加载和执行速度的下降。这点Bindows根本没有遵循”用多少去多少“的原则，仿佛就是一个贪吃鬼，有多少就吃多少。最最致命的还不在于此，IE并不能够保证这些类库只被初始化一次，一个窗口初始化一次的问题也可能出现，这样可想而知，速度能够好到哪里去。

    3。可能是基于类库完整的考虑的，Bindows封装了太多的本来属于HTML的方法，就相当于在标准的DHTML之外还做了一个完全的包装，就我个人看来这个带来的更多是坏处而不是好处。第一开发人员还必须完全理解bindows提供的api和dhtml模型如何对应，第二开发人员不得不面对一个完全新的API去开发他们的应用，何况这些方法和属性的封装更多的是在BiObject和BiComponent这两个基础类上的，因此任何实现对象比如BiWindow，BiChart都必须去经历那个创建过程，创建一个庞大的方法库的过程，而实际应用中这些方法根本不是开发人员能够用到的，一点一点的积累，这个将是一个灾难。

    4。Java或者.Net中的Import,using等等语句不知道为何也不借鉴,还是刚才的毛病，那么多的Class我能够用到的有多少啊，比如我需要做一个基于menu的应用，将所有的chart的库文件全部加载何必呢，到0.93版本为止，我认为类库内部偶合太强，根本无法根据需求加载必要的模块。

    5。内部大量利用了IE6.0的技术，虽然微软的浏览器已经一统天下，但是还没有达到完全使用IE6。0的地步，因此限制了Bindows作为Web UI应用框架的流行，在图表方面，大量采用了VML技术，但在我个人看来有点”炫耀“的感觉，我不曾怀疑作者的功底，但是在WEB上面的图形做到那样有点大可不比，何况在ie 5,ie 5.5这两个版本,VML引擎不是那么的成熟，很多地方的显示不够流畅和及其浪费资源，在目前企业用户的计算机里头，那样绚丽的图形最终会给用户带来崩溃。在小图形方面，偶尔采用VML是一个不错的选择，但是如果需要处理大量的矢量图形，SVG应该是一个更加明智的选择。

    以上的5点是我个人认为目前的Bindows不够成熟或者无法改进的地方，也正是因为如此,everything都b/s是非常stupid的，而这几年网络的发展似乎让B/S似乎有点过了头，尽管ASP.NET中有了WebForm，Java中有JSF(Java Server Face)用来帮助WEB开发，但是WEB真的不是万能的，Microsoft也意识到了这点，所以Smart Client还有Whidbey中的ClickOne技术都正在表明，胖客户技术正在渐渐回归，不过和传统的C/S比较，应该是如gigix提到的”像凤凰一样浴火重生“。