当前位置:编程学习 > JAVA >>

JavaScript的死与生

文章内容如下:

JavaScript的成功得益于在正确的时间出现在正确的地点。JavaScript的兴起与浏览器的支持息息相关。你瞧,VBScript就没这么好运气。

JavaScript很流行,但它有先天缺陷。Brendan Eich当初只花了10天时间就把JavaScript设计出来了,作为JavaScript之父Brendan Eich如是说:

与其说我爱JavaScript,不如说我恨它。它是C语言和Self语言一夜情的产物。十八世纪英国文学家约翰逊博士说得好:“它的优秀之处并非原创,它的原创之处并不优秀。”
JavaScript的不足,最明显之处是语法。

糟糕冗长的语法 可选参数和默认值

function(a, b, option) { 
  optionoption = option || {}; 
  // ... 
}
上面的代码中,option是可选参数,当没有传递时,默认值是{}.然而,传递的option值有可能是假值(falsy值)。严格来写,得如下判断:

function(a, b, option) { 
  option = arguments.length > 2 ? option : {}; 
  // ... 
}
注意:option = typeof option !== undefined ? option :{}也有可能是错误的,因为传递过来的可能就是undefined。当不需要b参数,删除后,基于arguments.length 的判断很容易导致忘记修改而出错:

function(a, option) { 
  option = arguments.length > 2 ? option : {}; 
  // ... 
}
如果能增加以下语法该多好呀:

function(a, b, option = {}) { 
  // ... 
}
Let
闭包很强大,也很恼火:

for (var i=0, ilen=elements.length; i<ilen; i++) { 
  var element = elements[i]; 
  LIB_addEventListener(element, click, function(event) { 
    alert(I was originally number + i); 
  }); 
}
上面的代码经常在面试题中出现,解决办法是再包裹一层:

for (var i=0, ilen=elements.length; i<ilen; i++) {
  var element = elements[i];
  (function(num) {
    LIB_addEventListener(element, click, function(event) {
      alert(I was originally number + num);
    });
  }(i));
}
如果直接支持let语法该多好呀:

for (var i=0, ilen=elements.length; i<ilen; i++) {
  var element = elements[i];
  let (num = i) {
    LIB_addEventListener(element, function(event) {
      alert(I was originally number + num);
    });
  };
}
模块
模块模式是一种无奈的选择:

如果原生支持该多好呀:

module event { 
 
  // private variables 
  var listeners = []; 
 
  export function addEventListener(f) { 
    listeners.push(f); 
  } 
 
  export function clearEventListeners() { 
     listeners = []; 
  } 
 
  // ... 

 
(function() { 
 
  import event; 
 
  // ... 
}());
继承
JavaScript要通过原型链来实现继承:

function Employee(first, last, position) { 
  // call the superclass constructor 
  Person.call(this, first, last); 
  this.position = position; 
}; 
// inherit from Person 
Employee.prototype = Object.create(Person.prototype); 
EmployeeEmployee.prototype.constructor = Employee; 
 
// define an overridding toString() method 
Employee.prototype.toString = function() { 
  // call superclasss overridden toString() method 
  return Person.prototype.toString.call(this) + 
         is a + this.position; 
};
如果能写成下面这样该多好呀:

class Employee extends Person { 
  constructor(first, last, position) { 
      super(first, last); 
      public positionposition = position; 
  } 
 
