FirePHP is essentially an extension for Firefox that allows debugging of PHP code by outputting to Firebug instead of printing directly to the webpage. It is used mainly for debugging of PHP code, in scenarios where for example, developers working on their scripts don't want to output variables and mess up the layout, and they do not want to interrupt the end user with JavaScript alerts or pop-ups. FirePHP is server side library for PHP, and is used with the Firefox extension and Firebug. FirePHP sends output directly to the browser, without having to clutter up a web page.
FirePHP uses HTTP response headers, which are small packets of data sent by the server before the actual HTML, XML, etc is sent to the client browser. The headers usually contain meta-information such as content type, cookies, server name, and so on. FirePHP uses the output headers and embeds debug information in it, that is then sent to the client browser. The PHP script can call FB::log($variable), for example, to record that variable. FB: :log() encodes the information and places it into special X-FirePHP response headers, which are then captured by the FirePHP Firefox extension, which decodes the headers and logs the information to Firebug.
The thing really comes into its own if you're logging AJAX responses or complex data structures. You can log entire arrays, objects, stack traces, etc. etc., and these get rendered in a nicely formatted way in your console with collapsible trees for objects and so on. Better than trying to read a huge print_r() call that completely wrecks your page layout and color scheme, for sure. You can even specify different log levels, e.g. info, warn, error, which Firebug then color codes to help you scan the output for problems.
There is also something appealing in how it worked, which has been lost with these newer solutions? You could just leave your code running and add log messages wherever you wanted, without having to setup breakpoints or step through execution. Very fast iteration, low overhead. And since the output was in the console, it allowed you to group logs into different levels and views, and look at stack traces, format of complex arrays or objects without using PHP's built-in functions which were awful by default. The extension approach was also lightweight in a way that full debuggers are not—you could drop an FB: :log() call in any script, even on shared hosting (assuming you had the extension installed locally), and get output (this was before profiling tools and Xdebug took over PHP). The server side FirePHP library does all of this. You include FirePHP.class.php in your code, then initiate the library, and then call logging functions at various points in your code. Basic functions are FB::log(), FB::info(), FB::warn(), FB::error(). But there are also functions like FB: :trace(), to record the execution path of your code, FB::table() to send data in tabular format, which was really nice to use if you wanted to inspect database query results, etc. All this information gets serialized, and then written to the HTTP response headers, with some default limitations since of course HTTP headers can't be too large. Logging a very large object tree would probably be an issue here, but that's not a realistic debugging scenario...
The headers part is worth a mention as that's the key. FirePHP packages its messages in custom HTTP headers, with names like X-Wds-Log or X-FirePHP-Data depending on version. Browser is already making the request anyway so response comes back with these extra headers in the HTTP header, extension intercepts them, parses the encoded payload, and then injects it into the Firebug console panel. Clever way to get around the fact that you can't really write to the browser console directly from server-side code.
Performance isn't a problem if you're smart about it—library will detect if the extension is actually installed and running before doing any work, so in production where no one has Firebug installed it's really a no-op. And of course you still probably want to condition all this on environment variables or whatever because shipping debug headers to your production users is... less than ideal. Most people would just disable the whole thing completely in non-development environments.
If you're working on a legacy codebase that still has FirePHP in place, just leave it alone. If it's working for you, that's great, there's no reason to remove it unless you're doing a larger upgrade or modernization of the stack. But for new development? Nah, don't do it. There are better logging frameworks like Monolog, you should use DevTools in Chrome or Firefox (or their native consoles if you're on Firefox), and if you're using a PHP framework like Laravel or Symfony, there are tools like Telescope or Symfony Profiler you can use. Or install Xdebug and setup IDE breakpoints for real step-through debugging. FirePHP was a product of its time, and that time has long since passed. But it was a cool trick while it worked.
Browser compatibility was always its weak point, and it's only gotten worse. Firefox-only, Firebug-only. Firebug itself is dead now (killed off once Firefox started using WebExtensions). So FirePHP is really mostly an artifact of web dev history these days—modern browser DevTools, or Xdebug, or logging frameworks with cross-browser support. Back in its time (mid-2000s to early 2010s) though, it was seriously one of the best PHP debugging tools out there.
