🎞️ Videos → What if TypeScript has Type Integrity

Introduction and Initial Technical Discussion0:00

Woo!

Yeah. Okay, so this section is going to be speak in English. So I hope you guys are familiar with the topic. Maybe, maybe not.

If you are not familiar with the topic, that's okay. Because we are going to talk about the overview of JavaScript and TypeScript in general.

Speaker Introduction and Cosplay0:24

Okay, let's start with a little bit of introduction. You can call me Aom, or if you're not sure how to pronounce Aom in English, you may call me Salty.

The full name is SaltyAom. I use this name on both Twitter and other places as well where it's like the blue app, like Bluesky or something. Everywhere else I use this name like Twitter, GitHub, and Bluesky as well if you want to follow along.

If you are Thai, you probably know that I usually cosplay as my favorite character to speak about

technical stuff. Today I cosplay as Pekomama from the kind of the

company that made VTubers.

Let's just skip because about license and stuff.

Technical Quiz: Guess the Language1:37

Oh, I see. So we're going to wait.

Maybe we can wait 5 minutes and start again? Sure, okay. Because we are a little bit earlier than time that we have. Actually it should be 10 minutes after this, right? Okay, sure. Maybe talk a little bit in general. Maybe we can get some idea about what I'm going to talk about today. But we are going to restart it all again after this 10 minutes. Is that alright?

Sure, okay.

Let's start with a little bit of quiz time, right? Just like for fun.

Let's start with this code example. We are going to play Who is a Millionaire?

What is the language of this code? I'll give you a little bit of time to think about it.

Maybe like we count down like 5, 4, 3, 2, 1.

Let's show the answer.

JavaScript ES4 History and TypeScript Overview3:00

The answer is actually JavaScript ES4, not TypeScript. You can see the syntax here. It looks almost identical to TypeScript, right? But actually, this proposal was introduced in JavaScript ES4 where maybe almost 20 years ago.

There's a proposal to add type natively to JavaScript.

This proposal was almost added to the language, but somehow dropped it because there are too much stuff that they want to add into the JavaScript language. But there's a lot of things that they can't implement and they just skip to ES5 as we know it.

That's a little bit of history.

I think maybe we can start or should we still wait?

What is TypeScript? (Definition, Compilation, and Popularity)4:03

Okay, let's start with what is TypeScript.

TypeScript is just like JavaScript with type. I think a lot of people know that. If you don't know TypeScript, it actually just adds some type annotation to JavaScript and that's just it.

You can't actually use TypeScript in browser, because you have to compile it since it isn't actually a language that you can run in the browser and it doesn't have browser support. So we somehow need to transpile the language into JavaScript to run it in the browser.

We can see in this example that this is what TypeScript is like.

You just add some colon after the parameter and you add type to it. So when you try to call a function with string, it is fine. But when you try to add a number, it throws an error.

That's actually just what you want to add to the language, just add a type to it and if the type doesn't match, maybe throw an error or something like that. We can see on the State of JavaScript,

in the last year, there are a lot of people that have been trying to adopt TypeScript maybe in their side project and their work. The charts show that there's a lot of people who are enjoying TypeScript and some people who don't enjoy it.

TypeScript's Duck Typing and Type Safety Issues5:48

But since we add type to the language,

does it actually work? If we think about it, we can actually just surpass this error.

TypeScript doesn't actually check the type in the runtime. So when you pass something that maybe TypeScript can't check, it is going to ignore it and pretend that everything is fine. TypeScript is like duck type. If it moves like a duck and quacks like a duck, then it's probably a duck. Let's say that you pass something that looks like a string, but it isn't actually a string,

it is going to work fine because TypeScript pretends that it is a string. Let's get back to our example. We can see that in this example, we pass a number and then everything is fine. But if we pretend that the number is something else,

it is going to be fine because TypeScript doesn't know what type of it.

So everything works fine when actually it shouldn't be this way.

Solutions for Improved Type Safety: Type Inference and Transformers7:07

So a lot of people are trying to make TypeScript be