  update(camera) { 
      return super.update() + is a + position; 
  } 
}
感悟
ECMAScript委员会已意识到JavaScript在语法层面上的不足。在Harmony规范中,以上所有语法均已提案。

我们什么时候才能使用以上语法呢?

只要有宏(Macro)
Lisp语言的宏特性非常强大。通过宏,你可以根据自己的喜好定义想要的语法格式。宏特性使得Lisp成为一门“可编程的编程语言(the programmable programming language)”.

JavaScript没有宏。给类C语言添加宏特性,目前依旧是个研究课题,很有难度。

只要有宏,我们就可以自定义语法。但JavaScript的宏特性遥遥无期,还是找找其他路子吧。

Harmony
Harmony规范里的语法扩展,可能是我们所有人的梦。Harmony有可能成为ECMAScript 6规范。在这之前,我们需要等待,耐心等待。

截止2011年5月,w3school显示IE6的市场份额还有2.4%。Net Market Share 显示IE6占有10.36%市场份额。还有IE7的市场份额也不少。这些老旧浏览器短期内不会退隐市场,对于商业公司来说,比如Amazon,不可能放弃这批用户。糟糕的现状。(中国大陆更惨,IE6/7还占有40%多市场份额)

我们不能寄期望于“IE该死”这类呼吁来让用户升级。听到过一种说法:IE用户仅会在更换电脑硬件时,才升级浏览器。悲催的是,对于普通用户来说,收email,上Facebook,Twitter,现有的硬件已足够。没有理由让他们去花一笔钱。

Goggle Apps最近宣布,从2011年8月开始,将停止支持IE7.

通过各种保守估计,Amazon的网站开发者,用上Harmony语法扩展,要一直等到2023年!

风华正茂的你,愿意等待10多年后,再用上这些好用的语法吗?

JavaScript已死
死因:分号癌。(semicolon cancer.作者的调侃,意指语法导致JavaScript死去)

通过上面的分析可以看出,宏特性实现太难,Harmony规范的实现则遥遥无期。大量程序员开始书写JavaScript,其中有很多人已经厌倦或开始厌倦JavaScript冗长糟糕的语法。我们需要新的语法,我们不想等待!JavaScript,作为源码编写语言,已经死了!

JavaScript先生,你曾有过辉煌的统治。我们与你,有过甜蜜的回忆,一起产出过很多有趣的应用。祝福逝者安息。

JavaScript长存
程序员喜欢掌控自己的命运。作为源码编写语言,JavaScript已死。我们可以选择或创造另一种更好的源码语言,将其编译成ECMAScript 3的语法格式。

JavaScript的新生,是作为编译目标(compilation target)。

编译成JavaScript的语言
能编译成JavaScript的语言有很多。我在1997年时,收集过一份列表。包括:

JavaScript扩展语言:已死的 ECMAScript 4, Narrative Script, Objective-J.
已存在的语言:Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell等。
还有一些崭新的语言:HaXe, Milescript, Links, Flapjax,专门为web 编程而设计。
在这些编译器项目中,Goggle的GWT Java-to-JavaScript编译器有可能是最成功的一个。然而悲剧的是,现实项目中,很少看到GWT的身影。原因如下:

1.维护成本很高。编译器可能有bug.假设你在一个大型项目中,发现了编译器的一个bug,作为维护者,除了维护源码,你还得维护编译器。天哪,你有这个本事吗?你有这个本事,CEO也不愿意花这个钱呀。

2.调试麻烦。Firebug报了一个错,报的是编译后的行号。老板站在你背后:赶快啦,小伙子!可是这该死的编译后代码,究竟对应哪一行源码呀?

3.招聘不到人。假设你使用Objective-J开发一个项目,但人手不够。赶紧招人,HR说1000个人里面,只有100个听说过Objective-J,另外900个只听说过JavaScript.结局是你每找一个新人,都得先培训一把,真是糟糕透顶。

虽然编译器有以上各种不是,但各种编译器依旧如雨后春笋大量涌现。毫无疑问,编写JavaScript编译器非常酷。给我报酬,我也想写一个。

在上面的编译器列表中,有一个非常有名的引起过很大轰动的:CoffeeScript。我们来谈谈它。
CoffeeScript
为什么CoffeeScript如此火爆?我到现在为止也没想明白。是因为给空白赋予了意义,还是带箭头的函数语法?每念及此,我的胃就忍不住波涛汹涌。CoffeeScript有很多新特性:default parameter values, rest parameters, spread, destructuring,fixing the whole implied global mess… CoffeeScript很多特性是Harmony规范的一部分,有可能在未来浏览器中直接支持。CoffeeScript 能让人立刻满足。

@pyronicide在Twitter上说:#coffeescript 支持函数默认参数值,这太令人兴奋了。
在TXJS 2011大会上,Douglas Crockford 也表示:CoffeeScript无疑是个好东东。

CoffeeScript: Accelerated JavaScript Development 一书的作

补充:web前端 , JavaScript ,
CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络,