TypeScript Slows You Down - Here’s Why

I love TypeScript. I try to use it as little as possible. And that's a good thing. 🙏
#typescript
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4seOn3 for the awesome edit 🙏

[@samuelgunter]

tsc = the slow compiler

[@omri9325]

[@danvilela]

Imagine you using rust lol

[@nivaldolemos5280]

@@danvilela rust compiler is slow for different reasons. You cannot possibly make it dozens of times faster.

[@CamaradaArdi]

@@nivaldolemos5280 The rust compiler is really fast my experience. The first time you build sure, it's going to be slow but after that builds are really quick.

[@angelcaru]

​@@nivaldolemos5280too true

[@queerly__coded]

I honestly gauge where I am in my web dev journey based on how much of these little talks I actually understand. Getting better.

[@BusinessWolf1]

ye same

[@ThePrimeTimeagen]

ooof, the writing with type errors and then fix after got me on a strong no. that scares me :)

[@KaiHenningsen]

I think that either your types are simple. Then it's simple to get them right, so why wait? Or they're complicated/hairy. Then it's likely your final code will depend on how your types look like, so getting the type right first avoids rewriting that code. Also, without the types, you don't have the Intellisense-style help in the editor, which is not good. Sounds to me like a bad optimization.

[@лилпипка]

100% agree. Have tried TS multiple times, been making all those messy types and felt like I don't wanna use it when it blocked me. But then tried Prisma w/ automatic type generation and then I got it. You should treat it like JS with types rather than typical serious (Java) language w/ types. More fun, less seriousness you know

[@masterdr1]

I had the same problem, I want to prototype fast some code, not to waste 30 minutes writing types. Linter and TSC doesn't like it;

[@MeonisRP]

чупапи муняня

[@BusinessWolf1]

Well sure, but why would I need type safety in Js? I learned to work around type coersion and even use it sometimes.

[@yxngboypolo]

@@BusinessWolf1”why do I need type safety” the most web developer question I’ve ever heard

[@Jpp-ez3dt]

TS make me loose time. Modify an object should take me 5 min but because of Type I have to search why the Interface throw some warning, and finally take me 30 mins. Typescript is for people who don't know how to read database and table entity relation specification.

[@PaulSebastianM]

I don't like this purely based on the fact that this is not how you work with other static typing systems.

[@Shadowdoctor117]

That just goes back to the point that JavaScript just a messy language. Typescript is honestly just a bandage. Maybe is pretty good bandage, but doesn't actually fully fix the underlying downsides of using JavaScript.

[@rallokkcaz]

It's a really shitty bandage for people who don't use TS. And sometimes even for people using TS.

[@JeyPeyy]

That's the issue, people treat typescript as if it was equivalent to other statically typed languages.

[@unimatrixzero7745]

Affirmative

[@PaulSebastianM]

@@Shadowdoctor117 Good type systems are in my opinion becoming increasingly important with modern software engineering. While TS dominates now, it can easily be replaced by other languages once WASM integrates fully with the web browser APIs. Just like JS was once top.

[@mariansam_was_taken]

Theo: don't block on TypeScript while deploying on Vercel Me: trying to deploy create-t3-app on Vercel, getting blocked by TypeScript

[@puddle.studios]

his eyebrows have a mind of their own, one of the most expressive faces iv seen in a while, good video 10/10

[@hamzakhiar3636]

Angular/react does this tho when you build it blocks you until you fix all the type errors

[@Shad0wL00p]

Yeah, it would be nice to see an example Angular/React application where this has been changed so that it's not blocking etc. I find that running the unit tests is very slow and I have a sneaky suspicion that is due to type checking also - wonder what the recommendation for type checking in unit test is? Presumably the same, type checking is not required for unit testing, linting and separate type checking can still cover it all.

[@Quimmoo]

