React
TypeScript or JavaScript for UI work: what actually changes
TypeScript doesn't make a UI better by itself. It helps where boundaries are unclear: props, variants, tokens and catalogue data. Here is where it pays.
Key points
- TypeScript earns its keep at the boundaries, not in the number of types written.
- A well-typed component API removes impossible variants better than any visual test.
- JavaScript stays reasonable for scripts, prototypes and config files.
The question “TypeScript or JavaScript?” almost always comes from a project that is already running. The useful answer is: where does a type prevent an error that a test cannot see? Everything else is preference.
Where TypeScript pays off
| Boundary | Error it prevents | Example |
|---|---|---|
| Component props | Values nobody planned for | variant: "ghost" | "solid" |
| API data | Missing or renamed fields | Catalogue response |
| Design tokens | Names that don't exist | --ui-surface vs --ui-surf |
| Registry item | Missing files and dependencies | Incomplete install |
| Events and refs | Wrong type at runtime | HTMLButtonElement |
Where TypeScript costs
- Polymorphic components: generics get hard to read before they start paying off.
- Partial migrations: an implicit
anymoves the problem without fixing it. - Build time and configuration on a small project.
- Hand-written types for data that changes often: generate them instead.
A typed API worth the effort
type Variant = "solid" | "outline" | "ghost";
type Size = "sm" | "md" | "lg";
type ButtonProps = {
variant?: Variant;
size?: Size;
loading?: boolean;
} & React.ButtonHTMLAttributes;
export function Button({ variant = "solid", size = "md", ...props }: ButtonProps) {
return ;
}This type blocks three errors that no visual test catches: a variant that doesn't exist, a size someone invented, an attribute the button doesn't support.
The incremental migration that works
- Turn on
strictfor new files from day one, not for the whole project. - Type the boundaries first: public props, API responses, exported functions.
- Generate types from real data instead of writing them by hand.
- Don't convert a file just to add a type: convert it when you touch it for another reason.
The test that decides
Take the most used component in the project and type it end to end. If the time you spend finds at least one real error, the migration pays. If it finds nothing, the problem was somewhere else.
The EneUI catalogue exposes components and blocks with structured metadata (31 October 2026: 111,985 components, 1,556 blocks): that data is worth typing because it describes what you install.
Frequently asked questions
Is TypeScript required with React?
No. React runs on JavaScript. TypeScript adds checks at the boundaries, not runtime requirements.
How long does a migration take?
It depends on how many any types and how many boundaries you have. A file-by-file migration is easier to sustain than a full conversion.
Do types slow development down?
Writing them takes time; reading them removes guesswork. The balance depends on project size and how stable the APIs are.
Is type or interface better?
For props, type is enough. interface helps when you need to extend. Consistency matters more than the choice.
Can I use TypeScript only in new components?
Yes, as long as the boundary is explicit. Mixed files without strict give you false confidence.