为啥要 sweet.js

from http://jlongster.com/Why-sweet.js-Matters

(Update Jan. 10, 2014: if you like this post, you should read my much more recent post "Stop Writing JavaScript Compilers! Make Macros Instead")

最近人们讨论的 sweet.js ，是一个 js 中的宏系统。我纠结是否写这篇文章，因为大多数的支持或者反对的声音过去都已经讨论过啦。不管怎样，此文会覆盖一些新手，宏又是很容易弄混人的东西，所以多点解释总是不错的。

首先，感谢 Tim Disney 以及 Mozilla 中其他帮助开发了 sweet.js 的人们。忽略长远的意义，它起码是非常有趣而又激动的玩具。

宏能扩展语言。宏的实现多种多样，且工作原理各不相同，但是他们都完成了同样的效果：拿一大块代码，展开它转为一种不同的东西，再返回新的代码。宏在 lisp 系语言中，非常流行，因为它们的语法让宏就像从直觉自然出来的。而其他有很多语法糖的语言让宏的实现特别困难。

这就是 sweet.js 的伟大之处：他为 js 在理想和现实中找到了一个合适的方法。可以在这里 http://sweetjs.org/ 看些例子。它用了非常特殊的模式匹配语言来表达宏。

如果你从未用过宏，这和你之前用过的东西是完全不同的。当你关注这个项目的时候，记住这一点，给宏一次机会。

问题来了：我们为啥要扩展语言呢？

在 https://thestrangeloop.com/ 的这年，Brendan Eich 说有些事儿让我认识到了 js 宏的潜能。他说“他希望宏的成功能解脱他，省的一直操心 js 语法的不足，好去做点其他事儿”。

这反应出了 ECMAScript 委员会为了增强 js ，决定加入/介绍一些新语法有多难。而且不能破坏现有的 web 环境，这对 js 来说更难了。新的改变要同十年前的 js 共同工作。不仅如此，浏览器厂商们，还各有心思。改变正龟速的一点点进行着。

这就是说 js 和它 10 年前一样被卡在那儿。幸运的是， ES6 ，下一个 js 版本来了，带来了很多好东西。更棒的是，他看起来很快就被批准了，这居然是真的！

但是看看 10 年来发生的事情吧， js 缓慢的演变步伐几乎停滞，我们需要其他人的很多工作才能拥抱 es6。而且如果你不喜欢新的 es6 呢？为啥 ESMAScript 委员会不得不决定每个 js 的细节，这可是使用最广泛的语言啊？

宏让我们，这些每天写 js 的人，把这门语言定制成自己需要的样子。他让我们为 js 的演化做出贡献。想象用模式匹配宏在基础的 js 社区和生态之外，扩展出新特性。

例如，一个简单的结构化变量声明功能就会很有用，但是要等到标准实现，花儿都谢了。如果我们有宏，我们可以简单的发布一个库到社区，就是这个我写的宏 https://gist.github.com/3881008 能让你：

varr [x, y, z] = [0, 1, 2];
console.log(x, y, z); // 0 1 2

varr {x, y, z} = {x: 5, y: 6, z: 7};
console.log(x, y, z); // 5 6 7

varr w = 10;
console.log(w); // 10

看他的实现：

macro varr {
  case [$var (,) ...] = $expr => {
      var i = 0;
      var arr = $expr;
      $(var $var = arr[i++];) ...
  }

  case {$var (,) ...} = $expr => {
      var obj = $expr;
      $(var $var = obj.$var;) ...
  }

  case $var:ident = $expr => {
      var $var = $expr
  }
}

我用 varr 代替简单的 var ，因为 sweet.js 中的一个 bug；未来我们可以完全重写关键字。

你可能喷我，因为你可以用预编译的工具的方式来做到。不管怎样，预编译语言和简单的内置宏功能的世界是不同的。想象能简单的 require('syntax-extensions'); 然后你就可以获取所有的新语法。原生的支持让他更接地气。

民主化语言语法，特别是一些依赖于现有的 js 实现的特性，这是非常伟大的进步。