Typescript Is SO SLOW...Or Is It?

Hey, everyone. My name is Mike. Super excited to be here and tell you about my love for TypeScript. Quick show of hands, though, because I want to get a little pulse of everyone. Who is not using TypeScript? Just give me a little raise of your hand. Yeah, we're virtual. We can't actually see each other. I don't know if you're actually raising your hand, but if you are raising your hand and you're not using TypeScript, it's totally fine. There's no judgment from me, but most people are using TypeScript today.

It's kind of the default expectation, especially when you consider people who are using agent-assisted development practices, whether they're running their apps in Cursor, Windsurf, whatever editor they're using. Most of the time, if they're generating project and they're generating code, it's going to default to generating TypeScript. When you look at a third-party ecosystem, it's pretty easy to see why TypeScript is so widely adopted. Whether you're using an agent to generate your code, types tell that agent whether or not they've generated the correct code. If you're still writing code by hand, you're still getting the benefit of that. Types don't change anything, depending on the code that they're writing. They actually make things a lot better.

Whether you're working with the various node frameworks, they all have very similar APIs. If you're doing, say, a back-end system, there's slightly different signatures that could be confusing if you jump between multiple frameworks. If you're working with tools that kind of blend the balance of front-end and back-end, whether you're working with things like Next and Nux, which have a bit of both inside of their code bases, having those types be there make that transition between the front and the back much easier to do. And so, types and having a type system in place really makes this all essential. Or there is one downside to all this. TypeScript is kind of slow. I'm sure I'm not the first person to have mentioned this or noticed this. TypeScript is very, very slow. We're going to talk about that.

So, like I said, my name is Mike. I work at a company called Prisma. I do some DevRel stuff. We do databases. If you want to follow me on Blue Sky, it's mhardington.

But let's get back to the TypeScript part. I said TypeScript is slow. And this is true. TypeScript is slow. In very unique situations, though. And slow itself as a word can mean many different things. So, what do I mean by slow? Well, we have two cases that we want to look at today. Build speeds and editor speeds. And I'm going to focus on the build speeds for quite a bit of this talk.

Because I feel like this is something that people might not believe actually exists. Especially if you're working locally. Your build speed is not going to really matter. How often are you building your entire project? But when you're in a CI environment, the build speeds can probably be your biggest source of frustration. Who loves waiting 20 minutes for their CI to complete to deploy a small app? Or even a slightly more complex app?

This is where things get really... This is where things become really important. And very... This is where things become very impactful. Because if we don't have good build... This is where things become very impactful. Because if we have slow builds, it's just going to mean that we ship things slower. So, let's start off with this little fact. Saying that your build is slow does not mean that we're pinpointing it to one tool. I'm saying TypeScript is slow and your builds are slow because of TypeScript. But really, it's kind of a culmination of a few different things. TypeScript can only do so much. Node can only do so much. Where is this slowness actually coming from? So, let's look at an app that we have over here. And what we have here is a relatively complex app. We've generated a couple files. We've worked with an agent.

We're probably crafting these all by ourselves. If you think of any large project that has been long lived and you're using types, you might have some of these projects. It might be legacy. What is in all these files doesn't really matter. But we have a lot of them. And we're going to try to run a build real quick.

So, let's time this and actually run build. We can see that we're just going to run the TSC command no emit. So, essentially we're just going to check all the types across this project. We're not technically doing a full build. So, we're going to isolate it to TypeScript itself. This is going to take a little bit. TypeScript, it's thinking, it's trying to look at our project. It's trying to see all the files that we have. Really kind of questioning its choices. Making me question my choices in life.

It's going to be a little while. We're going to come back to this because we only have so much time. I'm going to tell you right now that this build is going to take a long time. A few times that I've run it before, it's roughly around 115 to 120 seconds. Which on a relatively specced out laptop feels kind of weird. Why is a project that's just doing a type checking taking so long to run? And I'll tell you one reason why it's taking so long. It's just the sheer size of this project.

TypeScript can only process so many files at a given time. And if we have a large project, it's going to take a little while for it to process. Let's check in on it and see if it's done yet. Still not done yet.

So, if our project is large and we have a lot of things that we're trying to type check, what is an easy way to reduce the number of files and isolate things? We stop building large projects. Kind of joking, but also kind of serious here. If we stop throwing everything into one project, we're actually going to be able to see a huge improvement to our build speeds.

Let's double check on that previous build. Hey, it's a little bit faster, 109 seconds. Still not ideal. So, if we stop building large projects, what's the option? We build smaller things and we build them in isolation using monorepos. Monorepos are a perfect setup for this because we can actually take those large modules and all those chunks and just isolate them down into smaller sub packages. It sounds much more complicated than it could be, but most package managers support this kind of structure. They call it workspaces, but essentially we're doing the same thing.