FUCK YEA. I've been coding for an almost 15 years now, started to attend coding classes and contests in an age of 15 and back then I've been exclusively working with a statically-typed languages like C++ and even then I've been dealing with errors after I've laid my initial ideas and logic down. When I was first introduced do dynamic languages like PHP and JS - the ability to test your initial ideas without doing all this boilerplating - this what sold me on those technologies. It doesn't matter if my code is a set of data transformations, or a set of behavioural rules and relationships for entities, an algorithm is an algorithm, I wanna define a set of steps, test that all those steps are in a somewhat right order (sometimes with an unhealthy bunch of console logs, yeah) and move on to optimise and beautify my stuff, because it's very fucking hard (at least for me) to develop an idea further without having a sketch first. And for some twisted reason, it's not a 'normal' way of thinking anymore. People who were working within a dynamic JS environment suddenly are all about almost unhealthy boilerplating and writing a huge bunch of DTOs even before you figured out the business logic of a feature. Yeah, sometimes I wanna start by defining an interface or a data structure, but most of the time I just wanna test that my shit is following the order, defined by business logic and then move on. It's specially true while building an UI components, where you need to type the props before you can test if this type actually fits because if you don't type it - well, nothing is rendered and you can go fuck yourself. And people are actually seeing this as an upside. Incredible. Not gonna lie, I was very sceptical about you and your channel at first, but after watching a couple of videos, specially the 'Is OOP Evil??? Reacting to best YT video' I was very glad that I've finally found a content creator with a strong common sense. Thanks for your content fam, appreciate it very much!

[@troooooper100]

I don't use types because I don't even know how to do 95% stuff I've to do im literally operating at 150% of my brain capacity and ideas come and go in milliseconds.. I've to Implement them to even know what I was thinking. I was thinking the best way to go about types is to use them when product has matured and only when committing to main branch

[@davidzechowy]

While building a social media platform for an app contest, I remember spending almost a day creating a typesafe hook for my api calls, but I was too sleep deprived to realize how unproductive this was

[@Novagenesis]

I mostly agree, but want to point out one thing. I would never `fetch() as A`. It's input. I don't care if you just wrote the service and are running it behind a VPN, you need Zod in the middle of it. `x = fetch() as unknown; Schema.parse(x)`. All set. You can always start with your zod schema being analog to an "any" until you're ready to dial it down. (Also, to random readers, fetch() returns a response, and you need to call .text() or .json() on it and parse that)

[@null_spacex]

I just make typescript as strict as I can, then forget about it until it screams at me to fix something.

[@honefone]

I didn't see this in the comments and I asked in the discord so in the next config: typescript: { ignoreBuildErrors: true }

[@zayn8649]

Woah I've been having my TS errors block my browser output. So many good tips, this video totally shifted how I'm going to be using TS

[@benfrese3573]

Damn, that's such golden advice. Thanks mate!

[@lucie_gamer_yt]

Hey T3, thanks for this video. I was recently learning TypeScript using a complete Udemy course, and the instructor always uses `tsc` and even doesn't emit files build when there are errors. He is a great teacher, but I actually writed down your tips from your video in my notes to also take in mind. Be well.

[@peacefulexistence_]

Me, a Haskell programmer: _sweats profusely on the type system abuse_

[@hanes2]

Become a 10x typescript speed run engineer by using Any.

[@oscardasilva971]

This opened my mind, thank you

[@user-qe2ps9vm9o]

Polymorphism in javascript was an intentional choice. This removed a huge barrier to entry for building web focused code. Untyped programming is the primary reason that the internet grew so rapidly. Your argument for typescript must address this or it will fail (which is happening).

[@m.ridwanriansyah2781]

thank you, this is indeed very helpful for me that recently switch to TS for my projects

You got me until the point you suggested to switch off type checking in CI. In my opinion, when the code comes to CI it should already compile correctly. CI failing the type check, has saved me several times. Mostly due to local TS caching and how TSC works.

[@Zokiio]

Think you stopped early. He continues to say you can have it separate step and he also say that a preview build don’t have to be type safe but you should block main merge.

@@Zokiio no I watched it all. I suppose there's a different way we previews. In my opinion - any previews built by the CI system should already have correct types. The types could be incorrect during local dev or maybe if you use CI for catching your local dev. But when we're talking about a PR, the types should be correct already. That's my take on it.

That also brings me to the next point - if it is so difficult to get your types to be correct in the Ci - you're probably doing something wrong.

[@Zokiio]

