TanStack Query at Scale with Dominik Dorfmeister

🎧 New Señors @ Scale Episode

This week, I spoke with Dominik Dorfmeister, better known as TkDodo, the creator and maintainer of TanStack Query and a software engineer at Sentry. Dominik has spent over a decade building frontend tools and has become one of the most trusted voices in the React ecosystem. His first code wasn't even web — he did a technical high school in Vienna, a bachelor's degree in Great Britain, and started out doing desktop programming and JVM backend work in Java and Scala before transitioning to frontend somewhere around the introduction of TypeScript.

In this episode, we dig into how answering questions in the TanStack Discord during the pandemic turned him into an open source maintainer, the first feature he ever shipped to React Query, why major versions are "the pain of his existence," how he removed almost 3% of the Sentry codebase with Knip, and what it takes to build a design system inside a ten-year-old, million-line codebase.

⚙️ Main Takeaways

1. Frontend came after backend — and TypeScript was the turning point

Dominik didn't start on the web at all, and he's honest that the move surprised even him.

• The JVM beginning: He started with desktop programming, then backend development — Java, JVM stuff, Scala — before somehow transitioning to frontend.
• Surviving untyped JavaScript: Coming from typed languages on the JVM, he doesn't know how he survived looking at JavaScript and saying "yeah, this is totally fine." He liked functions as a first-class citizen and wasn't that turned off by the lack of types — until TypeScript came along and he thought "how could I live without that?"
• Frontend-only for almost eight years: Starting around 2018 he went frontend-only, which is now almost eight years.

2. He was on React from the early beginnings

Before React, his JavaScript career ran through some unusual stops.

• A pre-Angular framework: His first company used a proprietary, paid framework that predated Angular — full-fledged, with classes, inheritance, grids, tables, and charts before the language had classes. A one-stop shop, nothing like how we do JavaScript today.
• Angular 1, then React: He switched companies, did AngularJS for a while, and when React came out there was an immediate "okay, we are gonna rewrite to React." They did all the Redux stuff around 2015–2016.
• Still React-focused: He's played with Solid and Qwik, but he stays focused on React and the core functionality — "It's what pays the bills."

3. Open source started with answering questions during lockdown

The origin story is one Dan keeps hearing from maintainers — and it's the most actionable advice in the episode.

• The Discord screenshot: Dominik still has a screenshot of his first Discord message, where he said he wanted to give back to the community by answering questions and maybe doing a contribution here or there.
• Addicted to instant gratification: For the first six months he'd answer every question within a couple of minutes to the best he could. People were thrilled — "Whoa, I get an answer to my question" — and he learned a ton about the library by doing it.
• The path to code: It took six to eight months before his first real code contribution. He spent half a year just reading the library, answering questions, and understanding the concepts. By then Tanner had reached out to give him permissions to triage PRs, and "everything just went rolling."

4. The "answer it three times, then blog it" rule

His blog exists because he got tired of answering the same thing twice.

• The rule: "When I get asked the question three times, I write about it so that I can link people to the blog post." That's how the blog started, and he hasn't stopped since.
• The cadence: He still wants to write one article every four weeks, though time management makes that hard right now.
• It's about the community, not the resume: Most maintainers he knows, himself included, didn't set out to become maintainers or get rich (nobody does). They got on the road by genuinely wanting to help.

5. From a maintainer to the maintainer — because Tanner is an inventor

The handoff happened naturally, driven by different personalities.

• The inventor mindset: Tanner always wants to build something new — he did Query, then rebuilt React Table from the ground up for version 8, then started the router, which turned into TanStack Start and he hasn't stopped since.
• The long tail of maintenance: Tanner is the inventor who has the ideas and does the initial implementation; the maintainers handle the long tail. Dominik does that for Query, Kevin for Table, and there are over 20 maintainers working regularly across the libraries.
• Not an inventor himself: "I don't see myself as the inventor personality... All the libraries I've contributed to so far are things that I've used and that I like." He improves them rather than inventing new concepts.

6. The first big feature he shipped: tracked queries

His first real contribution was a render performance optimization.

• The problem: useQuery re-renders a component every time the cache changes. Background updates (like on window focus) cause at least two render cycles as a query goes into and out of the fetching state — even when nothing new comes back.
• The proxy trick: Tracked queries put a proxy on the result object of useQuery that keeps track of which properties you actually use. Your component only re-renders when something you're using — like isFetching — actually changes.
• Opt-in, then default: It was opt-in in version three, then became the default in version four because it yielded such a good performance improvement.

7. Framework adapters live or die on community

