Coffeescript的优缺点是什么？[关闭]

当然，在很多情况下，语法糖的大量使用会导致代码缩短，这是一大优点。在http://jashkenas.github.com/coffee-script/上，有许多令人印象深刻的示例。另一方面，我怀疑这些示例是否代表了复杂的实际应用程序的代码。例如，在我的代码中，我从不向裸对象添加函数，而是向其原型添加函数。而且，原型功能对用户是隐藏的，这表明是经典的OOP而不是惯用的Javascript。

数组理解示例将在我的代码中看起来像这样：

cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...

我是即将出版的关于CoffeeScript的书的作者：http :
//pragprog.com/titles/tbcoffee/coffeescript

我确信CoffeeScript在玩了大约一周后值得使用，尽管该语言当时只有几个月的历史，而且比现在有更多粗糙之处。官方站点在列出（大部分）语言功能方面做得很好，因此在此不再赘述。相反，我只想说这种语言的优点是：

1. 鼓励使用良好的JavaScript模式
2. 不鼓励使用JavaScript反模式
3. 使更好的JavaScript代码更短，更易读

第三名比前两名（即使在我的书中）也得到了更多的关注，但是我对它的思考越多，我越意识到我并不仅仅是为了漂亮的语法而跳。我之所以跳楼，是因为该语言将我推向了更好，更不易出错的JavaScript。举几个简单的例子：

• 因为变量是自动作用域的，所以您不能通过忽略var，用相同的名称遮盖变量（带有命名参数的变量除外）或在不同文件中交互的变量来意外覆盖全局变量（请参见https://stackoverflow.com/questions / 5211638 / pattern-for-coffeescript-modules / 5212449）。
• 因为->编写起来比容易得多function(){}，所以使用回调函数更容易。嵌套嵌套回调时，语义缩进使其清晰可见。并=>使其this在适当时更易于保存。
• 仅举两个示例，因为unless x英语讲者比解析起来容易if (!x)，并且if x?比容易if (x != null)，仅举两个例子，您可以在逻辑语法上花费更少的大脑周期，而在逻辑本身上花费更多。

诸如Underscore.js之类的出色库可以解决其中的一些问题，但不是全部。

现在，缺点：

1. 编译可能会很痛苦。CoffeeScript编译器抛出的语法错误通常很模糊。我希望将来会在这方面取得进展。（在编译器的辩护中，如果您使用JavaScript编写它们，通常会发现这些错误，直到运行该行代码，您才会发现它是错误。最好早发现这些错误。）
2. 相关地，调试可能很痛苦。尚无任何方法可以将已编译的JS行与原始的CoffeeScript相匹配（尽管Firefox人士已承诺会出现这种情况）。
3. 容易改变。在以后的CoffeeScript版本中，您的代码可能会以不同的方式运行或根本无法运行。当然，大多数语言都是这种情况-迁移到Ruby或Python的新版本是类似的-但JavaScript并非如此，您可以合理地预期当今在主要浏览器上都能正常运行的代码在主要浏览器上都可以正常运行只要我们知道网络存在的时间，浏览器就可以访问。
4. 它并不那么知名。JavaScript是通用语言。CoffeeScript在短时间内变得非常流行，但是不太可能像JavaScript一样拥有如此庞大的社区。

显然，我认为优点对我个人不利，但对于每个人，团队或项目而言，情况并非如此。（甚至Jeremy Ashkenas都编写了很多JavaScript。）CoffeeScript最好被视为JavaScript的很好补充，而不是替代。

我们有一个相当大的JavaScript代码库，大约一个月前，我们决定尝试使用CoffeeScript。我们的一位开发人员开始使用http://js2coffee.org/将我们的模块之一从JS迁移到CS 。这个工具非常方便，移植了1000多个JavaScript线大约花了两三个小时。在这一点上，我们注意到了一些观察结果：

1. 生成的CoffeeScript代码非常可读。

2. 我们将其重新编译为JavaScript，并且非常容易浏览和调试。当我们移植该模块时，我们团队的另一位开发人员发现了一个错误。这两个开发人员修复了我们的旧JavaScript代码和CS编译器产生的新JavaScript代码中的错误。他们独立工作，大约花费了相同的时间（15-20分钟）。