@ I kind of agree with you. I don't mind the types being off in a preview (still being developed) and kept in the developers own branch, but when it is up for a PR it should have already been fixed. I do not want to review a code that is not "complete"

@@Zokiio exactly! And it allows to catch weird cache related typing issues during the PR. At least in my experience.

[@untlsn]

"Stop Letting TypeScript Block You". Some people take it too literally and put "any" everyware. like: const [value, setValue] = useState([]); const longAdvancedFunction = (arg1: any, arg2: any, arg3: any) => { ... } Unfortunately, I often meet such programmers and when I enter their code. I spend half of my time figuring out how it works

[@NutchapolSal]

Typescript, without the types

[@j0hannes5]

How do you not use TSC? And how do I prevent my browser from blocking blocking me with ts errors? My client originated from a CRA that was js only.

[@beancoffee]

paying too much attention on the typechecking and also unnecessarily using return types had slowed me down a lot. When I started getting rid of these, it made it so much faster to move and ironically, felt more typesafe.

[@t3dotgg]

🙏🙏

[@ayushgogna9732]

not to use tsc then what is the alternative way to do things ? explanation was good but i dont know what to do next

[@YTCrazytieguy]

I think this is one of your most useful videos ever

[@dog4ik]

First thumbnail was masterpiece why???

[@Mitsunee_]

about the CI thing I recently changed tests to run after the lint step. I used to require typechecks to be done first, but testing is the slowest part of my CI, so I wanna start it as early as possible. I still lint first to make sure the code even has a valid syntax at all, makes no sense to open 3 more CI steps that'll just fail because one file is missing a closing parenthesis. I've previously disabled linting in nextjs builds as well (and moved to yarn install --production, so prettier and the linter aren't even installed in deployments anymore) but wasn't aware you could also disable typechecks. I assume you still need it installed for dependency reasons tho?

[@felixmildon690]

Loved the lint typescript/eslint pyramid diagram with your description. Keep doing your thang Theo F DA H8AZ

[@felixmildon690]

Caught that you wanna do more JavaScript talks aswell at the end. That would be amazing for the TS newbies here

[@davidsanders4463]

I don't agree with the last one. I don't want non type safe code in my remote master. I get the speeding up the cli thing, but seems like it defeats the purpose of typescript.

[@SayanMondal342]

Agreed that types should be kept as close to the data definition as possible, I generally try to keep my interfaces enclosed in my controllers but I would also disagree slightly that this should be the general pactise, IMO an api directory makes things cleaner and it can be used to only document your APIs and entities and their 'shared' types (not all the types just the ones the API needs).

[@sam-kmn]

I genuinely feel like devs in my country dgaf about innovations and improvements. It makes me sick when I ask recruiters if they are using Next, and they respond "Next what?"

[@essenmitsosse]

TypeScript should just officially separate the two: - type checking - removing types to get out JavaScript Because there is 0 overlap in those two steps, and having them both in the official tooling is causing more confusion then it helps.

[@nextorLeon]

Javascript is Typescript without types. Why the complain?

[@essenmitsosse]

The complaint is that tsc is doing both in one step (as pointed out in the video), which makes it hard to see they are two unrelated steps.

[@hakimbouabdellah3829]

How many times have u changed the title?

[@t3dotgg]

Like 7 lol. This video is bombing and I have no idea why because IMO it’s one of my most useful

[@JT-mr3db]

You need Jainism levels of discipline to properly add types after the fact, especially on a non trivial feature or project where type safety requires more than basic interfaces. Fighting the compiler as you build definitely slows you down in the immediate, but it removes the risk of you feeling too comfortable with your code to add strict high quality typing at the end. Working mostly in compiled languages has definitely brain washed me to think like this, but it's better to insulate your house as you build the walls.

[@asimpleguy2730]

Same thing that i thought, that's an approach that can be good in a highly competent team of good engineers.. Doesn't work anywhere else

[@dinkle9664]

I think he's just saying you don't gotta flesh shit out in test, and you should push changes asap instead of holding onto your erroring code at the end of the day. erroring code can just be commented out, but leave your progress if someone wants to pick it up when you're away

[@volshebnikozz]

Theo's putting these based takes so much that I want to work at Theo's company 😭😭😭

[@rememberme2170]

Yes. And it's taking away the coding joy. I want to have fun in making stuff work, rather than have to constantly satisfy TS complaining at every step.

[@mainendra]

Yes, totally agree, most of the time I just want to deploy to test.

[@FlorianWendelborn]

When you said "don’t run TS in CI" I immediately disliked this video. You then clarified you’re only talking about CI deployments and not about merges, so I changed it back.

[@daleryanaldover6545]

As someone who is still not using Typescript, I agree.

[@muhamedkarajic]

There you said it. Finally :)

