- Thanks for joining me Josh,
if you just wanna real quick introduce yourself,
talk about your YouTube channel, that'd be great.
- Okay, so I'm Josh.
I started my YouTube channel last year,
so about a year ago in September.
And then like one of the only goals I set for myself
is that I regularly want to post
and I just kind of made that happen
and it's been a bit harder
with my full-time dev job at the moment.
But no, I still try to do some videos regularly.
- Yeah, Josh has got great videos.
I'm gonna link his channel down in the description
so you can all check it out if you're interested.
But he covers a lot of stuff around development,
especially like newer, more emerging things in development,
which is great if you kind of want
to keep your finger on the pulse.
His videos are really great for that.
Now in this interview we're gonna be mostly
kind of talking about TypeScript
and we're kind of gonna talk about
how you can actually start to practice and learn TypeScript
after you've already learned it.
So after you've taken this course,
you learned all the things
you need to know about TypeScript.
How do you actually go about putting that
into practice into real world projects
and getting through some of the stumbling blocks
you've run into with TypeScript?
So kind of the very first question I want to ask you Josh,
is when someone gets that first step
where they've learned TypeScript, they kind of know
how types work, unions, generics
and they start to work on their first maybe larger project,
not necessarily massive, but beyond a to-do list,
what are the things that you need to watch out for?
Because for me at least when I started doing that,
I kind of ran into problems where TypeScript,
I felt like I was fighting it the entire way.
So how can you kind of try to get through that phase
where you're fighting TypeScript to get to the point
where it's helping you as quickly as possible?
- So I think one
of the biggest advantages you have is when you, for example,
join a team and then look at the conventions
that your other team members have set.
So that would be something that really helped me
to figure out how to properly write code
that integrates super well into like the work code base.
For example, when you take a look at
what other people have written
and how they structure their code
and then you try to emulate that,
you know, you don't bring in your completely own opinions
and it has to be that way and whatever
and are super strict on how you write the code.
But you take a look at what other people have done,
your coworkers for example,
whose chances are they're gonna be pretty good at TypeScript
and you know, just copy and emulate.
And I think that's one of the ways
that I learned the most really just ask them questions
on how they did stuff and try to implement that myself.
- That makes sense, and like let's say
that a person wasn't working for a company,
would you say maybe going to like open source projects
that are written in TypeScript is a good
kind of alternative to that?
- Oh yeah, for sure, I think open source projects are one
of the best ways to learn TypeScript.
There's also like,
there's a GitHub repository called Type Challenges
that offers like completely free,
I think it's like 100 challenges or whatever.
I don't know the exact number, but they're super well done
challenges where you have the solution,
which I think is also super important.
So you can try to figure out the problem by yourself
and then take a look at how other people have implemented
that exact thing and learn from them as well.
So try to get hands-on as much as possible.
You know, just very concept based.
You tend to forget what you learn,
I figure if you don't apply it right away.
So try to take one concept that you learn in TypeScript,
whatever source you might learn it from
and then try to apply that right away,
unlike a playground in your app
and just get hands-on in coding.
- That makes sense, and for those TypeScript challenges,
I'll link that in the description
so everyone can check it out.
But one thing I will warn you about this
is they're incredibly difficult.
They incorporate a lot
of really advanced TypeScript features
that you maybe don't always use for building apps,
but if you wanna take your kind of TypeScript skills
to the next level, this is a great place to practice that.
I mean even the beginner ones, they say they're beginner
but it's like still very difficult.
It's like beginner for advanced TypeScript
developers if that makes sense.
So kind of another thing I wanna talk about,
we talked about you know, you can kind of work
with your team, they have really good
TypeScript practices in place.
If you don't have that you got open source projects
which kind of have the same thing for you.
What would you recommend if you wanna
build a project on your own?
Are there good projects
or like size of projects that you can think of
that would be good places to start
for practicing your TypeScript skills?
- Oh man, I don't know actually.
- 'Cause like a to-do list for example
is obviously super basic
and that's great for learning
the absolute bare bones of TypeScript.
I mean we cover to-do list in this course,
but what would you kind of go to after that?
I mean obviously whatever project interests you
is probably the best option
but if people are really still unsure,
do you have any particular types
of projects you think would be good?
- I think one of the best repositories
that I looked into was the TRPC one.
It's two things at once that I really enjoy.
It's first off a really good API pattern that is RPCs
and then at the same time it's also type safe
where you also get the hang of,
how do you get types from the backend
across to the front end?
And I think learning that at the same time
makes a lot of sense,
you get a really good understanding of you know,
how you can profit from type safety
from front end to backend.
'Cause I think that is by far one of the best use cases
for TypeScript where you have areas
that are traditionally not type safe
or you have no idea what data is being passed forth and back
and then try to implement that in a type safe way.
- Yeah, that makes sense.
I mean TRPC, I absolutely love it.
I have multiple videos on YouTube talking about TRPC,
if you're interested I can link those
as well so you can check them out.
But I think it's a great library
'cause like you said, it solves the problem
of like going across that boundary,
that server to client boundary.
We you normally it's just an API
and we even talked about this in the course when you fetch
something from an API, you pretty much just have to cast it
to whatever you think it's gonna be.
And TRPC solves that problem for you
because you get all that type safety from the functions
that you're calling that make those API calls.
But they are type safe built in which is something
that is really hard to do otherwise.
- And then one more thing on that, touching on that
is form or schema validation libraries rather.
I'm not gonna name any specific one
'cause it's kind of you know, personal preference
with whichever you want to go for.
But the beauty of those is that you get two benefits at once
and that is one the runtime verification
of whatever you're passing in,
which is especially handy on the backend
because I mean it incorporates two best practices
at the same time that is making sure that the data
is what you expect 'cause anyone can call your API
with any data, you don't have any security on that
and by using some form
of schema validation you get the benefit of knowing,
hey I'm expecting this data
and I'm sure that I actually receive
this data on the backend.
And then also you get,
depending on which schema validation library you use,
but it should be standard by now
in most, the type safety of things, right?
Because after you made sure that the data
you get into that API is what you expect,
you know the type of it, right?
If you are expecting a name that is off string,
you can validate that at runtime
and also get the type for you when you're writing
the code for the API.
- Yeah, I 100% agree.
Taking, this is really a good point
because TypeScript is really great for you know,
writing out your types for certain things.
But if you add in these things like a validation library
and TRPC, you start to get a lot of the features
of TypeScript but you don't have
to write out the types manually for a lot of these things.
They're kind of built in for you, which is really nice
because I find TypeScript shines the most
when you don't actually write any TypeScript
and everything is just inferred for you
pretty much magically.
So using a validation library,
you can get a lot of that inference automatically
and then TRPC gives you that inference
across your entire stack, which is really nice.
- And I think you also don't really get any benefits
of TypeScript and for example, you cast a type
because there's no, it doesn't exist at runtime,
you know, you get no security from it
besides the one you get at you know, writing the code
but you don't get anything at runtime,
which I think is you're kind
of missing out on if you don't do
schema validation libraries.
- Yep, yeah, I 100% agree
'cause like if you do the casting essentially everything
from the point when you cast that onwards
is like it could be right, it could be wrong
'cause you don't know if that casting was actually correct.
'Cause if the casting was correct,
obviously all your code would be fine.
But if you cast it to something that it's not,
if you cast a dog to a cat
now your entire code base is going to be broken
because you know, things are just not working right.
So that's a really good point.
- Yeah, exactly, it just, you know,
kind of shoehorning it in there.
Yeah trust me it's gonna be that type
and then chances are I've done that
so many times, chances are it's just not
what you're saying it is.
So it can be undefined
and then you're gonna be really confused
as to why is that undefined?
I thought it was type safe
but really it isn't, it's not as bad as using any,
I think 'cause when with any you don't get any safety,
but you should try to avoid it at any point.
And there's also big difference between
what I've noticed is writing the first NPM package myself,
there's a huge difference in the amount of TypeScript
needed to work when you are writing apps.
So consuming packages versus writing your own own packages.
There's a lot more considerations you need to make
in terms of TypeScript
when you actually publish your own package
because then you're responsible for providing all the types
that users that use your NPM package could actually consume.
And there's a lot more that comes with that
that you don't really know if you've never done
like your own package.
So if you really want to get into TypeScript,
maybe try creating like a really basic NPM package
that has like the little TypeScript badge on NPM next to it
so people can just consume the types from it,
use them in your app and I think that's
a really good learning opportunity just trying
to get like a very basic TypeScript package out there.
- Yeah, yeah and I would say that even kind of leans
more into like advanced TypeScript
because like you mentioned, the TypeScript you need
to write an NPM library
versus just to write a to-do list application
is so much more complex in the NPM library
and honestly you have to use a lot
of the more advanced features of TypeScript
because you kind of need to massage the types to get them
to work just right because you need them to work
for your code in the library as well as for all of the code
that could possibly ever use your library.
So it has to be really, really flexible
and also bulletproof for any situation you run into.
- Oh yeah, for sure.
I mean if you're just starting out
that's probably not the right way.
It will be you know pretty hard
getting into it right from the get go.
But when you kind of grasp the basics
of what is TypeScript?
What purpose does it serve?
And that's, by the way, I think the thing
that's really important to understand,
what purpose does it serve?
You know, understanding,
why am I using this in the first place?
'cause chances are if you use TypeScript
and really leverage it to your advantage,
it makes you a lot faster
than you would be in a regular JavaScript.
And chances are also it's gonna be super hard to go back
to normal JavaScript once you try it.
So for example, at work we have two backends,
one is written in TypeScript and one is in JavaScript
and everyone just hates touching the one
that is in regular JavaScript.
Nobody wants to work with it anymore
'cause it's just so much nicer
and faster to work in the type safe one,
it's such a big difference.
- Oh I 100% agree.
Like I used to be kind
of be in the boat when I was first learning TypeScript
where I was like, ah man this is just slowing me down.
I find that it's more difficult than it should be
and I just like stuck with JavaScript
and then I finally took the leap
and started learning TypeScript
and I was like whoa, this actually makes me so much faster.
Like sure, that initial couple weeks
that you're learning TypeScript, it does suck,
it slows you down big time
because you're constantly trying to switch your brain
between TypeScript JavaScript, TypeScript JavaScript.
But once you kind of figure it out you realize
that it's all just one singular thing that you're writing in
and it becomes so much easier to actually write code.
And this actually kind of leads me into a question.
Do you have any advice on how people can get from that stage
where they hate TypeScript
and they feel like they're just fighting it to that stage
where they're like, oh this is why TypeScript is amazing?
- Yeah so there's a couple things.
One, for example, what was really good
for me in the beginning is always knowing
when you start TypeScript, you can always use any
and just go back to JavaScript.
So there's really no risk involved
in starting a TypeScript project
'cause you can always go back
to a regular JavaScript even though it says
.TS at the top of the file.
You know, you can still write code
as if it was regular JavaScript pretty much,
just with some very basic syntax adjustments.
And then also what really helped me
is make your TypeScript TS config pretty strict.
'Cause that's gonna force you to really understand
how different things could lead to errors at runtime.
So for example, one property I always set to true
is the no unchecked index access for example.
'Cause in regular TypeScript
what you have is if you access an array element,
say you had like an array of strings like a cat, dog,
whatever, and then you accessed an index of five.
So an element that doesn't exist in regular TypeScript,
you wouldn't get a problem from that.
It would actually be a string if you have a string array.
But the runtime value would be undefined.
So what really helped me in the beginning
is making your TypeScript config as strict as possible.
'Cause yes, in the beginning it's gonna be difficult
to figure out why you're getting the errors you're getting
but you're gonna learn much, much faster that way.
But always again, in the back
of your head you have the option to go back
to regular JavaScript and there's really no risk involved.
- Yeah, I really like that idea of being able
to slot in wherever you want
because most TypeScript things
you write are gonna be pretty simple.
You write a function it takes in a string,
you type it as a string, that's pretty easy.
But every once in a while you're gonna get to something
where you just, especially when you're first starting out,
you just don't know how to type it.
It seems beyond your abilities, too complex.
And if you're spending a bunch of time on it
and it's getting you really frustrated
and making you hate TypeScript for now just make it an any
and then continue on with your code base.
Everything else will be type safe
and that one thing won't be,
and eventually as you start getting more used to TypeScript,
you maybe can go back to that and be like, oh you know what?
I actually know how to type this now
based on my new skills you can add in that type.
And honestly that'll make you love TypeScript more
because now that you have that type in there,
boom, you get all of this type safety,
auto complete sense, all of those amazing features
that TypeScript is amazing for.
But it kind of helped you
because first when you ran into that, it was really hard.
So being able to just throw in any in there
and kind of skip that headache
means that you get a focus on the benefits
of TypeScript without dealing with most of the drawbacks.
'cause you're already used to the drawbacks of JavaScript.
So it's like throwing an any in there isn't really painful
for you 'cause that's what you're used to working in.
So it allows you to experience the benefits
of TypeScript without a lot of the downsides.
- And it was actually one of the requirements
for my current job that you know TypeScript,
'cause one really nice side effect of TypeScript
is that it also really improves your runtime code.
For example, the whole optional check,
right when I was developing in just plain JavaScript
when I first got into coding, you oftentimes forget
that values could be undefined
and you do like, you just let them be.
But in reality you should probably add
like a coalescence or whatever,
add a fallback value in case the value is undefined.
And that was just a fancy term for you know,
either the value or like question mark question mark.
If that is no or undefined, just you know any other value.
And that's actually gonna improve your runtime code as well
where you are incentivized to handle problems
that in regular JavaScript it's really easy to miss
and then you all like you only recognize
that once you actually start the app
and it crashes even worse if that happens in production,
you know, and with TypeScript, chances are,
you're probably gonna notice it beforehand.
'Cause even in the IDE itself it's probably gonna add
like a red quickly line
that makes it really easy to spot those mistakes.
- And another thing about that is it's really common
for those null mistakes
to go unnoticed in debugging
when you're actually writing the app.
Because a lot of times it can happen in a really small
subset of your code where it's like a single function
that doesn't work as you expect
because it's throwing an error
but it's still mostly working fine.
So you think everything's fine, you push it up
and it could be there for months, years even
before people finally notice, oh you know what,
our logging service actually isn't logging
because there's an error in the function that was caused
by a null or something like that.
And TypeScript will just automatically catch that for you,
which is really nice.
- And I think regular linters wouldn't,
I'm not too sure on that but TypeScript might catch that
well the regular lint might actually
be fine with your code.
So that's making it even harder to notice, right?
You do a lint, you assume that it's gonna do the code check
for you, but if it doesn't notice that,
which I think it doesn't, I'm not too sure.
- I don't think so.
- Then you know, it's very, very tempting to just push it up
to production and you know, you might notice it
as you said like way later, hey why is this not working?
And then getting into the debugging afterwards
when you've already finished
the code like months ago, they're not understanding
the code too much anymore
than you're gonna have a pretty hard time.
- Yeah and I think this is really where TypeScript combined
with testing really excels
'cause TypeScript is good for some
of those more static errors like I forgot to check for null
but it's not gonna check for, I wrote my code wrong.
So if you combine TypeScript
to get all of those static errors
and you combine it with a testing suite
to actually test the dynamic errors
that happen when your user uses your application,
you can get so much confidence in your application
that if you have it written well enough you could write code
and push it to production without even running a dev server
because you know you have your test
and your TypeScript set up.
I mean I would never recommend doing that
but like you can get that level
of confidence if you have a good test suite
and good TypeScript set up.
- Yeah, I mean at at work we don't test
as much as we probably should to be honest,
but when we do add tests, just like you said
with TypeScript, it gives you so much confidence,
as well as you know in the merch request to master,
for example, you can always say, hey I've tested this,
I've done all the work, I know this works really well
and it's ready to merge.
So it really gives you the confidence
that you're writing high quality code
that when people look at it, if you're searching for a job,
you know, they're looking through GitHub,
which most do, like it's pretty important
to have projects on there.
Then they're gonna notice those things
and the attention to detail on what could happen at runtime,
how are you handling errors,
which I think is super important
and it just is a very defining feature I feel like
of high quality code that you can be very confident in
that it runs very robustly in production.
- Yeah, I think one thing
kind of touching on the whole resumes
and portfolios, one thing you can really do
to help yourself stand out from other developers applying,
especially for entry level jobs is how you handle edge cases
and how you handle error estates.
'cause most people, myself included when I was learning
to code, I went only with the happy path,
just the main thing that makes the application work good
and I would maybe cover a couple, you know, major edge cases
but I would not really worry about error states.
I wouldn't worry about minor edge cases,
I just completely forgot about those things.
So if you have TypeScript that helps you
with some edge cases and then if you have testing
that helps you test those other edge cases
and through all of that you most likely are going to have
to write code for those error states
and that just makes your code look so much more impressive
to someone that's actually looking at you reading your code.
Like if a developer's going through your portfolio,
it makes your code infinitely more impressive to them.
- Exactly. It might feel a bit weird at the start like you
are writing the code for a case you don't want to happen,
you know, so it might feel a bit weird writing that course,
writing that code and handing that case
but it's so worth it.
'Cause chances are that case is gonna happen and if it does
and you know what, you handle it well
and there's not gonna be like an issue being opened
by the support or whatever
or by your users even worse
that hey this is not working at all as it's intended
and you know, it really gives you that confidence
to ship fast.
You know, I mean the main purpose
of TypeScript is just you're gonna be much faster
and you're probably gonna enjoy coding
a lot more, at least for me.
Like I could not, I don't know what it's for you
but I could not touch JavaScript again.
Like I would not want
to write a project in regular JavaScript by now.
What's your take on that?
- For me, if I'm writing something really small,
I'm fine with writing it in JavaScript.
I would prefer to write it in TypeScript
but as soon as I go beyond
like to-do list size applications,
I want to write it in TypeScript
just because it's more enjoyable, it's quicker.
Like I have less errors when I write my code that way,
just everything about it is a better experience for me.
And honestly when I write projects,
even relatively large projects, the amount
of TypeScript specific code that I write is really small.
I only write a few types in my code
and everything else is just automatically inferred for me.
Really it's like function declarations
and then like if I'm working to React like React props
and that's pretty much 90% of the types
for my entire project right there.
- Yeah I feel like yeah in my personal project,
it's not that you said it true,
I don't even write something like return types very often
for a function except if it's important
for that function.
At work we do it a bit more, like we are expected
to do things like return types or functions as well.
But once you get the hang of TypeScript,
there's actually a surprising little amount
in everyday holding I feel like.
- Which is great because honestly you can write 5% more code
and you get a hundred percent extra benefit.
Like it's it's pretty incredible.
- Yeah it should never be about the TypeScript.
Like the way I think about it, TypeScript is more a means
to an end than like in learning it itself.
You know you learn it to write better, faster code
and not to say hey I know TypeScript now
and you know you don't really know
what to do with it in the first place.
It's really a means to an end
and a very, very effective one at that.
I think learning TypeScript was one of the best decisions
that I've made besides learning React.
I guess like you can write React
and paint JavaScript but I think you're gonna have
just a much better time sitting down for that one, two,
maybe three weeks it takes to kind of get the grasp
of TypeScript and then use that every day
'cause that's probably the fastest way
you're gonna learn, right?
Like as I said, again, you can always go back
to any if you really need to but try to do it less and less
and you're gonna notice your TypeScript skills like going
through the roof after even weeks.
- Yep, and I think another really important thing
we were kind of talking about like how much time
you spend on TypeScript.
If you find yourself really struggling against some type
and it's taking you a long time
to write out some really complex types
and every time you change something you feel
like you have to mess with your types.
One of two things is happening.
One you're writing a really complex library
or something like that where that's necessary
but most likely you're overcomplicating your types
and instead of manually typing out every single thing
that happens, let TypeScript do a lot of that inference
for you if you can because that's I think
where the real power of TypeScript comes.
And if you're starting to write a bunch of manual types
and kind of overriding the TypeScript inference
with specific things,
that's where your code can become a lot more fragile
because now you change one thing
and then you also need to change the type
and then you need to change another type
that that type depends on.
And it just gets really complicated.
- Especially I feel like when you compare TypeScript
with statically type things in other languages,
you really notice how powerful
the TypeScript inference really is.
Like for example, we also use things like C++
and all those different languages
and then it feels really nice to go back into TypeScript
and have things like static inference for example
because they are really powerful and I think
besides like the, the main types and TypeScript
and generics inference might be one of the biggest bang
for your buck things to learn about TypeScript.
- And the nice thing is you don't even really have
to learn it, it kind of just comes naturally.
Like you just write code that looks like JavaScript
but you write it in a TypeScript file
and all that inference just happens for you.
- Exactly, yeah, you don't have
to worry about it in most cases.
Sometimes there's a bit more work involved
but in most cases there's not.
And it's just super powerful.
You can you know, save so much time,
just let the inference do its work
and you just benefit from it.
- And kind of speaking of inference, you had mentioned
that at your company, you guys manually
type the return types of all your functions.
Is that correct?
- Not of all functions
but for example on the backend,
we have some scripts that are set up.
So the way we do it is we add, by the way,
one thing that really surprised me
is that we still write class-based components.
Like Enterprise is usually pretty slow to adopt changes
so something is still class-based and whatnot.
But regarding TypeScript, so the scripts we have set up
to generate our backend models,
it's a lot done through CodeGen.
So it's basically, we re-implemented TRPC but with CodeGen.
So it's not like in real time
where you get the type safety
but you have to go through a CodeGen step.
Don't ask me why, I don't really know myself,
but that script that generates those types
to make everything type safe between front
and back end, it's is expecting the return types
of functions and it also makes sure
that the logic is in place for all those models.
So if you forget the return type
or type it as null for example, even if your return null
and TypeScript is technically happy with the logic
of how that script works, it would still not be very happy.
So you're actually required to do like a return,
it returns a string or an object with this
and that property it makes sure that you know,
that's actually being returned.
So even if TypeScript is happy, it kind of goes beyond that
and also just the whole logic checking
and that way we can just make sure,
hey if we create a model on the backend
and run that script, it will definitely work.
- And that makes sense and that's kind
of like a really advanced TypeScript use case.
It's not like you're creating a function
that's like returning a string
and you're typing that to return a string
for like normal everyday use.
It's more of like this is kind
of some really advanced code gen stuff, which is why we have
to manually type those returns.
- Exactly, I don't really know why
we did it that way to be honest.
I really enjoy approaches like TRPC that offer
kind of the same functionality
but even in real time, I think it's more
of an architectural decision that I will do differently
but it is what it is.
- Yeah it was probably was like that for a long time
before TypeScript or TRPC was a thing.
- Oh yeah, especially like with the old infrastructure
before the TypeScript days as I said earlier,
it's all in JavaScript and I think it's kind
of stemming from that because it was an important part
back then and you know that's probably
the reason why it's still is
but you know, you don't have to get
that advance, like as long as you know
what return types are good for, that is at least
what I feel like really making sure
that what you expect a function to return
is always what you return and when you later revisit it,
it's easy to maintain
because you've implemented the type
that it returns wants and if you mess that type up somehow,
even to the degree where TypeScript would still be happy,
like if you did not add the return type changed it up
and you wouldn't get an error in any other part,
chances are at runtime you would
and that's what the return type is good for.
- That makes sense, yeah for me personally I prefer
to just infer all my return types
but I could definitely see the the desire
to have it be more concrete as well.
Especially if you're writing maybe like a library,
it would make more sense to make it
a more concrete return type.
- Yeah, one thing I really enjoy with libraries,
I think it's some people took it to a very drastic
kind of degree like where you only rely
on JS doc, it's kind of like
the JavaScript TypeScript alternative I guess
that doesn't really, it also just exists on,
you know and not at runtime
but it does give you the advantage of,
you can kind of get the types of a function
and also annotate what the function is good for
and which parameters and types it takes.
So for example, but at that point,
you might as well just use TypeScript
I guess, you can't have the exact same functionality
and TypeScript but besides documenting
what the logic of the function is
and you know what the parameters are,
I think you're just better off actually typing it out
than using JS doc
and which I believe the approach was from Svelte,
I'm not too sure but some framework went like super hard
on the whole JS doc thing
and I didn't really understand why
but the only use case
where I can see not using TypeScript
is if the overhead from compiling it
would outweigh the complexity of the project.
'Cause as you mentioned earlier, like very basic projects
in JavaScript, that actually makes sense
because you do have to set up the whole infrastructure
to properly run TypeScript.
Oftentimes that's done for you like in frameworks
it's usually done for you.
If you do like a very basic project,
chances are you're gonna have to do that yourself.
And at least for me, I don't know how you handle that
but setting up something like Node
in TypeScript is kind of a pain, always takes like 10,
15 minutes to do and if you just try
to whip up something really quickly,
you might as well just go regular JavaScript.
- Yeah, no I agree, for me I generally,
if I'm doing something like on the front end I just do V
for a TypeScript project,
it takes 10 seconds and it's all set up for me.
So even if I'm doing something small,
I can at least get TypeScript that way.
But if I'm doing something like really, really small
where it's just an HTML file and a JavaScript file
and the JavaScript is like less than 100 lines,
I'm just gonna write it in plain JavaScript.
It's not worth all the extra effort
to have a build step for that.
But yeah like you said, the only time it makes sense
is when the build complexity
is larger than the project complexity
but that only happens at the minuscule size of projects
'cause the build time does not scale,
you know exponentially like the project complexity does
'cause as your project gets twice as large,
it gets way more than twice as complex
and when you get 100 times
as large, it's way more than 100 times complex.
But the build time only takes
maybe 100 times longer, maybe even less.
- Yeah, exactly, I mean you set it up once
and then you're kind of good to go and never touch it again.
Right, so if you anticipate
that you're gonna gonna spend like more than, I don't know,
a day or two building that project,
you're probably gonna be in a good position
if you take the time to set up TypeScript once
and then you know you're done with it.
And also you know, set up your TSS config
in the proper strict setting that you're comfortable with
and I would really say
or encourage you to make the types of config as strict
as possible as long as you still feel comfortable,
like yeah you can leave out one
or two settings, that's totally cool.
You can also read up on what all properties do.
Honestly I didn't do that myself.
There's a couple ones that you usually just go back to
and the rest is already set, mostly the default values
but try to make it as strict as you possibly can
because that's one of the fastest ways to learn
to really step into that cold water if you will.
And you know, let the compiler be mad at you, tell you
or let it tell you that you know,
what the hell are you doing here?
This looks horrible.
And try to fix those errors yourself.
And don't use like for example
AI too much at the start I feel like
using TypeScript 'cause what I used to do is outsource
all of the thinking work of TypeScript to AI
because honestly it's really good at that,
it's super tempting but the big downside
is that you don't learn how to figure out
that TypeScript problem by yourself.
And it might feel like you're saving a lot
of time while you send that problem over to the AI.
But in the long run chances are,
you're probably gonna be better off
learning why that problem exists
and then you always know how to solve
that exact same thing.
- Especially 'cause like in TypeScript,
a lot of problems are very similar.
So like if you learn how to solve one problem,
you're gonna see that same problem
in slightly different ways
all over when you're programming.
So it's once you learn how to solve one problem,
you really learn how to solve like 100
very similar problems while for the AI,
each one of those individual.
So like you have to spend the time, type that into the AI,
get the result, make sure the result
actually works for what you need
'cause if it's super complex,
the AI might not be able to solve it very well.
- Yeah, that's a whole different story.
Like AI could even give you like syntactically correct
things that still don't do what you intend to do
and it's just super hard to debug it then
'cause you didn't come up with it.
You don't really know what every part does
and as long as you are 100% sure that it goes way
beyond your capabilities and what you can do
or another good use case is try to implement it yourself
and if you're really stuck then go to AI with your solution,
paste it in there and then ask it
to explain why it went the path that it went.
Like using it as a learning tool.
That's probably one of the best ways to use it
instead of letting it solve the problems
for you and you leave it at that.
- And another thing I think is really important
is always fact check the AI
'cause they're wrong a lot more than they're right.
So if you tell it to explain something
around why it did something, take those explanations
and fact check them like TypeScript documentation,
my videos, your videos.
Just find something on the internet to help fact check that
because oftentimes you'll notice there's small discrepancies
between what the AI tells you
and what's actually true and if you just blatantly trust
whatever it tells you, odds are you're gonna have
some misinformation that you actually think is fact
and it's gonna really mess you up going forward.
- And the newer the feature I feel like the higher
the chances of that happening because they have like cutoff
dates of data that they're learning, right?
So if you're trying to implement a super new feature
that it could not possibly know about, then really make sure
to fact that, 'cause you know, chances are
it just kind of guess that it might work, it might not.
And I mean at the start,
debugging that TypeScript code yourself,
it might seem intimidating
'cause if you've ever had the TypeScript error
and take a look at the like error
that's showing up in your IDE,
it looks it they can look pretty scary.
TypeScript error,
and one of the best tips I've ever gotten
is to kind of go about solving those errors myself
is in TypeScript errors,
the ending part is usually the most important.
Like there's a lot of text
when you get a TypeScript error,
even if it's something really simple
you're still gonna get like a huge error message.
It might seem super intimidating
but chances are if you only read like the last one
or two sentences, that's gonna be kind of the path
to the solution as to what's actually wrong with your code.
Like you know, you pass undefined where you expect a string
or whatever and everything leading up to that.
I only ever read it
when I don't understand the last two lines
'cause chances are they're the best.
- Yeah, I 100% agree.
The last sentence in a TypeScript error is 90% of the time
what you need and the last two sentences
is 99% of the time what you need.
So it's pretty easy
'cause it gives you every single breakdown until you get
to the end where it's actually the thing that you want.
It's kinda like a stack trace.
You want just one part of the stack trace
to tell you where you actually need to go.
You don't really care
about the 100 other things in the stack trays.
- Exactly, there's even like a VS code plugin,
assuming you use VS code,
that makes the errors a bit less intimidating.
It's just kind of like a markup for the error.
So it looks a bit nicer, I guess you can use that
if you want, but just try to really understand
what the the error is telling you
because if you actually take the time
to take a look at the error,
they're actually pretty good at telling you what's wrong.
Not always of course, but for the most basic use cases
that you have a lot, at least what I'm doing wrong a lot
is like, you know as I said earlier, you're trying to pass
undefined to a string so it's gonna give you
like the object that you're trying to pass into
and the object that you're expecting
and there's probably gonna be like one property
that's different to look out for.
And once you understand that concept, I feel like it becomes
so much less intimidating to actually
take a look at the error, figure it out by yourself
and you're gonna get really fast at it after some time.
- Yeah it's just like JavaScript errors.
The first time you got a JavaScript error,
that was like thing is null cannot call function,
you're probably like mind blown I have no idea what to do.
But now you see that and you're like oh,
I just have something that's null.
It's the same thing with TypeScript errors.
The first time you see that wall
of text you're just like oh my god what's happening?
But after you've seen it 10,
20 times you're like okay, I read the last sentence,
I know exactly what that means, I change it.
And even if you don't, you can always try to Google
for the error or like I said, AI the error
and they can help give you some explanations
that maybe aren't the right answer
but at least point you in the correct direction.
- Exactly, there are so many good resources
on TypeScript as well.
And oh, one other tip I have is if you don't know the type
of something, try hovering over whatever you're trying
to figure out the type of 'cause chances are,
depending on the IDE,
I'm not too sure how that's done in like you know,
how you would do that in Vim or Neo Vim or whatever
but are many of you are gonna use VS code
and if you just hover over stuff, most of the time
you can actually get the type from there
then if you hit control
and click on the type you're gonna get taken
to the definition and can dig around
and see what the type expects and why it might error on you.
- Yep, 100%, and I think if you get
really complex TypeScript errors,
just digging into the types themselves
can actually a lot of times help you understand
why that error is happening.
- Especially if you use like open source software, right?
Most packages are open source, you can just dig into them
and then the only for the more involved ones, right,
you probably won't avoid, it's very time intensive
to dig into the source code and whatever.
But most of it is open source
and if you want you can dig into it
and you're A, gonna figure out
how a library implements TypeScript.
So it's probably gonna be on the bit more advanced level
but you can kind of get an idea grasp of it.
And then secondly you can go to the very specific function
that you are trying to call, for example from that library
and see exactly what it's expecting, how it's typed out
and then how your type that you're trying to pass in
for example, you know differs from that.
I've done that a couple times only
'cause it is so time intensive
but you learn a lot from like open source repositories.
I've done entire videos about topics I've learned
in TypeScript from open source.
One of my best TypeScript videos ever,
I just dug around in open source library
and you know, just found it
and was like wow, that's really cool
actually it was about the discriminated unions.
I didn't know they have a name back then, but now I do.
And I just found that out by digging around
when I had a code problem.
I went into the library, looked around how's the typing done
because you always have access to the typing
of any library that you use in your project
and you can just take a look, how do they do it?
- Yeah, 100% definitely.
And I guess we're kind of coming
to the end of our time here.
I don't wanna take all of your time.
So do you have any like
particular last thoughts, any questions,
things that you wanna mention when it comes
to just TypeScript in general?
- I think the most important thing by far is understanding
what purpose TypeScript solves for you.
'Cause there's no point in learning it
if you don't understand why you're learning it.
And for me personally, I can't speak for everyone,
but for me personally, it's definitely the speed
of development and the enjoyable.
Like it's just much more enjoyable.
You know the types, you know what you need to pass into,
the intelligence you get is awesome.
And then once you understand what purpose it solves for you,
you're gonna have a lot more energy to learn it.
'Cause you understand why.
And then get hands on, like do projects,
implement stuff yourself, get coding,
get your hands on the keyboard.
Like you can watch videos, consume all you want.
Like the biggest step I think is get your hands
on the keyboard, try out the TypeScript yourself,
see why it works, how it works, dissect it.
Like take things apart.
Does it still work, does it not?
Try to figure that out and you're gonna notice that,
you know, your TypeScript skills are gonna improve
like really, really fast.
- Yeah, I think personally the best way
to learn something is to break it
and to fail at building it.
'Cause those teach you the most amount of things.
If you just follow along with a tutorial
and write the code exactly as is,
you're not gonna learn the same
as if you actually break it apart.
Try to figure out why everything's working,
build it yourself and fail 100 times.
That's what really teaches you how to do things.
- And trying to re-implement like a very basic version
of stuff you see because you'll get an understanding
of how that works under the hood
and how they do their entire typing
and chances are, they're gonna be pretty skilled developers,
you know, if they have a good library that's open source.
And if you learn from that,
I think there's a lot to gain from it.
- Yeah, definitely, well thank you very much
for giving me your time.
I really appreciate talking with you.
I think people are really gonna enjoy this.
- All right, thank you Kyle, have a good one.
- You too.