# modular-forms: a type-safe form library now in maintenance mode

> Modular Forms is a headless, type-safe form library for SolidJS, Qwik, Preact and React, built around fine-grained DOM updates and a small bundle. The README's most important line: the project is in maintenance mode, and its official successor is Formisch, which is what the author recommends for new projects.

**fabian-hiller/modular-forms** — The modular and type-safe form library for SolidJS, Qwik and Preact

- Repository: https://github.com/fabian-hiller/modular-forms
- Website: https://modularforms.dev
- Stars: 1,212 · Forks: 61
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/fabian-hiller-modular-forms

## The first line of the README is a maintenance notice

The important sentence in this README is at the top, marked as important: Modular Forms is in maintenance mode, and the author recommends Formisch, its official successor, for new projects.

That single line changes how every other fact in the document should be read. The highlights, the mission, the vision, the credits, all describe a library that was built with care, and the project is still there, but the direction has been handed on. A team picking a form library today is not choosing between Modular Forms and the alternatives, it is choosing between Modular Forms and its own successor.

The project itself is a JavaScript library built on SolidJS, Qwik, Preact and React to validate and handle various types of forms. The stated qualities are type safety, speed by default, and a small bundle size thanks to a modular design, with a playground on the project site to try the API without installing anything.

What maintenance mode means in practice is not spelled out, and that is itself information. It says the code is not going to grow, and it implies that fixes still arrive. The release list backs that reading: the most recent tags are for the React package, the Qwik package and the Solid package, and each of those lines is versioned independently.

## Headless means you own every pixel

The library describes itself as headless, with the phrase you define the visual, and the mission statement says it pays special attention to type safety, bundle size, performance and input validation.

Headless is the architectural decision that explains the rest. There is no component library, no rendered input element, no styling layer, and no opinion about what a form looks like. What the library owns is the state, the validation and the submission, and what you own is the markup that renders it. That is why the highlights list says it supports all native HTML form fields, because a native input is a native input and the library has no need to replace it.

The other consequence of headless is that the library composes with whatever the project already uses for rendering. A SolidJS project renders SolidJS components, a Qwik project renders Qwik components, and the form state underneath is the same shape of thing in each case. A team that has a design system in place is not asked to give it up.

The README also claims progressively enhanced forms with actions, which is the part that reaches beyond the client. A form that works without JavaScript and then enhances itself is a different requirement from a client-only form, and it is the requirement that makes the no-dependency, native-field design pay off.

## Type safety as the reason the library exists

The vision section explains the origin. At the time of the initial development there was no form library with comparable type safety, bundle size and performance, and the mission is to gather the latest available experience and knowledge to provide the best possible form library for JavaScript frameworks.

Type safety is also the credit line. The highlights mention type safety with autocompletion in the editor, and the inspiration is named: React Hook Form and Formik, plus thanks to Ryan Carniato for his streams, and to David Di Biase, Miško Hevery and Manu Martínez-Almeida for support during the initial development. The first two are well-known form libraries.

So the type-safety claim is not decorative. In a form library, the shape of the data is the central fact, and a library that can express the field values as a type, and that the editor can complete, removes a category of runtime bug that forms are famous for. The risk of the claim being hollow is answered by the framework list: the same core, expressed in the idioms of four different reactivity models, is hard to do without real type-level work.

## Three kilobytes and fine-grained updates

The performance claims are specific in a way that form libraries often are not. The bundle size starts at 3 KB, and the DOM updates are fine-grained, which is the phrase that means only the affected part of the form is touched rather than the whole form being re-rendered.

The modular design is what makes the 3 KB figure possible. You import only the pieces you use, and the highlight is phrased as only use what you need, with no dependencies except the framework itself. For a form, which is a small part of most pages, that matters: a login form that ships a kilobyte of validation library and a kilobyte of nothing else is a very different proposition from a bundle that contains every date picker, every file uploader and every schema validator the library could have written.

The validation coverage claim is broader than people expect, with everything from emails to files supported. A form library that only handles text fields forces the file case and the date case out to bespoke code, and that is where a lot of the complexity of a real form lives.

There is a playground on the site for trying these things, which is the right way to judge a form library, since the questions that decide it are about how the API reads and how much the developer has to write, and those are not visible in a feature list.

## Four packages, four independent release lines

The repository is a pnpm workspace with a packages/ directory, a playgrounds/ directory, a website/ directory and a private root package.json that exists only to hold the workspace tooling, which is prettier, a Tailwind CSS plugin for it, and TypeScript 5.5.4.

