转:使用简单的JavaScript,我们为什么应该抵制ES6

Kris_zcl 发布于 2014/02/25 09:42
阅读 19K+
收藏 2

原文: http://ourjs.com/detail/530b64f23b73342e03000012


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

JavaScript的简单


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

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


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

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


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 需翻墙。

1. 看上去很美的类继承

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

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

2. 新的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的影子。

3.再来点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的覆辙,可能会再次被遗弃。


加载中
3
馒头
馒头
亲,你这是在误导读者,ES6是为了让JS能构建大型应用而诞生的,你觉得性能低是因为你还没玩转前端,楼主估计没听说过babel。估计也不知道webpack是干嘛的,ES6为什么诞生的也不清楚,请不要误人子弟~
0
billq
billq
写的不错。
0
figer1
figer1
语法糖诱惑程序员、以及编程语言的设计者。有时候多打几个字、代码写直白一些更好。
0
傅小黑
傅小黑
代码的可读性从原来的变量,函数的语义化,开始走向符号的语义化,比如 (x)->x*x。
0
lxrmido
lxrmido
如果真变成这样……也不是坏事
0
回去干活
回去干活

那大家还是统一C语言吧.

不加任何语法糖.最原始的.

0
_Oak_
_Oak_

ES6,让JS更加规范化,让其向着开发大型应用项目的方向发展。自从nodeJS出来后,很多企业采用nodejs做服务端,由于目前的JS语法太简陋了,不利于大型项目的团队维护开发,需要一套更加规范的语法,这是一种趋势。

条条框框有约束,但也有好处,利大于弊时候,就是需要变革的时候,拥抱变化吧

0
whywwhhyy
whywwhhyy

对于解释型语言来说,语法糖能够有效地减少代码长度进而减少解释开销,而关键字增加并不会带来同等程度的解释开销,因为增加关键字所增加的判断条件有限,对于状态机而言只是状态空间变大一点而已。相反,原型链的设计使得代码可读性降低,不适合大型项目的开发。综上,我与楼主的想法相反,希望js的未来版本去除掉原型链的历史包袱

同时,对于楼主所列出的js与java的性能对比,我认为那个测试是针对具体框架的测试,并不能用来说明语言本身的运行效率;而且,java属于半编译型语言,运行效率与语法复杂程度无关。因此,仅依据这个测试无法证明楼主所想要表达的“增加关键字会导致语言运行效率降低”。

如有错误,请指正,谢谢!

0
漫步海边小路
漫步海边小路
ES6的语法花样太多,很多地方有多种写法,阅读起来可能不太方便.不如python,语法接单干练,阅读也顺畅
0
yuanoook
yuanoook

楼主说的对。我一直认为 javascript 深受欢迎就是因为简单。ES4 http://www.ecmascript.org/es4/spec/overview.pdf 就是太激进了,所以被嫌弃。 javascript 不再简单易懂了,前途堪忧啊。

返回顶部
顶部