Forem: Grant Ammons

I built a Slack TUI in a week

Grant Ammons — Sun, 17 May 2026 11:26:24 +0000

Slack was having a bad day on my machine. Typing :wave: was taking two seconds to autocomplete. Two seconds to autocomplete an emoji! The fan was spinning. The whole app felt sluggish.

I have Slack running pretty much nonstop. Most people do. And the whole time I was watching that emoji dropdown crawl I kept thinking.. man, this is just text.

Terminals are great at text. The tools I rely on every day - vim, btop, tig, k9s - are a joy to use. They are incredibly fast and responsive. They feel alive. Meanwhile the app that I have to live in all day, where all my conversations happen, is the slowest thing on my machine. It is also freaking enormous, a bundled Electron app that takes up a ton of memory and disk.

Slack is just text. Terminals are great at text. So why am I running 1.5GB of Chromium to read it?

Where are all the TUI Slack clients?

I figured someone would have built this already. Slack is twelve years old. The TUI ecosystem has been mature for years. The intersection seemed obvious.

But it didn't exist. Not really. There were a few projects, mostly abandoned, mostly bare-bones. Nothing daily-driveable. Nothing that felt like a real Slack client. The gap was weird.

The honest answer is that polishing a TUI Slack client probably wasn't worth one person's year. Slack works, more or less, for most people. The desktop app is bloated but functional. The cost of building a real replacement was high and the audience was small. So nobody did it.

The unbuilt apps in the world aren't blocked by demand anymore. They're blocked by whether someone cares enough to scratch the itch.

What if I built it?

So I decided to try. Were TUI libraries up to a good Slack experience in 2026? Many unknowns: Real-time messaging. Threads. Multi-workspace. Polish that didn't feel like a 1995 IRC client. Images and avatars, which I knew were possible in terminals but didn't know how they worked, or whether they'd hold up in a Slack TUI.

The answer, working through them one at a time, seemed to be yes. The TUI ecosystem is in a really good place. Opencode, the AI coding TUI, was already proof. I use it daily. Modals, spinners, motion. Well put together.

Early on while I was deciding the stack, I really wanted to land on one single, portable binary. I didn't want to ask users to install Node or Python or Ruby or any runtime. I wanted a single download that just worked. That meant Go.

The next question was what TUI libraries are available for Go. I discovered charm.land. What a joy this suite of librares is. Bubbletea handles architecture, lipgloss handles styling. The V2 release also handled layouts, which was the key to making it feel polished without a ton of custom code.

Images and avatars are a core part of Slack's UX. So I knew I needed to figure out something there. Kitty's graphics protocol does what it says on the tin, and my tests showed it was viable for my use case.

All that being done, I figured I'd let agents do most of the typing and see how fast I could go.

The build

I started with the part I was most worried about: images.

The Kitty graphics protocol gives the terminal a way to render true-pixel images, not just half-blocks or sixel. In a Kitty or Ghostty terminal, slk shows real Slack avatars and images. They look like avatars, not blocky ASCII approximations. This was the moment slk stopped feeling like a half-toy. The screenshots in this post look the way they do because the avatars and images actually render in the terminal. If you try slk in a non-Kitty terminal, you'll get ASCII approximations instead.

The main slk view. Avatars are real pixel data rendered via the Kitty graphics protocol, not ASCII approximations.

The rest of the work was less surprising and more satisfying. Real-time messages, edits, deletes, reactions, and typing indicators over a WebSocket. Multiple workspaces stay connected in parallel with live unread badges in the left rail. Press 1 through 9 to jump between them. Vim-style modal editing. Fuzzy channel finder. Threads in a side panel, plus a workspace-wide threads view because I always forget which channel a thread came from.

The threads side panel. The workspace-wide threads view sits one keypress away.

