论坛首页 Web前端技术论坛

谈谈Javascript

浏览 55302 次
该帖已经被评为精华帖
作者 正文
   发表时间:2004-11-04  
在上世纪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的影子。

(待续)
   发表时间:2004-11-04  
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抬高到浏览器端解决方案核心地位的观点而已
0 请登录后投票
   发表时间:2004-11-04  
呵呵,robbin的技术直觉(这种直觉是多年深厚功底的基础上产生的吧)我真的佩服。如你所言,富javascript确实有很多缺点,而且你差不多把我们日常的抱怨都说出来了,但是在电信,国税等领域,一个页面可能需要多次与后台交互,而且每次交互的结果可能要作为中间状态保留,所以在这种场景下,公司的多个项目积累了一套富javascript的解决方案(框架),目前我们要求客户的终端PC至少512M内存,呵呵。
DLEE的实用主义在做项目时还是有优势的,所谓无招胜有招,在理解领会了软件开发组织的先进方法论后,结合实际情况,因公司制宜,将一些现有的技术(框架)结合公司业务领域开发一套二次开发平台,梳理一套项目开发的模式,是各位很自然的做法吧。(离题了)
总之,robbin,dlee,potian,o6z,gigix等高手的言论让我收益非浅。谢谢了
0 请登录后投票
   发表时间:2004-11-04  
我觉得你说的那些领域,需要复杂逻辑流程控制的情况下,看看当前的大公司给出来的方案:

1、ActiveX

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

2、Applet

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

此外,我觉得现在也有很多人主张用Java  Web Start,我觉得这种方式也很好。
0 请登录后投票
   发表时间:2004-11-04  
我也是一直想等待一种替代JAVASCRIPT的东西出现,可惜,眼前咱还是要先顾着的,现实就是这样无奈。
0 请登录后投票
   发表时间:2004-11-04  
你说的没错,但是你也说过有时候并不是技术的先进与否,而是市场策略占据主导。象DLEE,你让他再转向applet你看他干不?我们用这些东西的时候也会有怨言,但有个小组对你的意见与建议及时回复,并且公司也在各个领域推者一套东西,用久了自己也觉得这种模式虽然不好,但哪里有比这更好的呢?所以嘛。。。。。
在DLEE发起的那个帖子里,我发现网上论道,很容易脱靶,变成观点一致还在自说自话,搞对立,我看你在这个帖子里用红字来显示你的重点,呵呵。
0 请登录后投票
   发表时间:2004-11-04  
applet的缺陷比javascript更大,
因为客户端有2类JVM,你会选择哪个?
当然,我们是选中一个乐,但是其它系统就不同乐,至少我碰到过,由于整合的其它系统使用另一种JVM,结果只有痛苦。

而且,用户抱怨applet初始化时的缓慢。
0 请登录后投票
   发表时间:2004-11-04  
robbin 写道
然而考虑到Longhorn在2006年上市,到普及推广,我觉得可能要到2010年前后,XAML才有可能全面取代HTML。那么在此之前,仍然会是HTML/Javascript的方式。

最终的方向确实是基于 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 技术本身。
0 请登录后投票
   发表时间:2004-11-04  
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 层强类型的语言不如弱类型的语言顺手),我们只是看好这些技术但是并没有抱有非常高的期望。其实我们更多地还是采取一种注重实用而不是一味等待观望的态度(因为我们现在手边每天都有一些复杂的表示层问题必须要解决好,否则我们就很危险了),我相信即使将来我们更换到这些更先进的技术(把我们现在做的一些控件用新的技术重新实现)也不是非常困难的事情。
1 请登录后投票
   发表时间:2004-11-04  
首先我不大同意robbin的预测。
Jscript只所以可以活到今天而且活的不错。很重要的一个原因就是,技术的延续和广泛的使用很重要。假如现在出了一个可以替代HTML/DHTML+JScript的方案。并不表示这个方案就可以活的很长。很重要的一点是如果没有技术的延续性,我相信很多人会望而却步。因为要考虑学习成本,而且我要丢掉我现在的积累。这个成本很高。
如果将来IE放弃HTML而转而XMAL 也不会使用C#。C#设计的时候根本就没有考虑以后在Browse的运用,而很大程度上是冲 Java而来的。
我个人反而觉得js.net有可能会在以后的B/S编程中扮演一个角色。理由还是一样:技术的延续性。虽然js.net几乎改的面目全非了。
2 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics