WEBINAR

Hi, everyone, and welcome to this session on enterprise-ready JavaScript with TypeScript. My name is Dan Magid, and I’m the CEO of Eradani. In my job, I spend much of my time talking to customers about their efforts to use new technology and open source to extend their IBM i application. Because of its overwhelming popularity, and thanks to the great support IBM is providing, many of the companies I talk to are adopting JavaScript to build their new web application. However, JavaScript was originally built for creating small scripts that ran inside a browser. Using it to build enterprise-type applications creates a variety of challenges. TypeScript was developed in order to address those challenges. The main presenter today will be Aaron Magid. Aaron is the VP of Open Source Technologies at Eradani, and Aaron has been writing JavaScript applications for a variety of Eradani customers and has been aggressively moving to TypeScript in order to make those applications more scalable and more maintainable. He’s going to introduce you to TypeScript and help you to get started in using it. So Aaron, I’m going to turn things over to you. All right.

Thanks for the intro, Dan. So like Dan said, my name is Aaron Magid. I am the head of Open Source Technologies at Eradani. I also do a lot of work in our services arm. I head up a lot of our services projects that we do for IBM i customers to help get them onto Open Source Technologies. So in this webinar, what we’re going to do is we’re going to show you how you can make your JavaScript applications enterprise-grade by using the tools that are in the TypeScript ecosystem. And we wanted to give this webinar because in our services work, we see a lot of IBM i shops that are just getting started with Open Source Technology. And that is really exciting to see a new shop that is getting in, that’s using Node.js, that’s getting up and running. But a lot of times, that also comes with a lack of experience. And so we tend to see, in a lot of these shops, practices around the Node.js development that are not going to serve a company in the long term. And this actually gets into what Dan was saying earlier about JavaScript being written for small web scripts. JavaScript was originally built to be a simple language that could handle extremely unpredictable environments. So APIs and web pages with user input are incredibly unpredictable in terms of the data you’re going to get, the errors you might run into. It really is correctly described as the Wild West. It really is sort of a crazy environment. And one of the effects of that is that in order to handle environments like that, JavaScript has to be extremely flexible. And in implementing that flexibility, it doesn’t really do anything to guide new developers in how to use it effectively. So in the hands of a seasoned developer, it is an extremely powerful tool. But it also doesn’t do much to protect you from yourself. And so when you’re just getting started with it, it really is important to have a tool like TypeScript that can help you use good standards and show you what you should be using this language for so that it can really protect you from making the mistakes that the rest of the JavaScript community has been learning over the last 20 or so years that we’ve been using it. So is TypeScript really only for beginners? No, it’s actually not. So as Dan mentioned, I am pushing with my services teams, I am pushing TypeScript across the board. When you get into enterprise applications, it is incredibly helpful. And personally, I use it for everything. Absolutely every project that I do with JavaScript is a TypeScript project. So it’s not just for beginners. I want to be clear about that. But especially when you’re just getting started with it, it is that much more important. Because one of the things that we’ll do is make sure that JavaScript doesn’t bite you with some of its less opinionated tendencies and some of its more flexible options. So in this webinar, we’re going to go through five major points. First, we’re going to talk a little bit about JavaScript, we’re going to give you a quick intro and tell you a little bit about what it is and why you care about it, why the IBM i is caring about it, why everybody in the world seems to be talking about it. We’re going to talk about some of its challenges and some of the pitfalls that especially new teams and large teams tend to run into when they use this language. We’re going to give you an intro to TypeScript, we’re going to tell you what is TypeScript, how do you get it set up, why do you care about what it is, and how is it going to help you mitigate some of those problems that you can run into when using JavaScript. We’re going to show you how to get started with TypeScript, we’re going to set it up, we’re going to show you how to configure it and how to work with it so that you can get started immediately after this presentation on your own. And then we’re just going to take a little quick look at some of the more exciting TypeScript tools that are available in the ecosystem. So first of all, JavaScript, why do you care? Well, the most important reason, at least in my opinion, to care about JavaScript is because it is the most widely used language, the most popular development language in the world, and it has been for several years. This graph is taken from the GitHub State of the Octoverse study, it’s a massive study of 47 million developers, I believe, and which languages they’re using in their projects, and JavaScript has been absolutely dominating for several years. And so one of the major reasons why it’s such a powerful tool is just the sheer number of people using it. They’re actually coming up on 12 million developers very soon, we’ll hit that number. So very, very popular language, which means lots of tooling and a really sophisticated environment with lots of options for you. 

So Aaron, I noticed down there towards the bottom, there’s that really steep diagonal line there going upward that ends in TypeScript. Yes, yeah. So TypeScript, again, the subject of this webinar, is a fairly recent innovation. You can see that it comes onto this graph in 2017, and then just shoots up. And it has continued shooting up since this particular study was done. TypeScript, when you’re talking about JavaScript, an important thing to know is that TypeScript is just an extension of JavaScript, it’s really just a dialect of the same language. And so you really need to put them together when you’re talking about JavaScript. But it is really important to note that TypeScript is exploding, and it’s being used all over the world. Again, not just for beginners, this is being used, it really is considered the enterprise JavaScript solution. And so it’s been gaining popularity like mad for the last couple of years. And that’s also true in the IBM i world. In the IBM i world, we’re seeing a huge growth in open source technology usage. And most notably, we can see that with Python and Node.js, they are exponentially increasing over the years in terms of their adoption. And again, one of the reasons we want to give this webinar is because as people start implementing Node.js in their shops, they’re going to start running into those problems that the Node.js world, the greater Node.js world has been dealing with for roughly the last 20 years. And they’re going to start needing the solutions that we’ve come up with for that. And one of those biggest solutions is TypeScript. So just to give an intro to JavaScript and a little more information about it, again, JavaScript was designed to provide a simple, lightweight coding language for dynamic web pages. It’s actually kind of funny, the original JavaScript language was, the original engine was written in 10 days, just to show you how simple the language originally was. Again, designed for these asynchronous event driven environments, very, very powerful for web APIs and user interface applications, things where you’ve got lots of things happening all over the place in the environment. I do want to point out, JavaScript is completely unrelated to Java. They are entirely different languages. I want to point this out because I see this in a lot of shops that I talk to people, you know, I mentioned JavaScript and people say, and they start talking about Java. The only reason that these two languages share any similarity in their names is actually because of a 20 year old marketing deal between Netscape and Sun. Aside from that, that is where the similarity stops. I mean, these languages could not be more different. So again, JavaScript, Java, very, very different. We’re talking about JavaScript here. And one of the biggest differences between those two languages is that JavaScript uses a weak dynamic typing system. So what that means, and again, this is really important in an unpredictable web environment, it means that JavaScript is willing to accept all kinds of data. And it’s willing to shift between data very, very freely. And it’s very flexible with what information you give it. Because when you’re working with a web API, you don’t know what kind of data you’re going to be getting. And you’re going to get poorly formatted data all the time. So the language itself is built to handle that. Now, the downside of that, as we mentioned, is that when you start working in mission critical core applications, which is a fairly recent movement, really the last 10 years for JavaScript with Node.js, when you start working in these large applications, that weak dynamic typing can start to really hinder your progress. If you’re working with a large team, it can start to create a lot of difficulties and a lot of friction between developers, because it’s not all in the head of one developer anymore, which is really how it was designed to be run. And just some information about the JavaScript community. This is more about why you care. And it actually adds to the unpredictability of the environment. JavaScript is the fastest moving community on the planet. I mean, this community has just under 12 million developers around the planet. It’s got a little over one and a quarter million open source packages available for the language with 20 billion installations every single week. And the thing is, in the JavaScript world, a lot of what you do is you wire components together. You don’t actually write all that much brand new code when you’re working in a JavaScript application. A lot of what you do is just grab components and put them together. And that adds to the unpredictability of the environment, again, making it even more important to have a solution like TypeScript to help you keep your application maintainable and scalable. So let’s dive into the use case for TypeScript. So JavaScript, again, is weekly typed. What does that actually mean? Well, what it means is that it’s as permissive as possible with your data types. So this is a very short sample of some JavaScript code. What we do in here, we create a variable, we store the number five in that variable. We create another variable, we store the text, the string, ABC in there, and then we add them together. And the thing is, that operation, realistically, doesn’t really make much sense, right? When you say, I’m going to add a number to some text. But JavaScript does its best to interpret what it is you want it to do. And what you end up with is, behind the scenes, the number five gets converted to text, and then the two strings get concatenated, they get stuck together. And there are a lot of powerful features around this week typing. That’s an example of type coercion that JavaScript does to try to cast things for you into the types that they need to be for the operation you’re trying to do. Another really big concept in JavaScript is the idea of truthy and falsy values. In a lot of languages, if you want to do if something, do something else, your condition has to be true or false. In JavaScript, that’s not the case, right? As you can see in this code, in the second box, I can create a variable, set it to the number five, and then I can say, if that value runs some code, and that will actually run, that will evaluate to true, because the number five is considered loosely to be a truthy value. And similarly, if you look below, the variable that is not initialized, that variable D where I don’t give it a value, that it gets skipped, because the variable is not initialized. And that’s considered a falsy value. So these are the kinds of things that you can do with JavaScript, which is very powerful when you’re in an API environment where data might be missing, data might be poorly formatted, but it also can bring up a lot of issues. And again, JavaScript will push as hard as it can to figure out what it is you want it to do. You have to really piss JavaScript off to get it to actually give you invalid responses. And that’s actually what I’m showing here with this last box is I can add numbers together. I can even multiply a number by text, and it will do its best to try to figure out what I mean by that. I can add two to true, and it’ll give me back three. It actually adds them together somehow. And it’s not until I say, multiply some text by false, that it finally gives me NAN, which is a built-in JavaScript constant for not a number. It’s basically JavaScript saying, OK, fine. I have no idea what you want me to do with this. So I’m giving up.