A lot of people trying to make TypeScript better behave in this way. They try to make a lot of stuff recently and we have been using it a lot recently

that trying to fix something like this.

There's actually two solutions that we can prevent this from happening. The first one is we use type inference,

and the second one is transformer. But I have to warn that both of these solutions doesn't actually make TypeScript like a strong type language, but it's like some patches that we can apply to make TypeScript a little bit better at checking type.

Type Inference with Zod and Generics8:02

Let's go over our first topic, which is the type inference. I think a lot of people know what Zod is. Basically, it is a TypeScript library that you can define what the shape of object looks like. And then you can check if the input,

something you have in the code base, that need to check if the type is actually a type or not. You can use 𝚙𝚊𝚛𝚜𝚎 or something like that utility function. First, you define the object in JavaScript and then once you define the object shape, you can use that reference to check if something else is the same as you want or not. So in our case, we have an object with a username string and then we parse it using something else. And if it work, it is going to work, but otherwise it's going to throw an error. But the interesting thing is that recently we have been adding something like getting the type from our code. If we see, we can see that on the last line, we infer the type from the first one in the JavaScript code base. And then we use some utility call 𝚣.𝚒𝚗𝚏𝚎𝚛 and then we get a type. So this is what we call type inference, is that we write the code first and then we infer type from the code later.

Actually, we can implement something like that. Maybe it doesn't look easy, but actually TypeScript provides us with something called generic. Generic is like something, if we have written

some code in other language like maybe Rust, Java, we can pass some type and then infer something somewhere else. But ultimately, TypeScript also supports this same feature as well. So we can create some interface of class and then memorize the type and then provide them, does some recursive stuff to make something like that happen. But it has just been supported in recent version of TypeScript. So maybe TypeScript 4 or later,

which isn't long ago yet, which is the exact timeline that Zod and some library like that have been popularized.

So after we wrote some magic type, we can infer type from here. Actually my previous two talks were talking about how to implement this. So if you want to take a deep dive, maybe you can search in YouTube, but I'm not sure if it is uploaded or not.

Drawbacks of Implementing Type Inference and Audience Arrival11:00

So it is great, right? But that comes with a cost and drawback. The first thing is that you have to make sure that the code actually works by making sure that the code actually validates type correctly. And once we did that, we have to also make sure that our type system in the type level work as same as the code in the runtime. Which means that we now have to separate code base that should function the same. And this is very hard to implement in our code bases. Since I made Elysia, right? We have a lot of black magic about typing and stuff. We have to add unit test for type level to make sure that everything works all right.

So since I show you something like this,

when should you write it yourself? The answer is you shouldn't, you should never write it in your application code base. Like if you have some application that you use in production, you need to ship a feature to your customer, you shouldn't write that at all. You should just let the... oh like a lot of people are coming. So do I need to restart or something?

We have time. Are you guys okay? Can we recap a little bit?

Okay, I didn't thought that there's going to be a lot

of people.

Actually, we have just surpassed halfway through.

Recap and Apology for False Start13:05

Let's review a little bit.

I'm sorry for everyone. I like to talk about it so much. I want to get start quickly. You know that we have three people who are talking as keynote speaker, right? I actually want to see how the other speakers are going to speak. Somehow we have the same timetable.

I can't apply to other speaker, which is making me mad, actually. So, let's restart it again. Sorry for everyone who was here before.

Give me a minute.

I talk a little bit too much at first. Let's review.

TypeScript with Type Integrity and Speaker Introduction (Restarted)14:06

Today, we want to talk about TypeScript with type integrity.

Today, we are going to talk about TypeScript with type integrity. Obviously it's something that I'm not sure what it is about. Since we know that programmers are bad at naming things, I think it's understandable. I hope you guys forgive me for that. A little bit of introduction. My name is Aom in Thai, but for people somewhere else,

you can call me Salty or SaltyAom. Basically, I am a core maintainer of Elysia.js. It's a framework for making web server Bun, which does a lot of black magic with typing and stuff. This name I use on both Twitter, GitHub, and mostly everywhere else, including some games.

If you found player with this username, it's usually me.

