Skip to content

Instantly share code, notes, and snippets.

@KyleAMathews
Created March 23, 2026 14:23
Show Gist options
  • Select an option

  • Save KyleAMathews/4ef24a4e3c714d53dd02a25ee13badda to your computer and use it in GitHub Desktop.

Select an option

Save KyleAMathews/4ef24a4e3c714d53dd02a25ee13badda to your computer and use it in GitHub Desktop.

TanStack DB 0.6 Blog Post — Consolidated Editorial Review

Three editors reviewed the prose of the TanStack DB 0.6 release post, each through a different editorial lens:

  • Strunk & White (The Elements of Style) — economy, active voice, positive form, concrete language
  • George Orwell (Politics and the English Language) — dead metaphors, jargon, pretentious diction, meaningless words
  • William Zinsser (On Writing Well) — clutter, qualifiers, warmth, self-evaluating filler

The post is well-structured and genuinely informative — better than most technical release posts. The issues below are patterns, not disasters. Fixing them would tighten the prose without changing the voice.


I. Systemic Issues (patterns across the whole post)

1. "Story" is the most overused word in the post (8 occurrences)

Lines 50, 57, 61, 71, 73, 134, 142, 480.

In nearly every case it means "approach," "design," or nothing at all. It's corporate jargon that has drifted so far from its original meaning that it no longer carries information.

Original Suggested
"persistence story" "persistence"
"storage story" "storage layer" / "storage design"
"SSR story" "SSR support" / "SSR design"
"a sane story for schema evolution" "a clear path for schema changes"
"a performance and systems story" "it runs faster and scales better"

Recommendation: Use "story" at most once in the entire post, if at all.

2. "Unlock" is a dead metaphor (4 occurrences)

Lines 34, 38, 40, 48. Startup-speak meaning nothing more than "enables" or "adds." Once might pass; four times is a verbal tic.

Original Suggested
"the biggest practical unlock in 0.6" "the biggest change in 0.6"
"what 0.6 unlocks" "what 0.6 makes possible"
"what that persistence unlocks" "the real payoff"

3. "Application-shaped" is an empty compound (3 occurrences)

Lines 153, 284, 488. It sounds like it means something but doesn't — what shape is an application? Replace each instance with what you actually mean.

Original Suggested
"more application-shaped" "better suited to real apps" / "more practical"
"application-shaped views" "app-ready views" / "views shaped like your UI"

4. Self-evaluating sentences that tell the reader how to feel

The post has a habit of adding a sentence that ranks or praises a feature after already demonstrating it. These weaken the prose because the explanation already made the case.

Lines to consider cutting or tightening:

  • Line 26: "If you have been watching TanStack DB and waiting for it to feel like a more complete application data layer, this is the release for you." — The bullet list already proved this.
  • Line 284: "Taken together, this is one of the biggest features in the release." — Let the reader decide.
  • Line 344: "Virtual props are one of those deceptively small features that end up being useful everywhere." — The examples do the showing.
  • Line 378: "It is a small feature, but it rounds out the API in an important way." — The list above already made the case.

5. Hedge-qualifier habits

"A little bit," "really," "much more," "in an important way," "relatively," "somewhat" — these qualifiers dilute otherwise strong technical writing.

Original Suggested
"You can think of it a little bit like" "Think of it as"
"But the really important thing is" "What matters most is" / "But the real payoff comes when"
"much tidier and much more honest" "tidier and more honest"
"in an important way" cut

6. "In practice" appears 3 times (lines 75, 144, 148)

Twice is forgivable; three times is a verbal tic. Keep at most one (line 75, where it introduces a code example).


II. Line-Level Edits (ranked by impact)

1. Opening sentence (line 13) — all three editors flagged this

TanStack DB 0.6 is the release that lands some highly anticipated features that many of you have been asking for, making it a lot more ergonomic for app development.

TanStack DB 0.6 lands the features you have been asking for.

"Is the release that" is a roundabout construction. "Highly anticipated" is a pompous frill — of course they're anticipated; the next sentence lists them. "Making it a lot more ergonomic for app development" restates the obvious.

2. Double feedback ask (line 155) — all three editors flagged this

This is the first alpha release of persistence, and so we are looking for feedback and testing - we want to hear your feedback.

This is the first alpha release of persistence. We want your feedback.

Says "feedback" twice and "testing" once, all meaning the same thing.

3. Vague phrasing (line 40)

Once local state is durable, that stack can add up to something fully local-first instead of only feeling local while the app is open.

Once local state is durable, the app is truly local-first — not just local while it happens to be open.

"Can add up to something" is vague and indirect. State what happens.

4. Throat-clearing (line 50)

We have wanted a persistence story for a while, and a lot of you have asked for it too. The problem space was always broader than just "save some rows to disk":

We have wanted persistence for a while — and many of you have too. But it was never as simple as "save some rows to disk":

Cuts "story." Replaces "The problem space was always broader than just" (six words of abstraction) with a direct statement.

5. Hedged analogy (line 290) — Strunk and Zinsser both flagged

