Hello, I'm developer of typescript-json and have measure a benchmark comparing performance with other competitive libraries. By the benchmark, my library typescript-json has been turned out that maximum 1,000x times faster than zod.
Being proud of such performance enhancement, I hope many TypeScript developers to adapt my library. Advantage of typescript-json is not only better performance, but also easy usage exists. typescript-json does not require any extra schema definition and just requires only one line with pure TypeScript Type. Thus, what about using my library typescript-json instead of io-ts or zod?
// ALLOW SUPERFLUOUS PROPERTIES
export function is<T>(input: T): boolean; // true or false
export function assertType<T>(input: T): T; // throws `TypeGuardError`
export function validate<T>(input: T): IValidation; // detailed reasons
// DO NOT ALLOW SUPERFLUOUS PROPERTIES
export function equals<T>(input: T): boolean;
export function assertEquals<T>(input: T): T;
export function validateEquals<T>(input: T): IValidation;
p.s) Of course, as this benchmark is being measured by me, someone can doubt objectivity. Therefore, to ensure objectivity, I diclose all code used in the benchmark. Below codes are being used in the benchmark. You also can run the benchmark program by running npm run benchmark command after downloding this typescript-json.
- Schemas
- Benchmark Program
is() function
export function is<T>(input: T): boolean;
Measured on Intel i5-1135g7, Surface Pro 8
I hadn't known that zod is extremely slow until running on this benchmark program. io-ts is also slower than typescript-json and ajv about 8x times, but its slow performance looks like nothing comparing with zod.
More amazing thing is, ajv requires JSON schema definition for validating, but it can't validate the JSON schema type itself. Although other libraries io-ts and zod also failed to validating the JSON schema definition, isn't ajv different with them? Furthermore, when complicate type comes, ajv dies with runtime error in the most case.
validate() function
export function validate<T>(input): IValidation;
export interface IValidation {
success: boolean;
errors: IValidation.IError[];
}
export namespace IValidation {
export interface IError {
path: string;
expected: string;
value: any;
}
}
Measured on Intel i5-1135g7, Surface Pro 8
Unfortunately, unable to measure ajv's performance because it does not support the validate function describing detailed error reasons.
Anyway, although zod is the slowest library even in the validate() function, performance gap with other libraries are dramatically(?) reduced. Also, performance gap ratio with typescript-json with io-ts are sometimes increased and sometimes reduced.
By the way, when measuring of zod, I sometimes doubted myself, "Have I taken a mistake?". But there was not any mistake and I wondered why zod is such slow. To analyze the reason why, I'd read source code of zod and this is my conclusion.
Although zod is the slowest validator, error reasons are more detailed and exact than io-ts. Therefore, its slow performance on
validate()function is understandable.Also, zod hasn't implemented special logic for
is()function and let user to re-use thevalidate()function. Therefore, when zod implements the independentis()function algorithm, I think its performance can overcome io-ts.
Full Spec of TypeScript Type
typescript-json is much faster and much easier to use than io-ts and zod. But it's not all the thing. typescript-json can validate full TypeScript Type spec. Below table is a list of supported spec sheet about competitive runtime validator libararies. As you can see from the below table, only typescript-json can validate complicate union types.
| Components | TSON |
ajv |
io-ts |
zod |
C.V. |
|---|---|---|---|---|---|
| Easy to use | ✅ | ❌ | ❌ | ❌ | ❌ |
| Object (simple) | ✔ | ✔ | ✔ | ✔ | ✔ |
| Object (hierarchical) | ✔ | ❌ | ✔ | ✔ | ✔ |
| Object (recursive) | ✔ | ❌ | ✔ | ✔ | ✔ |
| Object (union, implicit) | ✅ | ❌ | ❌ | ❌ | ❌ |
| Object (union, explicit) | ✔ | ✔ | ✔ | ✔ | ❌ |
| Object (additional tags) | ✔ | ✔ | ✔ | ✔ | ✔ |
| Object (template literal types) | ✔ | ✔ | ❌ | ❌ | ❌ |
| Object (dynamic properties) | ✔ | ✔ | ❌ | ❌ | ❌ |
| Array (hierarchical) | ✔ | ✔ | ✔ | ✔ | ✔ |
| Array (recursive) | ✔ | ❌ | ✔ | ✔ | ✔ |
| Array (recursive, union) | ✔ | ❌ | ✔ | ✔ | ❌ |
| Array (R+U, implicit) | ✅ | ❌ | ❌ | ❌ | ❌ |
| Ultimate Union Type | ✅ | ❌ | ❌ | ❌ | ❌ |
Latest comments (36)
Ever heard of ArkType?
As I've promised, wrote an article introducing how to use
typiainNestJS.dev.to/samchon/nestia-boost-up-you...
deepkit.io/library/type
What about more advanced runtime validations, like basic regex?
github.com/samchon/typescript-json...
Is this what you want?
That looks great. if you could combine this with branded types, so instead of email: string
you would have email: Email
And an Email type that would carry the email validation rules. And has eg type string &
Brand<EmailBrand>deepkit.io/library/type
Still a long way to go 😉
I know that library and also benchmarked it. However, it requires too much compilation time and does not support any complicate type like generic. I will report bug soon.
"too much compilation time" are you transpiling code on a potato? I've had no issues whatsoever.
"complicate type like generic" I've still had no issues whatsoever.
Anyway, it's like comparing a quantum computer to a potato 🤷♂️
Can you use
typescript-jsonto validate based on JSON schemas like whatajvdoes?Use
TSON.application()function. It may what you want.You should benchmark against
@sapphire/shapeshift!Welcome your PR.
Two questions...
No plan to measure yup because it does not support even union type
No plan to make it. But welcome if you make and publish it as your own.
By the way, I made a react library which requires only TypeScript type like below. It would be published after styling, clear API designing with documentation. This may be what you want.
My dead grandma's dead dog is faster than TypeScript. low bar
Congrats!