SnippetsLab vs a Plain Folder of Gists: 6 Months Side by Side

Why I Ran Two Snippet Systems At Once

I spent six months running two competing systems for code snippets.

On one side: SnippetsLab on macOS. Polished, native, search box in the menu bar, syntax highlighting for basically everything.

On the other side: a plain folder of gists. Literally a directory of .md and .txt files, backed by Git, pushed to GitHub gists from the terminal.

I did not do this as a thought experiment. I did it because my snippet situation was a mess.

VS Code snippets. Old Evernote notes. Some random Notion pages. Half-remembered StackOverflow bookmarks. You know the drill.

So I forced myself to pick two contenders and actually live in them. Full time. No “just this once I’ll paste it into Notes”.

Here is what survived contact with reality.

The Two Setups, In Practice

This was the exact setup I ran.

SnippetsLab setup

• SnippetsLab on macOS, from the App Store.
• Library stored in iCloud Drive so both my Macs could see it.
• Structure: a handful of top level folders: css, js, react, devops, notes.
• Each snippet tagged with 2–3 tags: framework, topic, and today if I created it that day.
• Global hotkey to bring up the search window from anywhere.

Plain gists folder setup

• Folder: ~/code/snippets.
• Each snippet is a separate file. slugged-title.language or slugged-title.md.
• Backed by Git, synced to a private GitHub repo.
• One script to convert a file into a GitHub gist if I want it public.
• Search handled by rg (ripgrep) and Spotlight. Sometimes VS Code “Open Folder”.

No fancy UI. No hierarchy beyond folders. No tags. Just files and Git.

Speed Of Capture: Who Got Used More

What matters most for snippet tools is not features. It is time to capture.

Can I throw something in there in 10 seconds, in the middle of a messy debugging session, and trust it will be findable later.

SnippetsLab capture workflow

My SnippetsLab capture flow looked like this:

• Select code in VS Code or Chrome DevTools.
• Hit the global hotkey to bring up the SnippetsLab window.
• Click New Snippet, paste, select language, add title, add tags, pick folder.

On a good day that is 15–20 seconds. On a bad day I start fiddling with tags and spend a minute “organising”.

It feels nice. Feels like I am curating a little personal StackOverflow. That feeling is a trap. It encourages perfectionism instead of capture.

Gists folder capture workflow

The plain-folder capture flow was much more brutal.

• Copy the code.
• Hit a custom Alfred workflow or shell alias that creates a timestamped file in ~/code/snippets/inbox.
• Paste, maybe add one-line title at the top. Save. Done.

Average time: under 10 seconds, every time. No friction. No options.

After a week this became automatic. I stopped thinking about it.

If I did nothing else, the inbox filled with raw snippets. Once or twice a week I cleaned it up: rename the file, move to a folder, commit, push.

Because of that, the folder system ended up with more snippets than SnippetsLab, even though SnippetsLab is objectively a nicer app.

Search: Where The Fancy UI Actually Helped

Capture speed is one side of the story. Retrieval matters more.

The obvious fear with raw files is: “I will never find anything again.”

SnippetsLab search

SnippetsLab has a global search box with nice fuzzy matching. Type “react debou” and it suggests “react debounce hook”, plus any snippets tagged with react or debounce.

Syntax highlighting is clean. Multi-language snippets look fine. I liked how comments and code were visually separated. For skimming longer snippets that helps a lot.

For exactly-remembered snippets SnippetsLab is fast. I type 3–4 characters and hit enter.

Where it fell down for me is vague memory search. When I barely remember what I called something and mostly remember a fragment of an error message or a particular CSS property I used.

SnippetsLab search matches titles, content, and tags. It works. But it is slower and less precise than my terminal muscle memory.

Folder + ripgrep search

My folder search flow looks like this:

cd ~/code/snippets
rg "setTimeout"

Or in Alfred: type snip <term>, which runs rg under the hood and opens matches in VS Code.

For vague-memory search this is excellent. I search by random words that appear in the body of the snippet, not the title.

“shadow-md hover:scale-105” will find me the tailwind card example I half remember. “ERR_INVALID_ARG_TYPE” will find the exact Node API bug I hit in March.

And because it is just files, Spotlight also works as a soft backup. If I forget my own commands I can still type into macOS search and land somewhere useful.

So this one surprised me. I expected SnippetsLab to win search by a mile. In practice, the raw power of grep + keyboard habits beat the polished UI more often than not.

Structure, Tags, And The Illusion Of Organisation

I like structure. I coach baseball. I optimise sleep. I like systems.

SnippetsLab is catnip for people like me. Folders, tags, colors, icons. You can create a beautiful taxonomy of your past work.

Here is the problem. Maintaining that taxonomy became its own job.

I would paste a 15-line snippet, then spend more time deciding “Is this React or Frontend or Performance?” than I had spent writing the code in the first place.

The folder of gists did not give me the option. It was mostly:

• css
• js
• infra
• random