[@gideonmaxmerling204]

I generally agree with the "keep type definitions close to usage" but in some cases, like modeling complex APIs with complex types that may rely on each other (i.e. one type containing arrays of another type, like Pokemon stats in a fight description), I find it much more comfortable to have one file with all the typedefs, as I won't have lines of code in the middle of complex type definitions

[@aleksandr2245]

what about common types?

[@ThugLifeModafocah]

I hate typescript. This you described happens to me everyday. I hate typescript.

[@fnfal113]

to be honest I have been tempted to use typescript but never actually tried it cuz of mix reactions from the community at the same time I like to typesafe my functions or variables with comments, never had any issues with maintainability unless I'm working in a company

[@Brad_Script]

imagine using typescript when jsdoc does the same thing without a compilation step

[@thomassynths]

Some nice practical tips. Less of issues with TS the language, but TS the ecosystem.

[@zcythe-z6u]

does CRA run TSC in it's build command?

[@markclynch]

TS = guard rails, not a brick wall!!!!

[@1OvOI]

not related to the content but the random sliding images don't seem to be adding much to the presentation. would like to know what others think

[@RA-xx4mz]

So allow implicit any?

[@Pptruenoz]

Typescript has so many inconsistencies and weird behaviors, I hate it. However it's a necessary evil.

[@gro967]

As long as you don’t use JS anymore, it’s not important how you use TS.

[@maurov6861]

Ultimately, what is the benefit of using typescript? i am beginner and i still have a lot to learn about javascript. Is there a connection between css/tailwindcss and javascript/typescript?

[@maurov6861]

@@AustinCameron is required?

[@ChillAutos]

Typescript gives you the ability to go really fast once you learn how to actually use it. Don’t listen to the js fan team in this comment section, they never bothered to learn properly because you can cheat in typescript so anything past basic types they stumble and get mad at the compiler errors. Never met a single ts dev who knew their shit that would ever think about writing js for anything more than a quick personal project script.

[@maurov6861]

@@ChillAutos thanks Rick

[@nivaldolemos5280]

google: what's the advantage of static typing The advantage of typescript is the same of any typed language. Also, you get better autocompletion and IDE tooling.

[@anasouardini]

vite still uses TSC though

[@jalaybeewala]

Adam scott???

[@marcvanrenterghem5468]

I would not ship code that have types error...

[@naman_dw]

I was hesitant to adopt typescript, and I have to say it does take about 2-3 days of training. But once I got used to it it feels like I am flying. Thanks for introducing me to TS Theo

[@cheechlabeech]

it does, but chatgpt to the rescue.

[@AK-vx4dy]

It is not often but i agree with you...this time:)

[@LostMekka]

side note regarding types for api calls: in my workplace i convinced everyone to use openAPI for every project and this was a huuuge productivity boost for us. the api spec sits in a separate repo and CI builds versioned clients and server subs and publishes them to our npm and maven repositories. imho, writing api types and calls yourself is a potential source of integration bugs that can be skipped entirely by having one source of truth. but its still fine for small projects or rapid prototyping ofc

[@SteinGauslaaStrindhaug]

