谈谈Javascript

另外，Javascript是完整的面向对象语言。支持继承。

当然，跟我们以前所认识的基于类的OO有点不同，它是基于prototype的。简单的说：他的继承其实就是clone，它没有class的概念，只有object，你可以在任意的时候以某个object作为自己的原型，生成一个新的object。

另外，Function也被作为一种object存在。实际上，Javascript的重的所谓的构造子也就是一个Function，因而也是一个对象，通过构造子创建一个对象，跟前面说的以xx为原型clone一个对象其实是一回事。因此，Javascript中，所有的对象都是clone出来的，继承就是一种clone。所有的对象在运行中都可以改变其property，甚至增加或删除。大家可以想像一下他的用处。

另外，Function作为object还带来了一些额外的好处，比如可以尝试fp编程等等，就不细说了。

围绕着Function对象，有一大堆的属性，比如Context，比如Arguments，往里深入下去会发现有Execute Frame，apply（call）以及很多乱七八糟的东西，足够在里面打滚了。呵呵。

那位说了，找你这么说，javascript没一点坏处了？

  不是，Javascript的坏处也不是没有，那就是，由于没有基于class的机制，所有的对象都是clone出来的，这意味着它没有办法实现多继承，——说道这儿，我已经仿佛看见有人吐口水了，什么玩艺？多继承！！——多继承被人批的体无完肤了，但是他总是以各种各样的伪装的面貌出现在人们面前，最最被欣赏的是Interface，次之的有mixin，再次有delegation，甚至AOP在某种意义上也是MI。对于SI的语言，如果没有某种机制可以偷偷摸摸的引入MI，在实际的应用中会非常困难的。所以有人说JS不适合大型应用，我基本上是赞同的。

顺便给XForms做个广告：

XForms其实是一个架构，不是简单的表现层，可以认为它是UI层。（这里，我把UI和表现分开对待，UI意味着它还关注Control方面的东西，表现仅仅是展现数据）

总体来说，XForms包括了Model（注意，这里是业务层和UI层之间的数据交换中数据模式，而不是指数据层的数据模式），UI和XForms Submit Protocol三大部分。当然了，这些（包括Model，UI以及submit packet）都是用XML描述的。UI层的事件机制是XMLEvent，那是个可扩展的Event机制。

我对他UI层的Controls很感兴趣，就说说这个吧。

input
secret
textarea
output
upload
range
trigger
select
select1

这是他的主要Control，大多数都似曾相识。确实如此。不过需要注意的是，这些Controls完全没有规定自己怎么render，象什么样子，这可以留给CSS或者XSL-FO或者什么别的表现层的技术。trigger表示一个触发器，用来触发一个事件，可以认为就是button。另外它的Choices元素可以分级别，也就可以方便的表达menu和tree了。对于附加UI元素就不说了。

我觉得这个UI element list，已经可以用来表达各种我能设想的UI交互场景了。

另外，XForms还提供了一系列的Action和选择、循环等构造。可以非常方便的表达各种逻辑和重复数据。大家自己看规范吧。我就不罗嗦了。

关于AJAX，好多人给出了很多缺陷列表，但我一般都不以为然。

首先我觉得我们关于Web Page的概念需要更新。最初Web Page好像就是一个HTML文档，所以它可以方便的被SearchEngine去分析和识别。但是现在，我认为一个Web Page就是一个HTML document的想法有点问题了。且不说各种服务器端技术使得Web Page更像是一个临时存在的东西，但就看XML的发展，也能预测到Web Page会越来越模块化。想想关于XPath，XQuery，XLink，XPointer，XFrame，XInclude就会发现这一点。

其次，关于传统的整页更新方式，我想没有人会觉得舒服，尤其是确实只需要更新其中一部分的时候。由于client和server的通信带宽问题，异步的响应也是必然选择，但是，由于我们现在对于异步响应的ui还没有深入讨论过，所以很多时候会让人感觉不爽，就如同以声速跟月球上的人对话一样的感觉，这里需要设置一些交互同步点，一则让用户有一个明确的心理期待，二则可以让应用逻辑更清晰合理。这是现在AJAX没有涉及到的方面和领域。虽说A是AJAX的第一个字母。

一般来说，AJAX采用XMLHTTP作为通信协议，我觉得这不是关键问题。可以采用的方式很多，比如JSON-RPC等等。不过我倾向于相信XML包装的协议会更有优势，毕竟通用性更强，像SOAP，XForms Submit或者别的RPC协议的实现广度远远大于特定的实现。

关于AJAX中的JS，很多人也嗤之以鼻，不过我觉得现在还没有比JS更适合的UI层交互逻辑的控制语言，一则因为JS的广泛实现，二则因为JS本身就是作为Host的一个胶水语言存在的，可以非常容易的跟DOM结合。现在还没有什么语言同时拥有这两个优势。

对于技术而言，只要够用就好了。任何语言都不是万能的，没人会用js去写service的东西。至于替代js新技术最快也要个3、5年到时候不一定有什么变化呢。