The published packages are per framework, and the release list shows how far apart they have drifted. The most recent tag is v0.12.0 for the React package, dated 2026-01-18, while the Qwik package sits at v0.29.1 and the Solid package at v0.25.1, both dated 2025-03-01. The naming convention puts the framework after the version, so a consumer pins a package name and a version together.

That gap between the React line and the others is the interesting part. The React package is years behind the others in version terms, which is consistent with a project whose centre of gravity is the fine-grained frameworks and where the React adapter was always the awkward one, since React has no built-in fine-grained reactivity to hang the fine-grained updates on. A team on React should read that gap as a signal rather than a curiosity.

For a team choosing today, the practical question is not which package is nicest but which successor to use, and then whether the framework you already have is supported by it.

## Where Modular Forms is the wrong choice

The first wrong-tool case is any new project, and this one is not a matter of taste. The author recommends the successor for new projects, the library is in maintenance mode, and a team that starts a greenfield form layer on a library whose maintainer has pointed elsewhere is building on a dead end.

The second is a project that needs the newest framework versions. The framework packages are at 0.x versions with independent lines, so a React team on a current React release may find the adapter lagging, and a team that wants a Qwik or Solid feature that arrived after the package was cut has to wait for a release that maintenance mode may not produce.

The third is a project whose form requirements outrun the library. The claims are about type safety, size and speed, and the validation coverage is stated as everything from emails to files. Anything beyond that, a schema-driven form with conditional fields and cross-field dependencies at scale, or a form that needs a specific third-party component, means checking the API rather than trusting the highlights.

There is one more practical caution. The library is headless by design, which is a strength for a team with a design system and a cost for a team without one, since a headless form library hands you the markup work as well as the state work.

## MIT, a June 2026 push, and a project that handed itself on

The project is available free of charge under the MIT License, with LICENSE.md at the repository root, and it is published to npm as a set of scoped packages, @modular-forms/solid, @modular-forms/qwik and @modular-forms/react.

The repository is not archived, and the last push was on 2026-06-06, which is a few months before this review. Maintenance mode with occasional commits is the expected shape: fixes land, new features do not. The .npmrc, the pnpm-lock.yaml and the pnpm-workspace.yaml are the marks of a pnpm-based monorepo, and the code-workspace file suggests the packages are developed in an editor configured for the whole workspace.

What makes this project worth reading rather than just using is the handover itself. The author built something with a stated mission around type safety, bundle size and performance, and then, having established that the ideas work, passed the work to a successor and said so plainly at the top of the README. The credits section is equally specific about where the ideas came from, naming React Hook Form and Formik, and the people whose reactivity model the design leans on.

For a maintainer, that is a pattern worth copying: a successor named, a migration path visible, and the old project left readable rather than deleted.

## Conclusion

Adopt Formisch rather than Modular Forms for any new project, because the author states the library is in maintenance mode and recommends the successor, and the release lines show the drift, with the React package at 0.12.0 and the Solid and Qwik packages in the 0.25 and 0.29 ranges. Choose Modular Forms only for an existing codebase that already depends on it and would rather not migrate now, and in that case plan the migration, because maintenance mode means security and compatibility fixes, not new framework support. Before you decide, read the README note about maintenance mode, compare the successor against your requirements, and check which framework package your project actually needs, since the four packages are versioned independently.

## FAQ

### Is Modular Forms still maintained?

It is in maintenance mode, as the README states at the top, and the author recommends Formisch, its official successor, for new projects. The repository is not archived and the last push was on 2026-06-06.

### Which frameworks does Modular Forms support?

It is built on SolidJS, Qwik, Preact and React, with a separate package per framework and independent version lines. The listed releases are @modular-forms/react at 0.12.0, @modular-forms/qwik at 0.29.1 and @modular-forms/solid at 0.25.1.

### What does headless mean in Modular Forms?

The library owns the form state, validation and submission, and you define the visual. There is no component library or styling layer, which is why it claims to support all native HTML form fields and to have no dependencies except the framework itself.

### How small is the Modular Forms bundle?

The README states a small bundle size starting at 3 KB, achieved through a modular design where you only use what you need. The highlights also say DOM updates are fine-grained, so only the affected part of a form is updated.

### What is Modular Forms licensed under?

MIT. The README states the project is available free of charge under the MIT License, with the licence file at the repository root.

## Sources

- [fabian-hiller/modular-forms on GitHub](https://github.com/fabian-hiller/modular-forms)
- [License: MIT](https://github.com/fabian-hiller/modular-forms/blob/main/LICENSE)
- [Project website](https://modularforms.dev)
- [README](https://github.com/fabian-hiller/modular-forms/blob/main/README.md)
- [Releases](https://github.com/fabian-hiller/modular-forms/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fabian-hiller-modular-forms