3. 由于这是一个端口，因此所生成的代码未使用适当或理想的Coffee特定功能。如果我们从头开始用CoffeeScript编写代码，那么代码将更加惯用。因此，我们决定不再移植现有代码。

4. 通常，较短功能和较小对象的可读性有所提高。但是，对于更长的方法根本不是这样。最大的膨胀节省来自->和显式return，但除此之外，我们的代码没有显着缩短或简化。一些语法似乎很混乱，尤其是对象文字。CS省略了围绕成员定义的花括号，并与“一切都是表达式”和隐式结合在一起，return这使得一些代码很难阅读。

   这是JavaScript：

   var rabbitGenerator = {
       makeRabbit: function(rabbitName, growCarrots) {
           if (growCarrots) {
               carrots.growMore(10);
           } else {
               carrots.ensureSupply();
           }
           return {
               name: rabbitName, 
               height: 0,
               actions: {
                   jump: function (height) {
                       this.height += height;
                   },
                   eatCarrot: function () {
                       // etc
                   }
               }
           };
       },
       // more members
   }
   

   相应的CoffeeScript代码如下所示：

   rabbitGenerator = 
     makeRabbit: (rabbitName, growCarrots) ->
       if growCarrots
         carrots.growMore 10
       else
         carrots.ensureSupply()
       name: rabbitName // (*)
       height: 0
       actions: 
         jump: (height) ->
           @height += height
   
         eatCarrot: ->
   

   到现在为止，很难弄清楚return语句从第几(*)行开始。在我们的项目中，我们严重依赖对象文字：我们将它们作为函数参数传递，并从其他函数返回它们。在许多情况下，这些对象往往非常复杂：具有不同类型的成员和多层嵌套。在我们的案例中，总体感觉是，CoffeeScript代码实际上比纯JavaScript代码更难阅读。

5. 尽管调试CoffeeScript的结果比我们预期的要容易，但编辑体验却下降了很多。我们找不到适合该语言的优秀编辑器/ IDE。对于项目的客户端代码，我们尚未在editor / IDE上进行标准化，实际上我们都使用了不同的工具。实际上，团队中的每个人都同意，当他们切换到CoffeeScript时，会从其工具获得相当差的支持。IDE和编辑器插件还处于初期阶段，在某些情况下甚至无法为我们提供适当的语法突出显示或缩进支持。不谈论代码片段或重构。我们使用WebStorm，Eclipse，NetBeans，VisualStudio，Notepad ++和SublimeText2。

6. 说到工具，我应该提到CoffeScript编译器本身是作为Node JS包提供的。我们主要是Java / .NET商店，因此每个人都在Windows机器上进行开发。直到最近，Node几乎都不存在Windows支持。我们无法使CoffeeScript编译器在Windows上运行，因此暂时我们决定坚持使用<script type="text/coffeescript">标签和基于浏览器的即时编译器。

   编译器非常快，并且不会增加太多启动时间。不利之处在于，最终的JavaScript得到了evaled，并且在浏览器的开发人员工具（尤其是IE8）中很难在其中添加断点。如果调试时很麻烦，我们可以使用上面列出的迁移工具来预编译CoffeeScript代码，但这仍然不是很方便。

7. CoffeeScript的其他承诺，例如自动var插入或this使用胖箭头运算符（=>）的半透明管理，都没有像我们希望的那样带来太多收益。我们已经将JSLint用作构建过程的一部分，并ES3 x ES5-Strict使用该语言的子集编写代码。无论如何，Coffee产生相同类型的“干净”代码这一事实是一件好事。我希望每个服务器端框架也能产生有效的HTML5和CSS3标记！

   就是说，我不会说CoffeeScript通过var为我添加关键字来节省很多时间。varJSLint容易捕获缺少的，并且很容易修复。而且，一旦被它纠正了一段时间，您还是会自动开始编写良好的JavaScript。因此，我不会说Coffee 在这方面真的有帮助。

