Diffing is one of those problems that seems trivial until you try it. Building one teaches you a genuinely useful algorithm and produces a tool you'll reach for.

1. Understand what you're computing

A diff is the shortest sequence of insertions and deletions that turns one text into another. The standard approach is a longest-common-subsequence algorithm, and it's worth understanding rather than just calling.

diff-tool.txt
Build a browser-only text diff tool.

- Line-level diff first, using an LCS algorithm. Explain how it works
  as you go — I want to understand it, not just use it.
- Then word-level diff within changed lines, so a one-word edit
  doesn't highlight the entire line.
- Side-by-side and unified views, toggleable.
- Options: ignore whitespace, ignore case, ignore blank lines.
- Handle large inputs without freezing — say at what size the naive
  algorithm becomes too slow and what to do then.

Everything client-side. Nothing uploaded.

2. Word-level is what makes it usable

A line-level diff on a paragraph where one word changed highlights the whole paragraph and tells you nothing. Diffing within changed lines is the difference between a demo and a tool.

3. Performance has a cliff

The naive LCS algorithm is quadratic. Fine for two hundred lines, unusable for twenty thousand. The standard mitigations: strip the common prefix and suffix first (often most of the input), then use a smarter algorithm for what's left.

Know where your cliff is and handle it deliberately rather than hanging the tab.

4. Make the output usable

Line numbers on both sides. Synchronised scrolling. Jump to next and previous change. Copy the result as a unified diff. Colour that works in both themes and doesn't rely on colour alone — use symbols too.

Test with two versions of a real file where you moved a block. Naive diffs show that as a big deletion and a big insertion, which is technically correct and unhelpful.