>> I'm John Papa.
>> And I'm Anders Hejlsberg.
>> And today we're going to talk about
the five coolest features in TypeScript.
Number one, we can get type checking even in JavaScript?
>> Yes, you can.
>> How?
>> So TypeScript's language service
is all written in TypeScript and in JavaScript,
if you will, and
JavaScript is in a sense
just TypeScript without type annotations.
And so we can use
the TypeScript language service to analyze
JavaScript because we have
very strong type inference in the TypeScript compiler.
We can actually infer a lot of the types
even though you had no type annotations at all,
or if you write JSDoc annotations,
we can slurp up the JSDoc annotations and feed
them into the type checker
and move those to check your code.
So we have this mode for JavaScript called TSCheck,
or we have a directive you can put at the beginning of
your JavaScript file called @ts-check in a comment,
and then we will run the type checker
on your JavaScript file.
But we won't report as many errors
as we perhaps would have done in TypeScript.
In TypeScript sort of our mantra is, Well,
if we think something is wrong here,
we should give you an error so you can go check it.
In JavaScript, on the other hand,
it's more like, Well, if we're not sure,
then let's just leave it alone,
but if for sure we can tell this is not right,
then let's give you an error.
And it's remarkable. You just try and
file it up on on a plain JavaScript file,
and time after time,
I've heard people say, Oh my god.
It just found a couple of
bars right out of the gate, and I didn't do anything.
There's really no harm in doing
it because you don't have to modify your code at all.
>> And that's relatively recent isn't?
>> It's fairly new.
It's in Visual Studio code.
I forget if it's turned on by default now,
but it's one configuration file setting.
CheckJS, you set that to "true",
and then we will automatically
check every file in your project,
or you can individually opt-in by putting
a // @ts-check directive at
the beginning of those
JavaScript files you want to have checked.
>> Number two, I want to create variables,
but I want to constrain on
the certain domains like
have a string that's like, yes or no.
>> Right.
>> Can I go there?
>> You can with
the literal types or string literal types.
We also support numeric literal types
and Boolean literal types.
In fact, our TypeScript's type system
is pretty advanced compared
to type systems like say C# or Java.
We have concepts like literal types,
union and intersection types that in a sense are more
like functional programming than
your sort of classic type systems.
So you can express a type that is a string or number,
for example, or, you can express
a type that is " Yes" or "No".
And only that those two string literals
qualify at that point.
But, of course, a "Yes" is
assignable to a "Yes" or
"No" but not the other way around, right?.
So there's a whole bunch of checking
that we could do at a very granular level.
>> A lot of times in JavaScript,
I would have a array where I want an object.
Maybe I'm creating an array of
those objects or single objects.
>> Right.
>> So I could use that with unions?
>> Sure. Sure. You can have string or string array,
for example, as a type.
And then you can dynamically check
if x is of type string,
then we know you have the string,
otherwise, you have the string.
>> Number three, "Undefined is not a
function," I get this a lot. Help me.
>> Who does not get that a lot?
Yeah. This is like, who
has never had a null pointer bug, right?
I mean even in languages like JavaScript.
TypeScript 2.0 introduced the ability
to check types for null.
And it sort of
leverages many of the things that are in our type system.
One is union types that we just talked about.
In strict null checks mode,
we basically say that
the value is null and undefined are not
part of any type unless
you explicitly make them part of the type.
So if you say string,
that means a string but not null or not undefined.
But if you want to include null or undefined in domain,
then you say string or null or
string or undefined or both of them.
And then the type checker will check
your code accordingly and effectively
identify places where you have not yet guarded by
checking for null or undefined
before you do an operation that would blow up.
>> Number four, how does
TypeScript help with Control Flow Analysis?
>> So, Control Flow Analysis is
this idea that the compiler
will check what happens to the type
of a variable through the flow of a body of code.
Say, for example, you have a variable that
can be string or undefined.
Let's call it s, okay?
And now let's say that you write an if statement where
you say, "if(s!==undefined)," open-curly,
well in that block,0 we know that s is not undefined,
so we can actually dynamically change the type of s. So
s will appear all of a sudden to just
have type string within that guarded block.
But in the else statement we know,
of course, that well then string,
s must be undefined,
so in that part of the code,
s would have the type undefined.
And so it's in a sense the ability to
dynamically change the type of variables
based on the expression constructs
that surround those variables.
It harmonizes super well
with the way that you think about your code, right?
Because you know that I've just said if
s does not equal undefined, right?
Of course, it's not undefined then and, of course,
I don't need to then
get an error about nulls or whatever.
And that's how you guard your code,
and the process of doing
that is called Control Flow Analysis.
And it's basically is based on the compiler knowing
what every statement construct does to every variable.
And, of course, it goes deep
into patterns like the and "&&" and
the "II" operators and the type of
checks, "if(type of x===string).
Now we know that x is going to be a string in here.
We can also give you an error if you try to check
against something that x couldn't possibly be.
For example, if you've already
checked whether x is a string and
then you later in the code try to check again,
we'll just tell you, "You already checked that."
>> So this is more help with
the tooling to let us know in the editor
that these things are going to be used in a certain way?
>> It's really sort of the next level
of type checking, right?
This is the key enabler
for null and undefined and non-nullable types.
We could not do that without
Control Flow Analysis because it would
just be a major pain in
the neck if we did not narrow the type of
your variable after you have
excluded null or undefined. Do you know what I mean?
>> Yeah.
>> So it's like this symbiosis of union types and
Control Flow Analysis that give you
the ability to have non-nullable types if you will.
>> Number five, pyramid of doom,
callback hell, promises,
asynchronous programming, help me out TypeScript.
>> So the latest versions of ECMAScript now
include the ability to write
async functions and do a weight on promises.
This is actually a feature that originated in C#,
and it's been very,
very popular in C#,
and we then proposed a similar design for
ECMAScript through the ECMAScript
standardization process.
And that got accepted into I think ECMAScript 2016.
And, of course, TypeScript
supports down-level transpolation of
asynchronous constructs because most browsers
have not yet caught up.
>> Right.
>> With this feature, but if you're using TypeScript,
you can pretend that you're on
the latest version of ECMAScript, right?
Now, with async, you get the ability to await promises.
And in a sense,
what happens when you await a promise is that
the compiler turns the remainder
or the runtime turns the remainder of your function
into the callback that you
otherwise would have had to pass.
So it gives instead of pyramid of doom,
you get to just write nice sequential code.
You get to use all of
the control flow constructs that you use,
that you know, from sequential programming, right?
Or traditional non-async programming
like while loops and for loops and whatever which.
You try to write a while loop
around something that has a callback, right?
Then you have to
write at a state machine, and it's horrible.
Humans are very, very bad at writing state machines.
But compilers and runtimes are very good at it.
So, in a sense,
this is like taking
that hard part out of the equation that allow
you to think of the code just
in a straightforward synchronous fashion,
but then every time you use the await operator,
we will arrange to yield
and then control can later come back and continue
running in your function without you having to
do all of the hard work of arranging callbacks,
lambdas, or nested functions or what have you.
>> You promise?
>> Nice.
>> Question from Twitter.
We get this question a lot actually about you.
What's your favorite language that you've been a part of?
>> So like asking,
"Who's your favorite child?"
You can't answer that question.
I love all of them.
I started out in Pascal,
with Turbo Pascal, and then move to Delphi,
which basically like Object Pascal
or Turbo Pascal with objects and modules.
And then when I came to Microsoft, I worked on C#,
of course, and now I'm working on TypeScript.
And they've all been fun.
I mean, I'm fortunate enough to have been
doing this now for almost 35 years,
and it's always been my hobby.
So I've never really held the real job.
This is the way I talk to people about what I do.
TypeScript is found big because
it's different from the others,
in that it's a transpiler,
and it's a type system really more for tooling sake
than for code generation sake, for example.
I mean it's used to be that TypeScript's type systems
are important because then they
would enable your code generator
then to understand what kind of code to generate,
but that's not really what we're doing with TypeScript.
We're doing type checking
for tooling and productivity sake.
It also allows you to go in different places.
So TypeScript has a lot of novel features and
its type system that I
actually haven't seen in any other programming languages.
So it's always fun.
You don't get a lot of
greenfield opportunities like that,
so I've been very happy to work on it.
I write more code now that I've done in
the past decade probably, so I have a lot of fun.
>> We appreciate it.
>> So do I.
>> I'm John Papa.
>> And I'm Anders Hejlsburg.
>> We just learned five
coolest features about TypeScript.