If you are Thai, you mostly familiar with what I have been doing recently. I apply to a lot of talk and conference to talk about stuff I interested in. Mostly the organizer usually request me to cosplay to speak. Also this one as well.

The organizer actually request me to maybe cosplay and speak.

A lot of people actually follow my Instagram account and saw that I cosplay.

Today I cosplay as Pekomama, which is from the Vtuber company called Hololive. I think a lot of people are familiar with it. If you know like Pekora, Fubuki, or Gawr Gura or some people like that. They are Vtuber who are streaming gaming and something like that on YouTube and Twitch.

This talk is going to be recommend for beginner levels. We are going to give about general overview of

TypeScript. If you don't have any experience with TypeScript, that's fine. If you have a little bit, that's going to help a lot. Let's get started.

Technical Quiz: Guess the Language (Restarted)16:58

Let's start with a little bit of quiz. I think a lot of people who were here before already know the answer.

You can see this code, right? It does have interface, and it does have type annotation. My question is what is the language of this code? I will give you a little bit of time, like maybe 10 seconds to think about it. People already know the answer, but for the newcomer, maybe you can think a little bit about it.

Yeah, I think it's good time now.

JavaScript ES4 History and TypeScript Overview (Restarted)17:35

The answer is JavaScript ES4.

You can see this syntax here. It almost looks like TypeScript. It does have type annotation. It does have class. It does have interface. Actually, it also have a public and private property as well. But this feature was first announced in JavaScript ES4, which is like almost 20 years ago or so.

So we almost have type support in JavaScript,

which is what we are trying to achieve today with TypeScript, right? But since there's a lot of history lesson, which I actually skip, and I don't know why they skip this version and straight to ES5. My guess is that they add too many features that too hard to implement in one version. So they just decide to skip it. But what is TypeScript in general, right? TypeScript is just like JavaScript with type. That's it. That's actually what TypeScript is. Although it's very popular with JavaScript user, like just adding type, and then a lot of people who use JavaScript then somehow magically want to use TypeScript. It's just type, but that's actually a lot of feature added in the language that is dynamic type and can get very complex quickly, like JavaScript.

TypeScript Compilation and Runtime Support19:09

So the TypeScript language itself can't be used

in the browser because the browser only knows JavaScript, but TypeScript isn't JavaScript. It is just like JavaScript with additional step that we can add some stuff into it. And in this case, it's just we add the type to it. So first we need to compile TypeScript to JavaScript itself first, and then we can use it in the browser. But this also apply to runtime like Node.js, but recently they ship some experimental stuff that we can use TypeScript directly in the runtime. Deno and Bun also add the ability to run TypeScript file natively. Although it is not actually native, they just remove the type and run it as JavaScript, but I think that works as well.

TypeScript Type Example and State of JavaScript Survey20:09

But let's recap, right? Okay, a lot of people are already familiar with this. We have a function, and then maybe we say that this function should only accept a string like a word or something like that. So when we call it with word, it is going to work, but when we try to call it with the number, it doesn't work. So that's actually the point of TypeScript. We just want something that we can rely on and then make sure that we passing the correct stuff and everything is typed correctly. If we look at the state of JavaScript in the last year, we can see that a lot of people have been enjoying this feature like a lot. Although it's just type annotation, but actually that helps a lot in large codebase

and complex type. A lot of stuff have been helping. So a lot of people have been adopting TypeScript recently. We can see that almost 50% are satisfying down here. And then some people doesn't want TypeScript, they can use JavaScript.

The Problem with TypeScript: Duck Typing Explained21:25

But there's actually a problem with TypeScript itself. So we can see this code, right? It's we have a function that should only accept a string, but when we pass a number, it work fine, but actually TypeScript doesn't actually check a type. It only trying to make it look like it's checking a type, but it doesn't actually check it. So I want to introduce you to some concept called...

what is it called?

Okay, I actually forgot the term although I just talked about it 10 minutes ago, but it's called duck type if I recall correctly. But it is something that say that if it moves like a duck and quack like a duck, then it is likely a duck. So we have a duck here, and we have a rubber duck here. So if the rubber duck move like a duck and when we squeeze it, it also quack, then it's probably a duck. Although it isn't what a duck we want,