Again, you have to go really far to get JavaScript to do that kind of thing, which is, again, very powerful in APIs. But if used incorrectly, it can also cause a lot of problems. JavaScript is also dynamically typed in addition to being weakly typed. And that means that types of variables are determined when the program runs, not before. In a lot of other languages, you specify that this is the type of an object. It’s this particular class. These are the methods it has, or it’s a number, or whatever it is. And then you have a compiler or a set of tools that are able to say, OK, I know what this is, so I know what you’re able to do with it. In this code, what we do is we create a variable. We store the number 5 in it. Then we decide, OK, we want to change that. We’re going to store an object in it. And then we try to call a method on that object that does not exist, that get non-existent property. I just made up that name. You can see it’s not in the object in line 3. It does not exist. But my editor does not give me any error messages about that. It’s perfectly valid JavaScript. But when I run that, it’s going to explode in my face, and it’s going to give me a very angry error message. So what we’re looking for is, what if we could have a tool that would give us something more like this, where I say my variable is 5. I store an object in it. First of all, it gives me an error there because I can’t change the type of a variable randomly just because I want to. But then it actually tells me that get non-existent property function doesn’t exist, and it actually gives me an error message proactively while I’m working on it so that I don’t have to get into running the code before I find the problem. And again, the very logical problems come from that kind of thing. If you have this kind of code that’s buried deep in an edge case in your application, that kind of code ends up in production, and you end up with bugs that are hard to track down. Very, very big problems if they’re not handled correctly. So the word for what we’re looking for is a strong typing system. Strong typing system comes with a series of really, really important benefits. Number one, it helps you navigate your code very easily. When you have a strong typing system, you can get tools in the ecosystem that understand your code while you’re writing it. And so they’re able to navigate through and link things together and show you definitions and things like that. Aaron, isn’t RPG a strongly typed language? Yes. Absolutely. Right? RPG is very – that’s a great example. RPG is very, very rigid about the types that you can use, and actually, you will get significant problems if you’re – right? It will tell you if you use something incorrectly. RPG is actually a very interesting case, but I’m not going to go into a lot of depth about its parameter structures. But you do get this kind of thing when you’re working with an RPG program, right? This error checking without execution, right? A lot of problems, if you write an RPG program that’s invalid, you will get compiler errors most of the time, and you’ll be able to handle those before you actually run the code. With JavaScript, native JavaScript, you don’t get that. You get nothing. I mean, it’s until you run the code. You have no idea what’s going on. These kinds of systems also make it very safe to refactor your code, or much more safe, because again, you change your code, you change working, stable code, and your typing system will tell you most of the common bugs that arise from that kind of thing. It will detect for you. It also makes it much more consistent in your teams. When you’re using code, you’ll use it consistently because your editor will force you to use it consistently. It will give you error messages if you’re not using your code correctly. And that becomes very, very important with large teams especially, right? When you’re working with just one developer on a small script, you can write the code, keep it all in your head, it’s fine. When you have 100 developers, or honestly, even two developers on a project, one person writes code in a particular way, the other person needs to know how to use that code. And you do not want to have to guess when you use, when you do those kinds of things. That’s how you end up with hard to find bugs. So if I had a couple developers, or several developers working on the same programs, could they use variables differently? In other words, could one developer use a variable as a string and another use a variable as a number? Absolutely. And I will show you an example of this later in the presentation. You absolutely can do that. You can pass in variables that are whatever you want. You can call functions without passing in any parameters. You can just neglect them. And JavaScript will do its best to figure it out. And that typically does not end well. Important things to be paying attention to. And actually, this actually reminds me of a project that I was working on a while back. I was working on an IoT application. And this exact problem, we wrote the application in JavaScript a couple of years ago. We wrote the application in just JavaScript, not TypeScript. And we ended up with all kinds of problems when I left and handed off the project to the developers, to the other developers at the company. Because up until that point, I had been the only developer. And I wrote a whole ton of code that was written the way my mind works, the way that I think it should work. And when the other developers came in, they had to read my source code to try to figure out how to use my code and how to actually interact with it. And that caused all kinds of friction for their team as that was passed on. And those are all problems that we would not have had if we had TypeScript in that application. Nobody would have handled that for us. So that’s just a really important thing to be watching out for. So we talked a lot about TypeScript. What is it? TypeScript is strongly typed JavaScript. It is a superset of JavaScript. So it’s statically typed, not dynamically typed. It is strongly typed, not weakly typed. And it is JavaScript. So when we say TypeScript is a superset of JavaScript, what we mean is all JavaScript code is valid TypeScript code. TypeScript just adds the ability to put type restrictions onto your JavaScript code. And that is a really, really important characteristic of TypeScript, especially when you’re talking about migrating an existing application, because you can do that. You can take a JavaScript application and apply TypeScript as much or as little as you’d like, or gradually, to help transition it over to exactly the level that you want. And again, you can turn on and turn off features until you get the environment that’s best suited to your system. Again, trying to maintain that flexibility of JavaScript while also making it safer for your team. Now an important thing to understand, TypeScript itself is not executable. TypeScript itself will not run. But what happens is you take the TypeScript compiler, it compiles to JavaScript, and then that JavaScript can run anywhere that any other JavaScript can run. So web browsers, Node.js, any other systems that you have. And just going back to this graph for a second, TypeScript is becoming more and more popular over time. TypeScript is dramatically rising in the language rankings, because all of these JavaScript shops that are up there at the top of that popularity are finding out that as they get into big teams, they get into their core applications, they really need something that can help them. It can help them keep their applications maintainable and safe. So again, as I mentioned before, TypeScript compiles to JavaScript. So this is an example, a screenshot of my Visual Studio Code editor. And in here, what you can see is on the left side is my TypeScript code. And what I’ve got here is a TypeScript class. So I created a class that actually makes object-oriented programming a lot easier than it is with JavaScript’s built-in features around that. And what I do is I create this class, I give it some members, I give it a width and a height, and I specify what those types are. That’s what that colon number is in lines two and three. I’m saying, all right, I have a width member, I have a height member. Each one of those must be a number. And that’s effectively all that I have to do for the TypeScript specification. And when I run the TypeScript compiler, the first thing it’s going to do is it’s going to strip out all of those type annotations, because they’re not valid for JavaScript. And it’s going to create executable JavaScript for me. Now, one of the other things that I want to point out that is a really, really powerful feature of TypeScript, because it is compiling to JavaScript, it’s technically transpiling to JavaScript, I can tell TypeScript what version of JavaScript I want it to transpile to. So if I’m working with an old web browser, and I need to be working with, I think, as early as ES3, ES3 is a really old specification for JavaScript, I can tell it, I want you to compile for ES3 compatibility, and it will compile my TypeScript code over to the code that’s on the right. This is ES3 compatible JavaScript, which is before JavaScript actually had classes. It actually, at that point, did not have any support for classes. Its object-oriented support, object-oriented programming support was very shoddy. But I get to write the code the way I want to write it in the object-oriented way, or in a functional way, or whatever it is I want to do, and it will generate the code that actually runs and actually works on the platforms I want to work with. And I can change that to compile to, you know, to ES2019, which is the latest active specification, or actually, and this is where it gets really cool, I can tell it to compile to ES2020, which is not available yet. The 2020 specification of JavaScript is actually not official yet, but a lot of those features are available in TypeScript. If I write the TypeScript code, the Microsoft team that manages TypeScript has written their compiler such that it will compile those new features that are not available yet in normal JavaScript to their closest implementation in whatever JavaScript version you want. And so what’s really cool about that is I can start using new features of the language before they’re actually available, which is just wonderful. I can get started with them very early. So what I’m going to do is show a couple of examples now of how TypeScript can really help you with your JavaScript code. And so I’m going to switch over to my Visual Studio Code editor. And the first one that we’re going to look at is that JavaScript code that we were looking at before. So, right, this is the code that we were looking at. We, you know, we create our variable, we assign it, we reassign it to an object, and we reference a non-existent property on that object and call it as a function. This will give us an error, but if you notice in the editor, there are no compile errors, there are no warnings, there’s nothing of any kind telling me that something is wrong. Now, if I copy this, literally just copying the code over to a TypeScript file, I immediately get warnings about the code that I’ve written. There’s two warnings in particular here. One is that I created a variable that should be a number, and I’m then assigning an object to it, which is not a valid thing to do, again, static typing and strong typing in this language. I’m not allowed to do that kind of thing. And so it tells me that. It says type, that object structure is not assignable to a number. I’m just, I’m not, that those aren’t, that doesn’t make sense. I can’t do that. So that, you would not get a message like that in regular JavaScript. No, and you can see that, you can see that right here on the left side. The JavaScript on the left side is perfectly happy with my crazy code. And then, more importantly, I get an error here. It says property, get non-existent property does not exist on type number. So it’s saying, okay, I know that A is a number, and I know that that function does not exist. And so it’s telling me with the red underline, this is not going to compile. And if I actually ran the TypeScript compiler, it would fail, and it would reject my code, and it would tell me, this isn’t okay, you can’t do this. So this is a really important feature of this system, especially when you think about misspellings, right? I thought that get non-existent property did exist, but I thought it was get non-existent properties, right?

