Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 1046 of the free egghead.io lessons, plus get TypeScript content delivered directly to your inbox!

Existing egghead members will not see this. Sign in.

Catching JavaScript Mistakes with TypeScript

5:13 TypeScript lesson by

The TypeScript compiler is a powerful tool which catches mistakes even in vanilla JavaScript. Try it online at the TypeScript Playground, zero setup required.

Get the Code Now
click to level up

egghead.io comment guidelines


The TypeScript compiler is a powerful tool which catches mistakes even in vanilla JavaScript. Try it online at the TypeScript Playground, zero setup required.


An excellent screencast. Now that Angular 2.0 is being written in Typescript, it is important to know it well. Question for you: when would the modern browser start directly supporting TypeScript and we can do away with intermediaries. The reason I ask is that for awhile, I used Coffee Script. Soon I realized that debugging my code was a hassle, so I went back to the plain Javascript. If Typescript can run natively in the browser then it becomes a compelling story, since the benefits are huge.

In reply to egghead.io

Hi Bharat,
I would estimate a minimum of 5 years before multiple browsers would support TypeScript. It would first need to be at least a proposed ECMAScript standard. ECMAScript 5 was finished in 2009. ES6 has been in the works for about 5 years, and hopefully will be complete this year.

In reply to Bharat

But it sounds like your main concern is debugging a transpiled language. I'm curious, when you worked with CoffeeScript, did you debug the original code using source maps? Or were you debugging the generated JavaScript?

The TypeScript debugging experience is enjoyable for several reasons:
1. There's good support for source maps from modern browser debuggers, because the landscape of languages transpiling to JavaScript is huge now.
2. IDEs like Visual Studio and Webstorm/Intellij can debug TypeScript source in their own debuggers.
3. TypeScript generates clean, normal-looking JavaScript.
"Microsoft's TypeScript may be the best of the many JavaScript front ends. It seems to generate the most attractive code." -- Douglas Crockford, author of JavaScript: The Good Parts
If you should need to debug the generated JavaScript at times, it will be easier to follow than the output of some other languages.

In reply to Bharat

Hello Robert,
Thanks for your thoughtful answers, I appreciate it. Normally, I get an email from Egghead that a response has been posted to my question or topic of interest, so I can respond in a more timely manner. This time, I did not get one. Hence the delay.
Anyway coming back to the discussion, I have not used source-maps to debug the CoffeeScript code. I am a full-time Ruby on Rails developer who uses Javascript/Coffeescript 'Sprinkles' to make my server-pages more interactive. Now, I am venturing into pure client code talking to a server API, so my knowledge of SPAs is somewhat limited. I am maintaining a Rails application with 'heavy' sprinkles of Coffeescript code. I find less and less attractive to maintain it especially while debugging. I am converting most of my Rails Backbone heavy Javascript pages into Angular/Rails and while doing so, I am also replacing Coffeescript with Javascript. I got interested in Typescript after watching your short screencast and also ng-conf announcement of the shared partnership between Microsoft and Google in using Typescript as the development platform for Angular 2.0.
I would love to see more screencasts from you on how to configure WebStorm 10 which was just released to write Typescript code and more importantly, debug it. Also, more screencasts on how to 'deploy' the generated/transpiled javascript code in applications would be very useful too.

In reply to Robert

This video will use only Vanilla JavaScript, but TypeScript will still catch many common JavaScript mistakes. We'll use the TypeScript playground which runs the compiler directly in your browser.

I've prepared valid JavaScript that runs with no exceptions, but still contains mistakes. Let's paste the JavaScript into the TypeScript playground and see what happens. Look at all the mistakes TypeScript found.

Let's go through them one by one. Here TypeScript said, "Duplicate identifier title," because there are two title properties in the same object. Let's fix this by deleting the second title. TypeScript said, "Property IMDB does not exist," because the IMDB in our moving object is in all caps.

Let's fix this by changing the reference to match. TypeScript again said, "Duplicate identifier," this time because the function argument X is repeated. It should be Y, so let's fix that.

TypeScript said it cannot find name X, this means I forgot to add this, so JavaScript would've been looking for X on the global scope. Let's fix it by adding this before each property. The next error is interesting. TypeScript cannot find the get tie method on type string.

A string? Where did that come from? True story. The date function returns a string if we forget to use new. Let's fix that, so get time can work properly.

TypeScript says, "Property get ailment by ID does not exist." It once took me 20 minutes to realize I made this mistake. Our edit caused TypeScript to find a new error. Type bullion is not a sign of all to type string.

Why does TypeScript think our answer variable is a bullion? Because that's what the built in confirm function returns, however, we want the user to type an answer, not just confirm or cancel. Let's use the prompt window function to fix this logic.

TypeScript found another typo. To fix seems simple, but now we discover a larger problem. Type void is not a sign able to type EV event>any. This arrow is shorthand for a function. In ECMAscript 6, and TypeScript, the error message is trying to tell us that documental unload expects to be assigned an event handler reference.

However, it's receiving a void type. The problem is that we're executing the handle load function now instead of passing the function itself. This is a classic mistake I'm sure many of us have made at some point. Let's fix that.

Our next error will reveal a mistake in the opposite direction. TypeScript says, "The greater than operator cannot compare a function with a number." Math or random works much better when we actually call it. let's make that coin toss a fair one. This error message looks complex, but let's focus on the function return text following the arrows.

TypeScript expects this function to return a bullion, but it's returning a string. Why a bullion? TypeScript knows that when we test every element of an array with the every method, the tester function must return true or false. In our case, we want to test if every coin toss equals heads.

Unfortunately, we used the wrong equals operator. Let's fix that so our test works properly. TypeScript catches us trying to find the length of a bullion. What we're trying to do is to log the number of coin tosses to variable named all heads, is a bullion describing all of the tosses, but the actual coin tosses are in the tosses variable, which TypeScript knows is an array of strings.

Let's swap out that variable to resolve the error. Our final example, will demonstrate one of my favorite TypeScript discoveries. The error message says, "Client X does not exist on keyboard event." Where did that come from?

Hovering over the event parameter, we see that TypeScript expects it to be a keyboard event, but how? Because our event type string is key down, TypeScript infers a keyboard event should be passed to the listener, but we want the mouse coordinates. Let's use the mouse down event type.

Now TypeScript knows the event is a mouse event, and it's safe to call client X and client Y.

Joel's Head
Why are we asking?