rails 4.2 web-console gem是否是better_errors gem的完全替代品，还是我需要查看每个gem的功能以确定我更喜欢哪一个？
答案 0 :(得分：6)
他们并不是一回事.. web-console甚至在其自述文件上推荐better_errors：
查看better_errors是任何Rack应用程序的绝佳选择！
web-console 的优势在于，您可以在文件或视图中的任何位置启动调用debug的控制台会话，非常类似于binding.pry（来自{{3总是这样做。
better_errors 是一个改进的错误屏幕，恰好在侧边栏上有一个控制台会话（如果你使用pry gem）。
IMO，您可以同时使用这两种宝石..无需选择其中一种。
答案 1 :(得分：0)
TL; DR：Better_errors更好。
我不同意这里接受的答案。主要是因为建议的差异不是真实的。
在任何您想要的地方触发一个Better_Errors控制台一直很简单，就像raise 'bang'一样容易。您在想要的地方抛出异常，控制台便在该上下文中启动。您可以在任何文件或视图中引发异常，并在该上下文中获取控制台。
我不确定是否接受的答案是否暗示不会在异常上触发web_console，这就是他建议同时使用这两个gem的原因，但是在任何情况下，现在web_console确实也会在异常上触发。
因此，鉴于功能上没有区别，首先，运行两个gem没有意义。实际上，我期望有冲突，尽管也许只是首先导致异常的原因。
第二，真正的区别是Better_errors更好。看两个的截图。 web_console只是标准的rails例外页面，其下有一个黑色裸终端。如果您想知道局部变量或实例变量，则必须使用控制台进行检查。 better_errors具有（至少在我看来）样式漂亮得多的页面，但是更重要的是，它显示了调用堆栈（具有紧凑列表或完整列表），它为您提供了在控制台上方然后在控制台下方触发的代码清单它列出了请求/本地/实例变量，这些变量通常可以解释问题所在，而无需在控制台本身中进行任何操作。这是一堆额外的，有用的功能，web_console并不缺少任何东西（除非极简主义是你的包）。
我不知道为什么37Signals / Basecamp或Rails团队决定合并web_console而不是Better_errors。也许出于设计哲学/建筑方面的原因，他们想保持一定距离，也许他们认为它的功能太强大，无法自动包含在内。有些人似乎认为37Signals非常喜欢内部制作或可以内部制作的东西，也许这是唯一的原因。
自Thiago发布以来发生的其他变化是，正如Marklar所说，您现在以console而不是debug来启动web_console，并且web_console在其GH README中不再建议使用Better_errors作为替代。 / p>