In the JavaScript, that’s perfectly fine. It won’t care, because it doesn’t know what get non-existent properties is anyway. In the TypeScript, if this existed and I spelled it wrong, it would say, this doesn’t exist, and actually will often give me a suggestion as well, if I’m close enough. If I just get a couple of letters wrong, it’ll actually say, this property doesn’t exist, did you mean this other property that actually exists on the object? And so it’s a really, really helpful tool when you’re working with this kind of a system. And again, that’s something that I run into all the time when I’m writing TypeScript code, because you’re running through the code, you type something, it’s wrong, you misspell something, you use a capital letter when it’s supposed to be lowercase, and TypeScript saves you from a whole bunch of hard to find bugs that you would have had if you were just using native JavaScript. So again, very, very important, not just for beginners, every single day that I work with this technology. So given that first example, what I want to do from here is show you how to set up TypeScript on your system and get ready to use it, and then we’re going to go into some more examples so that you can follow this on your own if you’d like. So in order to install TypeScript, we’ve got a very long installation process where I come out here and I start off with npm install dash g TypeScript, and what that’s going to do, it’s going to go out and I install this the same way, the steps the same way that I do any other node module, and I’m going to install the dash g as globally because I’m getting a tool for all of my projects, not just for the one I’m working on. And I’m going to tell it, I want you to install TypeScript, it’s going to go out, and it’s going to go download TypeScript, and it’s going to set it up. And then I’m done. I have TypeScript now. That is everything that I needed to do to get TypeScript set up on my machine. So if you’ve been following along, congratulations, you have TypeScript now. So these tools are very, very simple to get started with, they’re very easy to get. Now we’ve got TypeScript installed. What we typically are going to want to do is configure it, or at least take a look at the configuration file. So I’m going to open that up. Now the TypeScript compiler has a ton of configuration options that are available to us. And this configuration file is generated for you when you tell it to initialize a new project. There’s a whole bunch of options in here for controlling the exact behavior of the TypeScript compiler. But you typically can go with the defaults, or find one online, or typically if you get a template application for Node.js, it’ll come with a tsconfig file, which is the TypeScript configuration. And just a little thing that I want to point out, this is where I specify the language. So I have my project right now compiling to ES2015, that’s a very common language to compile to because it had major changes to the JavaScript language. But I could change this right here to ES3, or ES2019, or whatever I want it to compile to. And it will do that, it will compile to whatever version I want it to. So now that we’re set up with TypeScript, we’ve got our configuration. When we want to actually compile our project, this is the command, tsc, and tsc stands for the TypeScript compiler. And when I run that command, the code that I’m running it over actually has no errors, and so I get no output. And that’s actually something that’s often confusing to people when they start out with TypeScript. When there’s no errors, it doesn’t tell you anything, it just silently finishes. If you get any output, that means there’s something wrong. So I’ve compiled my code, and I now have JavaScript from that TypeScript code that I wrote. So let’s take a look at a couple of other examples. Now that we’ve got TypeScript set up, and we’ve got it configured, and we’re ready to move, what I’m going to do here, I’m just going to blow away those changes, I’m going to take a look at this particular function, because this one is an example of just how powerful working with TypeScript can be in helping you write good code. So I had a JavaScript file there, there were no errors in it. And actually, let me hop over there again for a second and just show you what this is. So there are no errors in this file, there’s no warnings coming out of it at all. And what this function is going to do, I just wrote a quick little function that’s going to take an array of numbers, and it’s going to add them up and give me back the sum of those numbers. Very simple function, should be straightforward. Now what I’m going to do, again, no errors, what I’m going to do is I’m going to come over here and I’m going to paste it into a TypeScript file. And immediately, TypeScript starts complaining at me and telling me, there’s something you’re not doing right in this file, there’s something I can’t figure out about it. So let’s roll over that, and I can see that TypeScript is integrated with my Visual Studio Code editor. Actually, just a brief aside that’s interesting about Visual Studio Code, Visual Studio Code is actually written in TypeScript, it’s a native desktop application that is written entirely with TypeScript. So anyway, just a little shout out to a major TypeScript project. So what it’s telling me is, you didn’t give me a type specification for this, so I don’t know what it is, so I can’t actually help you, I can’t actually do any checking. So I’m going to give it a type specification, just so that TypeScript can actually start helping me here. And I’m going to give it optionally an array, that’s the type that I’m going to give to this. And as you can see, as soon as I gave it the type specification, it went back through and it looked at my function again, given that new information, and it started saying, wait a second, this isn’t right. You are, you’re way off here, something is definitely not right with this function. So let’s take a look at what’s wrong with it. So if I roll over here, it’s telling me numbers is possibly undefined. Now what that’s saying is up here, I made this parameter optional, which is very common in JavaScript applications, because I don’t really know what I’m going to get, I want to be permissive. And so if I get nothing, I want to be able to handle nothing. So in here, it’s saying this is possibly undefined, and if it’s undefined, trying to run a loop over something that doesn’t exist is going to get you an error. So I’m going to give you an error now at compile time. So the way that I can fix that, there’s actually a couple of ways, but the way that I’m going to go with is to put a guard clause in here, which is a very common programming pattern to say, if numbers, and again, this gets back to that truthy falsy thing, which is basically going to say, if the numbers variable exists, if I have a value, then do this code. And you can see immediately, it quiets down about this. And the type specification for numbers here actually changed before it said array or undefined. Now it says array, because it knows that if it gets into this code, numbers was not undefined, because if it’s undefined, you’ll fail that if check. So it’s really actively parsing my code and figuring out exactly what these types are at every line. And so that’s really, really a powerful tool. And that’s actually something that you don’t get in most other strictly typed languages. In some ways, this is more powerful than the type checking you get in languages like Java.

