谈谈Javascript

在上世纪90年代中期，Internet热潮开始兴起，其中的明星公司非netscape莫属。Netscape公司1994年成立，公司CTO Marc Anderson是Urbana-Champaign 的伊利诺斯大学研究生，在校期间，是NCSA Mosaic小组开发成员。现在当你在IE菜单的“帮助”下面的“关于Internet Explorer"，仍然可以看到对此的介绍。

Anderson被硅谷的风险投资家Jim Clark看中，合作成立了Netscape公司，Netscape公司开发出来了Web Server - Netscape Enterprise Server 和 Web browser - Netscape Navigator。其中Netscape Enterprise Server后来有Sun公司参与了合作开发，在Netscape公司合并到AOL之后，卖给了Sun公司，是Sun公司 iPlanet Server的前身。后来iPlanet改名为Sun ONE Server，现在又改名为Sun Java Application System8，已经可以免费下载了。

在当时，Netscape Enterprise Server是企业级市场卖得最好，性能最强劲，服务器端功能开发最好的Application Server，Netscape公司的主要收入也来自于此，只可惜了Sun公司把这么好的一个东西给毁掉了。如果有人用过早期的Netscape Navigator3的话，应该可以记得，当时的Navigator对部分用户是可以免费下载的。

Netscape公司自然也知道静态的HTML表现能力不够，因此他们给Server和Browser两端都增加了脚本支持，叫做Livescript，就是后来的Javascript。在服务器端Livescript使用SSI的方式提供动态处理能力，在Browser端，Livescript增强了Browser的表现能力。当然即使是引入了Livescript，也不足以表达丰富的交互能力，所以Sun的Java Applet也被引入，Livescript也干脆被改成了Javascript。

在与Sun公司合作之后，Netscape Enterprise Server逐渐抛弃了Livescript，改成了了一个Servlet/JSP支持的服务器。因此现在已经不为人们所知了。

客户端的Javascript在MS加入浏览器大战之后，也曾经一度岌岌可危。因为MS推荐的是IE支持的VBScript，而不是Javascript，以对抗Netscape公司。在当时，VBScript的功能要比Javascript强，并且VBScript的编程更加简单，例如在Javascript中，你希望一个按钮点击以后触发一个动作，那么你除了要写动作处理代码，还需要给按钮增加一个 onclick的触发机制，而VBScript则完全不需要给按钮增加这样的东西。但是后来，MS似乎自己慢慢的放弃了VBScript了，这也是我一个不太理解的地方，也许是因为Netscape已死，MS已经没有必要再用VBScript来打击Javascript了罢，再考虑到Javascript支持更加广泛，所以就放弃了VBScript。

MS之后在Javascript上面做了非常多的功能扩充，包括扩充Javascipt功能，搞一个Jscript出来，给HTML元素增加丰富的事件相应机制，扩展DHTML的能力等等。在MS自己的webforms出来之前，MS在DHTML/Javascript方面一向是做的很好的。

但是也许是因为Javascript本身功能比较弱，调试困难，开发困难，并且在单纯的HTML上面做扩展限制很大的缘故，从dotnet时代开始，MS又把重心转向了服务器端状态控制。

展望未来的表现层技术avalon，是XAML描述页面布局，C#编写事件响应代码，与现在的webforms的HTML描述页面布局，asp.net编写事件响应代码，两种方式都是非常相似的。要注意的是，在这种技术趋势中，我们没有看到Javascript的影子。

(待续)

HTML在被创造出来的时候，只是用来描述文本信息，以及文本之间的关系的，Tim Benas Lee也不会预料到Internet时代的热潮。不论人们后来在Browser上面附加了多少功能，Javascript也好，Applet也罢，ActiveX(Flash)，都没有从根本上面改变HTML交互能力弱的问题。其实大部分人都意识到了，不彻底改变当前的HTML，就没有办法改变Browser的弱点。

然而彻底改变HTML的方式的前提就是Broswser功能的扩充，考虑到Windows操作系统和IE浏览器占据了绝大部分市场份额，这个功能最有希望完成的也只有MS公司了。

在MS下一代表示层技术Avalon中，XAML将取代HTML，Browser的功能被扩充，页面不再是扁平的，而是立体俄，事件处理代码不再是Javascript，而是C#。然而考虑到Longhorn在2006年上市，到普及推广，我觉得可能要到2010年前后，XAML才有可能全面取代HTML。那么在此之前，仍然会是HTML/Javascript的方式。

