Listen Gem 与 FSSM gem 相比——哪个更好？

Question

刚看了sass changelog，发现FSSM（曾经用于指南针手表任务的gem）已经被Listen替换了

我试图谷歌找出原因，但找不到确切的原因。 截至今天，FSSM 的总下载量远远大于Listen 的总下载量。 此外，据我所知（如果我错了，请纠正我）如果不支持类似 inotify 的事件，FSSM 会优雅地降级以进行轮询。 Listen 不会。

那么，如果我想在我的脚本中使用文件系统事件，有人可以解释使用 Listen gem 而不是 FSSM 的原因是什么？

统一更新： 哈哈，更新FSSM并尝试调用它后，我从FSSM收到以下消息：

尊敬的在您的项目中使用 FSSM 的开发人员： FSSM 在这一点上基本上已经死了。进一步发展将 在新的共享警卫/监听项目中进行。请 如果您需要帮助过渡，请告诉我们！ ^_^b - 特拉维斯·蒂利

所以这看起来像是 FSSM 创作者的决定。然而，这并不能消除我的问题 - FSSM 出了什么问题？

Answer 1

在this Compass 问题中讨论了该开关。 Listen 目前似乎比 FSSM 更积极地由多个核心 Guard 开发人员维护。如果警告消息来自@ttilley（谁是 FSSM 的作者），则更可信。

在运行compass watch somefile.css.scss（使用罗盘 0.12.2）时，我也收到了 FSSM 警告消息。似乎只是切换到 Listen 的 coming attraction，而 yet 似乎没有发生。

根据当前的 Listen 文档，如果操作系统适配器无法确定文件是否已更改，它也会优雅地降级为轮询。