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.

In Practice: Navigating Nuance in a Remote Team

As Preact developers, you’re not just building applications; you’re communicating within a complex ecosystem of engineers, designers, product managers, and stakeholders. The clarity of your written communication – particularly in English – is paramount to successful collaboration, especially when working remotely or with international teams. It’s easy to fall into the trap of simply translating directly from your native language, but professional English utilizes specific phrasing and levels of detail that convey intent, risk, and expectations more effectively. For instance, a simple “fix bug” can be replaced with “Implement a robust solution addressing the identified issue, ensuring thorough testing for regression.” The difference isn’t just about accuracy; it’s about signaling competence and professionalism.

A common scenario involves a code review comment. Imagine receiving this: “This doesn’t work.” While technically correct, it offers no actionable information to the developer. A more constructive response, reflecting professional English, would be: “The component isn’t rendering correctly on mobile devices. Could you please investigate the issue with the responsive styling and ensure proper state management is being utilized? Adding a console log statement within the render function might help pinpoint the source of the problem.” Notice the use of precise language – “rendering,” “responsive styling,” “state management” – terms that demonstrate an understanding of the underlying technical challenges. Similarly, Slack messages should avoid vague complaints like “This is broken!” Instead, try: “I’m encountering a 404 error when attempting to access the /api/users endpoint. I’ve checked the server logs and it seems the route isn’t properly configured. Could we review the API integration?”

Another key area is crafting pull request descriptions. A brief summary like “Fixed bug” won’t cut it for a PR that might be reviewed by someone unfamiliar with the codebase. Instead, provide context: “Resolved issue #123 - Incorrect display of user profile image on larger screens. Implemented responsive styling using CSS media queries to ensure consistent rendering across device resolutions. Added unit tests to verify correct image scaling and fallback mechanisms.” This level of detail demonstrates thoroughness and allows reviewers to quickly assess the changes.

Finally, remember that English in a technical context often requires you to explicitly state why something was done, not just what was done. This reduces ambiguity and facilitates future maintenance. Consider using tools like Preact’s useContext hook – describing its purpose as “Providing a centralized store for application-wide data” is more effective than simply stating “Used useContext.”

Here’s an example of how to use preact-cli to create a new project with some basic configuration:

preact create my-app --template preact/typescript
cd my-app
npm install
preact start