Before we begin our TypeScript journey, it is useful to take a look back at JavaScript and where it comes from.

Before we go any further, we should take some time to briefly discuss the history of JavaScript and how it has evolved in recent years. You probably know that JavaScript is the core language of the web. It's actually a very versatile language that supports different programming paradigms such as imperative, object-oriented, functional, and event-driven programming.

As mentioned in the previous section, JavaScript can now be used almost everywhere, but that was not always the case. The language was initially designed by Brendan Eich (https://brendaneich.com) around 1995 (more than 20 years ago!) for the Mosaic web browser. The first version of the language was written in 10 days (!) and was called Mocha, and was later renamed to LiveScript. The whole story is very interesting and well worth reading.

It is important to realize that JavaScript has been here for a very long time and has also evolved a lot, especially since 2005, and more than ever since 2015.

Another important thing to understand is that behind JavaScript, there is actually a language specification called ECMAScript, standardized by Ecma International in ECMA-262 since 1996. Though reading about it will be time consuming for now and not mandatory in order to understand further topics, you should know that this specification governs what JavaScript is and how it evolves. New language features and API proposals all go through the Ecma TC39 technical committee, which decides which ones are mature enough to make it into the specification. This all happens in the open, so don't hesitate to go and check it out.

The version of JavaScript that most developers around the world are familiar with is ES5, which was released in 2009. It included strict mode, accessors, syntax changes, meta-programming, and, most importantly, support for JSON.

Since 2015, ECMAScript, and thus JavaScript, has rapidly evolved. The specification now has a yearly release schedule, meaning that a new version is released each year. Thanks to this evolution, each year, all of the language change proposals that are mature enough get included in the new version of the specification. This follows a trend that we can see throughout the industry to increase the pace at which things evolve. It is very disruptive for large enterprises but is great for innovation.

In 2015, ECMAScript 6 was released and was later renamed ES2015. Since then, ES2016, ES2017, ES2018, and ES2019 have been released in the respective years.

Make sure to stop by Dr. Axel Rauschmayer's blog (http://2ality.com) to learn more. Comparatively, ES2015 was incredibly big compared to the following iterations.

As you can imagine, it takes time for browser vendors and JavaScript engine developers to integrate newly standardized elements of the language. With ES2015, this meant that things such as let, const, classes, and many other features could not be used directly. This led to the increase in popularity of transpilation using tools such as Babel or TypeScript. Basically, the idea is to be able to use the newest features of the specification in your code right now and to transpile it so that it can run in environments that don't support those features just yet.

Now that you know a bit more about the history of JavaScript, and before we finally dive into TypeScript, we need to learn about the importance of knowing JavaScript, with its good and bad parts.

As you now know, JavaScript was initially created in 10 days, so it had issues, some of which are, unfortunately, still here today. The TypeScript compiler will protect you from some of these issues but it can't change things that are fundamental in JavaScript such as how numbers are represented.

Here are a few examples of things that are surprising (to say the least) in JavaScript:

• JavaScript variables declared with var are function-scoped. For example, if you declare a variable in a for loop, then that variable declaration actually gets hoisted (that is, moved) to the top of the enclosing function. Block scoping is only possible since ES2015 with the let and const keywords (which you should always use instead of var!).
• JavaScript's number type supports only 64-bit doubles (IEEE 754 double precision standard). Integers are represented as floating point variables; that is, some precision is lost once numbers get too large. Here's an example where it breaks: 9999999999999999 === 10000000000000000 evaluates to true!
• typeof(NaN) evaluates to number.
• true == 1 evaluates to true because == does type coercion (that is, converts the type).
• null == undefined evaluates to true.
• 42 == [42] evaluates to true: in conclusion, always prefer === and !== over == and !=.
• 0 == '' evaluates to true.
• null == undefined evaluates to true.
• alert((![]+[])[+[]]+(![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]);: Displays an alert box with the message fail. Check out the JSF*ck website to know more about this one. Needless to say, hackers love these kinds of things!

The list could go on and on but we will leave it here. As mentioned earlier, TypeScript transpiles into JavaScript, which means that you need to have a good understanding of JavaScript, even if you program in TypeScript, and have knowledge about its good and bad parts.

Douglas Crockford has written a lot and given many talks about JavaScript. He has covered at great length JavaScript's weaknesses and strengths and we really recommend you watch some of his talks and read his book. You'll have fun while doing so and you'll discover many things that you should avoid at all costs in JavaScript as well as some that are really worth using. For a quick review, you can also check out the following summary: https://github.com/dwyl/Javascript-the-Good-Parts-notes.

Mr. Crockford has also created JSLint, a JavaScript linter (that is, a code quality checker) that helps to avoid dangerous syntax and detect possible mistakes before it is too late. A similar tool exists for TypeScript and is called TSLint.