English for Preact Developers

Preact conversations center on bundle size and the compatibility layer that lets teams reuse the React ecosystem, so the vocabulary needs to cover both the performance pitch and the practical migration questions it raises.

Key Vocabulary

Preact/compat — the compatibility shim that maps React’s API surface onto Preact’s smaller core, allowing many React libraries to run unmodified against Preact instead. “Most of our component library worked immediately because preact/compat covers the React APIs we actually use — we only had to patch two edge cases.”

Bundle size budget — a target ceiling for the amount of JavaScript shipped to the client, often the primary motivation for choosing Preact over React on performance-sensitive pages. “Our bundle size budget for the landing page is 50kB gzipped total, which rules out React but leaves plenty of room with Preact.”

Diffing algorithm — the internal logic Preact uses to compare virtual DOM trees and apply minimal real DOM updates, smaller and simpler than React’s but functionally equivalent for most use cases. “The diffing algorithm is intentionally simpler than React’s fiber architecture — that’s most of where the size savings come from.”

Aliasing — configuring a bundler to substitute react and react-dom imports with Preact’s compat package at build time, without touching source code. “We didn’t rewrite any imports — aliasing react to preact/compat in the Vite config was the entire migration for most packages.”

Hydration mismatch — a discrepancy between server-rendered markup and what Preact renders on the client, which can surface differently than in React because of subtle differences in the reconciliation logic. “The hydration mismatch only appeared in Preact, not React, because of a timing difference in how effects run on first paint.”

Common Phrases

• “Does our bundle size budget actually justify switching to Preact, or is React’s overhead not the bottleneck here?”
• “Is preact/compat covering everything this library needs, or are we going to hit an unsupported API?”
• “Can we alias react to preact/compat for this one route without affecting the rest of the app?”
• “Is this hydration mismatch specific to Preact’s diffing algorithm, or would it happen in React too?”
• “How much of our performance win is actually Preact, versus other changes we made at the same time?”

Example Sentences

Justifying a framework choice to the team: “We’re proposing Preact for the checkout widget specifically because of the bundle size budget — every kilobyte there affects conversion on slow connections.”

Reviewing a migration PR: “Confirm preact/compat handles this component’s use of forwardRef before merging — that’s the one API where I’ve seen gaps.”

Debugging a rendering issue: “This looks like a hydration mismatch tied to Preact’s diffing algorithm — check whether the server and client are producing identical initial markup.”

Professional Tips

• Lead with bundle size budget when proposing Preact — it’s the concrete, measurable justification stakeholders can evaluate, not a vague performance claim.
• Name preact/compat specifically when discussing migration risk — it tells reviewers exactly which compatibility layer to audit against.
• Use aliasing to describe incremental migrations — it signals you’re not proposing a rewrite, just a build-time substitution.
• Flag hydration mismatch issues as framework-specific when they are — conflating them with generic SSR bugs slows down debugging.

Practice Exercise

1. Explain to a teammate why a strict bundle size budget might justify choosing Preact over React.
2. Describe what preact/compat does and why it doesn’t guarantee every React library works unmodified.
3. Write a sentence proposing aliasing react to preact/compat for a single route as a low-risk trial.