TanStack tries to be framework-agnostic, but adapters need maintainers.

• The real question: When considering a new adapter, the main thing they look for is whether there's a community willing to maintain it together with them — not everyone on the team is an expert in every framework.
• What exists: A Preact adapter shipped this year, there's been an experimental Angular adapter for over a year with lots of demand to graduate it, and a Lit adapter is in conversation.
• The Lit proof of concept: Two years ago he did a two-hour uncut livestream writing a React Query adapter for Lit without knowing anything about it, just to show how easy making an adapter is.

8. Major versions are "the pain of his existence"

The hardest lesson in the episode is about how badly major releases can go.

• The chaotic three-to-four: A last-minute decision to change the package name (to @tanstack/react-query) plus a changed bundling workflow led to ESM drama, things that didn't install on older bundlers until 4.3.x, and even an accidental React Query v4 release on npm.
• The version-five mistake he dreads: They renamed the internal query status and removed one of the status fields. He personally missed a specific case because he wasn't heavily using it; tests passed and the change looked minor. After release, people who'd waited for stable updated and broke — GitHub comments asking "which idiot made this change?" with hundreds of thumbs up.
• Feedback comes too late: "This would have been great feedback a week ago." Most people refuse beta and release-candidate versions, so the most valuable feedback arrives after the API is sealed. They shipped a flag, fixed the migration guide, and made a proper fix in the next major.

9. Sentry is the ultimate real-world test bed

Now that he's at Sentry, he has a million-line codebase to validate releases against.

• The biggest codebase he's worked on: A million lines of TypeScript with so many usages of queries — and so many weird usages and edge cases — that it's a perfect candidate to test versions against, behind a feature flag.
• Not just him: The TypeScript team tested their Go-based native rewrite against the Sentry codebase, and Knip tests against it too, because it's huge, full of edge cases, and fully open source on GitHub.
• The most real-world code there is: "It's the most real world code base I've seen" — hundreds of people and agents contributing daily, merges and releases almost 24/7 across time zones.

10. Knip removed almost 3% of the Sentry codebase

Dead-code detection turned out to be a huge, ongoing win — especially in the age of AI.

• What Knip does: It checks your codebase for code that's no longer used — exports that never get imported, code an agent added but nothing uses. It's gotten much easier to set up, with an AI agent, an MCP server, and near-zero-config behavior.
• The numbers: After enabling it and fixing all the violations, he removed almost 3% of the codebase — around 28,000 lines lying around unused — code that AI no longer has to read, parse, and put into context.
• Continuous cleanup for free: Running in CI, it catches the case where someone deletes code and the last import of something else disappears, making it unused — something you'd never catch in a single PR.

11. Building a design system inside a ten-year-old monster

Sentry didn't have a design system; the new design engineering team is fixing the "death by a thousand cuts."

• How it got bad: Every team built its own components. Over ten years, a component would grow to 20 props (some mutually exclusive) because "let me just add one more prop," until someone gave up and made a second one — and then a third. Sentry has three form systems for this reason.
• The pragmatic approach: Find the least-bad existing implementation of each component, move it to the design system, tighten the API, unify props, and provide escape hatches and documentation — because the biggest problem is people not knowing the good components exist.
• Named Scraps: It's an acronym (something like Sentry Components, Reusable Assets and Patterns) — "we take the scraps of the things that have been lying around for 10 years and we try to build something useful." It's not yet a separate package; untangling the circular import graph and Sentry-specific routing/translation coupling is still on the list, guarded for now by lint rules for boundaries.

12. Semver is a game — Epoch Semver is the proposed fix

He'd love to ship more major versions but feels boxed in by expectations.

• The trap: People conflate "major version for breaking changes" with "big new-features marketing event." So fixes get patched together into a major that can't be too big (people complain it's too much work) or too little — "all of this is actually bullshit... it's just a game that you have to play."
• Epoch Semver: Semantic versioning with a fourth number up front indicating a marketing event or big new version. Breaking changes stay in majors, features in minors, and a groundbreaking rewrite bumps the epoch — letting them do far more, smaller major versions.
• Version six, kept boring: He wants version six "as uninteresting as possible" — removing deprecations, upping supported browsers and TypeScript, possibly moving suspense to React.use (dropping React 18). The exciting stuff already ships in minors: version five has over 90 minor releases.

13. The complainers are a vocal minority

A reminder that echoes what other guests have told Dan.

