Menu
I want to implement frontend validation with either Yup or Joi.
From all the docs and articles that I've found, I've got to a couple of conclusions:
However, I didn't manage to find what Joi lacks in terms of support compared to Yup?
Right now, from all of these conclusions, it's choosing to either have a smaller bundle or better performance.
296
Joi can be used for creating schemas (just like we use mongoose for creating NoSQL schemas) and you can use it with plain Javascript objects. It's like a plug n play library and is easy to use. On the other hand, express-validator uses validator. js to validate expressjs routes, and it's mainly built for express.
It can be used for Node. js or in the browser by bundling with webpack or browserify.
Hapi Joi is an object schema description language and validator for JavaScript objects. With Hapi Joi, we create blueprints or schemas for JavaScript objects (an object that stores information) to ensure validation of key information.
Joi has better performance Joi is more popular for backend validation, while Yup is more popular for frontend validation Joi has a lack of support on the frontend Per official docs, Yup is leaner and built with client-side validation
It was still possible to use Browserify on it, or use the unofficial joi-browser npm package, but the process was cumbersome enough that it was less common to see joi used on the frontend. Yup was basically a workaround for that.
In Joi, you need to use Joi.object () to instantiate a Joi schema object to work with. All schemas require Joi.object () to process validation and other Joi features. You need to separately read req.body , req.params , req.query to request body, params, and query. You can just require express-validator and start using its methods.
I recommend using Yup if you do a lot of form validation because its extensive functions cover many patterns that are used in forms, even situational ones where you have to do a rounding.
In the past, it was true that joi lacked browser support, at least out of the box. It uses a few Node.js APIs, which aren't available in the browser, to implement some of its features. It was still possible to use Browserify on it, or use the unofficial joi-browser npm package, but the process was cumbersome enough that it was less common to see joi used on the frontend. Yup was basically a workaround for that.
However, that information is out of date, as joi now includes an official browser build that's easy to use and roughly the same size as yup. See its package.json: https://github.com/sideway/joi/blob/83092836583a7f4ce16cbf116b8776737e80d16f/package.json#L8
Your bundler, assuming it is set up correctly, should detect the browser build and use it automatically. For example, if you're using Rollup, make sure you are using @rollup/plugin-node-resolve with the browser: true option.
I would strongly recommend using joi on the frontend now as you can share schemas between frontend and backend, which is really fantastic.
114
For the front-end, performance bundle size is more important rather than fast work (you do not need to make millions of validation on the client-side). As you mentioned: "Yup bundle size is ~2.5 times smaller than Joi - link"
So my choice is Yup.
But if you use joi for the back-end and going to share schemas with the front-end I agree with Seth Holladay.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