So, if we move over to this new project, open it up, we can take a look at each one of those modules and the main app itself is its own project with its own package JSON, its own script. Everything in here is fully isolated. We can take a look at the package JSON for itself and it just has that package or just has that workspace key with a entry pointing to all of the packages inside of the package directory.

Now, if we want to confirm and see what the difference in build speeds are, let's run our time again and we're going to run the main app, which is going to pull in all the types that we are dependent on. Let's run this for a second. And let's go back to the slides and we're going to let this sync for a little bit. Now, I'll give you a hint, the speed is actually not that much better.

And there's a very important reason for this. Doing things with workspaces and having that bare minimum model repo setup doesn't actually benefit too much. If we open up our editor again, how are we actually getting all of these packages inside of our main app? Well, give you a little hint. The way that we're doing it is we're using this path entry. Now, this is going to require us to know a little bit how TypeScript works. And if you have a large project where you're importing a bunch of things from a single project setup, like our very first demo, when you move over to a model repo setup, you might think, let's just go ahead and use something called a path alias.

And a path alias allows you to rewrite all your imports to use this kind of node like syntax, or this module like syntax, where you're referencing a package, and then an actual thing that you want to import. But this is just an alias, it's literally in the name of the key path aliases. When TypeScript actually goes ahead and tries to type check everything. It's not actually doing anything different, it's just pointing it to a different direction.

So all of our packages actually just point back to something else. So we haven't changed anything, we're still doing file based resolution, which is really just the pain point of what paths are. And if we look at the TypeScript docs, we just say we see the from there from the reference of it, a path is a series of entries, which are remap imports to the lookup of relative locations relative to the base URL of set or to the ts config file itself path lets you declare how TypeScript should resolve an import. It doesn't actually change how that thing gets resolved, it just says go look at this location.

Types are basically smart enough to say I have this key for this package, I'm going to go look at it in this location. So this doesn't actually solve any of our problems. Just translates to this, it's an alias, it's not actually solving anything. So if TypeScript is being asked to resolve something using file locations, we don't actually have any code isolation and we don't actually get the major benefits that we would like to get. This is where workspaces come in. And this is our next step into adopting a good monorepos setup, but also making TypeScript faster.

And it's supported in all the major package managers, npm, yarn, pnpm, bun. All these are built in. All these package managers have built-in support for workspaces.

What a workspace is if you've never used it before, is just an entry inside of your package JSON that points to a location where you would like to tell your package manager, these are subprojects within this workspace.

So in this case, we have two locations that we want to be considered workspaces, or part of this workspace, we have an app, so we're going to list every single folder inside of apps. And then we have packages so we can split out what's considered top-level app level kind of projects and packages that get used within inside those apps.

When we go ahead and install all of our dependencies, we actually are able to tell each one of those packages, I would like to use library ABC or one, two and three, reference them using a different syntax.

Instead of giving a version number, we're just going to say workspace. And node will act, your node in your package manager will actually sim link them to the node modules. Now all your packages get resolved as if they're coming from node modules, and if they're just your regular old npm package.

So that's great networks fine, but it doesn't solve everything you just yet. And that's where we get to project references. Because if we have all these things sim linked into our node modules, how do we make sure that those types are included? And how do we make sure that we know where all these packages are coming from?

Project references? Anyone heard project references before? Again, I'm, I'm acting as if this is live, and I can see you. Chances are, most people haven't heard of project references. It was something that came out in TypeScript three, and I had only heard of it last year.

Project references are a way to reference other projects in a TypeScript project. Pretty, pretty self-explanatory. So if we think back to our pain point of using path aliases, remember, it is still a lie. These don't actually solve any of our pain points. These do not make TypeScript fast.

However, this can make TypeScript fast, make sure I'm using my words correctly, it can make your TypeScript fast. What we're doing here is instead of pointing to an actual project, like into an actual entry point like we did with paths, we're actually pointing back to a directory that has a TS config in there.

So while this looks very similar, it's fundamentally a different approach to how we can have TypeScript pre everything in isolation. So the path property is actually a reference to another TS config. And a project that you want to just or any other config file that you want to tell TypeScript, this is a sub project, this is something that is going to be built, isolated from everything else.

References, everything, all this just kind of works. And let's go back to our editor. And hey, look, our build from before actually completed, you can see it took about 106 seconds. First build took about 109. So slight difference.