I hate typescript (Admittedly TS is not something I've willingly chosen to use; it's been forced on me by others in the project) most of the time it doesn't do anything for me one way or the other except when it gets in my way and stops with some nonsensical error; and requires me to spend hours writing bizarre incantations just to convince the typescript engine that what I've written (that I know will work in JavaScrit) is what I want... Or I can just give up and use "unknown" or "any" everywhere just to get it to shut up. Which makes it all useless. I don't mind simple type definitions for function args or component props as long as they are optional; but I don't understand the point of adding types everywhere. And when you use libraries written in JS where you need to import a separate library (that tends to get out of sync with the library it's supposed to be for, because of course the type library doesnt have the exact same version numbers as the js library) to get the types, it's just hell. What do I really gain from having to convince the compiler I'm right just for it to discard all the type information when writing it as JavaScript anyway? At least PropTypes have runtime warnings when you feed a component props with a wrong type (though, even here 95% of the time; it's the code that is correct and just someone who has written the PropTypes definitions wrong or forgotten to update them. Or someone who has written boolean props as required, meaning they will essentially give warnings if you try to use them as intended and not set them when y). Type errors is _very_ rarely the cause of bugs in the code I write; with the one exception is when async fetches from servers I don't control return unexpected data, or malformed JSON; which a compile time check of "types" can do nothing about; everything fetched over HTTP is strings anyway and your code just has to assume it is a sensible JSON string and parse it as such. I normally write all code so that it tolerates unexpected null's and I will generally only trust that the type is already correct within a collection of functions in the same file; the function called from outside I will normally just parseInt any integers in case it's a string anyway; because if it comes from a browser event, you never know for sure if the browser will give the data as a string or a number etc. And TypeScript actually makes writing defensive code like this harder, because you then have to make type definitions that allow both integers (the desired type) and all sorts of invalid types, just so it will allow you to write parsing code to handle that.

[@kassios]

Preach!

[@trappedcat3615]

I almost never use interface or type defs

[@ToddDunning]

Ok so Zod for everything then?

[@lucasstark]

Ship code that isn’t type safe.😅 That’s called JavaScript. More of us need to learn than that typescript is not a language, syntax sugar.

[@greendsnow]

If you're not on a team, don't use TS.

[@Dingsel]

or hear me out: JSDoc

[@alexanderkrist95]

It's always hard at the start with Typescript but by understading how to work with it you've got to at least 2x your dev output.

[@ChillAutos]

Ya, I swear he doesn’t even like typescript. Typescript has sped up my development significantly because I bothered to learn how to use it. Adding types take fuck all time, every now and again you get a few hairy ones but one you learn ts it still won’t take that long. I’ve never heard a dev who knows how to use ts properly say it’s slowing them down. It’s always the whiners who tried it for 5 minutes one time or those who use any everywhere and call themselves ts devs.

[@alexanderkrist95]

@@ChillAutos totally! All my projects are ts only, gotta love it.

[@ChillAutos]

@@AustinCameron are you actually implying that modern IDEs can replace ts? If so… lol. If not then what is your argument. Neither of us said anything about what you just said. Nice straw man attempt though.

[@ChillAutos]

@@AustinCameron and yet not one either of us said lmao.

[@Thomas-uy4vn]

Why use typescript when you can just use Joi on useful data with plain JS. Pointless

[@johnnytestarossa]

This totally sounds like you are one of those beings that sorts their lego bricks first and then tries to find a labeling system afterwards and wastes everyones time in a 2hr meeting explaining their thought process behind it instead of designing a system together first with a concise and logical plan and then sort the bricks in accordance so everyone knows how it works beforehand.

[@lucastavares3518]

Knowing how to use said tools literally fix all his complains

[@gabrielcastilho4168]

Yeah, no, I can not agree with this. Sorry

[@i_youtube_]

As a software developer, try machine learning then tell us if you enjoy it more than software development

[@beancoffee]

machine learning is good and all, but it is so much OVERRATED and being implemented when not even necessary.

[@i_youtube_]

@@beancoffee but you know there are problems hard to solve without ML.

[@ishanksharma9051]

*sees a video not about AI/ML*, comment machine learning is enjoyable , extra chromosomes?

[@danvilela]

Ml is just data science.. statistics and shit. Too boring

[@i_youtube_]

@@danvilela why boring for you? What's your field of interest?

[@PapaVikingCodes]

Typescript is KING. Love my stack. Slowing you down? Pffffft.

[@nivaldolemos5280]

video is not about avoiding TypeScript, but about using the compiler where it's not really needed.

[@PapaVikingCodes]

@@nivaldolemos5280 yea I watched it dude. Commenting on a portion of what he was saying. Good for you on the compiler info.