but it also a duck. So TypeScript look at these images and then say that both are the same because they both are a duck. Actually, that's a concept that TypeScript have been using.

Duck Typing Example in Code22:53

So back to our code, we can see that our code function normally when we pass something like this. But when we try to say that a number isn't actually a number, but it is something else, this code somehow work perfectly fine. So we have a number, and we say that hey, you can see that

what if we say to TypeScript that what if it isn't a number? Can we make it something else? And then it pass, although in our codebase, actually runtime code doesn't work. TypeScript isn't going to complain about it because it looks like a number. It looks like a string. So that's fine to TypeScript, but isn't fine to us and customer because it is going to throw error in the runtime and then fail our production server. So recently there have been an effort to make TypeScript actually a strong type language, although it isn't actually a strong type language, but we are trying to get there.

Two Solutions for Improved Type Safety (Restarted)24:05

So there is actually two ways to make this happen: the first one is we are using something called type inference, and the second one is called transformer. But both of these doesn't actually make the TypeScript a strong type language. So just a note before we start.

Type Inference with Zod and Generics (Restarted)24:28

So, type inference, I think a lot of people know what Zod is about. Like we define some shape in runtime, and we validate the shape in runtime as well. But we can also get a type from runtime into the type itself. We don't have to duplicate the code, say that we have an object with a username in runtime, and we don't have to duplicate the code in the type level, like manually writing the interface that call like user.

We actually can infer the type from runtime itself. We write the code in the runtime and infer code to the type. This feature has just been recently added not long ago, like maybe two or three years, like in TypeScript 4, not sure which version, but there's a way to make it happen, which is using the thing called generic. Generic is like a function or some kind of special function,

but it behaves like a function if you think about it. Like you accept something from the class or interface, and then you can somehow make stuff with it. And with that type of both, we can make something with the code below. So, we can see that we add some type here, something like this, and then boom, it's going to work. I also talk about this like two sessions ago, like maybe three months or four months ago. I'm not sure if it is recorded or not, but if you find one, please post it in comment if you are watching from the recorded video. But actually, it seems cool, but it has a drawback that we have to maintain both runtime code to make sure that runtime code actually validate the type, and then we have to maintain the type itself as well. In our code bases that we are working in Elysia, we have been like a lot of black magic with type stuff, but it is so complex that we have to add the unit test for type level to make sure that runtime and type level, both of the code match the same behavior.

When to Use Type Inference and Elysia Code Example26:57

So, when should we use this, right? If you are using in the production server, like maybe you want to try to ship stuff

to your end user, your customer, you shouldn't write it yourself because it is going to slow you down. But if you are using a library, that's fine because they have been devoting their time in their free time to make some stuff in the production a little bit faster.

Just let some dedicated people handle it because it is going to consume a lot of time to make it happen correctly. So, this is the generic code in our code base. You can see that we have complex stuff from real code base, from real open source library, and this is just like the generic. There's a generic that accept it here, and then we do several like 3,000 or 4,000 lines of type to make stuff happen. So, you can see that it is actually code base in Elysia. I don't recommend you to look at it if you aren't familiar with TypeScript. But this pattern make a lot of things possible, like tRPC, Zod, Prisma, Drizzle, and Elysia itself.

Transformers: Turning Types into Code28:17

So, the second one is transformer. You may ask, what is it? This is actually the less known way to make it happen. The first way is that we write a code and transform it to type, right? But in this approach, we say that we have a type, and then we turn it into a code. So, how is that possible, right? Actually, there's some library called typia or typespec or io-ts that you can define a type in TypeScript, and then you can use that type in runtime.

How is that possible, you may ask? TypeScript actually let you access the AST parser

and then transform it into something else.

If you are familiar with AST, then I recommend you should check it out because it's actually very cool. You can do a lot of stuff with it. But you know that AST is amazing and it is very hard to handle it if you are not familiar with compiler or something like that. But the actual drawback is that

