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 | ✅ | ❌ | ❌ | ❌ | ❌ |
Top comments (35)
Suretype is an excellent library that folks forget to mention.
Thanks again for suggesting this library which I used in the end. Instead of deriving the validation from the types like here, they go the other way around. You define the validation rules, which can define more precise rules than mere type definitions, and it deduces the type directly. That way, you don't need the intermediate code generation step like in this article, you get more precise validation and full typing support. Truly the best of both worlds.
It's not even packaged as an NPM module? (I know it can be npm installed from GitHub directly, but that's not nice...).
deepkit.io/library/type
Interesting. I was just looking for a json/ts validation library, what a coincidence! Well, I might as well try this out. ;) By the way, as a humble developer, performance is nice but simplicity is key. Thanks for the lib.
Hmmm.... My first attempt failed.
no transform has been configured
. I guess the generation of schemas during the compilation step is missing. Btw, I'm usingwrangler
which is a toolchain of its own, so I have no idea how to incorporate the step.The
wrangler
is something likecra
orvite
? If you can configurewebpack
, then you can use thistypescript-json
following README article. If configuring customwebpack
is too hard, I recommend to usevite
instead because its configuration is the easiest one.If you wanna detailed help or guide, you also can write an issue on the repo. Then I or another developer may help you.
Wrangler should delegate to whatever is executed by package.json's build script . Usually it's either esbuild or webpack.
As I've promised, wrote an article introducing how to use
typia
inNestJS
.dev.to/samchon/nestia-boost-up-you...
Congrats!
wow! congrats!
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 🤷♂️
Written by a guy who has never had to hand validate hundreds of dependant models, discriminated types and deeply nested model heirarchies.
No, it's not "clean architecture". It's "Dunning–Kruger effect".
Well, I'm still a junior, please don't judge me, I'm still learning! Whenever I'm doing my whole entity validation with joi, zod or something else, my business logic becomes coupled to it. And when I read the clean architecture book it says, that the core entities should not directly depend on anything. But I understand it's not a law.
Can you use
typescript-json
to validate based on JSON schemas like whatajv
does?Use
TSON.application()
function. It may what you want.You should benchmark against
@sapphire/shapeshift
!Welcome your PR.
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>