在过去，Browser端的主流是HTML/Javascript，在将来，Browser端的主流是XAML/C#，那么当前一些富Javascript技术的Browser方案是否会成为过渡时期的主流呢？我的看法是没有成熟的开源框架的情况下，是不会的。

我们过去也曾经比较多运用DHTML实现一些方便的页面操作，例如在一个页面里面隐藏很多层，当点击某个信息，察看明细记录的时候，层显示出来，层里面的内容也俨然像一个窗口一样，并且模仿Windows的桌面窗口，有关闭按钮，有标题栏什么的，还可以像Windows桌面窗口那样拖来拖去，把很多客户都骗了。并且可以在一个页面里面做很多的工作。

但是Javascript/DHTML是有很多缺陷的：

1、复杂的Javascript事件处理相当的消耗CPU资源，有时候甚至很惊人
2、Javascript本身语法简单，很难做到类似面向对象语言的扩充性，复用性，因此无法大面积复用
3、Javascript的触发严重依赖页面元素对象，因此很难抽象出来高度复用的代码，很难降低Javascipt和DHTML元素的耦合性
4、Javascipt的可视化效果是最差的，如果过多运用Javascript来控制页面显示的话，美工根本对页面无从下手，甚至程序员在没有把页面运行起来之前，也无法判断页面显示出来的样子。
5、Javascipt/DHTML在不同的浏览器，在浏览器不同版本之间的表现差异很大
6、一个富Javascipt/DHTML的页面开发效率是很低的，我的经验是，如果可以使用服务器端状态控制完成的需求，我用好几个页面，加上少量的服务器端代码可以在半天时间完成的工作，那么我如果单纯用Javascript来完成，可能一天都搞不定这个页面的控制(也许Javascript高手例外)
7、大面积运用Javascript，页面很难维护，甚至无法维护

因此，我个人是不赞成使用富Javascript的浏览器端技术的。我的主张是贫Javascript的浏览器端技术做为这几年的过渡。Javascript可以有限的运用在数据输入校验，页面跳转，数据选取，Area编辑，日历控件，动态菜单，树状显示等等方面，而不宜以Javascript为核心构建浏览器端解决方案。

HTML这种方式的本身就和传统的Desktop操作流程有所不同，非要勉强的通过富Javascript技术的方式来实现一些传统的Desktop的操作流程，我认为是代价比较大的。既然你运用了HTML，就应该接受多写一些页面，多一些流程跳转的这种Browser操作方式，而不是类似Bindows那样企图把所有状态控制都在一个页面搞定。

回想过去我们用Delphi/VB/PB写Desktop程序的方式，拖拉出来控件，然后给控件的事件编写响应代码。MS webforms在这方面迈进了一步，然而仍未摆脱HTML的桎梏，于是搞出来一个XAML，扩充操作系统和浏览器，摆脱HTML的限制，真正实现Desktop那样方便的事件响应式编程，同时又保留了Browser方式用简单的标记来描述窗口元素布局的优点。

这样看起来HTML/Javascript方式将来总归会被淘汰(至少在2010年以后吧)，其实不是Javascript有什么错，而是HTML太弱了，如果HTML被淘汰，Javascript也只好被淘汰了，这就是我对Javascript未来发展的一个预测。所以我自己不想在Javascript方面投入更多的学习成本，我原来搞Javascript的底子还在，我更愿意多关注一下XAML。

最后我要声明的是，我不是一个Javascript反对者，我在2000到2001年也下狠功夫钻研Javascript过，我也认为当前的Web开发人员必须掌握足够的Javascript编程知识，不能忽视Javascript的作用，我只是不赞同把Javascript/DHTML抬高到浏览器端解决方案核心地位的观点而已。

呵呵，robbin的技术直觉（这种直觉是多年深厚功底的基础上产生的吧）我真的佩服。如你所言，富javascript确实有很多缺点，而且你差不多把我们日常的抱怨都说出来了，但是在电信，国税等领域，一个页面可能需要多次与后台交互，而且每次交互的结果可能要作为中间状态保留，所以在这种场景下，公司的多个项目积累了一套富javascript的解决方案（框架），目前我们要求客户的终端PC至少512M内存，呵呵。
DLEE的实用主义在做项目时还是有优势的，所谓无招胜有招，在理解领会了软件开发组织的先进方法论后，结合实际情况，因公司制宜，将一些现有的技术（框架）结合公司业务领域开发一套二次开发平台，梳理一套项目开发的模式，是各位很自然的做法吧。（离题了）
总之，robbin,dlee,potian,o6z,gigix等高手的言论让我收益非浅。谢谢了