Let's go back to this one, which is actually using workspaces, workspaces and project references. So we can see instead of using paths, we have all of these references set up and are running them here. So every single one of this, if we go to see go to this file itself, it's going to actually point us to a directory with a TS config. config. Let's go and run our build. And we'll just sit here, wait for a second. And the build is actually done in roughly nine seconds.

What gives here? How do we go from a significantly longer build to something that's short? Well, there is a little magic behind the scenes here. But what we actually are able to do is with project references, cache the results of those builds. So we could have them stored locally on disk in our project. And our build would be able to detect has something changed? No, then we don't need to actually run anything, we can just skip over it.

And there's a few other things about this that are also interesting. So if we go back to our previous example, I know we have a function in here that is used all over. In fact, we could probably just grab the entire project and find it. But this could be giving us false positives or whatever. We have TypeScript here to help us, we could just ask it for all of the references.

You notice, you don't see it probably here, but I have a little error inside of my editor saying that there are no results found. But we just saw that we actually do have it in tons of places all over this project. Well, if we go back over to our other demo, remember, this is using project references. Let's go open up that same function. And then let's double check that it is in fact everywhere.

Let's go ahead and ask TypeScript to get us all the references. So it does take a little bit, mostly because it is a large project. Every editor is going to be a little bit slower, but it's actually getting us the correct results. I used to say that this was more correct, but I was corrected. It is actually getting us the correct results. There is no more correctness is just how it should have been. Originally, the other example was wrong.

So project references are a big deal that can make your compiler a lot fast, they can cache the results of all your builds. So that way you're not having to recalculate things if they're not if nothing's changed. And it makes the build speed for every project a lot faster. Now there is another thing that I want to touch on that people might think are not that important. And that's the editor speed. We've already saw that in a large project, TypeScript's own LSP can be pretty slow. But I want to talk to you about another demo. It might not sound like a big deal, but you probably have faced this before. And so when somebody tries to be clever, and try to be clever with their types, and they try to be clever with how they build things, and it ends up becoming TypeScript tomfoolery. There are other words that we can call this, but you'll see what I mean.

So I have a project over here. And what we have is a deeply nested, different kind of routes that we're doing on the back end, we're creating a bunch of stuff with TRPC. This is not a fault of TRPC. It's just somebody was being clever. So all these various different endpoints that we could hit, if we go over to our front end, we have a bunch of additional types. And then we have this thing down here, completion target. We're going to try to trigger completion over here. So we'll say completion target. We're going to wait. Oh, okay. Took a little bit. Let's go ahead and do another one. Okay. And there is this delay every single time we go to try to trigger completion. It's not specific to this library into these projects. If you're using some various ORMs that exist out there, if you're doing live evaluation of all those types, if you're doing anything with a model and a schema, that live evaluation can be pretty slow. It doesn't feel like it should be that impactful. But if you're waiting this long, every single time you're trying to type something, it can be pretty frustrating as you're waiting for your editor to catch up with you.

This, however, can be resolved. We have the same project over here. But what we have is a pre-build script. So this pre-built script is actually going to go through and run a build of our project. You can see we actually have all the file differences over here. What this is doing is pre-compiling all of the different types that we could be calculating inside of our app. You could do something like a host install script to do this. That way it's not something that you have to set up every single time or even have to remember to do. But instead of having that multi-second wait, we actually have something that returns pretty much instantaneous. And if you can type correctly, like I cannot, you get the completion to happen right away. It's a pretty nice setup and it gives you all of that information right away at your fingertips. It's a small little footnote on this, but it matters so much more as you're starting to write your projects.

So don't do live evaluation types if your project is very big. Have something in there that can pre-calculate them. Try not to nest your types too deeply because it's just not good. But chances are you're probably not going to face this unless you are working in a very large and mature code base that has existed for a number of years. So pre-build if you can. If you do have a lot of types, it can help you out.

So this does bring us to the very end, but we have something that needs to be mentioned. And that is the TypeScript port to Go. TypeScript Go, TS Go, TypeScript Native, whatever the final package name ends up being, does put a little caveat on this because this could all change. We could have something completely different, and none of these concerns are really going to matter anymore. We're still a little ways out. TypeScript stable right now is 5.9.3. TypeScript, the Go port, the native version is slated for version seven. 5.0 came out in 2023.

So the life of a major version in TypeScript is very long. We still have a little ways to go, but I'm very hopeful. I actually run TypeScript, the native version, as my completion engine, as my LSP engine, and it has been significantly faster. I've run a few tests with some of these projects, and it has not been as big of an improvement as I would hope so. But it doesn't really matter because having TypeScript native doesn't get rid of the fact that we could be doing our builds in CI. And with limited resources on that machine, we still need to find ways to fine tune our project setup and fine tune how the speed of everything is calculated.