35 themes ship with it (including Hot Dog Stand, haha. I'm old.), with a live switcher. Smart paste handles clipboard images and file paths and text in one go, captions included. Slack-native sidebar sections are kept live, or you can configure your own with globs.

Mid-switch in the live theme switcher. 35 of these ship with slk.

The binary is 24 megabytes. A live multi-workspace session uses a fraction of the RAM. The official Slack app on the same setup uses five hundred megabytes to a gigabyte and a half. Same conversations. Same productivity.

This isn't a toy. It's my daily driver on Linux and Mac.

One week of intense vibed-out building

The spark hit hard.

I had been irritated by Slack for years, the kind of irritation that builds when a piece of software is always there but never quite right. Once I started writing slk, I couldn't stop. I ravenously coded for a week. I shipped more commits in those seven days than I'd shipped in any week of my life.

One week of slk commits. More than I'd shipped in any week of my life, and I commit stuff near-daily.

The setup was four tmux windows, opencode in each one, agents running in parallel git worktrees. Most of the typing was theirs. The decisions were mine.

The agents were great at the things I didn't want to spend a week on. Bubbletea boilerplate, lipgloss styling, parsing Slack's internal protocol, the theme system. The repetitive UI plumbing that holds the whole thing together.

I drove the things that mattered, starting with the architecture. After that was settled, it was a matter of implementing functionality on top. Then many many rounds of small polish decisions that make a tool feel alive, not just functional.

The reality is that building this way feels magical and is insanely addictive. The agents did not replace the builder's high of seeing something work. They cranked it up to borderline unhealthy levels. I was riding a wave of obsession for a week, and the agents were the jet fuel.

Most vibe-coded projects are toys because most people stop. slk is what happens when a builder gets obsessed and runs four agents in parallel for a week. The skill isn't writing code. It's communication, judgment, and being ready to ride the obsession when it shows up.

...but slk is not garbage

The line on vibe-coded software is that it is garbage. Unreliable. Falls apart the second anyone pushes on it. I am living that in my day job right now. The people saying it are not wrong.

slk is not that. slk works. The reason is not the agents. The reason is how I drove them.

I challenged the agents deeply on architecture at the start. I stressed unit tests and TDD for every change. I stressed documentation and readability. I actually read the code.

I insisted on agents generating code I would have strived to have written myself - well-documented, well-factored, easy to change, easy to extend. All those things that Uncle Bob likes. If the agent shipped code that didn't meet that bar, the code did not stay.

Most vibe-coded projects are garbage because most operators don't bring the discipline. The agent is the typist. You're still the architect.

Try it out

I built slk for me. That has not changed. If you live in the terminal and live in Slack, it might fit your life too. If it does, here you go:

brew install gammons/tap/slk

The source is on Github. There's also a marketing page of sorts. The wiki has setup, keybindings, and configuration. Read the tradeoffs page first if you want to know what is and isn't there. It's still not perfect - there are missing features and bugs. But it is a real Slack client that you can use today.

slk is not feature-complete. Huddles, screen sharing, and Slack apps are not there. But it is my daily driver. PRs welcome. Bug reports more welcome. The people I most want to hear from are terminal nerds who try it.

What I learned creating 12inch.reviews, a mashup of Spotify and Pitchfork

Grant Ammons — Wed, 22 Jul 2020 14:56:57 +0000

I'm a huge music nerd. I've played in many bands in my teens 20s, and music is a big part of my life. I'm also a big fan of Pitchfork music reviews.

There was a mashup site I was using called Pitchify, which was no longer updating, and it eventually got taken down. So I did what any engineer would do and I created my own mashup!

12inch.reviews is a mashup of Pitchfork's album reviews with Spotify's web playback SDK. It utilizes the browser's IndexedDB API to allow for fast, responsive searching and sorting of 17k+ album reviews, and allows you to play the full album right in the browser!

As with any side project, I had a few learning goals in mind that I wanted to bake in:

Continue to invest in learning React, specifically React hooks, and progressive web apps.
Learn tailwind.css
I wanted it to include all of Pitchfork's reviews, and have them be easily searchable. There are a lot of seminal albums that I just haven't had exposure to. Being able to find them easily would be a requirement.
I wanted to leverage different and interesting browser technologies to keep the main functionality of this site all on the frontend.
I wanted it to be completely open source.

Pitchfork has over 20k reviews on their site, so being able to store that many records on the frontend, specifically in Javascript, would be a challenge. Each browser has different storage quotas that aren't particularly well-documented. So I needed to think about how to work around these quotas in a seamless and transparent way.

The backend

12inch.reviews uses a simple(ish) retriever script script that does the following:

utilizes Pitchfork's undocumented API to find new albums since the last time the script was run
Attempts to find that album using Spotify's search API.
If found, add that album to a simple SQLite DB

There is another backend function that will take the contents of the SQLite DB and to create a series of JSON files, which includes all the data the frontend needs. The structure of each JSON album looks like so:

    {
      "id": 13501,
      "pitchfork_id": "5929e2d1eb335119a49ef060",
      "title": "Out of Tune",
      "artist": "Mojave 3",
      "rating": "6.3",
      "bnm": false,
      "bnr": false,
      "label": "4AD",
      "url": "https://pitchfork.com/reviews/albums/5376-out-of-tune/",
      "description": "Out of Tune is a Steve Martin album. Yes, I'll explain: Once upon a time, there was ...",
      "genre": "Rock",
      "spotify_album_id": "2TLUvacBePI5753CqHPpxF",
      "spotify_artist_id": "4jSYHcSo85heWskYvAULio",
      "image_url": "https://i.scdn.co/image/ab67616d0000b27360b1fa1c0a15bcb97f9544a2",
      "page": null,
      "created_at": "1999-01-12 06:00:00 UTC",
      "updated_at": "2019-10-25 12:33:03 UTC",
      "timestamp": 916120800
    },

Once the JSON files are created, they are uploaded to S3 for the frontend to use. Each album entry has all the info needed in order for Spotify's web SDK to use them on the frontend, and to be searchable.

The retriever Rakefile also has functions to backfill all albums (takes multiple hours!) and has some utility functions to be able to create a new SQLite DB and other functions to massage the data into the correct format.

The main task, refresh_and_upload runs hourly. Currently it's running as a Kubernetes CronJob on my homelab Kube cluster (I'll talk more about that in another post).

