权限不足 - SegmentFault
该内容处于隐藏状态，只有作者自己能看到哦02:04:56 UTC
Why not ES6? Desktop app using node.js/V8 is almost the perfect place to use (and let others use) ES6 right now.
02:07:18 UTC
Interestingly and completely unrelated to Atom, we had a very long discussion at Discourse about this issue:
Religion aside:
What is better for Discourse, CoffeeScript or JavaScript?
Notice, I am not particularly interested in personal preferences here.
I am interested in quality and frequency of potential contributions and long term sustainability of...
Reading time: 11 mins ?
Likes: 119 ?
We ended up going with JavaScript
02:12:45 UTC
See the discussion over here about using plain old JS in Atom:
02:15:33 UTC
You can use plain JS to develop packages:
JavaScript and JSON can be used in Atom packages, there is no requirement to write a single line of CoffeeScript or CSON to make an Atom package.
In Atom any .coffee/.cson/.less files can always be .js/.json/.css files instead.
So you can have...
02:23:04 UTC
It would be nice if all the open source components of atom where written in JavaScript.
The usage of CoffeeScript (opinion aside) increases the barrier to entry. There are more JavaScript developers. Usage of JavaScript would increase contribution to the project.
It appears both discourse & rethinkdb have seen the negatives of coffeescript wrt contributions and open source collaboration.
02:35:14 UTC
Agreed. Collaboration in core would see much higher adoption if in plain JavaScript.
04:32:44 UTC
I don’t agree that CoffeeScript raises the barrier to entry by enough to warrant converting core packages to JavaScript. CoffeeScript isn’t that different. It’s mostly syntax preference in my opinion.
05:41:09 UTC
Agreed, the idioms used by coffeescript devs are often quite different than the “norm” in js-land as well, so that alone leads to some pretty awkward APIs when interfacing with “regular” javascript. I also agree with the ES6 comment, there’s very few things that coffeescript really gives you on top of what we’ll have as a standard soon, so this seems like a bullet to the foot really. There’s no questioning that it will have an impact on contributions, personally I won’t even look at it because I might as well stick with the obscure editor I already use.
Hell I had to rewrite a coffeescript driver this week because I can’t have our company relying on things written by people who are unfamiliar with javascript, throwing strings, super awkward apis, lots of indirection, and stepping through the compiled source is a nightmare. It’s not like I didn’t want to contribute, I even tried for a while, but it’s just not worth the hell, it was quicker to just rewrite the thing. Not to say all coffeescript libraries are written poorly, but regardless you’re really not gaining much, just losing a lot.
Just my opinion
06:53:51 UTC
I would have preferred plain JavaScript in Core, too. We can relatively safely say that JS will still exist, evolve and be standardized in 5 or more years where CoffeeScript is a lot more questionable. CS tends to clash with new ES.x features, too. The community for JS is just much bigger than for CS - and you wouldn’t really lose any functionality or benefits of CS.
Promoting other new web standards than ES6 could also be beneficial. Atom already use flexbox, because it gives us functionality which didn’t exist before. Why not using Web Components? It gives us the feature to scope stylesheets. This is something really important, if you want to safely extend the GUI.
I do understand the benefits for using CSON. JSON is very limited - mainly because it doesn’t support comments. But why shouldn’t Atom prefer , which is a little bit more standard-orientated?
Speaking about standard-orientated: Maybe rework would be a good alternative to Less? It would fit the idea to work with modern web technologies like ES6 or Web Components, because you can forward polyfill some newish CSS specs. It also integrates very nicely with !
I have no problem supporting CS (or TypeScript or something else) at all. But I would do it the other way around. Instead of making every example in the docs in CS/CSON and noting that JS/JSON could be used, too, in the last paragraph, make JS/JSON the default language - and note that you can use other languages like CS/CSON, too. JS will always be the common denominator.
Bottom line:
Please consider using more standard-orientated and future-orientated technologies in all docs and modules (be it a core module or something else).
06:55:45 UTC
I agree whole heartedly with TJ.
Maintainers of this tool should go read the discourse conversation about CoffeeScript painting itself into semantic corners, locking itself to ES3/5.
07:06:14 UTC
Respectfully disagree. I saw coffeescript and immediately threw my hands up.
07:18:49 UTC
That’s fine. But I definitely have to ask why.
07:39:00 UTC
Without having looked at the code, I can point out one reason to use CoffeeScript instead of vanilla JS: Literate CoffeeScript makes for easy documentation.
Also CoffeeScript is necessarily compiled down to JS, so I don’t see CS causing me any insurmountable troubles. I’ll still be able to extend the editor with JS
I’d still prefer the developers had used vanilla JS or ES6.
08:19:47 UTC
In GitHub’s :
Write new JS in CoffeeScript.
Avoid adding new .js files.
So I think CoffeeScript is very reasonable choice of their own. But we can always develop plugins with JavaScript.
10:30:56 UTC
Choosing coffee script in core will certainly impact contributions. I think it’s a short sighted and lazy choice.
11:47:57 UTC
I respectfully disagree.
I personally much prefer CoffeeScript to JavaScript, both for readability and development speed. I am much more likely to hack on a CoffeeScript project than a JavaScript project. So while CoffeeScript may discourage some it will encourage others. It’s impossible to know what the net impact will be. So, if using CoffeeScript helps them ship, go for it!
I also would not be calling GitHub lazy as they clearly are not. (When was the last time any of us made something as awesome as Atom?) Being a jerk doesn’t help make your point.
12:01:14 UTC
My comment was regarding the choice, not Github as a whole.
12:27:07 UTC
I disagree too.
IMHO Coffeescript increases code readability,
and the core must be clean.
Even if raising the entry barrier for new core developers, the contributions may have higher quality, easier to read and easier to maintain.
12:58:24 UTC
donaldpipowitch:
I do understand the benefits for using CSON.
To be honest, I would rather see them use something like
instead, which is also adapted outside of the CoffeeScript world…
18:23:38 UTC
The good thing is that if the decision were made later to use vanilla javascript, doing so is very easy - you just compile.5.3k 人阅读
标签：至少1个，最多5个
我在多年前爱上了coffeScript。对于javaScript，我一直保持着深沉的爱，也十分高兴得看到node.js的快速发展，但是作为一个有python背景的程序员，我更喜欢coffeeScript的简练语法。
在任何一个活跃的社区中，事物的迭代更新都是必然的，现在，我们看见了javaScript向着ES6标准的巨大进步。ES6包含了相比于CoffeeScript更多好的特性，并且通过如这样的工具，我们已经可以开始着手使用他们。以下是从coffeeScript迁移到ES6的一些注意点和我的想法。
放弃空格（whitespace），重新转而使用圆括号，花括号和分号。请接受在使用ES6时，你会敲上更多的符号。不过在规范的代码格式下，它们看上去还是挺整洁的。
过去我使用的是，现在我通过来使用。遵循这个语法风格指南。最好将你的编辑器设置成在输入或保存时进行语法检查。这个语法校验插件非常不错，你可以将上面的Airbnb ES6 style guide链接中的内容，放入你的.eslintrc配置文件中。SublimeText也有。
代码转换（Transpiling）
由于现在离对ES6的完美支持还很远，所以最好还是使用代码转换器（Transpiling），如，就像在用CoffeeScript时一样。不过和CoffeeScript不同的是，这里有一些值得说明的：
1，并不是所有的ES6特性全部都可用，诸如Proxies。
2，另有一些ES6特性需要使用polyfill/runtime才可用，如Symbols，generator函数，WeakMap。一段package.json的例子：
"scripts": {
"lint": "eslint --ext .js,.es6 src",
"precompile": "npm run lint",
"compile": "babel --optional runtime src --out-dir lib",
"dependencies": {
"babel-runtime": "^5.3.3"
"devDependencies": {
"babel": "^5.3.3",
请不要将babel放入dependencies中，这样会下载许多你并不需要的package，请将babel-runtime写在dependencies中，将babel写在devDependencies中。
3，一些CoffeeScript即有的特性如数组推导（list comprehensions）在ES6中也是不可用的，因为这些特性的规范还未被完全完善。
Let和Const
var已经过时了，现在流行的是它的好基友let和const。今后在javaScript中，如果要声明不可变的变量，请使用const，反之，请使用let。
语法校验会给出警告当你仍在使用var或不通过任何关键字声明变量时。
有一个值得注意的点是，const仅仅是指向变量所在的地址，这可能需要花一点时间去适应：
jsconst name = 'Daniel';
// This is a compile error
name = 'Kari';
// ---------
const options = {};
const items = [];
// This is *not* a compile error
options.foo = 'bar';
options.baz = 5;
items.push(1);
items.push(2);
// This *is* a compile error
options = {};
字符串替换
幸运的是，CoffeScript和ES6关于字符串替换方面区别很小，你要做的只是改变一下你的手指肌肉记忆：
jsconst name = 'World';
console.log(`Hello, ${name}!`);
注意反引号代替了双引号。
请确保你的编辑器能正确的高亮这些新语法，我敢保证在一开始你任然会时不时敲出#{name}。。
ES6中，有了一些新的函数类型，如generator函数和胖箭头（=&）函数。胖箭头函数在ES6和CoffeeScript中表现一致，如绑定函数中的上下文（this）为它被定义时的上下文。
函数的变参也同样被支持，但是与coffeeScript语法不同的是，ES6中省略号在另外一侧。参数默认值和解构赋值也同样被支持。
coffeeScript:
Coffeesquare = (value) -& value * value
someTask (err, result) =&
# Handle err and result
myFunc = ({source, flag}, args...) -&
otherFunc source, args...
javaScript:
jsconst square = value =& value *
someTask((err, result) =& {
// Handle err and result
function myFunc({source, flag}, ...args) {
return otherFunc(source, ...args);
generator函数：
generator函数提供了一种迭代一系列超长任务的便捷方式，例子：
js// Instead of creating a 10000 item array, we yield each item as
// needed.
function *squares() {
for (let n = 0; n & 10000; n++) {
for (let square of squares()) {
console.log(square);
通过function*语法来声明一个generator函数。这与CoffeScript中只要函数体内包含yield关键字，本函数就是generator函数不同。generator函数同样也可以yield和返回值。
类（Classes）
两者关于类的语法非常的相似，不过在ES6中，只可以在class中声明函数。下面的例子说明了两者语法的接近，包括继承：
coffeeScript:
Coffeeclass Account extends Foo
@types = ['checking', 'savings']
constructor: (@balance) -&
history: (done) -&
someLongTask (err, data) -&
# Do something with data
done null, data
deposit: (amount) -&
@balance += amount
javaScript:
jsclass Account extends Foo {
constructor(balance) {
this.balance =
history(done) {
someLongTask((err, data) =& {
// Do something with data
done(null, data);
deposit(amount) {
this.balance +=
return this.
// Currently, you can only declare functions in a class
Account.types = ['checking', 'savings'];
一个不错的特性是类有了定义getter和setter的能力，不过它们不能是generator函数：
jsclass Account {
constructor() {
this.balance = 0;
get underBudget() {
return this.balance &= 0;
get overBudget() {
return this.balance & 0;
const myAccount = Account();
myAccount.balance = 100;
console.log(myAccount.underBudget); // =& true
可遍历类（Iterable Classes）
另一个灵活的特性就是可以创建可遍历类，并且可以将generator函数用于遍历器。
jsclass MyIterable {
constructor(items) {
this.items =
*[Symbol.iterator]() {
for (let item of this.items) {
yield `Hello, ${item}`;
const test = new MyIterable([1, 2, 3, 4, 5]);
for (let item of test) {
console.log(item); // =& Hello, 1...
ES6提供了一个，这也需要花一定时间适应，因为它同时提供了匿名导出和普通导出：
jsimport _ from 'lodash';
import {item1, item2} from './mylib';
import * as library from 'library';
//普通导出
export const name = 'Daniel';
export function abc() {
export class Toaster {
//匿名导出
export default function() {
return new Toaster();
几个值得注意的点：
1，如果不使用匿名导出，你不能直接通过import moduleName from 'moduleName';来获取所有的导出对象，而是要使用import * as moduleName from 'moduleName';:
js// mymodule.js
// -----------
export function yes() { }
// script-broken.js
// ----------------
import mymodule from './mymodule';
// This gives an error about `undefined`!
console.log(mymodule.yes());
// script-working.js
// -----------------
import * as mymodule from './mymodule';
console.log(mymodule.yes());
2，如果脚本中仅仅只有一个匿名导出，那么在使用Node.js的require命令引入时，这个匿名导出的对象表现得像被传递给了module.exports一样。但是如果脚本中还有其他的普通导出，就会得到非常奇怪的结果：
js// mymodule.js
// -----------
export function yes() { }
function no() { }
export default {yes, no};
// script-working.js
// -----------------
import mymodule, {yes} from './mymodule';
console.log(mymodule.no());
console.log(yes());
// script-broken.js
// ----------------
const mymodule = require('./mymodule');
// Wat? This is an error.
console.log(mymodule.no());
// This works instead. Turns out the module is an object with a 'default'
// key that contains the default export.
console.log(mymodule.default.no());
这个坑爹的情况目前还没有任何好的解决方案。所以如果你正在写一个库并且准备让Node.js使用者使用require命令对其进行导入，最好只使用一次匿名导出，并且把一切的一切都绑定在这个匿名导出的对象的属性上。
希望本文可以帮助到一些准备从coffeeScript迁移到ES6的人，我本人也在学习ES6的过程中感受到十足的乐趣，并且我对我的新玩具ESLint和Babel实在是爱不释手。。
3 收藏&&|&&22
你可能感兴趣的文章
console.log("Hello, ${name}!");双引号居然也不解析
`console.log(&Hello, ${name}!&);`双引号居然也不解析
你可能感兴趣的文章
分享到微博？
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。Dart、CoffeeScript、TypeScript 和 JavaScript 哪种最适合专门学习？ - 知乎616被浏览<strong class="NumberBoard-itemValue" title="5,123分享邀请回答该回答已被折叠 4412 条评论分享收藏感谢收起JavaScript 现状：方言篇
JavaScript 和其他编程语言有一个很大的不同，它不像单纯的一个语言，而像一个由众多方言组成大家族。
从 2009 年 CoffeeScript 出现开始，近几年出现了大量基于 JavaScript 语言，或者叫方言，例如 ES6、TypeScript、Elm 等等。它们都有自己的优势，且都可以被完美编译成标准 JavaScript。
所以，继上周的前端框架篇，今天带来 JavaScript 现状之方言篇，看一下大家对于 JavaScript 的方言是怎么选择的。
声明：下面的部分结论来自部分数据，这是在我想要展示完整数据时找到的最好的办法，这便于我分享我的一些想法。
注意：如果你还没有参与，现在就来参加吧，可以花十分钟完成调查然后再回来看这篇文章。
首先，我想看一下参与问卷调查的人是否知道下面六种语言：
经典的 JavaScript: 97%
CoffeeScript: 99%
TypeScript: 98%
ClojureScript: 77%
你可能觉得 100% 的人都应该知道『经典的 JavaScript 』，我想是有人无法抵抗在一个 JavaScript 调查中投『我从来没有听说过 JavaScript 』这个选项的强大诱惑吧&&
几乎所有人都知道 ES6、CoffeeScript 和 TypeScript 这三种语言，比较令我惊讶的是 TypeScript 竟然会稍微落后于 ES6 和 CoffeeScript。
另一方面，Elm 和 ClojureScript 得分就要低得多，当然这也有道理，因为它们跟自己的生态环境绑定的比较紧密，也很难在已有的 App 中进行使用。
接下来，让我们一起看一下，哪一种方言吸引新开发者的能力更强一些：
要注意，该表是统计该语言对从未使用过它们的用户的吸引度，因为只有很少人没有用过经典 JavaScript，所以『经典 JavaScript 』这一列的数值很低。
ES6的数值很有趣：已有很大比例的用户在使用 ES6 了，没有用过的人中的绝大部分（89%）也很想学习它。
TypeScript 和 Elm 的状态差不多：用过的人不多，但感兴趣的比例表现不错，分别是 53% 和 58%。
如果让我预测一下，那我觉得 TypeScript 和 Elm 都很难向普通的 JavaScript 开发者讲明自己的优势。毕竟如果开发者只懂 JavaScript 的话，你很难解释清楚静态类型的好处。
另外，只有很少开发者用过 CoffeeScript，而且很明显几乎没人想去学。我觉得我该写一本 12 卷厚的 CoffeeScript 百科全书了&&
现在是最重要的问题的时间了：有多少开发者用过这些语言，有多少人还想继续使用这些方言呢？
虽然经典 JavaScript 拥有最多的用户量，但就满意度来说 ES6 才是大赢家，而且我想现在已经能安全的说，ES6 可以作为开发 JavaScript App 默认的语言。
TypeScript 和 Elm 有相似的高满意度，都在 85% 上下。然后，只有可怜的 17% 的开发者会考虑继续使用 CoffeeScript。
最后一个问题，我问大家在用现在的方式写 JavaScript 时是否感到快乐：
这个问题的答案和上一个问题的满意度想匹配：平均分达到 3.96 分（1 - 5 分），大家在使用 JavaScript 时候确实是快乐的。
不过很难说高分是因为 JavaScript 最近的一些改进造成的呢，还是发现 JavaScript 可能（仅仅是可能）没有大家认为的那么讨厌。总之，JavaScript 令人满意。
如果说上次的赢家是 React 和 Vue，那此次调查的冠军毫无争议是 ES6 了。 ES6 并带来没有开天辟地的变化，但整个社区都还是很认可当前 JavaScript 演进方向的。
我觉得一年之后我们再来一次这样的调查，结果会很有趣。同时也可以关注一下 TypeScript、Elm 还有ClojureScript 有没有继续进步。
个人认为，当前 JavaScript 大家庭百花齐放的现象还只是一个开始，或许几年之后 JavaScript 就会变得非常不同了。
结语 & 敬请期待
对于我这样的调查来说数据越多就意味着数据越准确！越多人参加这个调查，那就越能代表整个 JavaScript 社区。
所以，我十分希望你能帮忙分享这个调查问卷：
在 Twitter 上
另外，如果你想收到我下一个调查结果分析，前往
并留下自己的邮箱吧。
作者： 译者： 校对：
原创编译， 荣誉推出
共计翻译： 3 篇
| 共计贡献： 125 天
贡献时间： -&
-17%-32%-51%-61%-71%-81%
从 2009 年 CoffeeScript 出现开始，近几年出现了大量基于 JavaScript 语言，或者叫方言，例如 ES6、TypeScript、Elm 等等。它们都有自己的优势，且都可以被完美编译成标准 JavaScript。
上一篇：下一篇：
评论功能关闭
根据国家法律法规要求，本站暂时关闭文章评论功能。开放时间不确定。我们将谋求一种可以让大家更好的发表意见的方式。
根据国家法律法规要求，只有实名认证后才可以发表评论。
来自四川成都的 Firefox 48.0|Windows 10 用户 发表于
10:07 的评论：
我来吐槽一下，es6是标准，javascript是实现。怎么能说es6是一种javascript方言。
确实感觉用词欠妥。原文用词是“ Flavors”。
分享到微信
打开微信，点击顶部的“╋”，
使用“扫一扫”将网页分享至微信。
请将我们加入您的广告过滤器的白名单，请支持开源站点。谢谢您。