although TypeScript expose the API for handle stuff like that,

it doesn't actually let you run it in TypeScript itself. You have to install some additional library called ttypescript and then you add the plugin into the compiler plugin in TS config to make it happen. Because TypeScript doesn't support it natively, a lot of people aren't using it because they want to rely on TypeScript itself, not some external runtime.

Taking Type Inference to the Limit: GraphQL Mobius and SQL to Type30:14

So what happened if we took type inference to the limit,

you may ask?

We have a little project that I did in my free time. The first one I published maybe a year ago is called GraphQL Mobius,

which allowed us to transform the string of the GraphQL into the type. You can see upward here that we have type definition writing in GraphQL and then we pass it into class called Mobius and then it generate the type. Actually this doesn't run any type, but we are actually using pattern matching in TypeScript in type level TypeScript to create something like AST and then pass it to the type. This doesn't involve any runtime code at all. There's no code generation, there's nothing. You don't need a CLI, you can just pass the type to the interface and then it create an AST syntax tree and then you can pass into the type. So you can actually create a compiler using pattern matching if you are crazy enough like what I did.

But we can also pass SQL to a type as well, not only limited to GraphQL. So this pattern actually also applicable to gRPC and something else if you are crazy enough.

I published both of these in GitHub and in my Twitter as well if you are interested. But the point is that we can make sure that everything works like we just want auto completion and then want some type safety when we try to run it.

Limitations of Type-Level Programming: Runtime Validation and Performance32:17

But let's talk about limitation. We already know that TypeScript doesn't actually check the type. So we have to maintain the runtime and the type as well. So what is the other limitation? Why can't we write everything in type level?

Actually, there's a limit let me talk about a little bit. This is Elysia code that we can pass the body and then it infer type into the handler. You can imagine this as Express.js or Fastify or somewhere else that we have some path and then we have some body. We want to make sure that the body work. We just pass the type and then it somehow check the type in the runtime and apply the type to TypeScript. It allows us to do a lot of thing, but there's a little bit of limitation.

If we have been grinding LeetCode or we know about time complexity, the type also has the time complexity and the delay that it can run. Let's say that we have a very large type and does a lot of recursive stuff. It is going to slow our code base down a little bit.

If we use TypeScript a lot, maybe we can see that our VS Code or IDE sometimes

take a little bit of time to apply change or trying to start a project. It is going to take a little bit of time because it also does stuff in the background that we can't see.

Visualizing TypeScript Type Checking Time and Optimization34:03

Let me introduce you to some CLI

that can help us visualize how long our TypeScript type take to run.

If we run this command in your CLI and then it is going to generate some graph like this. We can inspect that which file,

on the bottom right, you can see which file use how long the time.

So this file use around 300

And 66 milliseconds to type check. And imagine that we have thousands of TypeScript files. It is going to slow us down. So we can't actually run a lot of type here because it is going to slow the end user down. It also has a limitation as well. But one of the interesting things working with type is that when you know you have the limitation, you need to optimize the code. So in the previous year, we optimized Elysia from taking one and a half seconds

down to 400 milliseconds. We have to think about how our code runs in the type level a lot. If you are not careful, we are going to have TypeScript type stack limitation.

If you apply too much type to TypeScript, it might say that TypeScript has a stack of 30,000,

which is just a made-up number. But if we run a recursive type in one function,

and it does some stuff in the background that calls after 30,000 times, it will throw an error saying the type is infinite or it took too long to check the type. So TypeScript just assumes that maybe this type doesn't work because it has some recursive type happening that doesn't know when to end. But this also applies to functional programming. Maybe you have some loop that you forgot to exit, and it throws an error because it's too long to compute.

The Future of Type Safety in TypeScript36:58

So talking about a lot of stuff here,

we can see that we can make a lot with TypeScript, but how about the future? Can it really be type safe? From my own perspective, maybe not yet. It might be possible to make TypeScript behave like a strong type language, but we aren't there yet. At least maybe two or three years from what I can see. Maybe five years or 10 years, we don't know. But what we can do now is apply runtime validation and then infer a type to TypeScript to try to make type as accurate as possible.