• The poll: Someone polled whether there are too many or too few breaking changes — and for some it was too much, for others not enough. "You can't make it right for everybody... someone will always complain and that's just something in open source."
• Corbin's lesson, repeated: It's typically the angry people who leave comments; the millions of happy users say nothing. What you're seeing is the minority.
• The scale of it: It's amazing to Dominik that ChatGPT uses React Query in its interface — millions of users interact daily with code he wrote.

🧠 What I Learned

• Dominik came from JVM backend work (Java, Scala) and only moved to frontend around the introduction of TypeScript — the lack of types is what almost kept him away.
• The open source path that keeps recurring: answer questions in Discord/GitHub for months, blog the things you get asked three times, and the code contributions follow six to eight months later.
• Tracked queries — a proxy over the useQuery result that only re-renders for properties you actually read — was his first big feature, opt-in in v3 and default in v4.
• TanStack framework adapters only happen when there's a community willing to maintain them; one person doing a livestream proof of concept isn't enough.
• The version-five status-field removal is a cautionary tale: tests passed, the change looked minor, and it broke a lot of people because the valuable feedback only arrived after the API was sealed.
• Sentry — a million lines of TypeScript, fully open source — is used as a stress-test benchmark not just by Dominik but by the TypeScript team and Knip.
• Knip removed almost 3% of the Sentry codebase (~28,000 lines), and running it in CI gives you continuous dead-code cleanup for free.
• Design systems in old codebases fail not because the components don't exist but because nobody can find the good ones — Sentry literally has three form systems.
• Epoch Semver (a fourth leading number for marketing events) would let maintainers ship many small, boring major versions instead of waiting to accumulate "enough" breaking changes.
• The people who complain loudest are a tiny vocal minority; millions of happy users — including ChatGPT's interface — say nothing.

💬 Favorite Quotes

"I still don't know coming from like a background where we always had typed language... I don't know how I survived looking at JavaScript and saying like, yeah, this is totally fine."

"When I get asked the question three times, I write about it so that I can link people to the blog post. And that's how my blog started. And I haven't stopped blogging since."

"I don't see myself as the inventor personality. I don't have ideas. All the libraries I've contributed to so far are things that I've used and that I like."

"Guys, you know, this would have been great feedback a week ago. We could have still changed it, you know, now we have the major version out. The API is basically sealed."

"Major releases are really the pain of my existence."

"It's the most real world code base I've seen."

"All of this is actually bullshit. Like I think it's just a game that you have to play for whatever reasons."

"To me, open source is mostly the people and the community that build the things. And the writing code stuff is kind of like secondary."

🎯 Also in this Episode

• His origin: a technical high school in Vienna (a year longer than usual, software-engineering focus), a father who'd been in IT since the 70s/80s, and a bachelor's degree in Great Britain
• The LeftPad incident — "that was a fun morning when nothing worked" — about ten years ago
• How he joined Sentry: they have an office in Vienna (he doesn't enjoy full-remote and likes to go in once or twice a week), he works as a contractor through his own company, and the role grew into the design engineering team
• A "query function not defined" bug surfaced in Sentry that had lived in the code for over a year — caused by manually creating a query observer without a query function — which feeds a fix planned for version six
• The version-six TypeScript-level fix for accidentally calling useQuery without a query function (only safe when a global default query function is defined)
• The NPMX community as an example of how a healthy community produces more contributions than the core team can even handle as code — Daniel and a couple of others spinning up a new npm browser
• Advice for new open source contributors: not every contribution is code, and contribute to things you actually use and love rather than for the resume
• Mark Erickson and Corbin describing the same "answer questions, write docs" entry into open source for Redux
• Dan's own confession that writing well is hard and takes forever
• Dominik reads fantasy books aloud to his kids (ages 10 and 8) every evening; he prefers in-depth written content to video and admires Dan Abramov's blog and his Just JavaScript / React writing

Resources

More from Dominik & TanStack:

• TanStack Query — Powerful asynchronous state management for React and beyond
• TkDodo's blog — Dominik's writing on React Query and frontend
• Sentry — Application monitoring and error tracking (and the codebase behind the design system work)
• Knip — Dead-code and unused-dependency finder for JavaScript/TypeScript projects
• Dan Abramov's blog — long-form essays on React and JavaScript that Dominik admires
• The two-hour uncut livestream of Dominik building a React Query adapter for Lit (Dan plans to link it in the episode description)

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 53 minutes on TanStack Query, becoming a maintainer through community, tracked queries, the version-five disaster, Epoch Semver, killing dead code with Knip, and building a design system inside Sentry.

Whether you're a developer thinking about your first open source contribution or a library maintainer wrestling with the politics of major versions, this conversation has something immediately actionable.

Happy shipping,
Dan