Everthing you need to know about TypeScript
Nicolaysen, Torstein
There have been several attempts at patching static typing into JavaScript, but none have had notable success. TypeScript is different. Aligning with the EcmaScript 6 standard, it is a simple superset of JavaScript that’s easy and intuitive to learn — especially for those who know JavaScript. In this talk you will learn what TypeScript is, what’s new, how it differs from JavaScript, what to be aware of and where I think TypeScript is heading. TypeScript’s static typing opens up a whole new dimension for large-scale applications. It enables language analysis, gives type safety, refactoring support in IDEs as well as other features that are hard to achieve in JavaScript. Additionally, typing is optional, so you can add typing step by step in your existing application. This presentation will be loaded with code examples. I will give a quick comparison to some related languages like Dart and CoffeeScript, just to show you the difference and explain when TypeScript might be a safer bet. I have looked extensively into TypeScript and used it in production code. Come get the distilled version of what you need to know!
 So, welcome everyone. I'm glad to see that so many actually showed up here. It was quite – I had some competition at this time now with Uncle Bob and another JavaScript check, so I'm actually quite pleased with how many have – that have showed up. So, my name is Torsen Nikolajsen. I work as a senior consultant at Beck Consulting here in Oslo. I've been doing web development for many years now and I've been doing a lot of JavaScript the last few years. If you want to contact me, you can reach me at Twitter, LinkedIn or Google Plus using my username here. So, I know why you guys are here. Like I said, you have actually chosen this track now. There's a lot of other interesting things. So, I guess all of you are actually motivated to learn TypeScript today. And I won't spend that much time motivating you and explaining why we need TypeScript. I'll just mention it shortly. And an interesting thing was that during the earlier sessions here, John Syme, when he was talking about F-Sharp mentioned JavaScript. And I'll come back to that a bit later. So, I was actually going to do a pun here with walking you down memory lane, just explaining why we actually – I was going to explain all the troubles that we have had with JavaScript over the years. And actually, I also just wanted to show you this drawing, which I love, just to tell you about the browser wars and how we have come to a standardized way of doing web development right now. So, let's just take a quick look back at how we did JavaScript development when it started booming. So, we did – I have to say this before we start – I really like JavaScript, so I'm not going to trash talk JavaScript. But if you look back, many developers neglected JavaScript as a programming language. It didn't consider it a true programming language. So, actually, people actually wrote jQuery, not JavaScript. And many of the apps they generated was just one huge file called script.js, which was unmaintainable, and only one guy knew how to do stuff in it. It was the spaghetti code. But we have gotten a lot better the recent years. There has been a lot of focus on JavaScript, and it has established the stages as a real programming language now. And we actually managed to build quite large applications today. Just have a look at Gmail, Facebook, Trello, and Cloud9 IDE. Cloud9 is actually almost entirely written in JavaScript, both frontend and backend. And that's impressive. But in order to build these big applications, we require tools that lie outside JavaScript. We have to have script managers like – or dependency tools like Require.js. And in order to build this in a smooth fashion, we require tools like Grunt, or we have to use something in Maven, or in MS Build, or extra steps. We have to do a lot of extra. And once we have managed to build a quite large application, if we don't follow all the good practices, design practices on how to do proper JavaScript, and we try to fix one thing, it all just falls apart. And the reason for that is that there is a little glue that holds JavaScript apps together right now. The only glue that is common is unit test and integration test in JavaScript code. And you guys know that we aren't doing enough of that. So when we write JavaScript, we can easily refactor code or do stuff like that to it. And the reason is twofold. Again, we developers tend to neglect JavaScript as a language, and we also don't do all the good practices. And JavaScript as a language don't have that many means of encapsulating and structuring your code. You can use closures and stuff like that to simulate that you have some scoping. But that doesn't work really well in large scale, in my opinion. So I'm going to tell you today how TypeScript can help to mitigate some of these issues. So today we'll be looking at what TypeScript is. We'll dive right into some features, and I'll be doing a lot of live coding throughout the sessions. And we'll be looking at the ecosystem that TypeScript exists in, and I'll do a recap and give you my final thoughts on what is happening right now with TypeScript and what is going to probably happen in the short future. So let's just check out what TypeScript is on a high level there. It is technically a super set of JavaScript. That means that it actually has all the features and syntax features of JavaScript, but it's just adding more features on top of this. So you can actually write JavaScript inside of TypeScript. It will still compile. And it is one of those languages that compile down to JavaScript, so you don't need a browser plugin like Google Dart has actually. It requires you to either compile to JavaScript or run it as a Dart VM. So this compiles down to good JavaScript code. And you can compile it using the official node package, or you can actually use a Visual Studio plugin which makes this really smooth in Visual Studio at least. Like many other things in the JavaScript ecosystem, TypeScript is also open source. All the code is actually available on Codeplex and can follow the development, track the issues, and actually talk to developers. And it's worth noticing that this is actually a Microsoft initiative to write TypeScript. And that brings us over to this cheery looking guy, Anders Helsberg. He's most notably known as the lead architect for C Sharp. And I think that lends credibility as he is actually the designer of TypeScript as well. You can see that his previous work on C Sharp influences the way that TypeScript works. So if you like C Sharp, you will see some familiar elements in TypeScript. Another brilliant decision of the team that is creating TypeScript is to align it with the upcoming ECMAScript 6 standard. If you don't know what ECMAScript is, the simplest way to put it is that it is the standard for JavaScript. You can think of this as that. And the next version of ECMAScript, version 6, defines how classes and modules should work and some other language constructs. So by aligning with this, that means that TypeScript will look very similar to what JavaScript will look in the future. Another benefit is TypeScript has already implemented some of these features that are still a draft now. And that means that you can actually use classes and modules now instead of waiting for JavaScript to come along and add that. So let's look at some of the new features in TypeScript. We will be looking into type annotations, classes, interfaces, modules, our functions, and a few more during this session. So TypeScript is probably one of the most unique features in TypeScript. It works pretty much like you expected to work in other languages. And you can apply Types to objects, parameters, fields, and return values and some other things in the language. You have some primitive types that is unique for TypeScript. It's string number, and number is not, you can't separate between integer and float numbers. It's the same number type that you have in JavaScript, which is the float. And you have the boolean and you have any type. The any type is the default fallback type. So if you don't specify a type on a variable, then it will be of type annus. You can assign anything to it. And you have something called void. You have that in C sharp, of course, but JavaScript does not have that concept. So in TypeScript, you can explicitly say that this function does not return a value by using void, as you would do in C sharp. Another brilliant thing about TypeScript is that it uses, it gives you the option to choose whether you want to use types or not. And this has two advantages. You can actually migrate your code base, existing JavaScript code base over to TypeScript by applying types step by step by step as you go along. And another thing is that you can use types where you like. This is one of the things that Don Seim talked about earlier with F sharp. You have statically typed languages and dynamically and you have something in between. And that's where TypeScript is right now. You can choose what you want. So you get the best of both worlds. So let's look at some syntax. This is a classic thing you would see in JavaScript. And since I haven't annotated with the type, the type is annie here. That means I can assign a number to it. I can assign a string. And I can assign an object to it. No problem. So I can also do static typing. Here I say that this variable should be a string. So if I try to assign a number to it, the compiler will give me a warning here. So, and TypeScript also has type inference. That means if I declare the assigned value of the variable at the same time as I declare it like so, it will inference that offer is a string. And therefore, if I later try to assign a number to it, it will complain because it has inferred a type. So I'll just show some quick demo of how this can, what this can look like. So if I were to create a function called add contact, and I say I want a name and a phone. So this is what you would have in classic JavaScript. So if I were to call this, hmm? We don't see anything. Oh, sorry. The screen switch didn't work. All right. This should work. All right. So what you're seeing now is classic. This, again, this is look like JavaScript. And if I were to treat this as a black box, if I didn't know what this function does, I would call it like so, and I'd see that here we have two parameters. I don't know the type of that. So if I was, if I didn't know better, I guess that it's the first parameter's name. Okay. Hmm. Probably if it has a name. That's true. And the second parameter's phone. Yes, probably has an Android. So I don't know anything about how this expected to work. So with TypeScript, I can give types to this. So you see, I can annotate this to be a string, and then I will get a squiggly line here, which says, hey, the compiler won't be complaining. So here it says that this input here does not match the signature. So in order to fix this, I have to make this a string, and it will work. So I can continue adding a number to, especially if the phone is the number, I'll get the same error here. And to fix that, I will have to add a number here. So you see here, the compiler actually prevents me from making silly mistakes. And I can also assign the return value from this function to be a string. Again, the compiler will complain here because the function is not returning anything. So I can return something here, and it will go away. So let's look at the compiled code here. This is TypeScript, and here we have the JavaScript code. So again, it's, if I just center this, the code looks really similar, just without types here. And this last line here is just source mapping. That's used for debugging. So you can map a line in TypeScript over to a line in JavaScript. So let's go back to the presentation. Does this work? Yeah. Awesome. Great. Just going to go quickly through interfaces. Interfaces can, you probably know what they can be used to, but declaring them looks like so. And this, the only thing that's special here is that you have a way to say that this is optional. You can choose to not include this in the type that implements this interface. So common usage for interfaces is to have our class implement certain members, like a function of fields. And you can also ensure that if you have a parameter that you pass your function, you can ensure that this has some characteristic by using interfaces. And we're showing some demos of interfaces along with other code. So classes is, again, this is what's been proposed with ECMAScript 6. Classes are mostly like in other languages, but you should think of it as a container in JavaScript. So you can have constructors in them. You can have fields, functions. And if you are feeling really brave, you can actually use properties, which is something that's not really good, really well-supported in older browsers. But JavaScript has them. And you have this get set syntax for local fields. You actually have wrap them, get some extra encapsulation. So I'm just going to do a demo of classes and how they work. So in this example, I'm going to make, thank you, I'm going to forget that, this worked better than last time. So I want to create a class called superhero, like so. And you see on the right side here, it's already compiled that into JavaScript code. So you see that actually creates quite sane, readable JavaScript code. This is the way I would have done this if I wrote it in JavaScript. And now I'm going to create the constructor here. And in this constructor, I'm going to pass in a parameter called name. I want that to be of type string. So I want to assign that to a local field called name. And here the compiler will complain because this class does not have that field. So I have to declare it in the class. So the simplest way to do that is just like so. So now I have a local field. And this is okay. This is the way you would have done it. But there's a shorthand also for doing exactly the same thing. I can remove this too. And I can add public in front of here. And it compiles to the same code and works the same way. So that's just a shorthand for creating local fields. This can get messy if you don't use it correctly. So the next thing I want to do is create an interface. So I'm going to create an interface called I have superpowers. And that is going to force this implementation to have a method called get superpower. And I want that to want to return string. So that's my interface. And then I can say that this implements, this is things you can't do in JavaScript right now. So you can't drive the design or enforce the design in your code right now in JavaScript. You have to use other tools for that. So I say I have superpowers. And now the compiler will complain again because, and it gives really good error messages here. So if you see here, they says that the type super is missing the property get superpowers. So it's really helpful here. So all I have to do is implement that is just say get super power. And I have to implement this one and make sure that it returns a string. So clean code is my superpower. So that works now. And also another thing, if I had returned the wrong type here, notice that I haven't specified here which type this one returns. It's inferred and it therefore matches with the interface. So if I had returned a number here instead, I would actually get the compiler error. So it's a bit more discrete here. But here it says that it does not match. Doesn't matter what it says. So the next thing I want to show you is concept of accessibility. So this is public by default. I can actually add a private method in this code here. So get secret power. And this one will not be visible from the outside. So if I declare I have a hero, superhero, I can see that this object has get superpower and names, public fields. But I don't see this one because that's not publicly available in this type. But it was interesting here. In the compile code, you'll actually see that it's being defined as a regular function on the object. This is because JavaScript don't have a notion of public and private accessibility. So the last thing I want to show you in the classes is sub-classing. So I can do a super-duper hero which extends a superhero. And here I can also make a constructor. And this constructor I'll choose to take in a name and keep it like so. And when you do constructors in TypeScript or in sub-classes, you always have to call the super, use the super key word to call the constructor in the parent class. This is an thing that's enforced. So now I have made a sub-class of this. Yes. So you see that this is similar concepts that we already have in other languages. And again, doing this in JavaScript would have required you to write something really similar to what you're seeing here. It's not formatted as neatly, but you would have to do the same things here in JavaScript. So let's go back to the presentation. Like so. All right. The next thing I want to show is arrow functions. Arrow functions is simply just a short hand for writing methods. There's one special behavior in TypeScript, and that is that it binds to this keyword lexical. I will show you what that means by demo. But first, I just want to show the syntax of how this looks. So this compiles down to this JavaScript code. And again, you see here the input parameters goes here, and then you have a method body. And maybe this example is a bit clearer. But here you have some code that compiles down to this. You assign the function to a variable called sign, and then you pass in an input parameter, and you have a method body. So this is all that this syntax does. And the main application for this is using, for instance, working with callbacks in the user interface when a user clicks a button or when they get WebSocket data or someone has triggered an event. And it's also really useful for working with code that has functional style. So again, a demo. Hope you like demos, because I have a lot of them. All right. So in this demo, I have created this web page where I have a button here called demo button. Thank you very much for noticing. This is something I should have prepared better. All right. Now you see. In this demo, I have a web page here where I have a demo button on the web page, which I will use later. So I'll create a new class called button handler, like so. In this class, I want to have a constructor that takes in the HTML button. And the funny thing here is that in this demo, I'm actually going to show you quite a few things about TypeScript. So in this, you have this DOM API that's in the JavaScript already. And TypeScript has made strong typing upon that. So I actually have an HTML button element that comes directly from the DOM. So I can say that I want a DOM button of that type in my constructor. And I can actually just do like so. Then I have a sign to the public field. And I also want this class to have a private field. So it's a secret. Shh. Don't tell anyone. And what I'm going to show you now is a very classic example of what it's a bit of a hassle doing the same in JavaScript. So I want to, on the onclick event on the button, I want to trigger a callback. So I'm creating a function here that will be the callback. And what's interesting thing here is it knows that this type is of mouse event because that I'm using the strongly typed HTML button element. This is a quite nice feature that you get by using this. So what I want to show you, I want to alert this.secret. Like so. And in order for this to work, I'm going to show you another thing here. I want to again have this DOM button as HTML button. So I want to declare a variable here. Then I want to assign it on the line here. Document.getElementById, classic, no jQuery. And I call it the demo button. Like so. And now I see the compiler complains here. And the reason for that is that I get an HTML element back from this method. And I'm trying to assign it to something that's an HTML button element. So now I can actually show you casting in TypeScript. And you do that by using angled brackets like so. So this type inherits from HTML button. So that's what I need to do to get this to compile. So now I can actually call the button handler constructor and pass in my button like so. And this compiles. Now I can open this web page. I hope it's a star here. So what have I done? Like so. I can open this web page in my browser. And yes, I probably do that. So if I push this button now, I'm expected to see shh, which was the local field. But I get undefined. And this is a regular problem in JavaScript. And this is expected, by the way. And the reason for this is that when you are doing callbacks in JavaScript like this, the disk keyword here actually points to the element that triggered it. So it actually belongs to DOM button here in this context. And the easiest way to fix this is by using arrow function. What arrow function does, you see there was really not much change here in the code. But arrow function now binds the disk keyword to the context. And the context here is that it's within a class. So this now points on the class. So if I run the same code again, it's been compiled in the background, I actually get the string that I expected to see here. So I think, yeah, that was what I wanted to show in this demo. So, next one. So modules. Another great way of handling encapsulation in TypeScript. They are similar to namespaces in C sharp and packages in Java. And again, this is something we have, I think this is one of the issues in JavaScript right now. And they have addressed it in ECMAScript 6 by adding modules there. But you can right now have encapsulation in your code. And modules are really easy to import between code. So it actually makes it easy to reuse code. And you can compile these modules to either common JS or AMD. And if you don't know what that is, the best way to learn about that is actually talk tomorrow that will be about required JS, which implements the AMD pattern. But it's just a JavaScript or node way of actually getting source files between or runtime in an asynchronously way. So the syntax for creating modules is like you expect. You can have classes, functions and variables inside a module. And in order for them to be accessible outside a module, you have to prefix them with the export keyword. That means that they are publicly available. And if you don't have the keyword in front of them, they will be internal modules. So you're going to have helper classes and helper functional local variables inside that and not exposed. So it's a great feature. In real world, we are probably going to reference a lot of modules in our projects. So there's two things here. There's something I call internal modules. That is, if you don't have a big project and you are manually setting the script blocks in the header in your HTML file, you can use internal modules. So all you have to do then is just in top of each type script file, you have to add a comment like so to tell it that, really, this file and use the types that are inside this one. The downside by using internal modules is that you have to, if the application grows, you have to keep the sequence of the scripts correctly. So you have to ensure that all the scripts are loaded in the correct sequence up front. This doesn't scale very well. But external modules is probably more scalable. And it is when you use, when you use like a script loader, like require.js to handle this. I will show you in a demo how this actually works. So I want to be showing a lot of the basic things. I actually go right into the advanced thing. And I have prepared a demo here so I can actually just talk you through it. So just switch over to duplicate. I remembered it this time. All right. So I prepared a web page here which is using require.js. I already don't know this script. So the only thing that require.js knows about is that when require.js is loaded, it is going to load a file called main.js. That's the first thing that require is going to do. So in my TypeScript file, I have told it to look for, again, this is the only place I have to declare TypeScript or make the application know about TypeScript. So what I'm doing here is that I'm actually saying, okay, you need to read the types that's inside this definition file. I'll come back to that in the next demo. And that is the only place that you need to, again, know of require. So what you do here is that use require syntax. What this means is that when you load the application, look for a file called bootstrapper.js, load that entire module, and when that module is loaded, it will then be passed into this function as a parameter. And on that object, I have created a function called run app, which I will show you now. So the only thing this one has, it exports a function called run app. You see, I don't have to wrap this inside a module in this case because I'm using the external thing. And the interesting thing here is that inside here, you don't see any require.js syntax. You actually see that I import the module here. This actually looks for a file called view.ts. So I have a dependency to that module. So if I go into this module, I see that I expose a class called registration view. And again, I see that I have another dependency here. Again, there's no require.js syntax. This is typescript syntax. And if I go into the utils, I see that this is kind of a leaf node. So you see that I have nested dependencies here. And if I were to handle that within the script block here, I had to know which dependency needed which location, at which time. So you have to get the correct sequence. But if I'm really, really lucky now, this should work in the browser. And I can show you what happens. So like so. Yes. So let's check to console. Nope. And I know what's wrong here. There's an issue with loading. Awesome. There it goes. So what it does now is that when I load the page, require.js takes over and figures out which scripts need to be loaded first. So the only two files that are loaded first here are require.js and main. Then it knows that busstrapper, review and utils has to be loaded in sequence. And it handles all of this for me. So I don't have to know about that. And that's a great feature for doing large-scale applications because then you actually don't have to think about how the scripts are loaded. I think that's one of the key elements to getting scalability. All right. So. So. All right. I have something to say about parameters. I'm just going to show you some slides here. There's some really useful new syntactical sugar that makes it easy to write flexible functions. So you have default parameters, which means that you can set the default value. So you can either call it like so or pass along a boolean value here. This is really useful. And you also have optional parameters like I showed you earlier. So you can actually choose to pass in options or not. So you can call this function in several ways. And you also have something called rest parameters. This is also a part of ECMAScript 6, this thing, which you can compare to var args in C sharp. So what's going to happen if you pass in, you can have an endless number of parameters here. But you get the first one as the winner and the rest will actually just be in an array called the rest here because that's what I called it. And we have something that I think is one of the coolest features of TypeScript. It's type definition files. And before we show you them, I have to explain what ambient declaration is. It's a way of saying to TypeScript that, chill, I know that I get this variable from somewhere outside TypeScript. Typically, if you have loaded TypeScript in the script tag earlier. So just chill. I know what I'm doing. That's what you're saying to TypeScript. And it also, if you do use the clear word, it will actually not include this variable assignment in the compile code. So you just omit it totally. And there's something called type definition file. These are just a single file that defines all the signatures of the library that you're using or dependent on. For instance, if you're using jquery.js, TypeScript won't know about the types that it has. But by using definition files, you can actually get strong typing on jquery. So you can actually use it in a strong manner in the TypeScript files. This actually means that you get all the completion help and intelligence on jquery. That's really helpful. And the way this works is that you use this reference thing I showed you earlier in the top. And all of these type definition files does add an ambient declaration to say that this variable exists somewhere in the code. And there's a project, or a GitHub repository called definitively typed, which is a great repository for finding all kinds of definition files. So you'll probably find the framework you're using. So you knock out Angular, jquery, node, require.js. Yeah, it has a lot here. So you'll probably find some of the frameworks you're already using. So don't have to create these files yourself. So I'm going to show you quickly how this works. Like so. Just close all these files. I have now a definition file for jquery. And again, all it contains is just interfaces. It does not contain any implementation of jquery. So you can just see that it contains a lot of interfaces here and different functions. This doesn't say anything much like so. But what you can do is if I am writing a jquery function here, I can actually just write it like so. If I have to write something like this. And I don't get any auto-completion here because it doesn't know what type this returns to me. So I know there's a text probably, or maybe there's a function called add. I don't know. Can add some text. Hello. And this doesn't work. What I could do just to get the compiler off my back, I could use declare variable here. Again, I know what I'm doing. I know this library works and I have loaded this already. It's not strongly typed. So that's the simplest way to get it to work. But I can actually do one better. I can actually use this type file. Like so. You see it actually adds now reference to that file. And what that does is give me strong typing now. So now it knows that the type of this dollar here is of type jquery static. And that means that I actually get strong tooling here as well. So now I can actually browse all the possible methods I can use on this type. I think that's a great thing. So if I were to call, for instance, text now, can I set the text or can I get the text? Let me see. Okay. Here I have all the overloads of this one. So I can actually scan through those. So I see, okay, this takes in a string and I can return, it can return a string. Great. So you actually can, if you're new with the framework, you can actually easily learn this. And a great example to show that is actually underscore. I don't know how many have tried underscore, but don't have that definition following, but I can try installing it. So I'm using NuGet package manager to just get this source file. And it, so I have it on the file system. I'll just browse it. Code, demo, packages underscore. Okay. This is great. Like so. I can just drag it into there. Nope. Like so. And now we shall do is again. So and again, I always look up the documentation underscore. So again, I can just reference reference.file. This is way, is dragging and dropping it. That is a plugin called web essential that helps me out with this. So now I get the code completion on underscore. And that's, I need that a lot to help me understand how I do, for instance, the reduce function. What do I do there? So I can actually see the signature here, what, the sequence of parameters here. So back to slides. How am I doing on time? 20 minutes or so. All right. I want to talk a bit about tooling. TypeScript has already gained a lot of support in IDs and tools. It works best in Visual Studio right now, because it makes it and also makes the plugin. But you also get good support in Cloud9 and Sublime has a nice package that helps you compile and gives you syntax highlighting and some auto completion as well. So I think this is just an indication that there is many that invested time in TypeScript already, even though it's still a preview. And there have already appeared some community tools around TypeScript. We see, for instance, TypeScript definition package manager is a tool to download those definitions file like you do with Node package manager. So it actually worsens it and lets you easily update this if you want to. And web essential is a must have for Visual Studio if you are using Visual Studio. It allows you to configure how the compiler works and gives you some extra features with TypeScript. So I just want to give you a high-level overview of how TypeScript compares to TypeScript in Google Start just to know what the main difference is. Comparing it to TypeScript, we see that TypeScript has a much higher abstraction of JavaScript than what TypeScript has. Again, TypeScript is just a superset while TypeScript tries to lend style from both Ruby and Python. So we have more functional approach to developing JavaScript. And it's great for its purpose. And also it has much simpler class concept, but still it has this way of helping with encapsulation. But JavaScript in itself does not give you anything about help with file loading and dependency management. You've probably seen usage of Node in TypeScript that handles that. And Google Start. I haven't coded anything in Google Dart myself. But that's completely new language inspired by C syntax. So you can't just reuse your current skill set in JavaScript like you can with TypeScript. And it actually tries to solve many of JavaScript's inherent problems. But it gives you also many of the same constructs that you have already in TypeScript. But Dart has a lot more of them, language constructs. And there's a potential vendor lock-in. Again, you have this Dart VM, which is a part of Chrome that runs Dart without compiling into JavaScript. But you don't have to do that. You can also compile that to JavaScript. The resulting file is really big. And it also received some criticism from really, from Brendan Eich and Douglas Crockford, who are some notable characters in the JavaScript community. Brendan Eich actually created JavaScript. So that's just comparing it to those two. And one thing that's important to notice is that JavaScript is getting there. JavaScript will get classes, will get modules. It will get many of these modern features. But ECMAScript 6 is still a draft and it's not completed. And when that is completed, the implementation will start. And when the implementation starts, it will take some time for it to get implemented in all the modern browsers. And I have no idea how much time this will take, but unqualified guest is two to three years. And it will be really similar to what TypeScript is now, but TypeScript will have types and some more. So JavaScript is still a subset of TypeScript when it's done or released. So TypeScript is, like I said, it's still a preview. It's not finished. But there has recently been released a new version for preview that actually has generics and some performance tweaks. And adding generics is a really cool feature. So you can actually implement the link, language in the great query in TypeScript. So I don't know if anyone has started that, but it's an interesting feature to have in that language. And for when the language is completed, there is a plan to add async and await support, sharp keywords. And I think that is a really, really cool thing to add to this language. Because right now we are doing callbacks and we can actually just use the async keyword or await keyword in order to do this the same way as we do in C sharp 5. For those of you who have tried it, I think that will make the code easier to read and more easy to follow. And it will also add mix-ins to language. That's an interesting feature that the, because JavaScript is dynamic language, you can actually do mix-ins. And having that in TypeScript as well is really useful. So I promised you, I'll tell you about where the dragons are. But there are not many and they're not that severe. One thing to be aware of is using TypeScript or trying to use TypeScript in existing JavaScript frameworks like Angular. Angular actually tries to solve many of the problems that, or tries to make it easier to create JavaScript application. And it is designed entirely for JavaScript. And many of the things it tries to solve is not necessary to solve in TypeScript. So, and this is not just an Angular problem, but some frameworks might be difficult to use in TypeScript. So be aware of this. Don't try to use, for instance, one of the problems with Angular is that it's based on functions and functional design. And you don't need to need that in a TypeScript application. There are other ways of solving this. So a tip might be looking for a dedicated TypeScript framework that works better. So another thing is that there's a lot of syntactical shortcuts that you can use. But I'm pretty sure that you will end up with really messy code that's unreadable if you use this without caution. Especially you can actually do inline Type specification of interfaces. That means that you can actually, instead of creating an interface outside, in another place in the code, you can just write the interface declaration then and there. And you have, and you can also nest the modules that you're declaring really deeply and try to avoid that. And when using arrow functions, you can also, again, you can make these two complex for it to be readable. Again, it's still a preview. There are bugs in TypeScript, especially around when you use the property get and get and set properties. There are some known bugs there. And protected accessibility is not implemented yet. It's planned in a future release. So if you do subclassing, you don't have the keyword protect to make a field available to your children. And there are still features that need improvement. For instance, modules and the way you import modules need some improvement just on syntactical sugar in order to ease up how this is done. So I'm going to just look back at what we have been through. We've seen that we learn what TypeScript is. We have taken a deep dive into all the new features, almost important features. We have looked at how we can actually do dependency management in real world application, and compare it to some languages. And we see what's happening right now with both JavaScript and TypeScript. And what we can take out of this is that by having a compiler, you can actually eliminate a lot of bugs that you usually would find around time with JavaScript. You get strong typing and thereby strong tooling in your IDEs. So it makes it easier to refactor, you can actually refactor TypeScript code in your ID. You get more encapsulation, and you have mechanisms to simplify dependency management and, again, ID support. And it actually also lowers the threshold for beginning with JavaScript. So I personally think that the threshold for a developer that has not done JavaScript development is quite high right now if you wanted to start with JavaScript. But working with TypeScript, I think that might be a bit easier because you have constructs from object-oriented programming. So it will be a lot of pressure. You can reuse more of your existing knowledge. There are a few advantages for large-scale applications. You can actually build more robust apps. You have a strong typing that helps you and ensure that you have correctness throughout your application, at least when it comes to the typing. An interesting case, I experienced once, we were free developers working on a codebase, and we had interfaces for different commands we sent to the server. And at one time, one of us changed added a new field to this interface. And what happened then? We had three builders, and then we could actually find the three places in our codebase that we needed to update in order to conform to this new interface. So that was just an example of how you can get more robustness out of using typing. And you can also enforce design. You can actually do design patterns now, more easily at least. I don't know if it makes sense in TypeScript, but at least you have the mechanisms to drive the design. So you, as a... If you are developing a framework, you can actually make it really easy to use that framework for other developers. And you get more maintainable apps. This is probably what the enterprises want. They want something that is maintainable. I think JavaScript is... Might be a difficult technology to choose if you're enterprise and want to... And you don't have JavaScript resources. So this makes it easier. And you, again, it might be easier to train or get developers that know TypeScript or object-oriented design. And for small scale apps, it's not that much to gain on using TypeScript, but you get a simplified build process. If you're using Visual Studio, just compile when you save. You get less bootstrapping. You don't have to do as much to get your application up and running. You can just use the internal module references and things will work. And I think probably the biggest win is the strong tooling where you get autocomplete help in your IDE. And I think that's actually one of the things I've liked the most. So that was actually... I want more thing I can actually show you. Just for a little wow effect here. So this is the first time I actually used a GIF in a presentation. Do you like it? All right. I will now have to see if I have a file for this. All right. I'll actually create a new file for this. So add... Again, I have to switch here. All right. I'm going to scroll down to add a new TypeScript file here. And the setting I'm in right now is that I'm creating a Twitter application. So what I'm doing, I'm going to create something that gets a list of tweets or the timeline from Twitter. And if I were to do this with strong typing, I would have to go into the documentation. So I could go here and read the documentation for that query. So here all the parameters are described. And I would have to copy them into... Make interfaces out of this manually. But there is a cool little trick you can do. So if I just copy this one, which is one of the parts. And this is just a JSON file, not just a JSON code. So I have this feature in a web potential called paste JSON as classes. So if I do that, like so. I have to ensure that I haven't get... I have to take more or less of this. Again, wow effect. No, it's without them, I think. Yeah, it's without them. It's supposed to work like so. There we go. So what we see now is this is the... I can actually just call this the timeline. So what I have now, now I have a strongly typed type for entire return object here. So it has created it. So small modifications I can actually now have strong types. So if I were to have a jQuery function that looks something like this. So if I had something like.get timeline and in the call box I get this data, I can say that this data is of type... time... Twitter timeline. So now actually in the response, I could actually code knowing which fields were present in this. I don't know if this works. Yeah, so I can actually navigate the return structure here. So I think that's one of the cool features. So that was what I wanted to show you today. So are there any questions? I will be putting this presentation up on slide deck later. So if you want to... why don't it fix my presentation? Yeah, the cable here is a bit loose. Yeah, you probably managed to read that, right? So I don't know why it's not switching over to... try this. Let me do like so. Okay, you can reach me at Twitter. For instance, I'm going to post the links to the slides on Twitter afterwards. And if you want to see the code, I can probably put it up in GitHub. So the last thing I want to say, remember to vote outside using this, hopefully this green one. So thank you for your attention today and have a good conference.
 So, welcome everyone. I'm glad to see that so many actually showed up here. It was quite  – I had some competition at this time now with Uncle Bob and another JavaScript check,  so I'm actually quite pleased with how many have – that have showed up. So, my name  is Torsen Nikolajsen. I work as a senior consultant at Beck Consulting here in Oslo. I've been  doing web development for many years now and I've been doing a lot of JavaScript the last  few years. If you want to contact me, you can reach me at Twitter, LinkedIn or Google Plus  using my username here. So, I know why you guys are here. Like I said, you have actually  chosen this track now. There's a lot of other interesting things. So, I guess all of you  are actually motivated to learn TypeScript today. And I won't spend that much time motivating  you and explaining why we need TypeScript. I'll just mention it shortly. And an interesting  thing was that during the earlier sessions here, John Syme, when he was talking about  F-Sharp mentioned JavaScript. And I'll come back to that a bit later. So, I was actually  going to do a pun here with walking you down memory lane, just explaining why we actually  – I was going to explain all the troubles that we have had with JavaScript over the  years. And actually, I also just wanted to show you this drawing, which I love, just  to tell you about the browser wars and how we have come to a standardized way of doing  web development right now. So, let's just take a quick look back at how we did JavaScript  development when it started booming. So, we did – I have to say this before we start  – I really like JavaScript, so I'm not going to trash talk JavaScript. But if you  look back, many developers neglected JavaScript as a programming language. It didn't consider  it a true programming language. So, actually, people actually wrote jQuery, not JavaScript.  And many of the apps they generated was just one huge file called script.js, which was  unmaintainable, and only one guy knew how to do stuff in it. It was the spaghetti code.  But we have gotten a lot better the recent years. There has been a lot of focus on JavaScript,  and it has established the stages as a real programming language now. And we actually managed  to build quite large applications today. Just have a look at Gmail, Facebook, Trello, and  Cloud9 IDE. Cloud9 is actually almost entirely written in JavaScript, both frontend and backend.  And that's impressive. But in order to build these big applications, we require tools that  lie outside JavaScript. We have to have script managers like – or dependency tools like  Require.js. And in order to build this in a smooth fashion, we require tools like Grunt,  or we have to use something in Maven, or in MS Build, or extra steps. We have to do a  lot of extra. And once we have managed to build a quite large application, if we don't  follow all the good practices, design practices on how to do proper JavaScript, and we try  to fix one thing, it all just falls apart. And the reason for that is that there is a  little glue that holds JavaScript apps together right now. The only glue that is common is  unit test and integration test in JavaScript code. And you guys know that we aren't doing  enough of that. So when we write JavaScript, we can easily refactor code or do stuff like  that to it. And the reason is twofold. Again, we developers tend to neglect JavaScript as  a language, and we also don't do all the good practices. And JavaScript as a language  don't have that many means of encapsulating and structuring your code. You can use closures  and stuff like that to simulate that you have some scoping. But that doesn't work really  well in large scale, in my opinion. So I'm going to tell you today how TypeScript can  help to mitigate some of these issues. So today we'll be looking at what TypeScript  is. We'll dive right into some features, and I'll be doing a lot of live coding throughout  the sessions. And we'll be looking at the ecosystem that TypeScript exists in, and I'll do a recap  and give you my final thoughts on what is happening right now with TypeScript and what  is going to probably happen in the short future. So let's just check out what TypeScript is  on a high level there. It is technically a super set of JavaScript. That means that  it actually has all the features and syntax features of JavaScript, but it's just adding  more features on top of this. So you can actually write JavaScript inside of TypeScript. It  will still compile. And it is one of those languages that compile down to JavaScript,  so you don't need a browser plugin like Google Dart has actually. It requires you to either  compile to JavaScript or run it as a Dart VM. So this compiles down to good JavaScript  code. And you can compile it using the official node package, or you can actually use a Visual  Studio plugin which makes this really smooth in Visual Studio at least. Like many other  things in the JavaScript ecosystem, TypeScript is also open source. All the code is actually  available on Codeplex and can follow the development, track the issues, and actually talk to developers.  And it's worth noticing that this is actually a Microsoft initiative to write TypeScript.  And that brings us over to this cheery looking guy, Anders Helsberg. He's most notably known  as the lead architect for C Sharp. And I think that lends credibility as he is actually the  designer of TypeScript as well. You can see that his previous work on C Sharp influences  the way that TypeScript works. So if you like C Sharp, you will see some familiar elements  in TypeScript. Another brilliant decision of the team that is creating TypeScript is  to align it with the upcoming ECMAScript 6 standard. If you don't know what ECMAScript  is, the simplest way to put it is that it is the standard for JavaScript. You can think  of this as that. And the next version of ECMAScript, version 6, defines how classes and modules  should work and some other language constructs. So by aligning with this, that means that  TypeScript will look very similar to what JavaScript will look in the future. Another  benefit is TypeScript has already implemented some of these features that are still a draft  now. And that means that you can actually use classes and modules now instead of waiting  for JavaScript to come along and add that. So let's look at some of the new features  in TypeScript. We will be looking into type annotations, classes, interfaces, modules,  our functions, and a few more during this session. So TypeScript is probably one of the most  unique features in TypeScript. It works pretty much like you expected to work in other languages.  And you can apply Types to objects, parameters, fields, and return values and some other things  in the language. You have some primitive types that is unique for TypeScript. It's string  number, and number is not, you can't separate between integer and float numbers. It's the  same number type that you have in JavaScript, which is the float. And you have the boolean  and you have any type. The any type is the default fallback type. So if you don't specify  a type on a variable, then it will be of type annus. You can assign anything to it. And  you have something called void. You have that in C sharp, of course, but JavaScript does  not have that concept. So in TypeScript, you can explicitly say that this function does  not return a value by using void, as you would do in C sharp. Another brilliant thing about  TypeScript is that it uses, it gives you the option to choose whether you want to use types  or not. And this has two advantages. You can actually migrate your code base, existing  JavaScript code base over to TypeScript by applying types step by step by step as you  go along. And another thing is that you can use types where you like. This is one of the  things that Don Seim talked about earlier with F sharp. You have statically typed languages  and dynamically and you have something in between. And that's where TypeScript is right  now. You can choose what you want. So you get the best of both worlds.  So let's look at some syntax. This is a classic thing you would see in JavaScript. And since  I haven't annotated with the type, the type is annie here. That means I can assign a number  to it. I can assign a string. And I can assign an object to it. No problem. So I can also  do static typing. Here I say that this variable should be a string. So if I try to assign a  number to it, the compiler will give me a warning here. So, and TypeScript also has type inference.  That means if I declare the assigned value of the variable at the same time as I declare  it like so, it will inference that offer is a string. And therefore, if I later try to  assign a number to it, it will complain because it has inferred a type.  So I'll just show some quick demo of how this can, what this can look like. So if I were  to create a function called add contact, and I say I want a name and a phone. So this is  what you would have in classic JavaScript. So if I were to call this, hmm?  We don't see anything. Oh, sorry. The screen switch didn't work. All right. This should  work. All right. So what you're seeing now is classic. This, again, this is look like  JavaScript. And if I were to treat this as a black box, if I didn't know what this function  does, I would call it like so, and I'd see that here we have two parameters. I don't  know the type of that. So if I was, if I didn't know better, I guess that it's the first parameter's  name. Okay. Hmm. Probably if it has a name. That's true. And the second parameter's phone.  Yes, probably has an Android. So I don't know anything about how this expected to work.  So with TypeScript, I can give types to this. So you see, I can annotate this to be a string,  and then I will get a squiggly line here, which says, hey, the compiler won't be complaining.  So here it says that this input here does not match the signature. So in order to fix  this, I have to make this a string, and it will work. So I can continue adding a number  to, especially if the phone is the number, I'll get the same error here. And to fix that,  I will have to add a number here. So you see here, the compiler actually prevents me from  making silly mistakes. And I can also assign the return value from this function to be  a string. Again, the compiler will complain here because the function is not returning  anything. So I can return something here, and it will go away. So let's look at the  compiled code here. This is TypeScript, and here we have the JavaScript code. So again,  it's, if I just center this, the code looks really similar, just without types here. And  this last line here is just source mapping. That's used for debugging. So you can map a  line in TypeScript over to a line in JavaScript. So let's go back to the presentation. Does  this work? Yeah. Awesome. Great. Just going to go quickly through interfaces. Interfaces  can, you probably know what they can be used to, but declaring them looks like so. And  this, the only thing that's special here is that you have a way to say that this is optional.  You can choose to not include this in the type that implements this interface. So common  usage for interfaces is to have our class implement certain members, like a function  of fields. And you can also ensure that if you have a parameter that you pass your function,  you can ensure that this has some characteristic by using interfaces. And we're showing some  demos of interfaces along with other code. So classes is, again, this is what's been  proposed with ECMAScript 6. Classes are mostly like in other languages, but you should think  of it as a container in JavaScript. So you can have constructors in them. You can have  fields, functions. And if you are feeling really brave, you can actually use properties,  which is something that's not really good, really well-supported in older browsers. But  JavaScript has them. And you have this get set syntax for local fields. You actually have  wrap them, get some extra encapsulation. So I'm just going to do a demo of classes and  how they work. So in this example, I'm going to make, thank you, I'm going to forget that,  this worked better than last time. So I want to create a class called superhero, like so.  And you see on the right side here, it's already compiled that into JavaScript code. So you  see that actually creates quite sane, readable JavaScript code. This is the way I would have  done this if I wrote it in JavaScript. And now I'm going to create the constructor here.  And in this constructor, I'm going to pass in a parameter called name. I want that to  be of type string. So I want to assign that to a local field called name. And here the  compiler will complain because this class does not have that field. So I have to declare  it in the class. So the simplest way to do that is just like so. So now I have a local  field. And this is okay. This is the way you would have done it. But there's a shorthand  also for doing exactly the same thing. I can remove this too. And I can add public in front  of here. And it compiles to the same code and works the same way. So that's just a shorthand  for creating local fields. This can get messy if you don't use it correctly. So the next  thing I want to do is create an interface. So I'm going to create an interface called  I have superpowers. And that is going to force this implementation to have a method called  get superpower. And I want that to want to return string. So that's my interface. And  then I can say that this implements, this is things you can't do in JavaScript right  now. So you can't drive the design or enforce the design in your code right now in JavaScript.  You have to use other tools for that. So I say I have superpowers. And now the compiler  will complain again because, and it gives really good error messages here. So if you see here,  they says that the type super is missing the property get superpowers. So it's really helpful  here. So all I have to do is implement that is just say get super power. And I have to  implement this one and make sure that it returns a string. So clean code is my superpower.  So that works now. And also another thing, if I had returned the wrong type here, notice  that I haven't specified here which type this one returns. It's inferred and it therefore  matches with the interface. So if I had returned a number here instead, I would actually get  the compiler error. So it's a bit more discrete here. But here it says that it does not match.  Doesn't matter what it says. So the next thing I want to show you is concept of accessibility.  So this is public by default. I can actually add a private method in this code here. So  get secret power. And this one will not be visible from the outside. So if I declare  I have a hero, superhero, I can see that this object has get superpower and names, public  fields. But I don't see this one because that's not publicly available in this type. But it  was interesting here. In the compile code, you'll actually see that it's being defined  as a regular function on the object. This is because JavaScript don't have a notion  of public and private accessibility. So the last thing I want to show you in the classes  is sub-classing. So I can do a super-duper hero which extends a superhero. And here I  can also make a constructor. And this constructor I'll choose to take in a name and keep it  like so. And when you do constructors in TypeScript or in sub-classes, you always have to call  the super, use the super key word to call the constructor in the parent class. This is  an thing that's enforced. So now I have made a sub-class of this. Yes. So you see that  this is similar concepts that we already have in other languages. And again, doing this  in JavaScript would have required you to write something really similar to what you're seeing  here. It's not formatted as neatly, but you would have to do the same things here in JavaScript.  So let's go back to the presentation. Like so. All right. The next thing I want to show  is arrow functions. Arrow functions is simply just a short hand for writing methods. There's  one special behavior in TypeScript, and that is that it binds to this keyword lexical.  I will show you what that means by demo. But first, I just want to show the syntax of how  this looks. So this compiles down to this JavaScript code. And again, you see here the  input parameters goes here, and then you have a method body. And maybe this example is a  bit clearer. But here you have some code that compiles down to this. You assign the function  to a variable called sign, and then you pass in an input parameter, and you have a method  body. So this is all that this syntax does. And the main application for this is using,  for instance, working with callbacks in the user interface when a user clicks a button  or when they get WebSocket data or someone has triggered an event. And it's also really  useful for working with code that has functional style. So again, a demo. Hope you like demos,  because I have a lot of them. All right. So in this demo, I have created this web page  where I have a button here called demo button. Thank you very much for noticing. This is  something I should have prepared better. All right. Now you see. In this demo, I have  a web page here where I have a demo button on the web page, which I will use later. So  I'll create a new class called button handler, like so. In this class, I want to have a constructor  that takes in the HTML button. And the funny thing here is that in this demo, I'm actually  going to show you quite a few things about TypeScript. So in this, you have this DOM API  that's in the JavaScript already. And TypeScript has made strong typing upon that. So I actually  have an HTML button element that comes directly from the DOM. So I can say that I want a DOM  button of that type in my constructor. And I can actually just do like so. Then I have  a sign to the public field. And I also want this class to have a private field. So it's  a secret. Shh. Don't tell anyone. And what I'm going to show you now is a very classic  example of what it's a bit of a hassle doing the same in JavaScript. So I want to, on the  onclick event on the button, I want to trigger a callback. So I'm creating a function here  that will be the callback. And what's interesting thing here is it knows that this type is of  mouse event because that I'm using the strongly typed HTML button element. This is a quite  nice feature that you get by using this. So what I want to show you, I want to alert this.secret.  Like so. And in order for this to work, I'm going to show you another thing here. I want  to again have this DOM button as HTML button. So I want to declare a variable here. Then  I want to assign it on the line here. Document.getElementById, classic, no jQuery. And I call it the  demo button. Like so. And now I see the compiler complains here. And the reason for that is  that I get an HTML element back from this method. And I'm trying to assign it to something  that's an HTML button element. So now I can actually show you casting in TypeScript. And  you do that by using angled brackets like so. So this type inherits from HTML button.  So that's what I need to do to get this to compile. So now I can actually call the button  handler constructor and pass in my button like so. And this compiles. Now I can open this  web page. I hope it's a star here. So what have I done? Like so. I can open this web page  in my browser. And yes, I probably do that. So if I push this button now, I'm expected  to see shh, which was the local field. But I get undefined. And this is a regular problem  in JavaScript. And this is expected, by the way. And the reason for this is that when  you are doing callbacks in JavaScript like this, the disk keyword here actually points  to the element that triggered it. So it actually belongs to DOM button here in this context.  And the easiest way to fix this is by using arrow function. What arrow function does,  you see there was really not much change here in the code. But arrow function now binds  the disk keyword to the context. And the context here is that it's within a class. So this  now points on the class. So if I run the same code again, it's been compiled in the background,  I actually get the string that I expected to see here. So I think, yeah, that was what  I wanted to show in this demo. So, next one. So modules. Another great way of handling  encapsulation in TypeScript. They are similar to namespaces in C sharp and packages in Java.  And again, this is something we have, I think this is one of the issues in JavaScript right  now. And they have addressed it in ECMAScript 6 by adding modules there. But you can right  now have encapsulation in your code. And modules are really easy to import between code. So  it actually makes it easy to reuse code. And you can compile these modules to either common  JS or AMD. And if you don't know what that is, the best way to learn about that is actually  talk tomorrow that will be about required JS, which implements the AMD pattern. But it's  just a JavaScript or node way of actually getting source files between or runtime in  an asynchronously way. So the syntax for creating modules is like you expect. You can have classes,  functions and variables inside a module. And in order for them to be accessible outside  a module, you have to prefix them with the export keyword. That means that they are publicly  available. And if you don't have the keyword in front of them, they will be internal modules.  So you're going to have helper classes and helper functional local variables inside that  and not exposed. So it's a great feature. In real world, we are probably going to reference  a lot of modules in our projects. So there's two things here. There's something I call  internal modules. That is, if you don't have a big project and you are manually setting  the script blocks in the header in your HTML file, you can use internal modules. So all  you have to do then is just in top of each type script file, you have to add a comment  like so to tell it that, really, this file and use the types that are inside this one.  The downside by using internal modules is that you have to, if the application grows,  you have to keep the sequence of the scripts correctly. So you have to ensure that all  the scripts are loaded in the correct sequence up front. This doesn't scale very well. But  external modules is probably more scalable. And it is when you use, when you use like  a script loader, like require.js to handle this. I will show you in a demo how this actually  works. So I want to be showing a lot of the basic things. I actually go right into the  advanced thing. And I have prepared a demo here so I can actually just talk you through  it. So just switch over to duplicate. I remembered it this time. All right. So I prepared a web  page here which is using require.js. I already don't know this script. So the only thing  that require.js knows about is that when require.js is loaded, it is going to load a file called  main.js. That's the first thing that require is going to do. So in my TypeScript file, I  have told it to look for, again, this is the only place I have to declare TypeScript or  make the application know about TypeScript. So what I'm doing here is that I'm actually  saying, okay, you need to read the types that's inside this definition file. I'll come back  to that in the next demo. And that is the only place that you need to, again, know of  require. So what you do here is that use require syntax. What this means is that when you load  the application, look for a file called bootstrapper.js, load that entire module, and when that  module is loaded, it will then be passed into this function as a parameter. And on that  object, I have created a function called run app, which I will show you now. So the only  thing this one has, it exports a function called run app. You see, I don't have to wrap  this inside a module in this case because I'm using the external thing. And the interesting  thing here is that inside here, you don't see any require.js syntax. You actually see  that I import the module here. This actually looks for a file called view.ts. So I have  a dependency to that module. So if I go into this module, I see that I expose a class called  registration view. And again, I see that I have another dependency here. Again, there's  no require.js syntax. This is typescript syntax. And if I go into the utils, I see that this  is kind of a leaf node. So you see that I have nested dependencies here. And if I were  to handle that within the script block here, I had to know which dependency needed which  location, at which time. So you have to get the correct sequence. But if I'm really, really  lucky now, this should work in the browser. And I can show you what happens. So like so.  Yes. So let's check to console. Nope. And I know what's wrong here. There's an issue  with loading. Awesome. There it goes. So what it does now is that when I load the page,  require.js takes over and figures out which scripts need to be loaded first. So the only  two files that are loaded first here are require.js and main. Then it knows that busstrapper,  review and utils has to be loaded in sequence. And it handles all of this for me. So I don't  have to know about that. And that's a great feature for doing large-scale applications  because then you actually don't have to think about how the scripts are loaded. I think  that's one of the key elements to getting scalability.  All right. So. So. All right. I have something to say about parameters. I'm just going to  show you some slides here. There's some really useful new syntactical sugar that makes it  easy to write flexible functions. So you have default parameters, which means that you can  set the default value. So you can either call it like so or pass along a boolean value here.  This is really useful. And you also have optional parameters like I showed you earlier. So you  can actually choose to pass in options or not. So you can call this function in several  ways. And you also have something called rest parameters. This is also a part of ECMAScript  6, this thing, which you can compare to var args in C sharp. So what's going to happen  if you pass in, you can have an endless number of parameters here. But you get the first  one as the winner and the rest will actually just be in an array called the rest here because  that's what I called it. And we have something that I think is one of the coolest features  of TypeScript. It's type definition files. And before we show you them, I have to explain  what ambient declaration is. It's a way of saying to TypeScript that, chill, I know that  I get this variable from somewhere outside TypeScript. Typically, if you have loaded TypeScript  in the script tag earlier. So just chill. I know what I'm doing. That's what you're saying  to TypeScript. And it also, if you do use the clear word, it will actually not include  this variable assignment in the compile code. So you just omit it totally. And there's something  called type definition file. These are just a single file that defines all the signatures  of the library that you're using or dependent on. For instance, if you're using jquery.js,  TypeScript won't know about the types that it has. But by using definition files, you  can actually get strong typing on jquery. So you can actually use it in a strong manner  in the TypeScript files. This actually means that you get all the completion help and intelligence  on jquery. That's really helpful. And the way this works is that you use this reference  thing I showed you earlier in the top. And all of these type definition files does add  an ambient declaration to say that this variable exists somewhere in the code. And there's  a project, or a GitHub repository called definitively typed, which is a great repository for finding  all kinds of definition files. So you'll probably find the framework you're using. So you knock  out Angular, jquery, node, require.js. Yeah, it has a lot here. So you'll probably find  some of the frameworks you're already using. So don't have to create these files yourself.  So I'm going to show you quickly how this works. Like so. Just close all these files.  I have now a definition file for jquery. And again, all it contains is just interfaces.  It does not contain any implementation of jquery. So you can just see that it contains a lot  of interfaces here and different functions. This doesn't say anything much like so. But  what you can do is if I am writing a jquery function here, I can actually just write it  like so. If I have to write something like this. And I don't get any auto-completion  here because it doesn't know what type this returns to me. So I know there's a text probably,  or maybe there's a function called add. I don't know. Can add some text. Hello. And this  doesn't work. What I could do just to get the compiler off my back, I could use declare  variable here. Again, I know what I'm doing. I know this library works and I have loaded  this already. It's not strongly typed. So that's the simplest way to get it to work.  But I can actually do one better. I can actually use this type file. Like so. You see it actually  adds now reference to that file. And what that does is give me strong typing now. So  now it knows that the type of this dollar here is of type jquery static. And that means  that I actually get strong tooling here as well. So now I can actually browse all the  possible methods I can use on this type. I think that's a great thing. So if I were  to call, for instance, text now, can I set the text or can I get the text? Let me see.  Okay. Here I have all the overloads of this one. So I can actually scan through those.  So I see, okay, this takes in a string and I can return, it can return a string. Great.  So you actually can, if you're new with the framework, you can actually easily learn this.  And a great example to show that is actually underscore. I don't know how many have tried  underscore, but don't have that definition following, but I can try installing it. So  I'm using NuGet package manager to just get this source file. And it, so I have it on  the file system. I'll just browse it. Code, demo, packages underscore. Okay. This is great.  Like so. I can just drag it into there. Nope. Like so. And now we shall do is again. So  and again, I always look up the documentation underscore. So again, I can just reference  reference.file. This is way, is dragging and dropping it. That is a plugin called web  essential that helps me out with this. So now I get the code completion on underscore.  And that's, I need that a lot to help me understand how I do, for instance, the reduce function.  What do I do there? So I can actually see the signature here, what, the sequence of parameters  here. So back to slides. How am I doing on time? 20 minutes or so. All right. I want  to talk a bit about tooling. TypeScript has already gained a lot of support in IDs and  tools. It works best in Visual Studio right now, because it makes it and also makes the  plugin. But you also get good support in Cloud9 and Sublime has a nice package that helps  you compile and gives you syntax highlighting and some auto completion as well. So I think  this is just an indication that there is many that invested time in TypeScript already,  even though it's still a preview. And there have already appeared some community tools  around TypeScript. We see, for instance, TypeScript definition package manager is a tool to download  those definitions file like you do with Node package manager. So it actually worsens it  and lets you easily update this if you want to. And web essential is a must have for Visual  Studio if you are using Visual Studio. It allows you to configure how the compiler works and  gives you some extra features with TypeScript. So I just want to give you a high-level overview  of how TypeScript compares to TypeScript in Google Start just to know what the main difference  is. Comparing it to TypeScript, we see that TypeScript has a much higher abstraction of  JavaScript than what TypeScript has. Again, TypeScript is just a superset while TypeScript  tries to lend style from both Ruby and Python. So we have more functional approach to developing  JavaScript. And it's great for its purpose. And also it has much simpler class concept,  but still it has this way of helping with encapsulation. But JavaScript in itself does  not give you anything about help with file loading and dependency management. You've  probably seen usage of Node in TypeScript that handles that. And Google Start. I haven't  coded anything in Google Dart myself. But that's completely new language inspired by  C syntax. So you can't just reuse your current skill set in JavaScript like you can with  TypeScript. And it actually tries to solve many of JavaScript's inherent problems. But  it gives you also many of the same constructs that you have already in TypeScript. But Dart  has a lot more of them, language constructs. And there's a potential vendor lock-in. Again,  you have this Dart VM, which is a part of Chrome that runs Dart without compiling into  JavaScript. But you don't have to do that. You can also compile that to JavaScript. The  resulting file is really big. And it also received some criticism from really, from  Brendan Eich and Douglas Crockford, who are some notable characters in the JavaScript  community. Brendan Eich actually created JavaScript. So that's just comparing it to those two.  And one thing that's important to notice is that JavaScript is getting there. JavaScript  will get classes, will get modules. It will get many of these modern features. But ECMAScript  6 is still a draft and it's not completed. And when that is completed, the implementation  will start. And when the implementation starts, it will take some time for it to get implemented  in all the modern browsers. And I have no idea how much time this will take, but unqualified  guest is two to three years. And it will be really similar to what TypeScript is now,  but TypeScript will have types and some more. So JavaScript is still a subset of TypeScript  when it's done or released. So TypeScript is, like I said, it's still a preview. It's not  finished. But there has recently been released a new version for preview that actually has  generics and some performance tweaks. And adding generics is a really cool feature.  So you can actually implement the link, language in the great query in TypeScript. So I don't  know if anyone has started that, but it's an interesting feature to have in that language.  And for when the language is completed, there is a plan to add async and await support,  sharp keywords. And I think that is a really, really cool thing to add to this language.  Because right now we are doing callbacks and we can actually just use the async keyword  or await keyword in order to do this the same way as we do in C sharp 5. For those of you  who have tried it, I think that will make the code easier to read and more easy to follow.  And it will also add mix-ins to language. That's an interesting feature that the, because  JavaScript is dynamic language, you can actually do mix-ins. And having that in TypeScript as  well is really useful. So I promised you, I'll tell you about where  the dragons are. But there are not many and they're not that severe. One thing to be aware  of is using TypeScript or trying to use TypeScript in existing JavaScript frameworks like Angular.  Angular actually tries to solve many of the problems that, or tries to make it easier  to create JavaScript application. And it is designed entirely for JavaScript.  And many of the things it tries to solve is not necessary to solve in TypeScript. So,  and this is not just an Angular problem, but some frameworks might be difficult to use  in TypeScript. So be aware of this. Don't try to use, for instance, one of the problems  with Angular is that it's based on functions and functional design. And you don't need  to need that in a TypeScript application. There are other ways of solving this.  So a tip might be looking for a dedicated TypeScript framework that works better.  So another thing is that there's a lot of syntactical shortcuts that you can use. But  I'm pretty sure that you will end up with really messy code that's unreadable if you  use this without caution. Especially you can actually do inline Type specification of interfaces.  That means that you can actually, instead of creating an interface outside, in another  place in the code, you can just write the interface declaration then and there. And  you have, and you can also nest the modules that you're declaring really deeply and try  to avoid that. And when using arrow functions, you can also, again, you can make these two  complex for it to be readable. Again, it's still a preview. There are bugs in TypeScript,  especially around when you use the property get and get and set properties. There are  some known bugs there. And protected accessibility is not implemented yet. It's planned in a  future release. So if you do subclassing, you don't have the keyword protect to make  a field available to your children. And there are still features that need improvement.  For instance, modules and the way you import modules need some improvement just on syntactical  sugar in order to ease up how this is done. So I'm going to just look back at what we  have been through. We've seen that we learn what TypeScript is. We have taken a deep dive  into all the new features, almost important features. We have looked at how we can actually  do dependency management in real world application, and compare it to some languages. And we see  what's happening right now with both JavaScript and TypeScript. And what we can take out of  this is that by having a compiler, you can actually eliminate a lot of bugs that you  usually would find around time with JavaScript. You get strong typing and thereby strong tooling  in your IDEs. So it makes it easier to refactor, you can actually refactor TypeScript code in  your ID. You get more encapsulation, and you have mechanisms to simplify dependency  management and, again, ID support. And it actually also lowers the threshold for beginning  with JavaScript. So I personally think that the threshold for a developer that has not  done JavaScript development is quite high right now if you wanted to start with JavaScript.  But working with TypeScript, I think that might be a bit easier because you have constructs  from object-oriented programming. So it will be a lot of pressure. You can reuse more of  your existing knowledge. There are a few advantages for large-scale applications. You can actually  build more robust apps. You have a strong typing that helps you and ensure that you have correctness  throughout your application, at least when it comes to the typing. An interesting case,  I experienced once, we were free developers working on a codebase, and we had interfaces  for different commands we sent to the server. And at one time, one of us changed added a  new field to this interface. And what happened then? We had three builders, and then we could  actually find the three places in our codebase that we needed to update in order to conform  to this new interface. So that was just an example of how you can get more robustness  out of using typing. And you can also enforce design. You can actually do design patterns  now, more easily at least. I don't know if it makes sense in TypeScript, but at least  you have the mechanisms to drive the design. So you, as a... If you are developing a framework,  you can actually make it really easy to use that framework for other developers. And you  get more maintainable apps. This is probably what the enterprises want. They want something  that is maintainable. I think JavaScript is... Might be a difficult technology to choose  if you're enterprise and want to... And you don't have JavaScript resources. So this  makes it easier. And you, again, it might be easier to train or get developers that know  TypeScript or object-oriented design. And for small scale apps, it's not that much to  gain on using TypeScript, but you get a simplified build process. If you're using Visual Studio,  just compile when you save. You get less bootstrapping. You don't have to do as much to get your application  up and running. You can just use the internal module references and things will work. And  I think probably the biggest win is the strong tooling where you get autocomplete help in  your IDE. And I think that's actually one of the things I've liked the most. So that  was actually... I want more thing I can actually show you. Just for a little wow effect here.  So this is the first time I actually used a GIF in a presentation. Do you like it? All  right. I will now have to see if I have a file for this. All right. I'll actually create  a new file for this. So add... Again, I have to switch here. All right. I'm going to scroll  down to add a new TypeScript file here. And the setting I'm in right now is that I'm  creating a Twitter application. So what I'm doing, I'm going to create something that  gets a list of tweets or the timeline from Twitter. And if I were to do this with strong  typing, I would have to go into the documentation. So I could go here and read the documentation  for that query. So here all the parameters are described. And I would have to copy them  into... Make interfaces out of this manually. But there is a cool little trick you can do.  So if I just copy this one, which is one of the parts. And this is just a JSON file,  not just a JSON code. So I have this feature in a web potential called paste JSON as classes.  So if I do that, like so. I have to ensure that I haven't get... I have to take more or  less of this. Again, wow effect. No, it's without them, I think. Yeah, it's without them. It's  supposed to work like so. There we go. So what we see now is this is the... I can actually  just call this the timeline. So what I have now, now I have a strongly typed type for  entire return object here. So it has created it. So small modifications I can actually  now have strong types. So if I were to have a jQuery function that looks something like  this. So if I had something like.get timeline and in the call box I get this data, I can  say that this data is of type... time... Twitter timeline. So now actually in the response,  I could actually code knowing which fields were present in this. I don't know if this  works. Yeah, so I can actually navigate the return structure here. So I think that's one  of the cool features. So that was what I wanted to show you today. So are there any questions?  I will be putting this presentation up on slide deck later. So if you want to... why  don't it fix my presentation? Yeah, the cable here is a bit loose. Yeah, you probably managed  to read that, right? So I don't know why it's not switching over to... try this. Let me  do like so. Okay, you can reach me at Twitter. For instance, I'm going to post the links  to the slides on Twitter afterwards. And if you want to see the code, I can probably put  it up in GitHub. So the last thing I want to say, remember to vote outside using this,  hopefully this green one. So thank you for your attention today and have a good conference.
Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_0_107.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_108_1175.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_1176_2027.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_2028_2087.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_2088_2339.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_2340_3599.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_3600_6227.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_6228_7655.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_7656_7715.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_7716_9203.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_9204_9911.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_9912_10655.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_10656_10727.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_10728_10787.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_10788_15719.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_15720_18419.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_18420_18479.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_18480_18539.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_18540_18659.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_18660_19787.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_19788_21395.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_21396_21527.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_21528_21635.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_21636_24311.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_24312_28127.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_28128_28175.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_28176_30383.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_30384_31211.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_31212_36731.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_36732_36779.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_36780_36839.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_36840_40847.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_40848_41147.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_41148_42251.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_42252_42311.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_42312_42359.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_42360_46295.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_46296_46367.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_46368_46511.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_46512_50639.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_50640_51347.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_51348_51431.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_51432_51479.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_51480_51947.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_51948_56759.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_56760_56963.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_56964_57011.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_57012_57323.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_57324_57395.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_57396_62843.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_62844_68987.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_68988_72587.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_72588_74183.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_74184_74447.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_74448_75107.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_75108_75983.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_75984_77051.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_77052_77099.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_77100_79379.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_79380_80039.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80040_80123.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80124_80267.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80268_80315.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80316_80363.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80364_80495.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80496_80543.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80544_80651.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_80652_81227.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_81228_81311.png Torstein_Nicolaysen_-_All_you_need_to_know_about_TypeScript-68236434_81312_81411.png
So, welcome everyone. I'm glad to see that so many actually showed up here. It was quite – I had some competition at this time now with Uncle Bob and another JavaScript check, so I'm actually quite pleased with how many have – that have showed up. So, my name is Torsen Nikolajsen. I work as a senior consultant at Beck Consulting here in Oslo. I've been doing web development for many years now and I've been doing a lot of JavaScript the last few years. If you want to contact me, you can reach me at Twitter, LinkedIn or Google Plus using my username here. So, I know why you guys are here. Like I said, you have actually chosen this track now. There's a lot of other interesting things. So, I guess all of you are actually motivated to learn TypeScript today. And I won't spend that much time motivating you and explaining why we need TypeScript. I'll just mention it shortly. And an interesting thing was that during the earlier sessions here, John Syme, when he was talking about F-Sharp mentioned JavaScript. And I'll come back to that a bit later. So, I was actually going to do a pun here with walking you down memory lane, just explaining why we actually – I was going to explain all the troubles that we have had with JavaScript over the years. And actually, I also just wanted to show you this drawing, which I love, just to tell you about the browser wars and how we have come to a standardized way of doing web development right now. So, let's just take a quick look back at how we did JavaScript development when it started booming. So, we did – I have to say this before we start – I really like JavaScript, so I'm not going to trash talk JavaScript. But if you look back, many developers neglected JavaScript as a programming language. It didn't consider it a true programming language. So, actually, people actually wrote jQuery, not JavaScript. And many of the apps they generated was just one huge file called script.js, which was unmaintainable, and only one guy knew how to do stuff in it. It was the spaghetti code. But we have gotten a lot better the recent years. There has been a lot of focus on JavaScript, and it has established the stages as a real programming language now. And we actually managed to build quite large applications today. Just have a look at Gmail, Facebook, Trello, and Cloud9 IDE. Cloud9 is actually almost entirely written in JavaScript, both frontend and backend. And that's impressive. But in order to build these big applications, we require tools that lie outside JavaScript. We have to have script managers like – or dependency tools like Require.js. And in order to build this in a smooth fashion, we require tools like Grunt, or we have to use something in Maven, or in MS Build, or extra steps. We have to do a lot of extra. And once we have managed to build a quite large application, if we don't follow all the good practices, design practices on how to do proper JavaScript, and we try to fix one thing, it all just falls apart. And the reason for that is that there is a little glue that holds JavaScript apps together right now. The only glue that is common is unit test and integration test in JavaScript code. And you guys know that we aren't doing enough of that. So when we write JavaScript, we can easily refactor code or do stuff like that to it. And the reason is twofold. Again, we developers tend to neglect JavaScript as a language, and we also don't do all the good practices. And JavaScript as a language don't have that many means of encapsulating and structuring your code. You can use closures and stuff like that to simulate that you have some scoping. But that doesn't work really well in large scale, in my opinion. So I'm going to tell you today how TypeScript can help to mitigate some of these issues. So today we'll be looking at what TypeScript is. We'll dive right into some features, and I'll be doing a lot of live coding throughout the sessions. And we'll be looking at the ecosystem that TypeScript exists in, and I'll do a recap and give you my final thoughts on what is happening right now with TypeScript and what is going to probably happen in the short future. So let's just check out what TypeScript is on a high level there. It is technically a super set of JavaScript. That means that it actually has all the features and syntax features of JavaScript, but it's just adding more features on top of this. So you can actually write JavaScript inside of TypeScript. It will still compile. And it is one of those languages that compile down to JavaScript, so you don't need a browser plugin like Google Dart has actually. It requires you to either compile to JavaScript or run it as a Dart VM. So this compiles down to good JavaScript code. And you can compile it using the official node package, or you can actually use a Visual Studio plugin which makes this really smooth in Visual Studio at least. Like many other things in the JavaScript ecosystem, TypeScript is also open source. All the code is actually available on Codeplex and can follow the development, track the issues, and actually talk to developers. And it's worth noticing that this is actually a Microsoft initiative to write TypeScript. And that brings us over to this cheery looking guy, Anders Helsberg. He's most notably known as the lead architect for C Sharp. And I think that lends credibility as he is actually the designer of TypeScript as well. You can see that his previous work on C Sharp influences the way that TypeScript works. So if you like C Sharp, you will see some familiar elements in TypeScript. Another brilliant decision of the team that is creating TypeScript is to align it with the upcoming ECMAScript 6 standard. If you don't know what ECMAScript is, the simplest way to put it is that it is the standard for JavaScript. You can think of this as that. And the next version of ECMAScript, version 6, defines how classes and modules should work and some other language constructs. So by aligning with this, that means that TypeScript will look very similar to what JavaScript will look in the future. Another benefit is TypeScript has already implemented some of these features that are still a draft now. And that means that you can actually use classes and modules now instead of waiting for JavaScript to come along and add that. So let's look at some of the new features in TypeScript. We will be looking into type annotations, classes, interfaces, modules, our functions, and a few more during this session. So TypeScript is probably one of the most unique features in TypeScript. It works pretty much like you expected to work in other languages. And you can apply Types to objects, parameters, fields, and return values and some other things in the language. You have some primitive types that is unique for TypeScript. It's string number, and number is not, you can't separate between integer and float numbers. It's the same number type that you have in JavaScript, which is the float. And you have the boolean and you have any type. The any type is the default fallback type. So if you don't specify a type on a variable, then it will be of type annus. You can assign anything to it. And you have something called void. You have that in C sharp, of course, but JavaScript does not have that concept. So in TypeScript, you can explicitly say that this function does not return a value by using void, as you would do in C sharp. Another brilliant thing about TypeScript is that it uses, it gives you the option to choose whether you want to use types or not. And this has two advantages. You can actually migrate your code base, existing JavaScript code base over to TypeScript by applying types step by step by step as you go along. And another thing is that you can use types where you like. This is one of the things that Don Seim talked about earlier with F sharp. You have statically typed languages and dynamically and you have something in between. And that's where TypeScript is right now. You can choose what you want. So you get the best of both worlds. So let's look at some syntax. This is a classic thing you would see in JavaScript. And since I haven't annotated with the type, the type is annie here. That means I can assign a number to it. I can assign a string. And I can assign an object to it. No problem. So I can also do static typing. Here I say that this variable should be a string. So if I try to assign a number to it, the compiler will give me a warning here. So, and TypeScript also has type inference. That means if I declare the assigned value of the variable at the same time as I declare it like so, it will inference that offer is a string. And therefore, if I later try to assign a number to it, it will complain because it has inferred a type. So I'll just show some quick demo of how this can, what this can look like. So if I were to create a function called add contact, and I say I want a name and a phone. So this is what you would have in classic JavaScript. So if I were to call this, hmm? We don't see anything. Oh, sorry. The screen switch didn't work. All right. This should work. All right. So what you're seeing now is classic. This, again, this is look like JavaScript. And if I were to treat this as a black box, if I didn't know what this function does, I would call it like so, and I'd see that here we have two parameters. I don't know the type of that. So if I was, if I didn't know better, I guess that it's the first parameter's name. Okay. Hmm. Probably if it has a name. That's true. And the second parameter's phone. Yes, probably has an Android. So I don't know anything about how this expected to work. So with TypeScript, I can give types to this. So you see, I can annotate this to be a string, and then I will get a squiggly line here, which says, hey, the compiler won't be complaining. So here it says that this input here does not match the signature. So in order to fix this, I have to make this a string, and it will work. So I can continue adding a number to, especially if the phone is the number, I'll get the same error here. And to fix that, I will have to add a number here. So you see here, the compiler actually prevents me from making silly mistakes. And I can also assign the return value from this function to be a string. Again, the compiler will complain here because the function is not returning anything. So I can return something here, and it will go away. So let's look at the compiled code here. This is TypeScript, and here we have the JavaScript code. So again, it's, if I just center this, the code looks really similar, just without types here. And this last line here is just source mapping. That's used for debugging. So you can map a line in TypeScript over to a line in JavaScript. So let's go back to the presentation. Does this work? Yeah. Awesome. Great. Just going to go quickly through interfaces. Interfaces can, you probably know what they can be used to, but declaring them looks like so. And this, the only thing that's special here is that you have a way to say that this is optional. You can choose to not include this in the type that implements this interface. So common usage for interfaces is to have our class implement certain members, like a function of fields. And you can also ensure that if you have a parameter that you pass your function, you can ensure that this has some characteristic by using interfaces. And we're showing some demos of interfaces along with other code. So classes is, again, this is what's been proposed with ECMAScript 6. Classes are mostly like in other languages, but you should think of it as a container in JavaScript. So you can have constructors in them. You can have fields, functions. And if you are feeling really brave, you can actually use properties, which is something that's not really good, really well-supported in older browsers. But JavaScript has them. And you have this get set syntax for local fields. You actually have wrap them, get some extra encapsulation. So I'm just going to do a demo of classes and how they work. So in this example, I'm going to make, thank you, I'm going to forget that, this worked better than last time. So I want to create a class called superhero, like so. And you see on the right side here, it's already compiled that into JavaScript code. So you see that actually creates quite sane, readable JavaScript code. This is the way I would have done this if I wrote it in JavaScript. And now I'm going to create the constructor here. And in this constructor, I'm going to pass in a parameter called name. I want that to be of type string. So I want to assign that to a local field called name. And here the compiler will complain because this class does not have that field. So I have to declare it in the class. So the simplest way to do that is just like so. So now I have a local field. And this is okay. This is the way you would have done it. But there's a shorthand also for doing exactly the same thing. I can remove this too. And I can add public in front of here. And it compiles to the same code and works the same way. So that's just a shorthand for creating local fields. This can get messy if you don't use it correctly. So the next thing I want to do is create an interface. So I'm going to create an interface called I have superpowers. And that is going to force this implementation to have a method called get superpower. And I want that to want to return string. So that's my interface. And then I can say that this implements, this is things you can't do in JavaScript right now. So you can't drive the design or enforce the design in your code right now in JavaScript. You have to use other tools for that. So I say I have superpowers. And now the compiler will complain again because, and it gives really good error messages here. So if you see here, they says that the type super is missing the property get superpowers. So it's really helpful here. So all I have to do is implement that is just say get super power. And I have to implement this one and make sure that it returns a string. So clean code is my superpower. So that works now. And also another thing, if I had returned the wrong type here, notice that I haven't specified here which type this one returns. It's inferred and it therefore matches with the interface. So if I had returned a number here instead, I would actually get the compiler error. So it's a bit more discrete here. But here it says that it does not match. Doesn't matter what it says. So the next thing I want to show you is concept of accessibility. So this is public by default. I can actually add a private method in this code here. So get secret power. And this one will not be visible from the outside. So if I declare I have a hero, superhero, I can see that this object has get superpower and names, public fields. But I don't see this one because that's not publicly available in this type. But it was interesting here. In the compile code, you'll actually see that it's being defined as a regular function on the object. This is because JavaScript don't have a notion of public and private accessibility. So the last thing I want to show you in the classes is sub-classing. So I can do a super-duper hero which extends a superhero. And here I can also make a constructor. And this constructor I'll choose to take in a name and keep it like so. And when you do constructors in TypeScript or in sub-classes, you always have to call the super, use the super key word to call the constructor in the parent class. This is an thing that's enforced. So now I have made a sub-class of this. Yes. So you see that this is similar concepts that we already have in other languages. And again, doing this in JavaScript would have required you to write something really similar to what you're seeing here. It's not formatted as neatly, but you would have to do the same things here in JavaScript. So let's go back to the presentation. Like so. All right. The next thing I want to show is arrow functions. Arrow functions is simply just a short hand for writing methods. There's one special behavior in TypeScript, and that is that it binds to this keyword lexical. I will show you what that means by demo. But first, I just want to show the syntax of how this looks. So this compiles down to this JavaScript code. And again, you see here the input parameters goes here, and then you have a method body. And maybe this example is a bit clearer. But here you have some code that compiles down to this. You assign the function to a variable called sign, and then you pass in an input parameter, and you have a method body. So this is all that this syntax does. And the main application for this is using, for instance, working with callbacks in the user interface when a user clicks a button or when they get WebSocket data or someone has triggered an event. And it's also really useful for working with code that has functional style. So again, a demo. Hope you like demos, because I have a lot of them. All right. So in this demo, I have created this web page where I have a button here called demo button. Thank you very much for noticing. This is something I should have prepared better. All right. Now you see. In this demo, I have a web page here where I have a demo button on the web page, which I will use later. So I'll create a new class called button handler, like so. In this class, I want to have a constructor that takes in the HTML button. And the funny thing here is that in this demo, I'm actually going to show you quite a few things about TypeScript. So in this, you have this DOM API that's in the JavaScript already. And TypeScript has made strong typing upon that. So I actually have an HTML button element that comes directly from the DOM. So I can say that I want a DOM button of that type in my constructor. And I can actually just do like so. Then I have a sign to the public field. And I also want this class to have a private field. So it's a secret. Shh. Don't tell anyone. And what I'm going to show you now is a very classic example of what it's a bit of a hassle doing the same in JavaScript. So I want to, on the onclick event on the button, I want to trigger a callback. So I'm creating a function here that will be the callback. And what's interesting thing here is it knows that this type is of mouse event because that I'm using the strongly typed HTML button element. This is a quite nice feature that you get by using this. So what I want to show you, I want to alert this.secret. Like so. And in order for this to work, I'm going to show you another thing here. I want to again have this DOM button as HTML button. So I want to declare a variable here. Then I want to assign it on the line here. Document.getElementById, classic, no jQuery. And I call it the demo button. Like so. And now I see the compiler complains here. And the reason for that is that I get an HTML element back from this method. And I'm trying to assign it to something that's an HTML button element. So now I can actually show you casting in TypeScript. And you do that by using angled brackets like so. So this type inherits from HTML button. So that's what I need to do to get this to compile. So now I can actually call the button handler constructor and pass in my button like so. And this compiles. Now I can open this web page. I hope it's a star here. So what have I done? Like so. I can open this web page in my browser. And yes, I probably do that. So if I push this button now, I'm expected to see shh, which was the local field. But I get undefined. And this is a regular problem in JavaScript. And this is expected, by the way. And the reason for this is that when you are doing callbacks in JavaScript like this, the disk keyword here actually points to the element that triggered it. So it actually belongs to DOM button here in this context. And the easiest way to fix this is by using arrow function. What arrow function does, you see there was really not much change here in the code. But arrow function now binds the disk keyword to the context. And the context here is that it's within a class. So this now points on the class. So if I run the same code again, it's been compiled in the background, I actually get the string that I expected to see here. So I think, yeah, that was what I wanted to show in this demo. So, next one. So modules. Another great way of handling encapsulation in TypeScript. They are similar to namespaces in C sharp and packages in Java. And again, this is something we have, I think this is one of the issues in JavaScript right now. And they have addressed it in ECMAScript 6 by adding modules there. But you can right now have encapsulation in your code. And modules are really easy to import between code. So it actually makes it easy to reuse code. And you can compile these modules to either common JS or AMD. And if you don't know what that is, the best way to learn about that is actually talk tomorrow that will be about required JS, which implements the AMD pattern. But it's just a JavaScript or node way of actually getting source files between or runtime in an asynchronously way. So the syntax for creating modules is like you expect. You can have classes, functions and variables inside a module. And in order for them to be accessible outside a module, you have to prefix them with the export keyword. That means that they are publicly available. And if you don't have the keyword in front of them, they will be internal modules. So you're going to have helper classes and helper functional local variables inside that and not exposed. So it's a great feature. In real world, we are probably going to reference a lot of modules in our projects. So there's two things here. There's something I call internal modules. That is, if you don't have a big project and you are manually setting the script blocks in the header in your HTML file, you can use internal modules. So all you have to do then is just in top of each type script file, you have to add a comment like so to tell it that, really, this file and use the types that are inside this one. The downside by using internal modules is that you have to, if the application grows, you have to keep the sequence of the scripts correctly. So you have to ensure that all the scripts are loaded in the correct sequence up front. This doesn't scale very well. But external modules is probably more scalable. And it is when you use, when you use like a script loader, like require.js to handle this. I will show you in a demo how this actually works. So I want to be showing a lot of the basic things. I actually go right into the advanced thing. And I have prepared a demo here so I can actually just talk you through it. So just switch over to duplicate. I remembered it this time. All right. So I prepared a web page here which is using require.js. I already don't know this script. So the only thing that require.js knows about is that when require.js is loaded, it is going to load a file called main.js. That's the first thing that require is going to do. So in my TypeScript file, I have told it to look for, again, this is the only place I have to declare TypeScript or make the application know about TypeScript. So what I'm doing here is that I'm actually saying, okay, you need to read the types that's inside this definition file. I'll come back to that in the next demo. And that is the only place that you need to, again, know of require. So what you do here is that use require syntax. What this means is that when you load the application, look for a file called bootstrapper.js, load that entire module, and when that module is loaded, it will then be passed into this function as a parameter. And on that object, I have created a function called run app, which I will show you now. So the only thing this one has, it exports a function called run app. You see, I don't have to wrap this inside a module in this case because I'm using the external thing. And the interesting thing here is that inside here, you don't see any require.js syntax. You actually see that I import the module here. This actually looks for a file called view.ts. So I have a dependency to that module. So if I go into this module, I see that I expose a class called registration view. And again, I see that I have another dependency here. Again, there's no require.js syntax. This is typescript syntax. And if I go into the utils, I see that this is kind of a leaf node. So you see that I have nested dependencies here. And if I were to handle that within the script block here, I had to know which dependency needed which location, at which time. So you have to get the correct sequence. But if I'm really, really lucky now, this should work in the browser. And I can show you what happens. So like so. Yes. So let's check to console. Nope. And I know what's wrong here. There's an issue with loading. Awesome. There it goes. So what it does now is that when I load the page, require.js takes over and figures out which scripts need to be loaded first. So the only two files that are loaded first here are require.js and main. Then it knows that busstrapper, review and utils has to be loaded in sequence. And it handles all of this for me. So I don't have to know about that. And that's a great feature for doing large-scale applications because then you actually don't have to think about how the scripts are loaded. I think that's one of the key elements to getting scalability. All right. So. So. All right. I have something to say about parameters. I'm just going to show you some slides here. There's some really useful new syntactical sugar that makes it easy to write flexible functions. So you have default parameters, which means that you can set the default value. So you can either call it like so or pass along a boolean value here. This is really useful. And you also have optional parameters like I showed you earlier. So you can actually choose to pass in options or not. So you can call this function in several ways. And you also have something called rest parameters. This is also a part of ECMAScript 6, this thing, which you can compare to var args in C sharp. So what's going to happen if you pass in, you can have an endless number of parameters here. But you get the first one as the winner and the rest will actually just be in an array called the rest here because that's what I called it. And we have something that I think is one of the coolest features of TypeScript. It's type definition files. And before we show you them, I have to explain what ambient declaration is. It's a way of saying to TypeScript that, chill, I know that I get this variable from somewhere outside TypeScript. Typically, if you have loaded TypeScript in the script tag earlier. So just chill. I know what I'm doing. That's what you're saying to TypeScript. And it also, if you do use the clear word, it will actually not include this variable assignment in the compile code. So you just omit it totally. And there's something called type definition file. These are just a single file that defines all the signatures of the library that you're using or dependent on. For instance, if you're using jquery.js, TypeScript won't know about the types that it has. But by using definition files, you can actually get strong typing on jquery. So you can actually use it in a strong manner in the TypeScript files. This actually means that you get all the completion help and intelligence on jquery. That's really helpful. And the way this works is that you use this reference thing I showed you earlier in the top. And all of these type definition files does add an ambient declaration to say that this variable exists somewhere in the code. And there's a project, or a GitHub repository called definitively typed, which is a great repository for finding all kinds of definition files. So you'll probably find the framework you're using. So you knock out Angular, jquery, node, require.js. Yeah, it has a lot here. So you'll probably find some of the frameworks you're already using. So don't have to create these files yourself. So I'm going to show you quickly how this works. Like so. Just close all these files. I have now a definition file for jquery. And again, all it contains is just interfaces. It does not contain any implementation of jquery. So you can just see that it contains a lot of interfaces here and different functions. This doesn't say anything much like so. But what you can do is if I am writing a jquery function here, I can actually just write it like so. If I have to write something like this. And I don't get any auto-completion here because it doesn't know what type this returns to me. So I know there's a text probably, or maybe there's a function called add. I don't know. Can add some text. Hello. And this doesn't work. What I could do just to get the compiler off my back, I could use declare variable here. Again, I know what I'm doing. I know this library works and I have loaded this already. It's not strongly typed. So that's the simplest way to get it to work. But I can actually do one better. I can actually use this type file. Like so. You see it actually adds now reference to that file. And what that does is give me strong typing now. So now it knows that the type of this dollar here is of type jquery static. And that means that I actually get strong tooling here as well. So now I can actually browse all the possible methods I can use on this type. I think that's a great thing. So if I were to call, for instance, text now, can I set the text or can I get the text? Let me see. Okay. Here I have all the overloads of this one. So I can actually scan through those. So I see, okay, this takes in a string and I can return, it can return a string. Great. So you actually can, if you're new with the framework, you can actually easily learn this. And a great example to show that is actually underscore. I don't know how many have tried underscore, but don't have that definition following, but I can try installing it. So I'm using NuGet package manager to just get this source file. And it, so I have it on the file system. I'll just browse it. Code, demo, packages underscore. Okay. This is great. Like so. I can just drag it into there. Nope. Like so. And now we shall do is again. So and again, I always look up the documentation underscore. So again, I can just reference reference.file. This is way, is dragging and dropping it. That is a plugin called web essential that helps me out with this. So now I get the code completion on underscore. And that's, I need that a lot to help me understand how I do, for instance, the reduce function. What do I do there? So I can actually see the signature here, what, the sequence of parameters here. So back to slides. How am I doing on time? 20 minutes or so. All right. I want to talk a bit about tooling. TypeScript has already gained a lot of support in IDs and tools. It works best in Visual Studio right now, because it makes it and also makes the plugin. But you also get good support in Cloud9 and Sublime has a nice package that helps you compile and gives you syntax highlighting and some auto completion as well. So I think this is just an indication that there is many that invested time in TypeScript already, even though it's still a preview. And there have already appeared some community tools around TypeScript. We see, for instance, TypeScript definition package manager is a tool to download those definitions file like you do with Node package manager. So it actually worsens it and lets you easily update this if you want to. And web essential is a must have for Visual Studio if you are using Visual Studio. It allows you to configure how the compiler works and gives you some extra features with TypeScript. So I just want to give you a high-level overview of how TypeScript compares to TypeScript in Google Start just to know what the main difference is. Comparing it to TypeScript, we see that TypeScript has a much higher abstraction of JavaScript than what TypeScript has. Again, TypeScript is just a superset while TypeScript tries to lend style from both Ruby and Python. So we have more functional approach to developing JavaScript. And it's great for its purpose. And also it has much simpler class concept, but still it has this way of helping with encapsulation. But JavaScript in itself does not give you anything about help with file loading and dependency management. You've probably seen usage of Node in TypeScript that handles that. And Google Start. I haven't coded anything in Google Dart myself. But that's completely new language inspired by C syntax. So you can't just reuse your current skill set in JavaScript like you can with TypeScript. And it actually tries to solve many of JavaScript's inherent problems. But it gives you also many of the same constructs that you have already in TypeScript. But Dart has a lot more of them, language constructs. And there's a potential vendor lock-in. Again, you have this Dart VM, which is a part of Chrome that runs Dart without compiling into JavaScript. But you don't have to do that. You can also compile that to JavaScript. The resulting file is really big. And it also received some criticism from really, from Brendan Eich and Douglas Crockford, who are some notable characters in the JavaScript community. Brendan Eich actually created JavaScript. So that's just comparing it to those two. And one thing that's important to notice is that JavaScript is getting there. JavaScript will get classes, will get modules. It will get many of these modern features. But ECMAScript 6 is still a draft and it's not completed. And when that is completed, the implementation will start. And when the implementation starts, it will take some time for it to get implemented in all the modern browsers. And I have no idea how much time this will take, but unqualified guest is two to three years. And it will be really similar to what TypeScript is now, but TypeScript will have types and some more. So JavaScript is still a subset of TypeScript when it's done or released. So TypeScript is, like I said, it's still a preview. It's not finished. But there has recently been released a new version for preview that actually has generics and some performance tweaks. And adding generics is a really cool feature. So you can actually implement the link, language in the great query in TypeScript. So I don't know if anyone has started that, but it's an interesting feature to have in that language. And for when the language is completed, there is a plan to add async and await support, sharp keywords. And I think that is a really, really cool thing to add to this language. Because right now we are doing callbacks and we can actually just use the async keyword or await keyword in order to do this the same way as we do in C sharp 5. For those of you who have tried it, I think that will make the code easier to read and more easy to follow. And it will also add mix-ins to language. That's an interesting feature that the, because JavaScript is dynamic language, you can actually do mix-ins. And having that in TypeScript as well is really useful. So I promised you, I'll tell you about where the dragons are. But there are not many and they're not that severe. One thing to be aware of is using TypeScript or trying to use TypeScript in existing JavaScript frameworks like Angular. Angular actually tries to solve many of the problems that, or tries to make it easier to create JavaScript application. And it is designed entirely for JavaScript. And many of the things it tries to solve is not necessary to solve in TypeScript. So, and this is not just an Angular problem, but some frameworks might be difficult to use in TypeScript. So be aware of this. Don't try to use, for instance, one of the problems with Angular is that it's based on functions and functional design. And you don't need to need that in a TypeScript application. There are other ways of solving this. So a tip might be looking for a dedicated TypeScript framework that works better. So another thing is that there's a lot of syntactical shortcuts that you can use. But I'm pretty sure that you will end up with really messy code that's unreadable if you use this without caution. Especially you can actually do inline Type specification of interfaces. That means that you can actually, instead of creating an interface outside, in another place in the code, you can just write the interface declaration then and there. And you have, and you can also nest the modules that you're declaring really deeply and try to avoid that. And when using arrow functions, you can also, again, you can make these two complex for it to be readable. Again, it's still a preview. There are bugs in TypeScript, especially around when you use the property get and get and set properties. There are some known bugs there. And protected accessibility is not implemented yet. It's planned in a future release. So if you do subclassing, you don't have the keyword protect to make a field available to your children. And there are still features that need improvement. For instance, modules and the way you import modules need some improvement just on syntactical sugar in order to ease up how this is done. So I'm going to just look back at what we have been through. We've seen that we learn what TypeScript is. We have taken a deep dive into all the new features, almost important features. We have looked at how we can actually do dependency management in real world application, and compare it to some languages. And we see what's happening right now with both JavaScript and TypeScript. And what we can take out of this is that by having a compiler, you can actually eliminate a lot of bugs that you usually would find around time with JavaScript. You get strong typing and thereby strong tooling in your IDEs. So it makes it easier to refactor, you can actually refactor TypeScript code in your ID. You get more encapsulation, and you have mechanisms to simplify dependency management and, again, ID support. And it actually also lowers the threshold for beginning with JavaScript. So I personally think that the threshold for a developer that has not done JavaScript development is quite high right now if you wanted to start with JavaScript. But working with TypeScript, I think that might be a bit easier because you have constructs from object-oriented programming. So it will be a lot of pressure. You can reuse more of your existing knowledge. There are a few advantages for large-scale applications. You can actually build more robust apps. You have a strong typing that helps you and ensure that you have correctness throughout your application, at least when it comes to the typing. An interesting case, I experienced once, we were free developers working on a codebase, and we had interfaces for different commands we sent to the server. And at one time, one of us changed added a new field to this interface. And what happened then? We had three builders, and then we could actually find the three places in our codebase that we needed to update in order to conform to this new interface. So that was just an example of how you can get more robustness out of using typing. And you can also enforce design. You can actually do design patterns now, more easily at least. I don't know if it makes sense in TypeScript, but at least you have the mechanisms to drive the design. So you, as a... If you are developing a framework, you can actually make it really easy to use that framework for other developers. And you get more maintainable apps. This is probably what the enterprises want. They want something that is maintainable. I think JavaScript is... Might be a difficult technology to choose if you're enterprise and want to... And you don't have JavaScript resources. So this makes it easier. And you, again, it might be easier to train or get developers that know TypeScript or object-oriented design. And for small scale apps, it's not that much to gain on using TypeScript, but you get a simplified build process. If you're using Visual Studio, just compile when you save. You get less bootstrapping. You don't have to do as much to get your application up and running. You can just use the internal module references and things will work. And I think probably the biggest win is the strong tooling where you get autocomplete help in your IDE. And I think that's actually one of the things I've liked the most. So that was actually... I want more thing I can actually show you. Just for a little wow effect here. So this is the first time I actually used a GIF in a presentation. Do you like it? All right. I will now have to see if I have a file for this. All right. I'll actually create a new file for this. So add... Again, I have to switch here. All right. I'm going to scroll down to add a new TypeScript file here. And the setting I'm in right now is that I'm creating a Twitter application. So what I'm doing, I'm going to create something that gets a list of tweets or the timeline from Twitter. And if I were to do this with strong typing, I would have to go into the documentation. So I could go here and read the documentation for that query. So here all the parameters are described. And I would have to copy them into... Make interfaces out of this manually. But there is a cool little trick you can do. So if I just copy this one, which is one of the parts. And this is just a JSON file, not just a JSON code. So I have this feature in a web potential called paste JSON as classes. So if I do that, like so. I have to ensure that I haven't get... I have to take more or less of this. Again, wow effect. No, it's without them, I think. Yeah, it's without them. It's supposed to work like so. There we go. So what we see now is this is the... I can actually just call this the timeline. So what I have now, now I have a strongly typed type for entire return object here. So it has created it. So small modifications I can actually now have strong types. So if I were to have a jQuery function that looks something like this. So if I had something like.get timeline and in the call box I get this data, I can say that this data is of type... time... Twitter timeline. So now actually in the response, I could actually code knowing which fields were present in this. I don't know if this works. Yeah, so I can actually navigate the return structure here. So I think that's one of the cool features. So that was what I wanted to show you today. So are there any questions? I will be putting this presentation up on slide deck later. So if you want to... why don't it fix my presentation? Yeah, the cable here is a bit loose. Yeah, you probably managed to read that, right? So I don't know why it's not switching over to... try this. Let me do like so. Okay, you can reach me at Twitter. For instance, I'm going to post the links to the slides on Twitter afterwards. And if you want to see the code, I can probably put it up in GitHub. So the last thing I want to say, remember to vote outside using this, hopefully this green one. So thank you for your attention today and have a good conference.
explain all the troubles that we have had with at what TypeScript is. We'll dive right into some that it is the standard for JavaScript. You can ECMAScript, version 6, defines how classes and some of these features that are still a draft over to TypeScript by applying types step by step that you can use types where you like. This is I can also do static typing. Here I say that this to say that this is optional. You can choose to code. So classes is, again, this is what's been like in other languages, but you should think of it as a container in JavaScript. So you can have brackets like so. So this type inherits from HTML require.js to handle this. I will show you in a scripts need to be loaded first. So the only two doing large-scale applications because then you Start just to know what the main difference is. Dart myself. But that's completely new language who are some notable characters in the JavaScript to use in TypeScript. So be aware of this. Don't TypeScript, especially around when you use the TypeScript, I think that might be a bit easier can reuse more of your existing knowledge. There as much to get your application up and running.