Every engineer who has tried to review a large pull request on GitHub knows the moment: the diff view freezes, the comment boxes lag, and Chrome's memory graph spikes for the next ten minutes. The bigger the PR, the worse the experience — mobile browsers often crash outright on anything past a few thousand lines.
On May 20, 2026, a small team called Pierre Computer Company quietly published an answer: DiffsHub. Within 24 hours, the launch tweet had over 52,000 posts, the GitHub repo crossed 4,500 stars, and developers across the timeline were calling GitHub's native diff renderer a "skill issue." The pitch is disarming: take the GitHub URL you are already looking at, swap github.com for diffshub.com, and watch a million-line diff stream in almost instantly.
This is one of those rare developer launches that is both a marketing trick and a serious piece of engineering. Here is what is actually happening under the hood, why it matters for engineering teams, and how to fold the underlying library into your own products.
The one-line trick
The user-facing magic is a URL rewrite. Any public GitHub diff — pull requests, commits, comparisons, patches — can be opened on diffshub.com by changing exactly one part of the URL.
https://github.com/oven-sh/bun/pull/12345
https://diffshub.com/oven-sh/bun/pull/12345
That is it. No login, no extension, no setup. DiffsHub fetches the same public data GitHub exposes, then renders it through Pierre's own components. Within hours of launch, the community shipped a Chrome extension that does the redirect automatically and a GitLab adapter that wires the same UI to GitLab merge requests.
For private repositories the story is different. DiffsHub is a public service, so it cannot reach behind your SSO. The interesting move for teams is to embed the underlying library directly, which is exactly what Pierre is encouraging.
What Pierre actually built
DiffsHub is a thin web app sitting on top of a much more interesting open-source library: @pierre/diffs, currently at version 1.2.1 on npm. It ships as part of the pierrecomputer/pierre monorepo on GitHub and is the same engine powering Pierre's hosted product.
The library is built around three ideas that GitHub's web renderer does not currently optimise for:
- Virtualised scrolling. Only the lines visible in the viewport are rendered to the DOM. A diff of a million lines does not create a million elements — it creates a few hundred and recycles them as you scroll.
- CSS Grid plus Shadow DOM. The split (side-by-side) and stacked (unified) layouts use CSS Grid to keep additions and deletions aligned, while Shadow DOM isolates the diff styles from the host page. That isolation is what lets you drop the component into a Next.js, Remix, or Vite app without it inheriting half the world's CSS.
- Shiki for syntax highlighting. Themes are not bespoke. The diffs adapt to any Shiki theme, which means your existing brand tokens travel straight into the diff view.
On top of that base, the library adds annotations and comments anywhere on the diff, line selection with click-and-drag, token-hover callbacks for tooltips, inline character-level highlighting, and a merge-conflict resolution UI. It is also explicit about not being limited to Git: you can feed it any pair of files and it will render the comparison.
The engineering behind a million-line diff
The reason GitHub's diff view chokes on large PRs is not laziness; it is path dependence. GitHub renders every line, every comment box, every blame button, and every inline API call into the DOM up front. For a 200-line diff that is fine. For a 200,000-line refactor, it is a memory bomb.
Pierre's library inverts the model. The diff is treated as a stream of token-tagged rows, fed through a virtual list that only mounts what is on screen. Highlighting is performed lazily per visible row using Shiki, not eagerly across the entire blob. The annotations layer is decoupled from the render layer, so comments do not block the initial paint.
The result is the thing developers actually noticed on the timeline: opening a Linux kernel version-to-version comparison in DiffsHub feels closer to opening a static page than to opening a heavy web app. One developer on X noted that GitHub "crams every line, comment box, and heavy API call into your browser at once" while DiffsHub "simplifies the rendering page and uses virtual scrolling — only rendering what's on your screen."
Why this matters for your engineering org
DiffsHub itself is a fun toy. The library is the real story for teams building internal developer platforms, code review products, or AI coding tooling.
- Internal review tools. If your platform team maintains an in-house code-review UI on top of GitHub or GitLab,
@pierre/diffsis a drop-in renderer that gives you GitHub-quality diffs without GitHub-shaped performance problems. - AI coding agents. Agentic coding tools like Cursor, Claude Code, and the new wave of autonomous PR reviewers need to surface diffs to humans during approval. A library that renders agent-generated diffs of any size, with annotations and inline comments, removes a category of UI work.
- Audit and compliance views. Security and compliance teams often need to read very large generated diffs — dependency updates, migrations, infrastructure-as-code plans. A renderer that does not crash on 100,000 lines changes what is reviewable.
- Documentation and education. Teaching engineers how a change shaped a codebase is much easier when the diff itself is fast, themeable, and embeddable inside any MDX or doc site.
The licensing posture matters too. The repo is genuinely open source, the package is on npm, and the team behind it carries pedigree from Cloudflare, Stripe, and GitHub. This is not a closed SaaS that might pull the rug; it is a primitive you can build on.
How to try it in five minutes
The fastest path is the URL trick. Pick any public PR you are already curious about — one of the heavyweights is the Bun, Node.js, or Linux comparisons featured on the DiffsHub homepage — and swap the domain. Scroll. Notice that it does not stutter.
If you want to wire the library into your own product, the install is one line:
bun i @pierre/diffs
# or
pnpm add @pierre/diffsFrom there you can mount the CodeView component, hand it a pair of file contents, and pick a Shiki theme. The README in the pierrecomputer/pierre monorepo walks through the split versus stacked layouts, annotation API, and merge-conflict resolution mode.
The Pierre ecosystem signal
DiffsHub is one of three pieces Pierre is putting in the open: Diffs (the rendering library), Trees (file-tree primitives), and Code Storage. Each piece is the kind of unglamorous foundation that most teams reinvent badly. Releasing them as open source — and showing them off with a viral consumer-facing demo — is a deliberate strategy. It earns trust, ships the primitives into thousands of developer toolchains within a week, and seeds the market for whatever Pierre charges for next.
For engineering leaders, the lesson is broader than DiffsHub itself. The most leveraged developer-tool launches of 2026 keep following the same playbook: open-source the primitive, ship a viral demo that proves the primitive works at extreme scale, and let the community port it everywhere before competitors can react. We saw it with shadcn/ui for components. We saw it with Shiki for syntax highlighting. Pierre is doing it for code review.
What we are taking from this at Noqta
At Noqta we think a lot about what AI coding agents need to feel native inside enterprise workflows. Most of our enterprise pilots eventually run into the same wall: agents can generate large, correct diffs faster than humans can review them. The bottleneck is the review surface, not the model.
Libraries like @pierre/diffs are the kind of building block that closes that gap. Pair a fast, embeddable diff viewer with an agent that explains its own changes inline, and the human-in-the-loop step stops being the slowest part of the pipeline. That is the direction agentic coding has to move if it is going to land in regulated, large-codebase environments.
DiffsHub is a small launch with a one-line trick. The library behind it is a quiet upgrade to one of the most common, most painful surfaces in software engineering. If you have not opened a 100,000-line PR in it yet, do it before your next code review — and then take a serious look at what your own developer platform could do with the same primitive.