It is actually what Zod has been trying to do, and other libraries as well, which I usually call "an illusion of type safety."

Because this code isn't actually type safe.

If we have some complex stuff and Zod has some bug,

let's say Zod somehow can't check if the username is string or not, it creates a mismatch between runtime and the type level.

JavaScript can't check it. So if the library has a bug, it's going to be out of sync on the type. So we actually don't have type safety built in yet, but we are almost there.

We could only create an illusion, like it does look like it is type safe, but it isn't actually type safe because it isn't built into the language itself. But we are very close to making it possible. With community libraries like Zod, and companies like Prisma and Drizzle have been trying to aggressively use TypeScript to make an illusion of TypeScript look as real as possible.

We are almost there. But for now, we can just rely on the library to make sure that every type stuff and every magic stuff actually works, and we can only trust the library to make it work.

The Importance of Community Involvement and Open Source Contributions39:39

But how about the source? The source is... yeah, trust me, bro.

But actually the source is you. The source is you because if you think about it, we are relying on open source maintainer to maintain our type, right? And if the situation that I put up like maybe the type of source are out of sync, they have some bug, you have the ability to report the bug to the maintainer to file an issue and let them fix it.

That's how you can help TypeScript and JavaScript like illusion of type as real as possible because it is almost impossible to make TypeScript really type-safe. But we can take a little bit part of ourselves and trying to find an issue, trying to solve it as a community together. So we are trying to get closer and closer to that reality.

And the most important part is that please file an issue, please talk to the open source maintainer, please trying to connect with the library, with the maintainer of the library you are using because it is going to help a lot. Also it doesn't have to be financially, just maybe hang around and sometimes just file a bug or something like that. But there's also something called open source pledge which say that your company does a lot of like maybe million dollar per year, maybe we can just donate a little bit like maybe

$10 a month or $100 a month to open source maintainer that we are using. Because this problem are very real like if you know

what does it call like XKCD or something like that.

Yeah, I think we already know like XKCD also highlight that our industry are relying on some effort of

part-time open source maintainer that doesn't actually get any money at all. And then if the project fail or like we can see that

if the project fail like maybe the maintainer don't want to maintain the project anymore, the industry are going to collapse and then we have a supply chain attack and something like that. But please really just connect with open source maintainer that maintain that you are using. So also shout out to Scalar that we are since I am

maintainer of Elysia, I also benefit from this open source pledge.

There's something called Scalar which is like a Swagger UI alternative. So they trying to connect with us. At first, they trying to connect with us and then they also help us maintain our Swagger package and then also maybe they also ask like some kind of idea

like how do you feel about the project, like how may we improve it or something like that. And then they also apply to the open source pledge and help me maintain and like Elysia in general. So I think that's it for today for me. So congratulations for going through like a very long time.

Q&A: Maintaining Code Safety in Large Projects43:29

So if you have any question, feel free to ask. Also, พี่ช้าง doesn't actually send the QR code yet. We will change the computer to have scanner over here. Okay, so if you have any question, feel free to ask. Any question? Yeah, sure. What is it?

Yeah, so well as you mention your project Elysia and you mentioned code safety. When you are working on a large complex project with larger codebases like Elysia, how do you maintain code safety in your project? Yeah, actually since we have a lot of complex type like 3 to 4,000 line of type, I try to break it down from a very long line of type

to maybe a little bit smaller of utility type that I can write a unit test on. So let's say that I have something like this.

Give me a second. Okay, I have something like this, right? That I can input the shape of an object and then infer it to the body. So at first, I doesn't write the test or doesn't write the feature to make this possible at first. At first, I was just like I write something like 𝚝.𝚘𝚋𝚓𝚎𝚌𝚝 and then trying to make a unit test with it to see if it work. If it work, then I can maybe try to generic to the method patch here to see that if it infer type from here and if it work, I write a unit test for that. And then if it work, I try to gradually apply. I think you know the concept, but I think we just like maybe if you are not sure like if you have a complex type and then we need to make it actually accurate, maybe we can write a unit test for that.

