All right, welcome back.
Let's finally get into things and talk
about TypeScript.
Now, why did I pick TypeScript?
Because there's actually many ways that we can introduce static typing to JavaScript.
There's tools like Flow, Elm, ReasonML, and obviously TypeScript.
For example, ReasonML and Flow were created by Facebook and the developers at
Facebook, and TypeScript by the fellows at Microsoft.
But they all do the same thing.
They all try and make JavaScript a
statically typed language.
Now, let's talk about ReasonML.
Reason is based on a programming language called OCaml.
And like I said before, it's created by Facebook to make it easy for JavaScript
programmers to pick up.
It's a language in its own, but similar
enough to JavaScript that it's easy to pick up.
And Facebook actually uses it with some of their projects, and currently 50 % of
their messengers' front -end code is written with Reason.
So that's a popular language coming out of Facebook.
All right, but again, I'm still not getting this.
What does this all mean?
Well, maybe the next slide will help you.
Again, all of these tools, their goal is to make writing JavaScript a little bit
nicer, a little less buggy, and introduce static typing.
And Flow, which is used very commonly with React projects, is what we call a
static type checker.
Let's start off with this one.
Flow is able to add types to our JavaScript by writing some code that
works with Flow and then putting it through a compiler, such as the Babel
compiler, which spits out JavaScript.
And we know what Babel does from previous sections.
It takes ES6 code or ES7 or ES8 code and changes it into ES5 code so that all
browsers can understand it.
Now, Flow is a static type checker, which
means we're actually writing something like this at the top of our files.
At the top of our files, we'll do something like dash dash at Flow.
And Flow is going to be able to say, ah, this file has Flow types, and I'm going
to check it for you.
It checks the types.
Again, don't worry.
When we talk about types, you're going to
learn them in later on videos.
But again, we want to build the
foundation first.
If you go back here, what we actually do
with Flow is that it checks everything.
And it relies on Babel to actually remove
that addFlow and all the other types that we've entered into our code before
production, before sending it to our users.
And Flow actually comes pre -built into
Create React app.
If we go to the Flow documentation at
flow .org, we see that in Create React app, we simply run these commands, and we
can start writing type checking in our code.
Again, something that we'll cover.
TypeScript differs from Flow because TypeScript has its own compiler.
It's not like Flow that depends on Babel to remove all this extra code before
spitting it into JavaScript that we want to send to the front end.
TypeScript is what we call a superset of JavaScript.
That is, it adds functionality on top of JavaScript.
That means that JavaScript is TypeScript.
And TypeScript just simply adds a few
extra features on top of JavaScript.
But it also has its own compiler.
So we write TypeScript code, which then gets run through the compiler.
And remember, a compiler is just simply a machine that takes an input of some piece
of code and outputs a different piece of code.
In our case, we're going to convert it
from TypeScript to JavaScript that our browsers can read.
Just like I talked about before about ReasonML, it has the same thing, its own
compiler, and it's going to go through the compiler and spit out JavaScript code.
The difference between TypeScript and ReasonML is that Reason is a completely
separate language from JavaScript on its own.
TypeScript tries to mimic JavaScript and
grow with JavaScript.
Like I said, it's a superset.
But ReasonML is just a whole different language on its own.
It doesn't depend on any JavaScript changes being made in the ecosystem, any
of that.
And Elm is pretty much the exact same
thing as ReasonML.
Its own language that is type -safe, that
has its own compiler, and spits out JavaScript.
So you might hear in JavaScript land
people using these tools.
The ones that you should really focus on,
because Elm and ReasonML are still fairly new.
You won't find that many jobs out there
that actually request it.
It is nice to learn and interesting.
But again, most of the time, you're looking at either learning Flow or TypeScript.
The reason I'm teaching TypeScript instead of Flow in this course is that
the growth of TypeScript outweighs all of the others that we've learned in this section.
All these ones.
A big part of this is that Angular is
built with TypeScript and using TypeScript.
So if you're an Angular developer, you're
already using TypeScript pretty much by default.
However, a lot of the React community is
also starting to use TypeScript.
And just general JavaScript community is
starting to get more and more used to using this.
And although Flow was created specifically to work with React,
TypeScript currently is overtaking its popularity.
So we wanted to learn this instead.
Plus, once you learn, just like with most things, once you learn the one method,
it's quite easy to pick up Flow and how static typing works in Flow.
By the way, if you don't trust me, if we take a look at Stack Overflow developer
survey from this year, we see that the most loved languages, well, we have Rust,
Kotlin, Python, we have JavaScript in there, but you see TypeScript because
it's its own language.
I mean, it's a superset of JavaScript,
but it's up there.
It's very, very loved.
And it's also quite high in the wanted section.
So it's very, very important.
And if you look anywhere, everybody's really excited about TypeScript.
One quick note, by the way, why do you think Angular is such a big fan of TypeScript?
Now, this is just my opinion.
I may be wrong.
But if you remember, I said that Angular is kind of like the kitchen.
It's great for big companies like banks to make sure that their massive developer
teams work within a kitchen that has already everything defined of how to cook
bread or how to cook an app.
TypeScript adds static typing, which adds
an extra layer of security or an extra layer of type safety in the code.
Again, expanding that kitchen to make sure that the codes or the coders, the
developers on the team play within the rules.
I think that's pretty interesting.
So let's get back to the topic at hand.
As developers, we must understand why we
put things into our projects.
We don't want to just follow the trend
because I just showed you the developer survey and everybody's using TypeScript
and just jump on the latest bandwagon.
As senior developers, we must decide for
ourselves what works for our project and our team and what makes sense.
So here's my outline of when to use static type checking like TypeScript.
Your project grows larger and larger.
You already have tests written.
And as more developers join the team, you want the code to be self -documenting and
also avoid bugs as new people touch the code.
You also have the budget within the
company to train new employees to learn this new language and expect that our
development cycle, that is how fast we're able to write features and new code is
going to be slower because we're writing more code now.
That's your checklist.
If that's the case, then we should add TypeScript.
If not, we shouldn't.
But in order to really understand it, we
actually have to write TypeScript and go through the process.
So let's finally get into coding.
I'll see you in the next video.
Bye -bye.