FormKit

A free & open source Vue form building framework that simplifies form structure, generation, validation, accessibility, error handling, and more.

[FormKit @FormKit]

@ahvsfporra Not in the roadmap currently

[FormKit @FormKit]

FormKit is now available for React!

Been wanting to do this for a while.

[Justin Schroeder @jpschroeder]

Hell froze over: announcing FormKit for React.

Secretly framework-agnostic since inception, today we��re open sourcing the most popular Vue form library…for React.

Why is this a big deal?

1. Forms are still hard. We (the creators of FormKit) thought form libraries were no longer necessary, given the trajectory of coding agents. It turns out we were wrong, and we learned this the hard way. Need repeating conditional fields nested 3 layers deep inside a dynamic component, with accessibility, validation, internationalization, and backend error placement? Turns out coding agents aren’t great at that. It’s table stakes for FormKit.

2. Single component. This matters more than you would think, but FormKit doesn’t ship lots of different components each with its own props. Instead, it has a single one: <FormKit type="any-input-type-here"> and unified props. This was done to provide a better DX to human engineers. It makes it easy to spot when a given component was part of the form’s data structure vs a presentational component. It turns out this matters even more to coding agents than humans. No matter where your coding agent is, whenever it sees “FormKit” it immediately knows “oh, that’s part of the form’s data”.

3. No plumbing. FormKit doesn’t require any manual data collection, event listening, or state tracking. It does all this for you on a heavily tested, framework agnostic, self-assembling graph. The only code your agent needs to write is declarative templates and submission handlers that respond to the state.

4. Dense colocation. FormKit’s syntax happens to be ideal for coding agents; nearly everything you need to know about a given input is *on* the input:

<FormKit
type="text"
name="email"
label="Email address"
help="How should we get ahold of you?"
validation="required|email"
/>

Colocation dramatically improves the efficacy of coding agents.

5. DOM. FormKit, unlike most form frameworks in React, renders the actual DOM. This also increases colocation and best practices, meaning your coding agent is far more likely to produce consistent and high-quality output that looks and acts the way its supposed to.

6. Schema. FormKit’s own inputs are not written using Vue or React — instead, FormKit has its own render schema — think of it like an AST for the DOM — and you can modify it on the fly. It’s not very human-friendly to write, but it turns out most models are already pretty well trained on FormKit’s schema. Want your inputs to look a bit different on one form than another? No problem, your coding agent can easily make those changes *without* modifying the JSX structure at all. Oh, and any inputs you create for Vue work with React and vice versa.

7. Plugins. FormKit leans into the unstructured tree graph hard. The graph doesn’t just collect data, it also passes down configuration and plugins. Want one form to work a bit differently than another one? No problem — just add a plugin to the top of that form or group and its children will all receive that feature. You can even mass assign props and configuration this way.

Of course, FormKit has been solving these exact issues for a long time, but it wasn’t until we started using it on our own projects with coding agents that we realized what a huge advantage it is.

With so many people using coding agents with React, it made sense to unveil FormKit for what it has always been — a completely framework-agnostic form framework that happens to unlock your coding agents.

➡️ https://t.co/jTsViHTo20

[FormKit @FormKit]

A/B test different coding agents.

[Justin Schroeder @jpschroeder]

dmux just shipped support for 11 coding agents including A/B testing for any/all of them. Now supports:

@claudeai, @cline, @Alibaba_Qwen, @opencode, @OpenAI, @AmpCode, @charmcli, @cursor_ai, @github copilot, @geminicli, pi

Also new ui &amp; merge diffs

➡️https://t.co/ImLyLY82pL

[FormKit @FormKit]

New productivity level unlocked.

[Justin Schroeder @jpschroeder]

We're open sourcing dmux.

Our internal tool for running Codex and Claude Code swarms.

- tmux + worktrees + claude/codex/opencode
- hooks for worktree automation
- a/b claude vs codex
- manage worktrees
- multi-project per session
...more.

➡️ https://t.co/ImLyLY82pL

[Justin Schroeder @jpschroeder]

Launch day for @FormKit!

- Beautiful new docs site
- Themes updated to Tailwind 4
- Improved @nuxt_js 4 support
- lots of bug fixes
- Lots and lots of ecosystem maintenance

Go checkout the new website, oh yeah, we finally put some of FormKit’s users on the website 👀

[FormKit @FormKit]

New features and bug fixes coming soon...👀

[Lee Martin @leemartin]

@mockvideo @boniver @instagram @nuxt_js @Netlify @contentful @uppy_io @transloadit @goserverless Shout out to @formkit for once again providing the excellent inputs that make these apps possible and a joy to maintain.

[Justin Schroeder @jpschroeder]

🎃 Available for the next 2 days: FormKit Pro Unlimited:

🤫 No telemetry for life
📈 Unlimited projects for life
♻️ Free updates for life
1️⃣ One payment for life ($3,495)
❤️ My personal gratitude for life
🔗 👇👇👇

[Justin Schroeder @jpschroeder]

📣 Announcing: KickStart!

A next-generation form builder from the @FormKit team. Going live...now 👀

Generate a form, edit it with manual controls or AI prompts, then copy and paste @vuejs components or schema into your project.

🔗👇

[FormKit @FormKit]

And make sure you're importing only the Pro Inputs you need in your installation:

import { createProPlugin, repeater, dropdown } from @formkit/pro

[FormKit @FormKit]

We've greatly improved tree shaking in FormKit Pro.

Update to v0.125.2 or later to get the benefits.

[FormKit @FormKit]

@IsraelOrtuno Great to hear. We may have something that helps with this in the near future.

[Justin Schroeder @jpschroeder]

🚨🚨 New FormKit Pro input released today...🥁...

The currency input! 💰💸💵💶💷💴🪙

🔗👇

[Justin Schroeder @jpschroeder]

Coming soon to @FormKit — built in icon loaders!

- Eva
- FormKit
- Hero
- Ion
- Lucide
- Material

Anyone other open source icons we should add?

[FormKit @FormKit]

@ivano_da_gioia Oh no! was this adding it to an existing nuxt 3 app? We’ll take a look and make sure there aren’t any known issues there.

[Luan Nguyen @luanguyen]

.@FormKit is 2 stars away from 4,000. Push us over 🙏!

https://t.co/Gu5F7jbXc4

Also thankful for our other open source projects getting love:
- AutoAnimate: 11,467
- Tempo: 1,947
- Drag and Drop: 786

[FormKit @FormKit]

We expected "Integration w/ UI libs" to win.

But were surprised that "Form builder + publish" was a close 2nd.

Thanks for voting!

[FormKit @FormKit]

Which FormKit feature would you like to see next?

Reply with other feature requests if not in the poll.

[Justin Schroeder @jpschroeder]

FormKit 1.6 is out today!

🧩 New composables like useFormKitContext
⚙️ Improved TypeScript support
📙 Added library prop for FormKit components
🐛 Deez bugs fixed: https://t.co/1SQF9MMfk3

Excited about the composables! They let you build complex forms even more fluently ❤️

[Justin Schroeder @jpschroeder]

Rolldown might be the most important web project of the next 5-10 years. I thought it might be helpful to explain why:

The landscape:

Rollup is the best and most comprehensive bundler to date. It was ahead of its time, pioneering key concepts like tree shaking (🙏 @Rich_Harris & @lukastaegert) and still hasn’t been matched in this regard. When @evanyou introduced @vite_js — Rollup was a cornerstone of the build process. Vite plugins are (for the most part) Rollup plugins.

It didn’t take long for Vite to become the standard development and build environment for nearly every major meta framework: @nuxt_js, @solid_js start, @sveltejs kit, @remix_run, @angular cli, etc. (basically everything except Next). Rollup is still the underpinning of all of these. It has gone from being a way to bundle your library before publishing on npm to the backbone of how the modern web is being written.

The problem:

We find ourselves in a world where Rollup has been pressed into service building nearly every byte on the web — something it wasn’t originally intended to do — and its performance (really JavaScript’s performance) could be improved. esbuild (🙏 @evanwallace), a bundler written in Go, showed the world just how much faster a "native" bundler can be, but esbuild was not Rollup compatible and had its fair share of shortcomings as well (no TypeScript, limited tree shaking, etc.).

@vite_js uses esbuild and Rollup to get the best of both worlds, but here lies another problem: parsing. Different build tools use different AST trees, and each of these must parse the code to derive the AST. Also, many plugins for Rollup/Vite perform their own parsing. Wouldn’t it be incredible if the parsing was done a single time and a single AST tree could be used by all layers of the build stack?

@evanyou said recently that @vite_js often has to parse the same TS file at least 5 times at various levels in the stack. Clearly this could be better.

The solution:

The @rolldown_rs project is attempting to (eventually) solve all of these problems. First, it is written in Rust, one of the fastest languages out there — generally even faster than Go (i.e., esbuild) due to Rust not using garbage collection. In some applications, this doesn’t matter much, but in the context of parsing and compiling, this is a massive benefit (oh the irony that Rust itself is the world’s slowest compiler 😂).

Rolldown isn’t just attempting to be fast though, it is also attempting to be API compatible with Rollup. This would be a monumental accomplishment (the Rollup API is not for the faint of heart). If successful, the @vite_js team could swap out the engine inside Vite while the plane is flying and we wouldn’t notice anything except we arrived at our destination much earlier.

Finally — and perhaps most ambitiously — a standard singular parse. Perhaps this is a bit further down the road, but because Vite is so prevalent and because Rolldown uses OXC (🙏 @boshen_c) for parsing, we could end up in a world that standardizes around a single parse and AST tree. The performance improvements we could see in our development environment and build times would be tremendous.

If successful, Rolldown will be responsible for transforming nearly every byte of web code — no matter what framework you use (happy to share my thoughts on what it means for Next some other time).

Thanks:

Finally, thanks to the @vite_js team, and everyone working on @rolldown (@_hyf0, @_h_ana___, @evanyou)! I am in no way affiliated with these fine engineers, just a mere plebe building on the backs of these giants.