React Hook Form vs. TanStack Form vs. Formisch: React Form Libraries Compared

#react #webdev #javascript #typescript

I work on Formisch, so I'm obviously biased. We published this comparison on our blog last month and I'm posting it here for feedback. I tried to keep it fair, there are several cases where I straight-up say "stay with RHF."

TanStack Form has been gaining serious traction as an alternative to React Hook Form, especially for teams building complex, type-safe forms. The natural question is whether switching is worth the effort, or if you should just look at something like Formisch instead.

I'm not going to walk through every API. The docs do that better. Instead, here's how RHF, TanStack Form, and Formisch actually differ in the areas that screw you over later: TypeScript inference, validation architecture, and performance as forms get fat.

TL;DR

RHF: You declare a TypeScript generic (useForm<MyType>) and wire up a schema resolver separately. They have no enforced connection. Type drift is your problem.
TanStack Form: Types are inferred from defaultValues. Cleaner, but if you also use a validation schema, you now have two sources of truth that can drift.
Formisch: Types come directly from the Valibot schema. One object, runtime and compile-time. No generics, no resolvers, no sync work.
RHF validation: Field-centric. One form-wide mode controls timing for every field. Async loading state is yours to manage.
TanStack Form: Per-validator triggers (onChange, onBlur, etc.) and built-in async state. More config, more control.
Formisch: Everything lives in the schema. Submit-time validation by default, then live feedback after the first attempt. Async rules live in the schema too.

TypeScript inference: where the pain starts

All three libraries support TypeScript. The real question is how much manual alignment you're signing up for.

RHF makes you pass a generic to useForm. That generic is compile-time only. It has zero connection to your runtime validation schema. You can have ten fields in your type and only seven in your schema, and TypeScript won't care. Most teams derive the type from the schema (z.infer, etc.) to remove the duplication, but the architecture is still two separate things you're keeping in sync.

Deep nesting and useFieldArray are where RHF's path typing starts producing any when you need a concrete type.

TanStack Form drops the generic entirely. It infers everything from defaultValues. This is genuinely nice: add a field, update the default, types follow.

The catch: if you use a schema for validation (which most teams do), your types still come from defaultValues, not the schema. Optional fields, union types, or fields that start empty don't naturally express their full type range through a default value alone. You still have two things to keep aligned.

Formisch couples directly to Valibot. The schema is the type. When you change the schema, the form's types change everywhere automatically. There's no second place to update and no way for them to drift, because there is no second thing.

	Type source	What you're actually maintaining
RHF	Generic you declare	Type + schema + resolver wiring
TanStack Form	`defaultValues`	Defaults + schema (if used)
Formisch	Valibot schema	Schema only

For small forms, this is mostly academic. For large forms with conditional logic and nested structures, the maintenance difference is real.

Validation: who owns the rules?

RHF attaches rules at field registration. Each field owns its validation. Timing is controlled by one form-wide mode option. There's no built-in way to validate one field on blur and another on change without custom handlers.

TanStack Form makes validators first-class objects. Each one declares its own trigger and manages its own async state. Password strength on every keystroke, username availability on blur, checkbox only on submit: all config, no custom event wiring. It also handles debouncing and form-level validators for cross-field logic without manual trigger calls.

Formisch pushes everything into the schema. No field-level validators. The <Form> intercepts submit, runs the schema, blocks if invalid, then switches to live feedback. Async checks (like username availability) live in the schema via pipeAsync/checkAsync, not in components. Cross-field validation (password matching) also lives in the schema with partialCheck and forward.

The practical difference: in RHF and TanStack Form, validation logic lives in or near your components. In Formisch, it lives in the schema, and components adapt to whatever schema you hand them.

	Where rules live	Timing control	Async handling
RHF	Field registration or resolver	Form-wide `mode`	Manual loading state
TanStack Form	Per-validator config	Per-validator trigger	Built-in `isValidating`
Formisch	Valibot schema	Schema-level	Built-in, via schema

Performance: when forms get heavy

RHF stores values outside React state and updates the DOM directly through refs. This is why it's fast: typing doesn't trigger re-renders by default.

The tradeoff hits when React does need to know the value. Conditional rendering, derived UI, or cross-field rules require watch or useWatch. Broadly scoped watch is the source of most RHF performance complaints. useFieldArray in particular can get expensive if parent components subscribe to formState too broadly. It works, but staying fast requires deliberate component structure.

TanStack Form uses a reactive store. Components subscribe only to the slices they use. When a field changes, only that field's subscribers update. No manual optimization needed, granularity is automatic.

Formisch uses signals under the hood (implementation detail: you read plain values, not signals). Similar to TanStack Form, updates scope automatically, but signals track dependencies more directly. The difference is negligible for most web forms and more noticeable in React Native or very large dynamic forms.

	State model	Re-render scope	Your job
RHF	Internal object + refs	Manual via `watch`/`useFormState`	Structure the tree carefully
TanStack Form	Reactive store	Automatic per subscription	Nothing extra
Formisch	Signals	Automatic per signal	Nothing extra

So which one?

Use RHF if your forms are simple to moderately complex, your team already knows it, and you're not hitting type or validation issues. It's mature, well-documented, and the switching cost usually isn't worth it if things are working.

Use TanStack Form if you need fine-grained validation timing, built-in async handling, or you're already deep in the TanStack ecosystem (Query, Router, etc.).

Use Formisch if you're starting a new TypeScript project and expect form complexity to grow. The schema-first approach reduces the number of moving pieces over time. But be honest: it's Valibot-only right now, and migrating an existing RHF codebase is a genuine rewrite, not a drop-in swap.

	Best for	Main caveat
Formisch	New projects, TS-heavy codebases	Valibot only; migration is a rewrite
TanStack Form	Complex forms, TanStack ecosystem	More explicit configuration
RHF	Simple/moderate forms, existing codebases	No switching cost if already in use