JavaScript 主要的问题到不是不支持多重继承，熟悉 C++ 的朋友都知道，多重继承是一只双刃剑，用的不好也会伤了自己。
JavaScript 的设计主要参考了 Java 和 Perl 两种语言。其实 JavaScirpt 这门语言本身的设计是非常精巧的，结合了 Java 和 Perl 的很多优点，语言本身的设计即使拿到今天也不落伍。和 Python 一样，JavaScript 中函数和类是合一的，这样的设计带来了很多的好处。
JavaScript 最初是为了编写一些比较简单的页面脚本而设计的，并没有考虑到大规模组件化开发的需求，对于面向对象编程的支持是很不够的。突出表现在以下两个方面：
1、JavaScript 不支持 package 或者 namespace 的概念，所有的函数名称都是全局名称，因此在大规模开发时容易造成重名。
2、JavaScript 中的继承并不是真正的继承，而是所有的子类对象共享同一个父类对象。这个父类对象相当于一个 Singleton，一般不应该有自己的属性。如果某个子类对象修改了父类对象的属性，就会影响到所有的子类对象。正是因为这个限制，JavaScript 很难实现 3 层以上的继承，因此无法构建大型的面向对象继承体系（当然，那位说了，为什么要用继承，全部用组合难道还有解决不了的问题么？）。

上面两个是最主要的问题，这两个问题限制了基于 JavaScript 的大规模组件化开发。不过考虑到目前客户端 Ajax 组件库的规模相对于服务器端 Java 组件库的规模来说要小的多，JavaScript 目前的能力基本上够用了。

在 JavaScript 的下一版本——JavaScript 2.0 或者 ECMAScript 4 中，都已经把支持真正的面向对象编程能力列入了重点增强的内容。
http://www.mozilla.org/js/language/js20/core/classes.html
http://www.mozilla.org/js/language/es4/core/classes.html
其实 class 在现在的 JS.Net 中已经被 M$ 抢先支持了。JavaScript 也将引入 class，到那个时候我认为从语言本身来说，JavaScript 是完全可以与 Python 媲美的。

另外，挖出这些老帖的人要注意，上面这个主题仅仅代表 robbin 去年的观点，robbin 现在的想法与那个时候已经有了一些差别。每个人的观点都不是一成不变的，没有那么僵硬的人。包括我 dlee 在内，不要拿我一年前说过的话来攻击我。我一年前说过的话，现在很可能想法已经发生了很大的变化。不断前进的人完全没有必要担心否定自己以前说过的话。

我不知道你们讨论这些有什么意义？？？2010年还早着呢，谁知道那时候有什么新鲜玩意？？？
我觉得关心好眼前就行了，喜欢痩客户端就做痩客户，喜欢胖客户就做胖客户端，我喜欢用javascript、xmlhttp不是因为它好（我不知道什么技术好什么不好），也不管它是不是OO，能不能继承，这些对我都不重要。只有去给客户做演示的时候，我作的比别人酷，功能强，界面好，能拿下项目能赚钱就行，Money决定一切！

to wtusmchen：
多讨论一下也有好处。JavaScript 也是在不断发展的，不害怕别人的批评。

很多人都只看到了javascript的短处，而对它的长处视而不见，其实javascript能活到现在就证明了它在目前还是有一定优势。
我认识的很多人都认为javascript只是一种简单的脚本，只能做做在检验页面上的一些东西，却没有想到java一开始也是这样被人们理解的。

应该算是对多继承最委婉的批评了。呵呵。总体来说，我相信多继承更符合现实，更能有效的表达我的思维模式。当然了，我也把多继承稍微推广了一下，跟大家熟悉的多继承稍微有点出入。当然，主要也是大家都已经放弃了多继承而没有关注对它更深入地研究导致的。



老大不愧是老大，直指问题的核心。我基本上完全同意老大的说法。不过，第一点其实也并不是多么可怕的问题，C也没有这些东西，OS也开发出来了，感觉规划更重于语言的实现。
第二个问题来源于基于原型的继承。其实整个计算机工业界对于基于原型的继承应该怎样并没有很好的想法，幸好原型比类更轻量级，可以非常简单的修改以避开继承的问题。甚至完全不用继承，因为基于原型的OO提供了对象property的增删，同一个类型的对象可以拥有完全不同的属性。



呵呵，我总觉得基于原型的OO没有充分发力，就已经被工业界抛弃了。当然了，业界的正统就是基于类的OO，因此基于类的OO无论在理论上还是实践上都已经充分发育了，对程序员来说也更熟悉。

不知道self这个研究项目会有前途么？

我是不太赞同javascript是一种过渡技术,每一中语言都有缺点,但是能存在,必然有它的用处,如果仅仅针对缺点,不如好好考虑IE的兼容问题怎么得到解决.其实微软的霸道才是javascript是否可以发扬的问题
我的工程中开发了一组级联菜单组件,我使用经典的页面请求,回应方式连测带调用了一个月,痛苦不堪,既要维护后台数据,又要顾及请求状态!!!接着使用javascript 作为前端渲染,仅化了两天,这就是ajax技术使用后的优势,免除了页面请求状态维护的复杂性,而把注意力尽可能的化在业据逻辑,而我的组件中业务逻辑已经建立,只需要轻松的建立连接就可以了. 对于前端的处理,它真的比页面请求方式高效,快捷多了,这就是javascript的贡献!!!