Almost everything fit into one of those. If something did not, it went to random, and future-me could deal with it or ignore it.

Over six months, SnippetsLab looked more organised, but the effective organisation was not better. I still searched by keywords most of the time.

Tags felt great on day one and completely optional by month three.

Sync, Backup, And Lock-In

This is where my bias really shows.

I trust Git + plain text more than any app database. I have seen enough proprietary formats die.

SnippetsLab sync

SnippetsLab stores its library in a single database file. You can sync that through iCloud or Dropbox.

iCloud sync was mostly fine, but I had two annoying incidents.

• Once, after a macOS update, SnippetsLab came up with an empty library for about 30 seconds while iCloud rehydrated the file. I nearly had a heart attack.
• Another time, both Macs were open, and I edited the same snippet on each machine within a short window. One of the edits disappeared. No visible conflict handling.

Neither issue lost me critical data, but my trust took a hit.

Git-backed folder sync

The git-backed folder did not care about macOS updates. Or about which editor I used. Or about my future self.

It is just files. I commit regularly. Push to GitHub. Occasionally pull on the other machine.

Worst case, I get a merge conflict in a single snippet file. I fix it like any other code conflict.

Long term, this also keeps my options open. If I decide in two years that I want to move everything into some web-based tool or a different snippet manager, I can feed it a directory of .md files and call it a day.

SnippetsLab has export, which is nice. But needing an export step at all is already a form of lock-in for me.

Daily Usage Patterns: What I Actually Reached For

Numbers time. Over six months, on my main Mac, I tracked my usage roughly like this.

• Snippets created in SnippetsLab: around 90.
• Snippets created in the folder: around 220.
• Retrievals from SnippetsLab (window opened with actual copy): roughly 140.
• Retrievals from the folder (terminal or VS Code search resulting in a paste): around 260.

Early on, the split was closer to 50/50. By month four it was not. I just stopped putting new things into SnippetsLab unless I needed its specific strengths.

Those strengths were mostly:

• Multi-part snippets where I wanted a description, code, and maybe a shell command together.
• Visual references, like when I pasted a small SVG or wanted to remember a diagram.
• Presentations. When I was pairing or sharing screen and wanted a nice UI to browse examples, SnippetsLab looked professional. The folder did not.

For everything else, the folder won just by being boring and fast.

When SnippetsLab Is Clearly Better

Despite all that, I do not think SnippetsLab is bad. Far from it. It just solves a slightly different problem well.

Here is where I think SnippetsLab genuinely shines.

Teams and teaching

If you are the “developer who teaches other developers” on your team, SnippetsLab is useful.

You can group snippets into collections, add clean titles and descriptions, and then screen share that while walking through an onboarding session.

A raw folder in VS Code looks sloppy in that context. It is fine for me. It is not as friendly for someone new to the codebase or to the stack.

Heavier use of tags and metadata

If you love tags, and you actually use them, SnippetsLab gives you a UI that rewards that behaviour.

You can think in tag intersections: “show me all react snippets that touch forms and validation.”

With plain files you can fake that with naming conventions and grep, but it is clunkier. I personally do not think in tags often enough for this to matter, but some people do.

Living entirely on macOS

If you are 100% on macOS, never touch Linux, and do not care about future portability, then the native feel of SnippetsLab is nice.

The menu bar icon. The hotkeys. The minimal friction to paste into any Cocoa text field. All of that is smoother than my terminal-heavy setup for most casual users.

Why I Ultimately Stayed With The Boring Folder

After six months, I did something decisive. I turned off SnippetsLab’s auto launch.

It is still installed. I still open it once in a while when I want to show someone something cleanly. But my default stack is now:

• Folder of snippets under Git.
• Couple of small shell scripts and Alfred workflows for capture and search.
• VS Code or Neovim as the viewer.

The reason is not that SnippetsLab is bad. It is that tools that pretend to be simple but add invisible friction annoy me more than tools that are obviously manual and dumb.

Every time SnippetsLab triggered my “organise this properly” instinct, I paid a cognitive tax. The folder never asked for that. It just accepted the mess.

And I have learned that for anything I expect to live longer than a year, simplicity and portability beat polish.

How I Would Decide If I Started Fresh

If you are reading this because your snippets are scattered and you want to fix it, here is how I would choose, knowing what I know now.

• If you want a personal snippet knowledge base that feels like an app, with tags, folders, and a nice UI, use SnippetsLab.
• If you want a low-friction, long-term, no-drama archive that you can migrate easily in 5 years, use a Git-backed folder of text files.
• If you work across Linux, Windows, and macOS, do not even bother with native-only tools for this. Use the folder.
• If you teach often or onboard juniors and want to show snippets on calls, SnippetsLab helps you look more prepared.

Honestly, you cannot really get this wrong, as long as you actually use whatever you pick for a month.

That is the main lesson from my six months of running both in parallel. The real value did not come from which tool I used. It came from the simple discipline of capturing everything I did not want to think through twice.

The plain folder just made that discipline slightly easier to keep.