Learn Fzf - History, Background & Why You Need Fzf

#Introduction

After episode 0 set up our environment — making sure fzf --version shows 0.74.x and the supporting tools are ready — in this episode we will take a brief pause from the hands-on work and understand why fzf exists. A tool's history and background may feel unimportant, yet that is exactly where the reasons behind its design live.

Why should you understand fzf's history? Because fzf was not born in a corporate meeting room, but from a very concrete personal need: "how can I find files quickly without leaving Vim?" Understanding its origins explains many design decisions — why fzf is pipeline-based, why it is so fast, and why to this day it remains the first choice of millions of developers and sysadmins.

#The Beginning: A Vim Plugin by Junegunn Choi (2013)

The fzf story begins with a Korean developer named Junegunn Choi. In 2013, Junegunn was frustrated with the way file search worked inside Vim. This text editor is famously efficient, but file search still relied on heavy plugins or rigid commands. So, as good engineers tend to do, he wrote his own small solution: a fuzzy finder plugin for Vim that he named fzf — short for fuzzy finder.

At first fzf was just a Vim plugin. But its design principle differed from other plugins from day one: everything is pipeline-based. You could feed fzf any list — files, buffers, tags — and fzf would display it for interactive filtering. This principle is what later took fzf beyond the boundaries of Vim, and in 2015 the project was rewritten in Go as a standalone CLI program.

#Why Was It Rewritten in Go?

The decision to rewrite fzf from Vim script into Go was not without reason. There were three problems that only a more "serious" language could solve:

1. Speed — Vim script is a scripting language that is slow for real-time interactive filtering tasks. Go compiles into a native binary, so it can filter thousands of lines in milliseconds — something that matters, because fzf re-filters every time you type a single character.
2. Standalone — the Go version produces a single binary that does not depend on Vim, any editor, or any runtime. fzf can be called from any shell: Bash, Zsh, Fish, PowerShell, even from inside other applications.
3. Portability — Go is easy to cross-compile, so one codebase serves Linux, macOS, Windows, and FreeBSD without changing behavior. This is what allowed fzf to grow into a cross-ecosystem tool.

This decision also explains why fzf --version only takes a few milliseconds to run and why fzf can filter millions of log lines without slowing down — two things that become quality standards in the following episodes.

#The Problem fzf Solves

The core problem fzf solves is very simple to state, but annoying to do by hand: choosing one item from a long list by typing a partial pattern.

Take the contacts analogy on your phone: you never scroll through 500 contacts one by one. You type part of a name — say "jun" — and the list immediately shrinks. That is the same basic fuzzy finder philosophy: type a little, get what you mean. fzf brings that philosophy to the terminal, where the list can contain anything.

#Pipeline Interactivity: More Than Grep

The most fundamental difference between fzf and classic search tools is interactivity. grep is a non-interactive filter: it reads lines, matches a pattern, prints the results, then finishes — you cannot choose from the results.

ls | grep config

Compare that with fzf: instead of printing all results at once, fzf shows an interactive interface that updates the results every time you type. Each character you type filters the list in real time, until the item you want is left. That is when you press Enter, and fzf prints the selected item to stdout — becoming input for the next command.

ls | fzf

This is the answer to a question that often comes up: "doesn't grep already search? Why do we still need fzf?" grep answers "which lines match?" while fzf answers "which item do you want?" fzf is not a replacement for grep — it is the successor to the output of grep or find, turning a list into a living menu of choices.

#Comparison with Other Finders

fzf is not the only fuzzy finder in the terminal ecosystem. Several other projects try something similar, and understanding where it stands helps you appreciate its design choices:

What sets fzf apart from the others is its feature scope and ecosystem: preview window, multi-select, custom keybindings, HTTP API, and integration with dozens of other tools. Many projects like skim were actually born as attempts to imitate fzf — proof of how strong its core design is.

#The fzf Ecosystem

Over time, fzf grew from a mere tool into a foundation used by many other pieces of software. The list below is only a small part of what uses it:

• Neovim — plugins such as fzf-lua use fzf as the engine for searching files, buffers, and text.
• zoxide — this directory navigation tool uses fzf as its interactive picker when results are ambiguous.
• Shell plugins — many shell frameworks and plugins use fzf for completion and history.
• VS Code extensions — some extensions bring a similar fuzzy finder experience into the editor.
• fzf-go — fzf is available as a Go library, so you can embed its fuzzy matching engine into your own applications.

The presence of fzf-go is the most important leap: fzf is not just a program, it is also an API. You can use its scoring and filtering engine inside your own applications — a model that keeps fzf relevant far beyond a command-line tool. This is what "de-facto standard" means: a tool that others rely on to build upon.

rg --files | fzf --preview 'bat --color=always {}'

The line above summarizes its ecosystem in one example: rg prepares the list, bat brings a colorful preview to life, and fzf is the interactive bridge in between. Each tool does one thing well, and fzf unites them.

#Closing

In this episode 1, you traced fzf's journey from a 2013 Vim plugin — written by Junegunn Choi to speed up file search — to the Go fuzzy finder that has become the de-facto standard of the terminal ecosystem. You also understood the problem it solves, its difference from grep, its comparison with other finders, and the ecosystem that has grown around it.

The key takeaways:

• fzf was born as a Vim plugin (2013) and became a Go binary (2015).
• fzf solves the problem of choosing one item from a long list with a partial pattern.
• grep filters; fzf filters and selects at the same time — interactive and real-time.
• Among skim, peco, percol, and others, fzf wins because of its features and ecosystem.
• fzf is used as a backend by many tools and is available as a library (fzf-go).

In the next episode, episode 2, we will dissect fzf's core concepts and main architecture — the stdin -> filter -> stdout model that is its soul, how subsequence-based fuzzy matching and relevance scores work, the exit code language, and the anatomy of its interface components. See you in episode 2!