So just really powerful tool. Now it’s still complaining at me. So I’m going to take a look at this, and I’m going to say, OK, let’s see, what’s wrong here? Well, it’s saying my argument, where I gave it an array of three numbers, is not assignable to type array. And this is my mistake in this code. This is I quickly gave it this array specification. And what it’s saying is types of property length are incompatible. Type three is not assignable to type zero, because the type I gave it is actually not generic array. What I gave it is empty array. What I told it numbers is is an array with zero elements. So then when I pass in an array with three elements, it’s saying, wait a second, that’s not what you told me that was going to be. And it’s giving me an error because of that. So what I’m going to do here is I’m going to say numbers is any, and actually, I’m not going to I’m not going to say any. You genuinely you generally don’t want to use any because any basically turns off the TypeScript compiler. It’s a very useful in very specific circumstances, but I’m going to say, OK, it’s numbers. So it is an array of numbers. And now you can see this one immediately went away because now it’s saying, oh, I get what you’re saying. It’s an array of numbers. You gave me an array of numbers. So that’s OK, and I can accept that. Now, moving on. We still have one more error here. If I take a look at this, I can see this object is possibly undefined. And when I look at this, it’s saying, OK, so it’s saying possibly undefined and it’s giving me an error here. But all I’m doing here is I create my variable and then I start adding numbers to it. And the reason it’s giving me an error is because total here is not initialized. And so if I say total is zero at the beginning, now it quiets down and it says, OK, that’s OK. And that was actually a bug in my JavaScript code. That wasn’t just a TypeScript issue. That was in my JavaScript code. I would have gotten an error if I ran that code because total would have been undefined. Actually, I wouldn’t have gotten an error. I would have gotten really weird output. I would have gotten actually text output starting with the word undefined and then followed by the numbers in text would have been very weird. So what TypeScript did is it pointed that out to me so I could change that number and get what I need. Now, there is actually one other that we can see if we look here is this count says number or undefined. But I’m always returning a number here. And if I come up here, this is a very important thing to do with TypeScript. I’m actually going to explicitly mark my return. I’m saying this function returns a number every time. That is what it’s going to do. And TypeScript is saying, no, it does not. You are wrong. It does not always return a number because sometimes it does not return anything, which in JavaScript is considered undefined because if this if check fails, I don’t get a return value. So what I’m going to do here, I’m going to put a return zero there. And now it’s not complaining about my number code anymore. It’s accepting my my number code. It gets this entire function. It knows what everything is. And there’s a whole bunch of valuable features around this that I now have with this code. Again, in this example, TypeScript took me through taking this JavaScript code from something that was hard to work with and would not have worked in actual runtime into a fairly robust

