Yeah you always need a backend part as part of your dev dependencies but currently you also need to add a little snippet in your production view code.
It could be a browser extension like Rails panel + meta_request but I think it’s also good that anybody working on the codebase always get the debugbar, regardless of their browser or setup.
The downside is that if the project decides not to have that in the code, nobody gets it. Example: I suggest to a customer to use it. They decide they don't want it, I can't use it too.
Without some kind of perf api baked into rails, this will require some server side code at the very least. An extension won't work without _something_ on the server.
But, there's also nothing stopping you from adding this during development and not committing it.
One thing to check out: ruby-lsp gets around this by using a custom gemfile, which enhances the project with the lsp's dependencies. That means you can use the gem, with bundler, without adding anything to the "official" project gemfile.
You could probably accomplish something similar, and possibly inject some rack middleware to add the view, or even mount it as a rails engine.
> NOTE: starting with v0.7.0, it is no longer recommended to add the ruby-lsp to the bundle. The gem will generate a custom bundle in .ruby-lsp/Gemfile which is used to identify the versions of dependencies that should be used for the application (e.g.: the correct RuboCop version).
If you click learn-more on the linked page the first section ends with this:
".... I was able to explore my application in ways I didn't think was possible. Yet, I always missed what I was used to in PHP with the Laravel Debugbar."
Look at what they did for the last 20 years for Basecamp and other product. It doesn't seem very likely that they randomly raise prices for existing customers.