我觉得你说的那些领域，需要复杂逻辑流程控制的情况下，看看当前的大公司给出来的方案：

1、ActiveX

MS的WindowsUpdate，招商银行的网络银行

2、Applet

Oracle，SAP，BEA的很多产品中大量使用Applet来处理复杂业务。

此外，我觉得现在也有很多人主张用Java  Web Start，我觉得这种方式也很好。

我也是一直想等待一种替代JAVASCRIPT的东西出现，可惜，眼前咱还是要先顾着的，现实就是这样无奈。

你说的没错，但是你也说过有时候并不是技术的先进与否，而是市场策略占据主导。象DLEE，你让他再转向applet你看他干不？我们用这些东西的时候也会有怨言，但有个小组对你的意见与建议及时回复，并且公司也在各个领域推者一套东西，用久了自己也觉得这种模式虽然不好，但哪里有比这更好的呢？所以嘛。。。。。
在DLEE发起的那个帖子里，我发现网上论道，很容易脱靶，变成观点一致还在自说自话，搞对立，我看你在这个帖子里用红字来显示你的重点，呵呵。

applet的缺陷比javascript更大，
因为客户端有2类JVM，你会选择哪个？
当然，我们是选中一个乐，但是其它系统就不同乐，至少我碰到过，由于整合的其它系统使用另一种JVM，结果只有痛苦。

而且，用户抱怨applet初始化时的缓慢。

最终的方向确实是基于 XML 完全改造浏览器的呈现方式，但是现在以及以后很长的一个时期内 HTML+CSS+JS 仍然是浏览器端开发的主流。XML+XSLT 因为复杂性不可能成为开发的主流。XAML 仍然需要提供一种脚本语言（表示层由于修改频繁，肯定是弱类型的脚本语言的天下）的支持，我感觉 M$ 可能不会以 JS 作为这种脚本语言（不确信，不大清楚 M$ 对 JS.Net 的支持力度），而是会以某种与 C# 语法相似的脚本语言。如果使用 C# 这种强类型的语言，那么其与脚本语言的竞争就象 robbin 所说的强类型的 JSP 与弱类型的 PHP 的竞争一样讨不到什么好处。

这里的博弈绝对不是单纯技术层次上的博弈，其实从单纯技术层次我并不觉得 XAML 比 XUL 有何优越之处。但是 M$ 统治了桌面，它就有能力强迫用户和开发人员跟着它跑。不愿意的话，大家都改用 FireFox 好了。现在 FireFox 很大程度上与 IE 还是兼容的（象 AMD 兼容 x86 指令集一样），但是我预测将来总有分道扬镳的一天。我们有几种选择：

1、完全跟着 IE 跑，把 IE 的功能用足用全。这是目前很多公司采取的做法。甚至会只使用 IE 的某个版本（例如 IE6）而忽略其它版本。
有些特性，例如 HTC，还有 IE6 的一些打印功能是只有 IE 支持的。
2、使用 IE 和 FireFox 共同支持的功能子集，以便兼容两种主流的浏览器。
也有一些公司这样做，比如新浪对 FireFox 支持的也很好。我们也是这样做的。两种浏览器共同支持的功能包括：JS、CSS、XML DOM、XMLHTTP、XSLT。
3、只使用 FireFox 支持的功能，例如 XUL。
目前几乎没有公司敢这样做，但是我确实遇到过这样的公司。因为他们做的一般都是 Intranet 的应用，可以要求客户只使用某种浏览器。

至于 Web 开发架构发展变化的方向，我们可以看到从服务器端的 MVC（以 Struts 为代表）到 XMLHTTP+JS 到 Flex 到 XUL/XAML，总的趋势还是客户端越来越胖的，所以 Rich Client 在我看来肯定是技术发展的方向。将来所有的表示层开发全部放在浏览器端也是一个趋势。这是一个好的趋势，让浏览器和服务器两端各自做自己最擅长的事情。这样可以得到更好的分层、更好的交互性、服务器端的开发也大为简化。这些就是我所看到的趋势。其实要说支持我更支持这样一种发展趋势和一种新的 Web 开发架构，而不是 XMLHTTP+JS 技术本身。