Okay, thank you so much. Another question?

Q&A: Type-Level Optimization in Elysia45:37

Yep, sure. Alright. Okay, wait.

Yeah sure. So you talk about your optimization on your library, right?

Yeah.

Yeah, in type level, right? Right right right. Okay. So there's actually a lot of stuff. The first thing first is that the big O notation. If we grind LeetCode, there's like some algorithm to like make some stuff faster, but which is is a part of what make this possible. The second one is that TypeScript actually provide a lot of stuff like there's something called invariance and covariance that it actually allowed us to like make how it is a little bit complex, but in a nutshell, it actually allowed us to like make the union and intersection a little bit faster. And since every method in Elysia somehow return a new type, a little bit of invariance that maybe boost up 20% or 30% each somehow gradually build up

into a smaller type here. But we also actually have a blog post written for this as well. So like if we go to elysia.js and then we go to blog,

and then in this one, and then in type inference improvement, we have oh did I wrote it here? Okay, sorry, wrong one. Okay, this one.

Maybe give me a little bit of time. Maybe this one. Actually, I forgot, but it is somewhere in this Improves startup time. I think maybe this one. Yeah, but okay, here. I think it should be linked to my Twitter,

but I can't find it, but it is somewhere in one of these blog posts, which I can't find, but is somewhere here. But to recap, it is actually big O notation that we can improve. And the second one is that covariance and invariance, which is some annotation called in and out. The third one are constant generic, which when you try to infer a type from an object, it is going to infer as some mutable type, but you can also say that

the type doesn't have to change. It is if the type doesn't change, it can maybe help improve type inference a little bit faster. The fourth one are the generic itself.

So if we go to this slide here somewhere here.

Okay, somewhere here. Yeah. Actually, this one you can see that we have a lot of generic parameter here like eight or around eight parameter, right? But if you think about it, we can at first glance,

we can make it just one parameter. So like why do we need to have eight parameter here? The first one is that there's something called inference constructor inference. So like let's say that if you have a constructor, let's say the constructor first we create a new instance, and then say that if this class has a prefix, we can pass it into the object, right? But in this case, if the parameter only require the type to be string, it doesn't make sense to make the object to infer the type from. So like we have to separate all of the parameter that need to be memorized into each individual field to reduce the complexity of the type and reduce the big O notation in the first thing

that I mentioned. So like there's a lot of stuff to think about when you write a type like constant generic here and covariance parameter here and a lot of stuff like that which actually, you can check out

the guide on the TypeScript documentation. They wrote something like tail call optimization for type and a lot of stuff that can help our time to make to get it faster. You can search it in TypeScript documentation. There's a section written for that.

Thank you.

Q&A: Naming the Next Major Release of Elysia51:07

Last question, me? Yeah. Anyone has a question? Again? Okay, sure. You want to ask a question?

What will be the name of the next major release of Elysia?

Okay, let's recap.

Every release in Elysia has the name.

This is inspired from Vue.js. You know that every major Vue release also have a name for that release. They name after the anime. The latest one are like [Quintessential Quintuplets]. The latest one are also name after the anime. If we look from here, from every block release version, you can see that we have some name after the version. The first one are The Blessing from YOASOBI.

I think from YOASOBI, from this song. I'm not going to meme it, but I think a lot of people know the song.

Every major release follow the same naming convention.

Back to the question. The next major release are called Supersymmetry. They are from Supersymmetry from game called Tone Sphere.

If you play some rhythm game, I think a lot of people may know it. But otherwise, it is a very nice song.

The reason that I pick this name for the next version is that, in the next major release of Elysia version, we are focusing on adapter and multiple runtime support. Currently Elysia can mainly run on Bun, but maybe you can also run it in Deno if you can hack the type and hack the runtime stuff. But in the next version, we are trying to make it possible to run in Node.js as well and trying to make it possible to run in many runtime as possible. The name Supersymmetry are from some theoretical

concept that, in a nutshell, there's two version

of the same thing. So you have one version in Bun and you also have the other version in Node that exist in parallel. That's the name of the next version. Yay!