我们对CoffeeScript进行了大约一周的评估。所有团队成员都在其中编写代码，我们彼此分享了经验。我们用它编写了一些新代码，并在合适时移植了一些现有代码。我们对这种语言的感觉参差不齐。

总的来说，我不会说它没有加快我们的发展，但是也没有减慢我们的发展速度。其他方面的放缓（主要是工具支持）降低了因打字量少和错误表面少而带来的一些速度提高。一周后，我们决定不强制使用CoffeeScript，但我们也不会禁止使用它。给定一种自由的选择，实际上至少在目前，没有人使用它。我不时考虑在其中建立一些新功能的原型，然后将代码转换为JavaScript，然后再与项目的其余部分集成，以更快地开始开发，但是我还没有尝试过这种方法。

优点

查看Trevor Burnham的答案。

另外，您可以把自己想象成时髦的家伙，他在做时髦的事情，而不是弄乱JavaScript的污点。

缺点

CoffeeScript就是语法糖和粉红色眼镜。

对于简单的东西-CoffeeScript是多余的，因为使用任何语言进行简单的东西都很容易。jQuery可能甚至比CoffeeScript更简单。

对于困难的东西-您必须了解您的媒介。而且您的媒体是HTML，DOM和CSS，Javascript只是将它们互连的工具，但是-所有API都是专门为Javascript编写的。使用其他语言，然后将其编译为“实际”语言，则很有风险，例如Java（GWT），Dart或CoffeeScript。

可以通过阅读一本两本好书来解决反模式或对语言规则的平庸无知。而且我很确定Coffeescript有自己的反模式。

IDE对Coffeescript的支持甚至比JS更差。

我认为最大的优点是：

简单明了的咖啡脚本可以编译为您应该编写的javascript ，但不是，因为它不是很简单。

有一些javascript令人讨厌的角落，只有警惕才能避免-我脑中浮现的例子是：

• 正确设置原型
• 使用===代替==
• 检查空
• 用var声明所有变量
• 将所有内容包装在一个自动执行的匿名函数中。

如果您编写coffeescript，所有这些将自动为您处理。

IMO的缺点主要是次要的：

• 调试很痛苦
• coffeescript程序员较少
• 您必须将文档从javascript转换为coffeescript。

优点

1. CoffeeScript帮助我进一步了解了JavaScript
2. 即使对于复杂的嵌套回调，也非常易于阅读
3. 提供安全性，避免一些JavaScript难以找到语言问题

我发现安德鲁的上述工作示例很有启发性。我相信，只需手动识别返回值，即可提高其现有对象文字返回值的可读性

返回

//这里的对象文字

IDE工具已得到增强，TextMate和Cloud9支持CoffeeScript。诚然，Windows支持一直滞后（不过，对于Web开发而言，这不是真的吗？）

缺点

浏览器解释的CoffeeScript可能很难调试。

它是JavaScript之上的另一层，需要开发人员有所了解和考虑。

优点

1. 他们确实在语法上优化了常见情况，实际上，CoffeeScript是 http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-副词/
2. 隐藏JavaScript的不良部分（自动强制==，隐式全局变量，更传统的类系统使常见的事情变得更容易）
3. 对于Python / Ruby程序员而言非常容易学习
4. 多行匿名函数+空格语法

缺点

1. 删除var意味着您不能在不使用对象的情况下在内部范围内更改外部作用域变量，或者使用var fall_back_to_js; hacks [为什么不使用另一个仅分配值的赋值语句'：='所以obj.naem： = 5个错别字更容易调试]
2. 您必须让每个工具都知道这一点，除非您想调试JavaScript :(; btw：您可以通过添加对源地图的支持来从Chrome调试CoffeeScript； yeoman（npm install yeoman）可以帮助您编写gulp或grunt配置文件CoffeeScript
3. 没有可选的静态类型（必须等待下一个EcmaScript标准）
4. 仍然需要模块系统的第三方库
5. 要注意的语法陷阱：隐式返回，abgo表示a（b（g（o（）））），fp，b：2，c：8表示f（p，{b：2，c：8}）而不是f （p，{b：2}，{c：8}）
6. 不会更改损坏的JavaScript数字/类型系统