function that’s actually very resistant to any kinds of bad input or errors that I might get. Now, I want to be very clear that TypeScript is not a cure all for every typing problem that JavaScript has because it only works at compile time. It is still possible for your code to be misused while it’s running. So you need to be very clear that at runtime, you’re still not getting runtime checking of your variables of your data types, but it will help you enormously as you’re developing your code. So again, does not solve every problem, but very, very powerful and very important tool. And there’s some other benefits now that I’m working with this that I can use, not the least of which is automatic documentation. And this gets into actually one of the cool features that I wanted to mention here. In here, I can roll over this function now, and it tells me what are the arguments, what’s the return type, and I know that immediately. Without this, with just normal JavaScript, I would have had to read the source code to figure out what it needs as input and what it returns, and that’s a very dangerous game to play because, A, I could read it wrong, I could guess wrong and have problems because of it, and, B, if it changes, it’s a problem, and, C, it’s just not an efficient way to be writing the code, especially if this was, you know, a 100 or 500 line long function or a class or something, it’s a really inefficient way to do things. This is much, much cleaner than what you end up doing with normal JavaScript. And I’m actually going to just really quickly do something real quick. I’m going to export that function because I want to demonstrate something here. I’m going to run my TypeScript compiler over my code. And this gets into what we were saying earlier about the really cool tooling around TypeScript in the ecosystem. TypeDoc is this awesome tool that goes through my TypeScript code and generates web documentation for me that I can use for my code. So if I just ran TypeDoc over my code, and I’m going to open this up in my web browser, and I can see in here, first of all, all kinds of information about my application, and I can come in here to this sum file that we wrote, and it tells me there is an exported function named sum, and it tells me exactly what the parameters are, it tells me what the return type is, it says, okay, the numbers parameter is optional, it’s an array of numbers, this returns a number, it tells me where it’s defined in the code, and if I go into these functions with this documentation, I can actually, if I link this to a GitHub repository, I can actually jump to the code directly, so I have this really powerful documentation that is just automatically there. And again, if you ask most developers, at least most of the developers I know, their least favorite thing in the world is doing software documentation, and so this is just a wonderful tool that at least makes me very happy, because I don’t have to write all of this documentation, because it generates it automatically, and again, this is something that can only be done when you’re using a tool like TypeScript. So just very, very powerful tools in this ecosystem. And this was actually a really important tool when we were doing a particular application, when we handed off the application. I was doing an insurance, an application for an insurance company, and when I had built the application, I built it all with TypeScript, and it was all me, and so with that application, I was the only one who knew how everything worked, but at the end of the project, I handed that application off to the company and to their developers so that they could continue the development on from there. And in that case, TypeScript and the type documentation is going to be extremely useful as that transition goes, because what it’ll allow developers to do is very quickly see how the code works and how they need to work with it without having to study my source code or be experts in JavaScript to be able to understand that information. So again, very, very powerful tools, very, very important, and everything else about TypeScript is really just an extrapolation of the concepts that we’ve gone over here.