Netlify Lambda functions

12inch.reviews is hosted on Netlify, mainly because Netlify is amazing. It provides a seamless CI/CD pipeline, SSL, and AWS Lambda-like functions - all for free.

I use these functions to "log in" a user via Spotify Oauth. I would have done this all on the frontend, except for the fact that Oauth requires a secret token and that can't be exposed on the frontend.

Since Spotify's access tokens are short-lived (1 hour max!) there is also a secondary function that will renew an access token seamlessly upon playback.

Once an access token is obtained, state is stored via the browser's LocalStorage API.

The frontend

The frontend of 12inch.reviews is a relatively simple create-react-app single-page app, that provides search and sort functionality, as well as the ability to play any album using Spotify's web playback SDK.

Getting all the album data

When you visit 12inch.reviews the first time, it will show the albums from a small JSON file called initial.json. This file includes only the first 25 most recent albums, so we have something to paint on the screen.

Then, the rest of the album data will be backfilled in via a series of fetches to retrieve all of the JSON files. I decided to partition each JSON file with 1000 albums, so there are 17 files altogether. Each album JSON file is at least 600k uncompressed, so there is probably room for more optimization here.

After each JSON file is retrieved, they are stored in an IndexedDB on the frontend. Subsequent visits to 12inch.reviews don't require the large JSON payload - it will only load the delta payloads into the DB. I'm taking advantage of the fact that these reviews are immutable - once they are written they will never change.

Searching albums

Although IndexedDB is great for storing this data, there is currently no functionality to actually query IndexedDB like a regular database. So in order for 12inch.reviews to do searching and sorting, all of the data must be loaded into a simple javascript array.

Playing albums

I utilized Spotify's Web playback SDK to do the actual playing. It provides a series of hooks to use in order to initialize the player, and to do the actual playing.

I wrapped the actual playing into a simple class that ensures a refreshed access token is always provided.

The player component is one of the most complex react components in the app. Although the web playback SDK has its own state, I had to essentially "sync up" the player component's state with the SDK's state. As with any type of synchronization, there are probably bugs keeping these 2 things in sync with each other.

The progress bar is clickable and utilizes some simple CSS animations to look and feel like a regular music progress bar.

IANA designer, but I was heavily influenced by Tesla's UX when designing the player component.

Criticism of Spotify's Web Playback SDK

My experience with Spotify's web playback SDK has been sub-par. The SDK does not have a package.json file, and therefore is not in the npm universe. There isn't an easy way to hook the SDK into a React or Vue app. This required a lot of manual syncing code that is probably hiding bugs.

They have a public issue tracker on Github, but many of the issues don't have answered questions.

It's hard for me to understand who the target audience was for this SDK. I think it would benefit greatly from being open source and part of the NPM ecosystem. This would allow others to create wrappers for popular frameworks, which would allow me to remove my terrible syncing code.

Lessons learned + planned optimizations

This was a really fun project to work on. It took me about 6 weeks of coding, utilizing my "side project hours" (roughly 5:30am - 7am on weekdays).

I learned a bunch of things:

Tailwind.css
IndexedDB
Netlify Lambda Functions
Spotify's APIs

12inch.reviews is a toy. It has enormous shortcomings, mainly the fact that it needs to backfill nearly 20Mb of album review data in order to work well. This is insanely inefficient and wouldn't be appropriate for anything other than a personal side project site coded for educational purposes.

Other shortcomings:

I don't feel like I leaned into Flow types as much as I could.
Overall performance is still not great, as measured by Chromes Dev Tools.
I should utilize a service worker to populate the indexeddb.
Could create a GraphQL backend to do the data serving, to alleviate the need to bring all 20MB of data to the frontend.