Why pico-xbar
Pico-xbar was a weekend project... one of those "weekend" projects that end up stretching over several weeks. The kind where you can't stop working until they're finished. It turned out to be the first (along with PicoJSX) of my hobby projects that I marked as "public" on my GitHub profile after deciding to share a bit more of what I do.
The reason for the pico-xbar experiment is that I recently upgraded my MacBook to one with 64GB of unified memory. It might not be much by current standards anymore, but the jump from the 16GB on my old MacBook feels huge. And the more RAM you have, the more jealous you become about its usage. It happened to me. I found myself constantly checking which apps were consuming the most memory, cursing Google Chrome, minimizing the use of Electron-based apps, and preferring native apps. All to keep memory usage as low as possible—a nonsense. That's where pico-xbar comes in.
I've been a user of xbar for years. I became addicted once, trying to avoid using apps like Local by Flywheel, I installed the entire WordPress development stack using homebrew. A custom xbar script was enough to have an icon in the macOS menu bar that, when clicked, showed me options to select a different PHP version or turn Apache, MariaDB, or XDebug on/off. More recently, I use it to show an icon indicating the current state of the Mac keyboard's multimedia keys, since I constantly configure them to function as function keys for certain terminal tools, but switch back to their regular use when I want to listen to music, for example.
So, during my paranoia about memory consumption, I realized that xbar was using a lot—a ton of memory—for an app that just shows a menu in the system bar and nothing else. A quick look at the macOS Activity Monitor revealed the reason: filtering the process list by "xbar" showed 4 processes with names very characteristic of apps that use web technologies for their graphical interface. But what graphical interface does xbar have? The "Plugin Browser." A window you only open once in your life was using a good chunk of memory all the time. "We have to remove that window. It's open source, and it's a good excuse to write some Go," I thought, and I got to work, believing it would just be a matter of removing some references here and there and in a few hours I'd have a more efficient version.
It was certainly good practice. Not just in Go, but also in Objective-C and AppKit, technologies I hadn't used since my days at Teknol, back when ARC was a novelty. This was because xbar is made with Wails, which is nothing more than a more specialized Electron that uses Go as the backend instead of Node. It wasn't possible to simply "excise" Wails; on the contrary: I had to excise the useful code and re-implement it in an app without Wails. Wails has a very flexible API for creating any number of elements in the macOS menu bar and constantly updating their content, something I couldn't reproduce with any of the popular Go modules that already exist, which is why I ended up getting my hands a bit dirty.
In the end, it was all worth it, and I have my own xbar that's not only more efficient but also updates the menu contents even when they're deployed. I chose the "pico" prefix for obvious reasons: "pico" being smaller than the traditional "nano" used to denote small things. I also did it to align it with PicoJSX, PicoTap, and PicoGap, which are other baby projects of mine.