You can think of it a little bit like a database trigger, except it runs on the result of an arbitrary live query instead of only on writes to a single table.

Think of it as a database trigger that fires on any live query result, not just writes to a single table.

"You can think of it a little bit like" is five words of hedging before the sentence begins.

6. Clause chain (line 292)

They run incrementally on query-result deltas, which keeps them low-memory and makes them a much better fit for workflow logic than "subscribe to a whole collection and diff it yourself", especially because the query engine itself is already incremental.

They run incrementally on query-result deltas, keeping memory low — a better fit for workflow logic than subscribing to an entire collection and diffing it yourself.

The original chains three subordinate clauses. Break the chain.

7. Wordy includes description (line 165)

It lets you retrieve normalized data and project it directly into the hierarchical structure your UI wants to render, over any data source TanStack DB can sit on top of, without needing GraphQL-specific infrastructure.

It projects normalized data into the hierarchical structure your UI needs, over any data source TanStack DB supports, without GraphQL infrastructure.

"Lets you retrieve...and project" → "projects." "Wants to render" → "needs." "Can sit on top of" is a tired spatial metaphor. "GraphQL-specific" — the "-specific" adds nothing.

8. Negative-first framing (line 198)

So this is not just a nicer projection API. It is also a performance and systems story.

This is a performance and systems improvement, not just a nicer projection API.

Lead with what it is, not what it isn't. "Systems story" is jargon.

9. Dead metaphor (line 134)

That same persistence story also opens the door to runtimes outside the UI.

Persistence also works in runtimes outside the UI.

"Opens the door to" is a dead metaphor. "That same persistence story" — just say "persistence."

10. Padded sentence (line 71)

Instead of inventing a different storage story for each environment, we can keep one persistence model and swap in runtime-specific adapters. The result is optional persisted local state that can enable a local-first application, without limiting TanStack DB to only local-first use cases.

One persistence model, with runtime-specific adapters, replaces per-environment storage schemes. You get optional persisted local state that enables local-first apps without limiting TanStack DB to that pattern alone.

"Instead of inventing" frames the sentence around what you didn't do. "The result is" is a filler phrase.

11. Restated conclusion (line 144)

so paying a bit more upfront for a much cleaner persistence and query model felt like the right tradeoff.

so the trade is worth it.

The sentence already stated the tradeoff. This clause just restates the conclusion in more words.

12. Jargon for simple concept (line 73)

and then reconcile back to the upstream source of truth when sync resumes.

and then reconcile with the server when sync resumes.

"Upstream source of truth" is jargon; "the server" was named one sentence earlier and is what you mean.

13. Compounding praise (line 323)

This is only one example, but it shows why the 0.6 features matter together: includes, virtual props, and reactive effects all compose into something much more powerful than any one feature on its own.

Includes, virtual props, and reactive effects compose. That is the real point of 0.6.

Let the example speak. "Something much more powerful than any one feature on its own" is a generic claim.

14. Filler construction (line 15)

And a few APIs that used to rely on implicit magic are now getting more explicit and uniform.

And a few APIs that relied on implicit behavior are now explicit.

"Are now getting" → "are now." "And uniform" adds little after "explicit."

15. Redundant centralization (line 206)

and it centralizes the definition of the data the UI needs in one place instead of scattering it across multiple components and loaders.

and it defines what data the UI needs in one place, not scattered across components and loaders.

"Centralizes" already implies "in one place."

16. Self-congratulatory hedge (line 482)

So rather than rushing into a shallow solution, we want design partners.

Rather than guess, we want design partners.

"Rushing into a shallow solution" implies all other approaches are shallow. Just say what you're doing.

17. Process language (line 484)

We will set up calls with teams, interview them to understand the requirements, and run proposals past them as we shape the design.

We will talk to teams, learn their requirements, and run proposals past them.

"Set up calls with teams, interview them to understand the requirements" is process language. "As we shape the design" restates what "run proposals past them" already implies.

18. Double hedge in closing (line 488)

If you have been waiting for TanStack DB to feel more complete, more durable, and more application-shaped, 0.6 is a big step in that direction.

0.6 makes TanStack DB more complete, more durable, and more practical.

"If you have been waiting for X, this is a big step in that direction" hedges twice — "if" and "a big step." Just say what it does.


III. Typo

Line 68: CapacitiorCapacitor


IV. What's Working Well

All three editors noted the post is better than most technical release posts. Its strengths:

  • Clear structure with a scannable bullet list up top and well-organized sections
  • The "More than local-first" section (line 44) is some of the best prose in the post — direct, confident, no filler
  • Code examples are well-chosen and illustrate the points without over-explaining
  • The persistence requirements bullet list (lines 54-57) is crisp and effective
  • Plain factual sentences work beautifully: "Persistence gives you a durable local base to start from quickly, work against offline, and then reconcile with the server when sync resumes." — That sentence works. More like it.

The post's weakest moments are almost always where the writer reaches for an impressive-sounding abstraction ("story," "unlock," "systems story," "application-shaped") instead of saying the concrete thing. The fixes are simple: say what you mean, once, and move on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment