Formik === Final Form ??
Tags: react
Published: 2020-10-17 23:33:05

This post is not a battle royal or a straw man debate where one library stands victorious at the end. No, both [Formik](https://github.com/formium/formik) and [Final Form](https://github.com/final-form/final-form) do forms quite well and evidently with incredibly similar APIs. Their differences do not become apparent until you dive into the philosophies behind the development of each. 

Checkout the source code and play with the [app](https://unruffled-clarke-fc36d4.netlify.app/) if you are curious.

{% github hansjhoffman/formik-final-form no-readme %}

## Philosophy

### Formik

The primary guiding principle behind Formik was to keep it simple. Consequently, this constraint resulted in no external state management, no subscriptions or observables and no re-inventing the wheel - it simply uses React. Therefore, if you have a problem understanding Formik then you probably have a problem understanding React.

### Final Form

The creator of Final Form, [Erik Rasmussen](https://twitter.com/erikras), also wrote [Redux Form](https://github.com/redux-form/redux-form). Certain [issues](https://codeburst.io/final-form-the-road-to-the-checkered-flag-cd9b75c25fe) encountered in the aforementioned evidently influenced the two-part structure of Final Form: 1) a [core](https://github.com/final-form/final-form) written in Javascript to make it framework agnostic and 2) separate wrappers around Final Form’s subscription-based state management in your framework of choice such as [react-final-form](https://github.com/final-form/react-final-form) or [vue-final-form](https://www.npmjs.com/package/vue-final-form).

## Performance

### Formik

Since Formik is built with React, it naturally takes advantage of builtin performance optimizations. Should you _really_ need it (e.g. gigantic forms with > 70 fields), React’s `shouldComponentUpdate` lifecycle method can be indirectly used through the special `<FastField />` component.  

### Final Form

Final Form is based on the Observer pattern, so observers can subscribe to receive updates for either form or field state changes. By default, like Formik, it subscribes to all form updates. It keeps state out of React, and then uses React context to hook in to the tree with react-final-form as previously mentioned.

It is not clear to me how subscription based performance enhancements compare with React’s reconciliation algorithm since I could not find any thoroughly detailed assessments. Therefore, I remain skeptical until proven otherwise. 

## Validation

### Formik 

Formik capitalizes on the powerful, and popular validation library [Yup](https://github.com/jquense/yup). Yup’s builder pattern makes building validation schemas a breeze and less error prone. You can also bring your own validation (BYOV) if Yup is not sufficient for your particular use case. 

### Final Form

Sadly, unlike Formik, Final Form subscribes to the BYOV philosophy. This is where I feel that the library missed an opportunity to save developers from themselves. Form libraries (in my opinion) are supposed to help with validation not skimp on it. 

## License

Formik → Apache 2.0
React Final Form → MIT

## Bundle Size

Minified + gzipped:

[Formik](https://bundlephobia.com/result?p=formik@2.2.0) → ~15 kB
[Final Form](https://bundlephobia.com/result?p=final-form@4.20.1) + [React Final Form](https://bundlephobia.com/result?p=react-final-form@6.5.1) → ~9 kB
[Redux Form](https://bundlephobia.com/result?p=redux-form@8.3.6) → ~27 kB (for comparison)

## Conclusion

As previously stated, the two libraries are quite similar so it really comes down to a simple question: which one does your your team prefer?