- Hey Adrian, thank you so much for coming on
and doing this video with me.
If you just wanna real quick introduce yourself to everyone,
kind of tell 'em what you're about, that'd be great.
- [Adrian] Yeah, that sounds amazing.
Thank you so much, Kyle.
It's so interesting to speak with you in person
after watching a lot of YouTube videos.
But yeah, I'm Adrian.
I founded JavaScript Mastery
about five, six years ago now,
and we do YouTube videos.
We help new developers develop software
with a project-based approach.
So I would say that's something that's a bit different.
We try to truly dive into it
and focus on building comprehensive,
project-based, real life work
that would simulate a real life environment.
- Yeah, no and and that's something I really like
about like your videos and your courses.
It's really cool to be able to see
these larger projects come to life.
That's something you do a lot differently
than I do on YouTube, is like you make
a lot of these larger projects,
and I think they're really cool.
So if people want to check out those larger projects,
I'll link his channel in the description
so you can check it out.
I highly recommend you do.
But in this kind of interview,
I really want to talk about some of that stuff
around working on larger projects,
especially around TypeScript.
Because when you're on a small project,
the amount of types you have to write is relatively small.
It's relatively simple.
But when you move over to a larger project,
a lot of extra things you need to think about,
especially as you start to scale all the way
to like the enterprise level.
But I kind of want to get your thoughts just in general.
What are some of the things that you keep in mind
when you move from like a to-do list,
kind of really small application,
up to a larger and larger application,
like from middle all the way up to a larger application?
What are kind the main things that you think about
when you're starting to make that move?
- [Adrian] Yeah, that's a great question,
and I think it really dives into the purpose
of TypeScript in the first place.
So, I'm gonna be very honest and straightforward right now
and say that I think that you do not need TypeScript
on very small projects,
on small projects like to-dos or stuff like that.
TypeScript really starts paying off
as the projects get larger.
So for medium projects, already you can start seeing
a lot of its benefits,
and then for large projects especially,
and then for enterprise projects even more so.
There are many benefits that you can only start seeing
when the projects get bigger and the team gets bigger.
- Yeah, no, I 100% agree.
I personally think TypeScript's good at all project sizes,
but as you said, that really small project size,
it's like a 1% increase.
It's not really gonna make or break it.
But when you move to like an enterprise-level project,
I can't even imagine working
without TypeScript on those projects,
'cause I would be in fear
of making any changes to any of the code.
- [Adrian] I couldn't agree more.
It allows you to introduce strong typing, right?
You can create code that, you catch errors early.
We all know that situation where you misspell a variable
or you fetch the data from the API,
and then you figure out
that that property doesn't exist, right?
And TypeScript saves you from all of those things,
from improper naming of the variables
to using improper types to referencing some properties
of an object that are not really there.
And you can spend hours and hours on trying to fix it,
but TypeScript just immediately flags it for you,
right within your code editor.
Also, as the project gets bigger,
I think it's important to talk about the team.
Most likely you'll be working within a team setting,
so having those type definitions within a team is important.
You can create interfaces and types,
and everybody can know what specific code does
and how specific data structures look like.
- Yeah, definitely.
I know back before I started my YouTube channel,
I used to do a lot of Ruby on Rails development,
which is a language without any types in it as well,
very similar to JavaScript in that regard.
And it was really difficult
because most projects you work on, there's no documentation.
Sometimes you'll work in a project that has documentation,
but 99% of the time if you work on a large project,
there's really no documenting how things work.
And if you don't have any types, it becomes even harder
because now you don't have types to tell you what things do.
You don't have documentation to tell you what things do,
so all you have is the code,
which means you just have to read the code
to figure out what things do.
And it's very error prone, because reading code,
obviously you're not gonna get all the nuances
of how everything works in every single permutation.
Well, if you have types, it at least kind of gives you
a level of documentation.
It's basic, but it's enough
to get you through most of what you need to do.
You know all the inputs and outputs of a function,
you know kind of how it works based on the name of the types
and the different inputs and outputs,
and it almost gives you like a really rough version
of your documentation.
Like, even some documentation
for different libraries out there
is really just type definitions
with a few different comments in there
to explain what they mean.
So having those types
is already like a good level of documentation,
which really helps when you're working on a larger team.
- [Adrian] I couldn't agree more.
And we developers,
we tend to not write proper documentations in most cases.
We focus on coding, and yeah, Kyle, as you said,
in most cases, medium projects
are not gonna even have documentation.
So having something already there just immediately,
by writing proper TypeScript code, you and your team
will already know how that code is going to work
based off of the function names,
as well as the function inputs and outputs.
- Yeah, 100%.
And kind of not so much related to TypeScript,
but related to working on a team on a larger project,
do you have other techniques you'd use
to try to help collaborate with the team
to make sure maybe your code formatting
or your code style is kind of similar?
Anything that you do in that regard at all?
- [Adrian] Oh, definitely.
So recently we have introduced
really comprehensive linting strategy.
So, before I didn't really like Prettier.
We used ESLint, mostly, but now I've sat down,
I've took some time and I've made them work together.
So we have a proper ESLint/Prettier linting strategy
with custom rules, and we ensure that every team has it
and every member of the team has it.
So, I'm talking indentations, semicolons,
quotes, right?
All of these things have to be the same.
And you might think that these don't go a long way,
but they truly do.
Just take one example, PRs, right?
When you open up a pull request,
when the entire team has different kind of coding styles,
it's so hard to review because you're not looking
just at the changes that matter.
You're looking at the basic line changes.
So having proper types and having proper linting
significantly helps and makes your team more efficient.
- Yeah, I 100% agree.
I also personally like the combination
of Prettier and ESLint.
I feel like Prettier is great at doing all the formatting,
just automatically, no configuration needed,
and ESLint is really good for the more nuanced things,
like more, I wouldn't really say it's more like formatting.
It's more like kind of how you write your code.
It almost helps you with also preventing certain bugs.
Like, especially if you're working in like React,
for example, the ESLint rules for hooks is really helpful
for making sure you don't misuse things.
So I think ESLint is really good in that regard,
and then Prettier's obviously super amazing at formatting.
- [Adrian] Exactly.
- And kind of almost on the same note of configuration,
this is jumping back into TypeScript, is,
do you have different preferences
around certain things in your TS config?
Like, are there certain config options where you're like,
"Oh, this must be in every single project,"
or certain ones where you're like,
"Oh, I hate this. This is terrible."
- [Adrian] Hmm, that's a good question.
I wouldn't really say I do.
Right now, on bigger projects as well, we use TypeScript.
We leave the config as it is,
which might not be the best thing, but we do.
And then if I do notice that something bothers me,
we then add it into the config later on.
But it's more so of a style
of how we define interfaces, types,
and all the other more complex data structures
or defining the types for those data structures
as we go throughout the project that matters.
So kind of having a team-based guidelines
on how to use TypeScript.
And I wanna dive into another aspect,
which is educating your team members
and educating yourself on how to use it properly.
So a lot of people can use TypeScript
with adding those any's or unknowns, right?
But then using TypeScript properly
is a whole different deal, I would say.
- Yeah, I think that the reason most people
don't like TypeScript is not because they think
TypeScript's actually bad.
It's because they've tried to use it
and they ran into struggles
because they didn't truly learn how to use TypeScript.
They just kind of tried to brute force it
from their JavaScript knowledge.
So they had lots of any's, they had unknowns.
They ran into troubles 'cause they didn't know
how to type certain things properly.
And those are really painful experiences to run into,
but you don't get to the benefit of TypeScript
until you learn how to get past those different things.
So I feel like a lot of people
that have a strong hatred or TypeScript
run into those problems,
but never actually push past them to get to the benefits.
And, you know, they just don't get to see
the amazing part of TypeScript
that comes after you run through those roadblocks.
- [Adrian] And it's not necessarily that tough, right?
I mean, your course is, what, about six hours long?
- Yeah, it's actually even shorter than that
if you just go through the main content.
It's only like five hours.
- [Adrian] Yeah, so it allows you to,
it does have a learning curve, right?
But five hours nowadays to learn something
that can significantly help you is huge, in my opinion.
- Yeah, yeah, I couldn't agree more.
And I used to be that way with TypeScript.
Like, I had to use it in school actually for a project,
which is kind of unheard of,
because back when I was in college,
like TypeScript was not what it is now.
It was very kind of niche back then, but I had to use it,
and I was used to JavaScript.
I'd done a lot of JavaScript before, so I was like,
"This is kind of painful.
"I feel like I'm having
"to like code all these things in a weird way."
I felt like I was going back to working in Java
and I hated Java. so I was like,
"This just doesn't feel right."
But I never got past that, and for the longest time,
a couple years after that, I still didn't like TypeScript.
I was like, "Ah, JavaScript is so much better.
"It's so much easier."
And then I finally jumped ship
and I was like, "You know what?
"I'm actually gonna spend the time to learn this."
And like you said, it didn't take me very long.
I spent like a week,
and it wasn't like a week of full-time work.
It was just a week on and off
trying around with different projects and stuff.
And then it just clicked for me and I was like,
"Wow, this is so much nicer."
Because I was working on a project and I was like,
"Oh, I have really great autocomplete."
That was like the first thing I noticed.
And then I needed to change something, and I was like,
"Oh, changing this is now really, really easy."
And like all these different things
just started to click for me.
- [Adrian] Well, one thing that was a breakthrough for me
is when I used to write some code in Java back in the days,
and Java has really good kind of intelligence
when you get into an object or any kind of a class, right?
And when you do a dot on that class,
it automatically knows everything about it,
all the methods, properties,
better than JavaScript used to be a couple of years ago.
But TypeScript immediately brought that in
into JavaScript, right?
So once, it knows everything
about the data you're working with.
It knows everything about your functions, objects, arrays,
and then you can immediately just use a dot
or use the .space, is it, to autofill something?
And then it's just so much smarter
in knowing how your code base works,
so it allows you to be more efficient.
- Yeah, 100%.
Like, I find this is actually one of the things
that differs a lot
between small projects and large projects,
is when you're working on a smaller project,
the biggest benefit of TypeScript is the autocomplete.
Because refactoring things on a small project,
you can just kind of look at all the code
and know what to change.
But then once you move to a large project,
yeah, that autocomplete is still amazing.
I mean, it doesn't ever stop becoming amazing,
but it becomes a smaller benefit in my opinion
compared to other benefits like safe refactoring
and stuff like that.
That is where I feel like as you go to a larger project,
TypeScript shines even more,
because the refactoring, like I said,
on a small project is pretty easy.
You can do it manually if you want,
but when you move to a large project,
you're not gonna know all of the 1,000 different files
that used this particular variable.
So renaming it in all those places,
it's pretty much impossible.
But if you have TypeScript,
it just does it for you essentially,
and if it doesn't do it properly,
you get errors every single place
that you didn't update it properly.
- [Adrian] Exactly.
But you did say that it took you some time
to kind of get used to it
or to get yourself to use it, right?
So I think this is a good point to start talking a bit
about some obstacles or concerns of why people
might not want to
get into TypeScript for the first time they're trying it.
I'm gonna start with one.
Some people think that it potentially adds
too much boilerplate code
that you have to go over to write
to just have some logic into it.
But my immediate and really simple answer to that
and a solution is that, at the end of the day,
it's going to save you so much more time
than it took you to write that single type
or that single interface,
and it's going to pay off tenfold
by increasing your efficiency later on.
- Yeah, I think this is especially apparent.
Like, when you first start writing TypeScript code,
the amount of time it takes you to write those extra types,
even though it's a small amount of code, is not trivial
because you're not sure of it,
you're kind of confused by the syntax.
It's relatively new.
So maybe let's say you're writing a to-do list application.
Let's say that it increases the time to write that
by 50% just for the types,
but the amount of time that it saves you
maybe won't equal 50%, 'cause your project is small
and you had so much starting learning,
like, there's a huge learning curve there at the start.
But then after you've built
that first to-do list application,
now let's say you go and build something else
maybe a little bit bigger.
You kind of are familiar with types,
so adding in the types maybe only adds 10%
additional time to your project.
Still more than you would be
if you're an expert in TypeScript,
but not as bad as it was at the start.
But now the time that you saved from having autocomplete,
having less bugs that you run into, that is a huge saving.
Like, that's something I don't think people realize,
is they think, "Okay,
"TypeScript does do a good autocomplete.
"Yeah, whatever. That's fine.
"I can type in things on my own.
"I don't need autocomplete."
What they don't realize is that the amount of time
it saves you while you're developing,
because you write less bugs.
Having the autocomplete
means you don't misspell a variable name,
and then five minutes later you're like,
"Why isn't my code working?"
and you spend 15 minutes debugging that.
TypeScript completely removes those 15 minutes of debugging.
So even if it took you 15 minutes
to write the type for that, you already saved that time,
just in the development time
before you even get into refactoring and future work.
- [Adrian] Yeah, and just like you said,
it becomes second nature.
- Yeah.
Yeah, when I'm writing TypeScript code, like, I don't think,
"Okay, I need to swap my brain from JavaScript
"to TypeScript
"into Typeland and all this." - Exactly.
- It just happens.
I just write the code, and it becomes so second nature
that now, writing TypeScript code takes me like 1% longer
than writing JavaScript code.
- [Adrian] I couldn't agree more.
- Yeah.
So, I wanna kind of talk a little bit,
we talked slightly about teams.
I wanna talk a little bit about maybe
when you're working on a team and you want to try
to start integrating TypeScript.
Like, maybe you're starting a new project
or you're on an existing project
that's written in JavaScript.
How do you go about maybe trying to convince the team
that you're working on that,
"Hey, maybe we should try out TypeScript.
"Like, we've done things in JavaScript in the past.
"Let's try out TypeScript
"because I think it might be really advantageous."
- [Adrian] Hmm, that's a good question.
So we're talking about teams of, well, let's say,
let's talk about teams of like two, three, four, right?
At the start, you will just start working
with a friend maybe on a project.
Later on in a smaller company,
you will work with five, 10 people maybe.
And then on enterprise projects,
you will work with dozens,
maybe even hundreds of people, right?
At this point, are we gonna look at...
So, the people watching this, Kyle,
right now, they're gonna be at the point
of having their superior maybe set up the project,
or maybe one day are they going to be the ones
getting their team to use TypeScript?
- Yeah, at the start, it'd be mostly superiors
setting up projects for them,
but hopefully eventually they become team leads
and senior developers,
and they're the ones actually setting up the projects.
- [Adrian] Exactly.
So here, I would say that from that regard,
educating the team members is going to be necessary.
So, like what I'm doing with YouTube and what Kyle is doing,
sharing some of those videos.
Not necessarily ours, but sharing resources,
sharing tips to your team members
and how to use TypeScript properly.
Well, Kyle's course, right?
It's just five hours long, but then at the end of the day,
it helps them significantly helping you on the project.
So, sharing the resources.
Holding some kind of training sessions as well
or creating resources to help them learn is good,
because Typescript's a learning curve,
no matter how, it doesn't take too much time,
can be steep, right?
Especially for developers not familiar
with those strongly typed languages.
So, for that reason, kind of try to take it slow.
Share some resources with your team,
and then encourage them to avoid using any's or unknowns
for absolutely any reason necessary.
- Yeah, I think one of the best ways to do this
is something called like a lunch and learn.
It doesn't have to be this, but this is a good concept,
where for example, lunch break is usually like an hour
or so that people take for lunch.
An idea behind a lunch and learn
is that someone will over that lunch break
present a topic to the people that are eating lunch.
So everybody just says,
"Hey, we're gonna eat lunch at like 12 o'clock today,
"and then Kyle is gonna do a short little presentation."
Maybe it's gonna be a half hour of that hour,
and you could kind of present about TypeScript,
maybe some of the advantages,
teach some of the basics of TypeScript,
just kind of get your team familiarized with TypeScript.
And you can do this whether you're a senior on the project
or a junior on the project, because lunch and learns
are pretty much open to anyone.
as long as people just agree to come
and listen to what you're talking about.
And a lot of companies are gonna be okay with this
because it's not actually taking away development time.
It's over the normal lunch break people have anyway,
so it's not like adding to the day,
and it's actually improving the team
because they're learning new things.
So most companies are gonna be more than happy
if you end up doing this, and a lot of developers,
they get into the development because they enjoy learning.
So having a lunch and learn,
it's something that's enjoyable for them as well
and it slowly kind of gets that idea
of TypeScript into your team.
So even if you don't have like the seniority to say,
"We're doing this in TypeScript,"
you can start to kind of plant those seeds.
And maybe one of the seniors that are there watching
are like, "Oh, you know what?"
"This TypeScript thing seems kind of cool."
They do some more learning on their own,
and now all of a sudden,
your next project is written in TypeScript.
- [Adrian] That's amazing.
It kind of makes me miss a bit more of in-person work.
Nowadays a lot of things is is remote, but, hmm.
Do you have an idea of how we would do this
in a remote world?
Kind of just sharing it into Slack messages maybe
or something like that?
- Yeah, yeah, you could do like Slack messages
and things like that,
but you could also even just do like a Zoom call.
Just be like, "Hey, everyone hop into a Zoom call,"
or even I think Slack has like video calling
and stuff like that now.
It doesn't even need to be a video call.
You could just share your screen
and everyone else can be muted with no video
so you don't have to worry about sounds
of people eating potato chips the entire time.
But like, you can kind of emulate that same thing.
It's a little bit harder, though,
because in a actual office,
everyone's just already there eating lunch,
so it's like no brainer, like people are already.
There's a little bit more extra work for them to be like,
"Okay, I'm gonna turn on Zoom when I'm eating my lunch."
But it's not that much extra that I think people are gonna,
like, you may get a few less participants,
but it's not like nobody's gonna show up.
- [Adrian] Yeah, definitely.
One thing that's not maybe necessarily related
to TypeScript, but it is to working in large projects is we
in JavaScript Mastery now
try to avoid having too many meetings.
And the more people you have in a team,
the more meetings you're gonna have eventually, right?
And as developers, nobody likes having those meetings.
So we started using a tool called Loom much more,
where we record a short video
that you can then share across your organization
and everybody can watch it at their own time,
often in like a 1.5 speed.
So they can quickly go through it,
get the point across, and that's about it.
- Yeah, and this, I actually really like this idea
also for documentation.
So, like we've both said, writing documentation is tough,
it's slow, it's boring, it becomes outta date.
If you do video documentation,
you can generally make a video relatively quickly
with like a software like Loom that does it for you.
It doesn't have to be Loom. It can be any software.
But like you can do a really quick screen recording
showing the code, talking about it,
or like showing the different parts of an application,
and it's a really good tool for onboarding new developers
onto your team or even educating developers
that maybe switched departments
who are like now going to be working in your new department.
And it's just like an hour of video
versus having to read hundreds of pages of documentation.
And I find that yes, once you get the documentation written,
it's relatively easy to update,
but it generally doesn't get updated.
It becomes outta date, and then it's a pain to update.
And videos are just so quick just to redo a whole video.
It's not like a huge commitment
if someone can just do it in one day,
so I find that doing a video form of documentation
is another great way to help keep your team stronger
and more knowledgeable about the code.
- [Adrian] Oh, absolutely. I couldn't agree more.
As we kind of started creating more courses as well in JSM
and our Masterclass program,
we wanted to improve our processes significantly
and documentations and wikis and everything you said.
So we found that video documentation
and video internal processes helped significantly.
So that includes a combination of two tools that we now use.
It's Loom paired with Notion.
So we create different Notion pages,
and then we add video documentation for anything
that people might need to go through.
It's much better than text,
and nowadays Loom and other companies with video
are also adding AI features,
so you can kind of get main takeaways from those videos,
get the next steps and so many more things.
- Yeah, 100%.
And this is a little bit more of like a senior level thing,
like writing out the video documentation and stuff like that
and like writing SOPs for a company.
A lot of people aren't gonna run into that,
but you can kind of take it
and use it for your own uses as well.
Like, how we talked about the lunch and learn.
Instead of doing a lunch and learn,
where maybe people can't come because you're all across
different time zones and stuff like that,
instead you just record a Loom and you say,
"Hey, I'm gonna share this with the team.
"I just did a quick 30-minute video
"on TypeScript, some of the benefits.
"Feel free to watch it at your own time
"and send me over any questions you have
"and I'll try to answer 'em."
Just, that's a really easy, asynchronous way
to do this type of thing.
- [Adrian] And one more thing,
is also PRs, pull request reviews as well, right?
You can provide a video pull request review.
It speeds up the process.
You can go through the code base,
record yourself going over it,
and just provide some feedback maybe
to the people below you if in case you're a team lead.
Or if you're not, you can also kind of record
the quick video asking a question,
going over the tabs you have open
that you have already explored,
questions you have and so on.
It's a powerful tool to essentially save you
and people around you time.
- Yeah, another thing that's great about that
is I know that a lot of times
when you get a code review back,
it doesn't really matter what's in the code review,
you take it very personally.
It's really hard not to.
Like, "I spent weeks on this code and now you're telling me
"that this thing is wrong and it needs to change?"
It's very easy to take it personally,
but if someone records a video,
you get a lot more like connotation
around what they're saying, they have body language
if they're recording their face, you have vocal inflections.
So it's really easy to see, like,
"They're not actually mad at me.
"They're just saying like,
"'Hey, you should probably change this thing.'"
It's not like you're a dumb person.
It's just like, "Hey, you know what?
"In our company we do this differently."
But like when you read that as an actual text piece,
you're like, "Ooh, I take this so personally,"
but as a video you take it much less personally.
So I find it makes developers more happy.
- [Adrian] Yeah, "Change this, change that,
"do this, do that," right?
It feels bad, but then at the end, if you record the video
and say, "Okay, have a great day," right?
That that's all that it takes
to completely switch the connotations with that.
- 100%, yeah.
'Cause like I said, I would take it so personally sometimes.
I'd look at it and be like, "Oh, I spent so long on this
"and I thought it was perfect,
"and now you're telling me to change it."
And it's like, they don't mean it in a negative way.
They're just like,
"Hey, I have 100 times more experience than you.
"You should probably do it this way
"because I've ran into so many problems
"doing it that way," you know?
- [Adrian] Yeah. That's it.
- Awesome, well,
kind of let's jump back to TypeScript here.
We had a pretty long tangent,
but it was super useful I think.
But jumping back to TypeScript,
when you're working with TypeScript,
as you get on a larger project,
do you have particular things
that you do differently about your file or folder structure
pertaining to TypeScript versus if you're working
on like let's say a JavaScript project?
- [Adrian] That's a good question.
Let me think about it for a sec.
- Yeah, yeah, I mean I can kinda give my input.
Personally, I don't really have much difference.
I know some people like to create a types folder
or a types file, but for me, I generally put my types
right in the place that they're used.
And I usually have very few if any files or folders
specifically just for types.
I may have like a couple files
that are for overriding different types in libraries
or like creating types for libraries that don't have them,
but that's a pretty rare and niche scenario for me.
- [Adrian] Yeah, I couldn't agree more.
That's exactly what I wanted to say.
So, besides the like one or two files
that TypeScript provides as soon as you set it up,
that you can put some types into,
we don't essentially create any other files
regarding to TypeScript.
We just put it on top, in case we have, yeah,
we always put it on top
in case we have the kind of database files
where we set up the models, we put it there, right?
And in case we reuse some of the types, which often happens,
in that case, we then we do kind of create
an additional folder and file for those specific types,
and then we can call them and import them.
- Yeah, that that makes a lot of sense.
And the nice thing is that generally
those types that you use in a lot of places,
you don't actually need to export them a lot of times
from a particular file.
'Cause let's say for example you have like a API request
that has a particular type in it
for the return from that API request.
Once you call that API request, you get that data back,
you have it already typed properly
'cause you have that function set up,
the nice thing is that type
just kind of propagates everywhere for you,
and you generally don't need to reference that type exactly.
And in my opinion, if I, like, for example,
really needed that exact type somewhere,
what I would often do is just export the type
directly from that file, 'cause that's like the place
that the type is created and used,
so I would generally export it from there.
But maybe if you have a more general type,
it makes more sense
to put it in like a type
file or type folder. - Yeah, but you're right,
you're right.
You don't export the types.
You export the functionalities
that already use those types
so you immediately get the benefits out of it.
Yeah, that's true.
- Yeah, and there are situations
where you do need to export the types,
but I find it's relatively small in comparison
to the number of times where you just don't need the types.
You just get the actual result from the function
and it's already typed for you.
- [Adrian] Agreed. Yeah.
- Awesome.
Well, I don't have any major other questions for you.
I don't know if you have anything else you wanna mention
related to TypeScript and big projects
or just anything around that in general,
what we've talked about.
If you have anything else at all you wanna add,
just feel free to.
- [Adrian] Yeah, essentially TypeScript and big projects
is the topic of today's conversation,
but I think when talking about TypeScript,
you are talking about medium to large projects.
It's when it really shines.
So, I'm really happy we've gotten a chance
to do a conversation or interview on this exact topic.
I do wanna kind of compare it with a story
from my personal developer life about learning Redux,
and I wanna kind of make a comparison
of TypeScript and Redux.
They both have a steep learning curve, right?
When I was first learning Redux, it was so bad.
It introduced a lot of boilerplate code,
and at least it felt like that at that point in time, right?
And then I didn't really see the purpose of using it
as I was working on small projects at the time.
Only after I've started using it more
and learning it properly have I gotten to understand
the purpose and the point of Redux,
and only you can see it on medium and large projects,
how much it saves you from state management and all of that.
Now, with that in mind, TypeScript
has a less steep learning curve
and will make you significantly more efficient than Redux.
So for those two reasons, I think that it's, you know,
I think just go for it and definitely include it
in your larger projects.
- Yeah, and kind of on the same note
of comparing it to Redux,
TypeScript also has a way less boilerplate than Redux,
especially compared to how Redux was in the initial stages.
Like, it's a significantly smaller footprint,
more benefit and less to learn,
so it's pretty much a win-win
no matter. - Exactly.
That's it, yeah.
- Yeah, and kind of on the same note to end this,
if you have watched all this course,
you've watched all these interviews
and you're still at the point where you're like,
"I don't really see the benefit in TypeScript.
"It's really hard."
I would highly recommend
just keep pushing a little bit longer
and try to maybe move it into a more medium-sized project.
'Cause a lot of the projects you work on are smaller,
move it to a medium-sized project,
and then you'll really start to see the benefits,
especially if you come back to that project
like a month later after you write it to add something new.
That's, I think, where it really shines,
because it essentially acts as a memory bank for you,
because you can't remember how everything works.
And TypeScript will remember that for you
and document it and make it just automatic.
- [Adrian] I agree, and on the same note,
in our Masterclass Bootcamp,
we try to help a lot of people to get a job.
I'm guessing that's a plan for a lot of people
watching your courses as well,
to get that first junior developer job.
So even if you still don't understand it, push through it,
because two of the most highly requested things
in the Masterclass as well as in the job force right now,
I mean, go look at any job posting,
you'll see most likely two things.
Of course, it's gonna be JavaScript, React,
Next.js, all that stuff,
but then alongside every single one of those,
it's going to be TypeScript
and it's going to be testing, right?
Knowing how to test things.
And both of these things are special
because you don't really see the purpose of doing them
in small projects, but there's a reason
why companies have put it there, right?
Bigger corporations need testing and TypeScript in there
for the same reasons, to make you more efficient
and to make your code base less error-prone.
- I couldn't agree more, honestly.
Like, I love both testing and TypeScript,
and I feel like when you put the two of them together,
they even add more than they do on their own.
Like, as two parts they're great, but as a combined whole,
they're even better than they are on their own.
- [Adrian] Exactly.
- Awesome.
Well, hey, I want to thank you so much again
for taking the time to talk with me.
Hopefully this video was really useful for everyone.
- [Adrian] Yeah, absolutely.
Thank you for having me,
and I hope people found value in it.