I can talk about web applications. I have here an example Express web server, this is a web API that’s just about ready to be deployed. We can talk about classes, we can do all kinds of typing, actually in some ways significantly more flexible typing than most other languages, and everything from there again is just an extrapolation of what we’ve talked about here. So hopping back into our presentation to wind up a little or to wind down a little bit here. TypeScript is really what you want to be using for these kinds of big projects, right? TypeScript is very, very widely used in the JavaScript ecosystem. Again I mentioned Visual Studio Code is completely written in TypeScript, and TypeScript actually ships its releases with Visual Studio Code, they get released at the same time because there’s such a tight integration between the Visual Studio Code editor and the TypeScript language team. TypeScript is actually required if you use the Angular web development framework, the TypeScript application development framework from Google, any version after version two, I think we’re on version eight now, requires TypeScript, you actually cannot do it any other way. And TypeScript also supports React and Vue and every other major way of working with JavaScript. TypeScript is also constantly moving forward, right? So we mentioned at the beginning that graph that showed TypeScript was just shooting upward in popularity, it’s also constantly growing in features. TypeScript gets a new release every two months, that’s their schedule, where you get new features from this thing. I mean it is an insane speed to be moving at, and if you need even faster, if two months is too slow for some reason, you can actually also get on their nightly builds. They deploy a new version every single day, and you can trust that it’s stable because they run a suite of 55,000 automated tests over the TypeScript code base to make sure that it is completely stable and that there’s nothing that you need to worry about in this tool. So just looking back on what we’ve covered in this webinar. First of all, we went over why JavaScript is important, why you want to be using this incredibly powerful tool for your API development, why it really, when you’re talking about APIs, is the best language in the world that you will find for building APIs and for building user interface-based applications, because it’s designed to the core to do those things. We also covered how that can present some challenges. That same strength is a double-edged sword that can cause some problems when you start working with large teams or where you need a lot of stability in your application. You could start to get problems with JavaScript’s native features, and you’ll need to bring in a tool like TypeScript to make that easy and to mitigate some of those problems. We covered how to install the incredibly complex process of installing TypeScript and configuring it, the one command that we had to run to get it automatically, and the basics of coding with TypeScript. Now, there are wonderful tutorials that will get you really in-depth discussions of how you use TypeScript and what the best practices are. It really becomes its own language when you really get deeply into it. So we didn’t go that deep into that technicality, but again, there are great tutorials out there that can teach you all of that information. And that’s also something that we at Aradani are also happy to help with, is helping people get started with these technologies and really just helping you learn the easy way how to write good JavaScript applications rather than what the JavaScript community has done, which is really, over the last 20 years, learning the hard way. So that’s it for my technical presentation about this tool. I am going to kick it back to Dan now to close us up. Great. 

Thanks, Aaron. So I hope everybody has sort of picked up on Aaron’s excitement about TypeScript and why TypeScript is the right way to go if you want to build scalable, maintainable applications that can be worked on by large teams of programmers. So I think now we have just a few minutes left for some Q&A. So thanks, everybody. All right. Thank you. Bye-bye. Thanks, everyone.