to spring嘟嘟：
接受你的意见。以后我也不再说什么主流了，这样说确实很无聊。XSLT 能用好也是非常有用的技术，不过它也不是 OO 的。

我同意 robbin 说的把 JavaScript 当作一种过渡方案的说法，这也是我们一贯的看法，所以我们其实也很看好 Flex 等等技术的。但是我不同意 robbin 对 JavaScript 前途的预测。JavaScript 是一种已经标准化（ECMAScript）的语言，甚至在有些嵌入式设备中的脚本语言也是基于 ECMAScript 的（WML+ECMAScript），其实还是有很多的优势的（我现在仍然认为 JavaScript 融合了 Perl 和 Java 两大语言的优点，其设计还是很精巧的），不大可能在短期内消亡。让时间来检验一切好了，robbin 你说的 2010 年真得好远啊，我们现在有把握预测两年以后的事情吗？我没有这个信心。我的预测是至少在将来的一段时间，JavaScript 还会出现在除了浏览器以外的很多其它地方。

最后说一下，robbin，你上面列出的 7 条对 JavaScript 的批评中的任何一条都是有些值得怀疑的（就是说有些情况确实存在，但是都是可以加以避免的，把这些都当作缺点其实也是相对的而不是绝对的）。JavaScript 没有被用好是因为 JavaScript 是一种其价值总是被低估的技术，因此很少有人认为甚至有必要花上一周时间认真读完一本《JavaScript 权威指南》。其实对于任何一个 Java 的熟练开发人员，掌握好 JavaScript，然后写出整洁的甚至完全符合面向对象原则的代码是完全有可能的。“一蓑烟雨任平生”已经很清楚地解释过了，要做好 JavaScript 开发就应该把它真正当作程序开发来做。一个传统的 C 程序员如果不理解面向对象的开发思想，使用 Java 仍然会写出很差的代码，于是得出结论，Java 确实不是一门很好的语言，这个结论是不是很合理？一个熟练的 Java 程序员想要掌握好 JavaScript 或者 Python 也是要付出一些努力的。我经过亲身体验（这两年我手把手带了 3、4 个程序员），这种培养的花费并不多，并没有你所说得那么惊人（培养一个好的 JavaScript 开发人员其实比培养一个好的 Java 开发人员要容易得多），这也是我基于自己的经验来怀疑你的 TCO 分析的原因。如果说我自己的经验不能作为我判断这个问题的依据，那么我实在不知道应该把什么作为判断这个问题的依据了（还是 jasonhsu 说的，ORM 方面你是我们的老师，但是在表示层开发方面不是，因为我们现在每天都在做这方面的开发，每天都在为如何得到更好的界面和交互而绞尽脑汁）。

而且我对你把 Web 开发技术的希望唯一寄托在 XAML/Longhorn/C# 上的观点表示怀疑（原因就是我上面说的，我认为在 Web 层强类型的语言不如弱类型的语言顺手），我们只是看好这些技术但是并没有抱有非常高的期望。其实我们更多地还是采取一种注重实用而不是一味等待观望的态度（因为我们现在手边每天都有一些复杂的表示层问题必须要解决好，否则我们就很危险了），我相信即使将来我们更换到这些更先进的技术（把我们现在做的一些控件用新的技术重新实现）也不是非常困难的事情。

首先我不大同意robbin的预测。
Jscript只所以可以活到今天而且活的不错。很重要的一个原因就是，技术的延续和广泛的使用很重要。假如现在出了一个可以替代HTML/DHTML+JScript的方案。并不表示这个方案就可以活的很长。很重要的一点是如果没有技术的延续性，我相信很多人会望而却步。因为要考虑学习成本，而且我要丢掉我现在的积累。这个成本很高。
如果将来IE放弃HTML而转而XMAL 也不会使用C#。C#设计的时候根本就没有考虑以后在Browse的运用，而很大程度上是冲 Java而来的。
我个人反而觉得js.net有可能会在以后的B/S编程中扮演一个角色。理由还是一样：技术的延续性。虽然js.net几乎改的面目全非了。