Does the web-console gem supersede the better_errors gem?

Question

Is the rails 4.2 web-console gem a complete replacement for the better_errors gem or do I need to look at the features of each to work out which one I will prefer?

Answer 1

They're not the same thing.. The web-console even recommends better_errors on it's README:

Check out better_errors as a great alternative for any Rack application!

The advantage of web-console is that you can start a console session calling debug anywhere in your files or views, pretty much like binding.pry (from pry gem) always did.

The better_errors is an improved error screen that happens to have a console session on the sidebar (if you use the binding_of_caller gem with it).

IMO, you can use both gems.. no need to choose one or another.

Answer 2

TL;DR: better_errors is better.

I disagree with the accepted answer here. Mainly because the difference suggested aren't real.

It's always been trivial to trigger a better_errors console anywhere you wanted, as easy as raise 'bang'. You throw an exception at the point you want and a console gets started in that context. You can raise an exception in any of your files or views and get a console in that context.

I'm not sure if the accepted answer was implying that web_console wouldn't get triggered on an exception and that's why he suggested using both gems, but in any case it's now true that web_console does trigger on exceptions too.

So given there's no functional difference, well, firstly, there's no point running both gems. In fact I'd expect conflicts, though maybe it just comes down to which one catches the exception first.

Secondly, the real difference is that better_errors is just better. Look at screenshots of the two. web_console is just the standard rails exception page with a bare black terminal under it. If you want to know local or instance variables you have to inspect them with the console. better_errors has (to my taste at least) a much prettier styled page, but more importantly it shows the call stack (with compact or full listings), it gives you the code listing where it was triggered just above the console and then below the console it lists request/local/instance variables, which will often explain what the problem is without having to do anything in the console itself. That's a bunch of extra, useful features and nothing missing that web_console has (unless minimalism is your bag).

I don't know why 37Signals/Basecamp or the Rails team decided to incorporate web_console rather than better_errors. Maybe there are design-philosophy/architectural reasons they want to keep it at arms length, maybe they think it's too full featured to be automatically included. Some people seem to think 37Signals strongly prefers stuff built in-house or that can be taken in-house, and maybe that's the only reason why.

Other things that have changed since Thiago posted are that, as marklar says, you now start web_console with console not debug and that web_console no longer suggests better_errors as an alternative in its GH README.