Jafeney
Jafeney

[转] 使用简单的JavaScript，我们为什么应该抵制ES6

作为一名专职的JavaScript开发者，我会密切关注有关JS最新动态，不过最近看过ECMAScript 6的一些新的语法后。我认为ES委员会已经偏离正确的轨道，正在将JavaScript引向错误的方向，很可能又在重复ES4的老路。

JavaScript的简单

长久以来，我一直认为当今JavaScript的广泛应用一部分原因是源于她的“简单”。

一定程度上也可以叫作“简陋”，因为她并不能让程序员很“舒服”的写代码。我曾经从事过很长时间的C#和Java的开发，一度认为JavaScript的讲法极其糟糕，跟很多人一样对这种语言非常不屑，甚至觉得她并不能称之为语言，到处都是坑：浏览器兼容，异步回调，继承机制，域，类型转换……

《JavaScript就是一种垃圾语言 》
《Javascript诞生记-C和Self语言一夜情的产物》

但自从Node.JS的横空出世，重新审视这门语言，你会发现这种简陋却可以让解释器很“舒服”地运行代码。在各种评测中，看到JavaScript虚拟机比Java虚拟机快个一两倍，甚至几倍已经不是什么新鲜事了。

这种性能的提升正是源自于她的简单，没有线程对CPU和内存的额外消耗，远小于各种主流编程语言的关键字的数量，以及灵活的闭包而形成的多样的代码组织形式，都决定了JavaScript是一种灵活高效的语言。

《Web服务性能测试：Node完胜Java 》

JavaScript的开放

目前JS被Node及其他平台采用的另一个原因是因为她的开放，目前JS引擎多达4，5种，这种局面也将长期持续下去，这些引擎相互之间在不断竞争，终究会不断提升JS的运行速度。

不光是Node，Java也早已内置了JavaScript的运行环境；最新的QT和Gnome也准备将JavaScript视为首选开发语言；微软在Win8也采用了WinJS技术；SAP最新推出的基于内存的数据库HANA，其中的XSEngine也正是由JS驱动的，与NodeJS的异步单线程不同，由于写法过于灵活，且程序流并不是很容易控制，XSEngine将其改造成同步多线程的形式，这一点其实已经有些违背JS的核心特性，但可以尽可能地保证ERP软件的正确性，降低ERP实施过程中的风险。

JS标准不是由一家公司制定的，也不存在专利问题。相对于使用Oracle的Java，微软的.NET，JavaScript的成本和风险似乎要低的多，这也是这些大公司选择基于JS技术，构建自己的JS平台的原因。

为什么要抵制ECMAScript6

我们都知道ECMAScript4，是一个著名的失败的标准。坊间传闻其最初由Adobe撰写，后被ECMAScript委员会采纳，这其中有多少故事我们暂且不表。我曾经也从事过一段时间的AS3的开发，一度被其优美，严谨的语法所迷住，其实当实并没有意识到，这样全新的语法体系对于浏览器来说可能过于复杂了，可能也正因为如此，其并没有在一款浏览器上真正实施过，同样这也可能是导致Flash Player越来越不稳定的原因。

现在翻开ES6的新特性，这些被遗弃的部分似乎又回来了，而且似乎更多了。

以下特性，部分截自此幻灯片： ECMAScript 6 需。

看上去很美的类继承

class MetaLanguage extends Language {
  constructor(x, y, z, version) {
    super(x, y, z);
    this.version = version;
  }
  summary() {
    return version;
  }
}

看这段是不是觉得有点眼熟？为嘛这段跟微软的TypeScript的长得这么像？我们暂不去揣测标准制定者跟微软有何关系，但一下子用了这么多关键字，浏览器知道吗？

新的function表达形式

let empty = ->;
let square = (x) -> x * x;

$("#shopping-chart").on('click', (event)=>
  this.customer.purchase(this.chart);
);

[1, 2, 3].map{|x| x * x}; //[1, 4, 9]

照抄Ruby/Python的表达式，似乎还有Lambda的影子。

再来点Java和Node的模块管理

module DBLayer {
  export function query(s) { ... }
  export function connection(..args) { ... }
}
import DBLayer.*;

module CanvasLib = require('http://../canvas.js');
import CanvasLib.{Triangle, rotate};

看到这儿我彻底混乱了，前端能用这样的模块加载方式吗？而且还是同步的，知道这会给性能带来多么大的损失吗？

结论

我一度以为我只是为数不多反ES6的程序员，其实有些国外程度员很早就已经提出异议了，参见 Thoughts on ECMAScript 6 and new syntax 观其评论，反对ES6者居多。

总而言之，最新的ES6似乎“借鉴”了一点Java，一点.Net，一点TypeScript，一点CoffeeScript，一点Ruby/Python，一点Node.JS……　我不是很明白他们要制定出一个什么东西，我们应该欢迎那些简单，实用的新特性，但标准并不应该让语言变得更复杂，尤其是一个四不像的东西。但幸亏JavaScript是一个公开，开放的，由大家共同维护的平台，这些样标准可能会再次重蹈ES4的覆辙，可能会再次被遗弃。

原文链接： http://ourjs.com/detail/530b64f23b73342e03000012

看了不爽的 敬请吐槽吧！ ^_^

你可能感兴趣的:(web前端)