Does the is method support TS interfaces or just classes that exist during runtime? I ask because I played around with type guards for interfaces using code generation to create runtime representations of interfaces, and I wonder if that's something typia does.
I worked with TS in the past and now I work with Java and protocol buffers, where I also did code generation based on generated Message Java subclasses. Interesting to see what protobuf looks like in TS.
Yes, this is a transformer library generating validation script by analyzing TypeScript type. If you're wondering how typia generates protobuf message, reference test automation code.
I know automatically generated message by current typia is so ugly yet, but it would be reasonable. Also, as you are interested in protobuf, you may understand how typia implemented non-protobuf supported type through detour expression.
In another community, someone asked me the reason why such performance gap.
It's my answer and I also paste it here dev.to
"15,000x faster" is just a benchmark program result and such different is not weird considering principle of v8 optimization. It is enough reasonable and descriptable.
typia performs AOT compilation through TypeScript API
ajv and typebox performs JIT compilation through eval() function
class-validator abuses for in statement and dynamic [key, value] allocation in every step
V8 engine optimizes object construction by converting to a hidden class and avoid hash map construction for taking advantages of static class definition. However, if for in statement or dynamic key allocation being used, v8 cannot optimize the object.
The secret of extremely slow validation speed of class-validator is on there. class-validator utilizes the un-optimizable in every process.
for in statement on metadata when iterating raw data to transform
dynamic allocation when transforming to a class instance
dynamic statement on metadata (of decorator)
for in statement when validation
For reference, ajv and typebox are using JIT compilation, generating optimized code in runtime through eval() function (or new Function(string) statement). In v8 engine, priority of optimization is the lowest and it is the principle reaon why typia is faster than such ajv and typebox libraries.
Another reason is how to optimize object accessment. You can see the detailed story about it from below link (this article)
![Cover image for [Typia] 15,000x faster TypeScript Validator and its histories](/samchon/typia-https-media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Frvtijd06cf7v87v30iqv.png)
This looks great!
Does the
ismethod support TS interfaces or just classes that exist during runtime? I ask because I played around with type guards for interfaces using code generation to create runtime representations of interfaces, and I wonder if that's somethingtypiadoes.I worked with TS in the past and now I work with Java and protocol buffers, where I also did code generation based on generated
MessageJava subclasses. Interesting to see what protobuf looks like in TS.Yes, this is a transformer library generating validation script by analyzing TypeScript type. If you're wondering how
typiagenerates protobuf message, reference test automation code.I know automatically generated message by current
typiais so ugly yet, but it would be reasonable. Also, as you are interested in protobuf, you may understand howtypiaimplemented non-protobuf supported type through detour expression.github.com/samchon/typia/tree/feat...
In another community, someone asked me the reason why such performance gap.
It's my answer and I also paste it here
dev.to"15,000x faster" is just a benchmark program result and such different is not weird considering principle of v8 optimization. It is enough reasonable and descriptable.
typiaperforms AOT compilation through TypeScript APIajvandtypeboxperforms JIT compilation through eval() functionclass-validatorabuses for in statement and dynamic [key, value] allocation in every stepV8 engine optimizes object construction by converting to a hidden class and avoid hash map construction for taking advantages of static class definition. However, if
for instatement or dynamic key allocation being used, v8 cannot optimize the object.The secret of extremely slow validation speed of
class-validatoris on there.class-validatorutilizes the un-optimizable in every process.For reference,
ajvandtypeboxare using JIT compilation, generating optimized code in runtime througheval()function (ornew Function(string)statement). In v8 engine, priority of optimization is the lowest and it is the principle reaon whytypiais faster than suchajvandtypeboxlibraries.Another reason is how to optimize object accessment. You can see the detailed story about it from below link (this article)
great job with this library🎉 will definitely give it a try.
I am proud to be your first comment.
There's too much I don't understand about your post 😅
But I recognize that there is genius here. And
typiawill be very famous 💙🔥Thanks for the interesting material, I use ajv actively, it's definitely worth it
Can it replace the tsc? Very exciting project and I can't wait to try it out.
Well, this is not a project for replacing
tsc(TypeScript Compiler).As I've promised, wrote an article introducing how to use
typiainNestJS.dev.to/samchon/nestia-boost-up-you...