VIDEO TRANSCRIPTION
Theo - t3․gg
These Legendary Devs HATE TypeScript & React
Description generated by Skrybot
No description has been generated for this video.
Transcription generated by Skrybot
Y'all probably know I love TypeScript and React. They make my life as an application developer so much better. I cannot imagine building an app without either of these technologies. However, I'm not just building apps anymore. Now that I've spent more time than ever in library land, beginning to understand why people hate on React and TypeScript so much, specifically library authors. There are not many good developers who have frustrations with React and TypeScript. And there is really useful feedback coming from library authors who are effectively forced to do a bunch of work so that application devs don't have to.
There's a different way you could view these technologies that I'm beginning to see more and more as I work on the library side. I describe it as shifting the burden. Before TypeScript, consuming APIs and libraries was a scary crap shoot. And the majority of the errors we would see in applications were undefined in places unexpected because we didn't know what shape the data we were getting was in. And there was no guarantee when we made a request or got a response that would be in the right shape.
Even with TypeScript, it's not necessarily a guarantee, but there is a contract in place telling us what is expected from this thing and making sure we check that values are there when they should be and aren't there when they shouldn't. That makes working on these things much easier. However, the reason for that is because the types are defined. Defining your own types is not great. And if you've had to do it yourself for complex things like a weird API that's spitting out data and strange shapes, you know how painful it can be. TypeScript is in its best when you don't have to write any of the types yourself.
And in most of the applications we build at Ping, we're not writing very many type definitions because we're querying from database. We're using TRPC. We're inferring our types from where they're created to where they're consumed. But in order to infer those types, we need to have libraries that both handle inference really well and expose correct types in the first place. The burden to do that has shifted away from the application developer and onto the library devs. If you're a library author and you're not already pushing types out for your library, I'm sure most of your issues are filled with it and you're beyond frustrated at this point.
We've even seen projects like Svelte and SvelteKit move away from TypeScript and towards JS doc in order to get typed contracts without all of the bloat and weight of the TypeScript server compiling your code on every single change. TypeScript often is more of a burden for library devs, even if it makes consumption of their libraries much better. It's now work that previously we would have to do on our applications every time we used the library. It was so easy to have your whole app break when you did a single package JSON bump of one dependency, slightly changes the syntax you call something with, and suddenly your whole code base is broken.
With types, it's much easier to see where those changes are happening and have a red squiggly line or a build error telling you where that stuff happened. But in order for all of that to work, the developers of the library have to make their code some amount more complex. I've even heard of library developers having to change their architectures entirely because the way they did things before didn't have a good way to be typed correct. And that sucks. It's sad to know that there's code that works and is performant that has to fundamentally change in order to make the type contracts correct.
Even in our experience with upload thing, we've had stuff that worked, but to make the change we wanted to a type definitions, we had to wrap functions in like 15 additional layers just to pass the types through correctly without making the DX too bad. The performance of our library is going to be some amount worse because of TypeScript, just to make the good developer experience possible. And obviously maintaining all of this has required me to bring on additional staff just to get all the types working correctly. And it still didn't prepare me for what I was getting into with server components.
Server components are incredible as a developer of applications, man, if you're trying to support them with a library right now, good luck. It has not been pleasant to do. We had something that we were pretty sure was working and in a small number of developers environments, it would infinite loop really bad. So we couldn't ship it. And that sucks because again, we're so close to having all these things in a phenomenal position so that every developer can rely on them to have a great experience. But the library authors are going to have to take a huge burden on not dissimilar from what TypeScript put on them before.
And now if you want to support the most popular technology combo on the web, which is React and TypeScript, you're going to have to do a bunch of work specific to TypeScript and to React. That work might make it easier to maintain your applications and your libraries in the future, but it's probably going to make the library maintenance harder. And from my experience, building things correctly with TypeScript so that others can consume them is much harder than building a good application with TypeScript.
The way I see this is that the amount of work you had to do to build an app goes down because that work you used to have to do has been fully shifted over to the library authors. And as long as they do that correctly, we all benefit massively. Huge shout out to the developers who have made this whole ecosystem viable. People like Colin, the creator of Zod, people like Tanner Linsley, creator of Tanstack, React Query, and so many more useful things. People like TK Dodo, whose hard work in both documenting React Query and the whole contribution and building process has been so valuable.
People like Alex from TRPC, who has proven things are possible TypeScript we never would have imagined before using inference to do insane shit. Our own community's Julius, who started as a CreateD3 app contributor, started contributing to TRPC and is now carrying our asses with upload thing. We would not be able to do what we do in there without him. These people are the reason TypeScript is so viable. The hard work they're doing to deeply understand document and use TypeScript for things it was probably not meant to be used for before. But the result is we can build our applications faster and more effectively.
I think it's important to acknowledge these TypeScript advocates and the hundreds more that I have missed when I'm just bringing up the ones I talk to the most, but it's important to thank them for their work. Take some time to appreciate the TypeScript and React devs who are building the libraries that we use and understand that to them these things are much harder and it's understandable when they get frustrated. But the reason that they're frustrated is they're doing the work we no longer have to as application devs. So to each and every one of you, thank y'all.
You're making the web a better place and we're having a lot of fun playing with the sandbox you've given us. Got a pin a video in the corner here all about using TypeScript incorrectly. So if you want to hear all about that, there you go. Thank you as always. Peace nerds. .
S K R Y B O T
Skrybot. 2023, Video transcriptions from YouTube
By visiting or using our website, you agree that our website or the websites of our partners may use cookies to store information for the purpose of delivering better, faster, and more secure services, as well as for marketing purposes.