在生产环境中使用 CoffeeScript
我真的很喜欢将 CoffeeScript (1.1.1) 用于小型项目，并且到目前为止效果很好.但是，在更广泛的环境中使用它之前，我想听听关于在生产中使用它的第二个意见.
I really like using CoffeeScript (1.1.1) for small projects and it worked out great so far. However before using it in a more broad environment I would like to hear second opinions on using it in production.
所以我的问题是:
- 语言本身的稳定性如何?
- 我是否需要注意即将发生的会破坏我的代码的更改?
- 如果上述问题的答案是肯定的:旧版本的支持情况如何?
- 是否有稳定版(仅限错误修复)和单独的开发分支?
- 如果您已经在您的产品/网站/等中使用过 CoffeeScript，请描述它的使用范围和您的整体体验.
谢谢！
注意:我已经听说Ruby on Rails 3.1 版将包含对 CoffeeScript 的支持".(维基百科)这很棒，因为来自 Rails 社区的额外支持.
Note: I've already heard that "CoffeeScript support will be included in Ruby on Rails version 3.1." (Wikipedia) which is great because of the additional backing from the Rails community.
推荐答案
该语言在过去六个月里一直很稳定(1.1.1 基本上只是 1.0 修复了错误).这并不能保证未来的稳定性，但我不希望 我的书 在任何时候都完全过时很快.
The language has been stable for the last six months (1.1.1 is basically just 1.0 with bugfixes). That's no guarantee of future stability, but I don't expect my book to be totally obsolete any time soon.
我想说避免版本问题的最佳做法是
I'd say the best practices for avoiding version issues are
- 确保记录您的项目所针对的 CoffeeScript 版本，并且
- 在该版本下编译成 JS 并将 JS 保存在某个地方
- 拥有良好的测试覆盖率(用 Samuel Adams 的话来说:总是一个好的决定！)
这样，当新版本的 CoffeeScript 发布时，您可以使用 JS 备份以防您的 CoffeeScript 代码损坏.破坏性更改是一种痛苦，但它们对于几乎所有语言来说都是一种痛苦除了 JavaScript——只要问问最近从 1.8 过渡到 1.9 的 Rubyist，或者仍在迁移 Python 2 的 PythonistaPython 3 的代码.
That way, when a new version of CoffeeScript is released, you have a JS backup to use in case your CoffeeScript code is broken. Breaking changes are a pain, but they're a pain common to nearly all languages except JavaScript—just ask a Rubyist who recently made the transition from 1.8 to 1.9, or a Pythonista who's still migrating their Python 2 code to Python 3.
我可以给出的防止您的代码在 CoffeeScript 版本更改下中断的建议是避免语法边缘情况.例如 func a:b, c 以前表示 func {a:b, c:c}，现在表示 func {a:b}, c.这是一种改进(旧的行为被认为是一个错误)，但有些人对此措手不及.因此，只要有模棱两可的迹象，就使用明确的标点符号；无论如何，它使代码更具可读性.
The advice I can give for preventing your code from breaking under CoffeeScript version changes is to avoid syntactic edge cases. For example, func a:b, c used to mean func {a:b, c:c}, and now it means func {a:b}, c. That's an improvement (the old behavior was considered a bug), but some folks were caught off-guard by it. So use explicit punctuation whenever there's a hint of ambiguity; it makes for more readable code anyway.
Jeremy 将不得不评论 stable/master 的区别，因为这两个分支都存在，但 stable 自 4 月以来一直没有更新(1.1.0 之前的版本).
Jeremy will have to comment on the stable/master distinction, since both branches exist but stable hasn't been updated since April (pre-1.1.0).
相关文章