Good afternoon. It's my great pleasure to welcome Erich Gammmer as our speaker in the distinguished colloquium today. So Erich Gammmer is a distinguished engineer at Microsoft working in a small team in Zurich here. And as I think all of you will know he has a great record in developing

practical and convincing solutions to some of the most pressing soft engineering problems. His work on design patterns changed the way how we think about software, how we design software, how we talk about software designs. His work on JUnit had a huge impact on how people test programs and made unit testing really popular.

He showed us with Eclipse how to write implicit, sorry, IDEs, how to write IDEs integrated development environments and how to integrate different tools into one such environment. And with Rational Team Concert, he showed us how to support teams of developers with proper tool support. So it's not surprising that his solutions are taught in soft engineering courses in basically every university and

millions of developers use his ideas and tools every day. So today he's going to talk about another really pressing soft engineering issue and this is how to write large and how to maintain large JavaScript applications. So thank you for coming and we look forward to your talk.

Okay, so my apologies to you. And I always say you don't have to read the book as long as you have it on your bookshelf, right? Okay, and today I talk about another interesting thing related to programming, right? I love to program. But more recently since I jumped ship from Java

into the world, I'm really interested in what you can do with JavaScript, what you can do in the browser, right? So I really wanted to try something new. When I jump ship, I want to at least go in another direction. So my talk is really about writing large-scale JavaScript programs and how you can actually even survive that. So how many of you are doing JavaScript development?

See? How many of you have heard of TypeScript? That's good. How many of you have written TypeScript code? So we'll fix that, right? So when you leave the room, we'll go home and write TypeScript. So why is JavaScript so exciting, right? So because it's

kind of the most popular language available today, right? And available in every device, browser, phone, whatever. And very exciting is the execution of JavaScript has improved so much, right? So it's really fast today. All the investment that went into this whole browser competition between

V8 versus Jocko, right? They really result in great JavaScript execution engines, which make it actually viable to write large-scale relaps into in JavaScript. HTML5 also came along, right? It's not only just some libraries. It's a real platform to write apps against. And

that's very exciting, right? It's actually really fun to do that, but it's very rewarding, right? So five years ago, if you would ask me, how do you write a pull application? Sure, Java it is, right? With all the libraries. Today, of course, JavaScript, right? If you want to write a portable app,

I do it in JavaScript using HTML5. Very interesting, there are rich libraries, and there's lots of brainpower in the libraries you get with JavaScript. And one fun episode was on Friday, we had to prepare a demo and want to add a bug into a JavaScript program. And this JavaScript program was done in Knockout,

which is a library based with data binding. What we found is, it was very hard to introduce a bug, because everything is so well abstracted, right? You declared if you find the data bindings, there's no more loop or whatever. You just bind your array, and the data binding does the rest for you. Which was kind of funny, right? Because this shows there's a lot of power in these JavaScript libraries.

Then JavaScript has really grown up, it's not only used for websites, for some validation of fields, but it's really used for apps in different setups, like for Win8. I can write apps in JavaScript, Office has an extension for JavaScript, Phone Apps, and PhoneGaps, or Cordova.

I can do that, and do all my coding in JavaScript, which is great, right? Finally, it's really grown up at scale, know what's cool today? The cool thing is, you not only write multiple pages, but you stay in one page, and all you work in is in there, right? The single page apps, it's a cool thing today, single page apps.

If you look at the browser footprint in some of these apps, they go up to 400, 500 megabytes. So there's some real stuff running in there, right? That all showed to me, JavaScript has tons of potential. Actually, that's my team, I just want to say, so we work here in Zurich.

We're eight developers, some of the faces you might know, they are just graduates from ETH. We're eight developers in Zurich, two testers in Redmond, and one program manager in Redmond as well. So what we found soon is, we really enjoy programming JavaScript.

It's very rewarding, right? You write some piece of code, you run it in the browser, refresh, it's all there, right? F12 if it doesn't work, and so on. This is all cool. But still, when we got the mission at Microsoft to work on this assignment on how can we use the browser for developing code,

I was still getting a little bit nervous, right? How can we survive that? Because development tools have a tendency to grow, right? You deal with abstract syntax trees, parsers, whatever. So this will be quite a large code base, you know, from the beginning. So what do we do, right? So we really love this clean subset of JavaScript, right?

But the other less unpleasant, less pleasant areas. So I kind of, if you look at the question we had, right? So you have all these two choices, you know, the more static type and dynamic languages, or how I want to call it pessimistic versus optimistic, right?

So the pessimistic language is like C sharp, Java, C plus, or Eiffel. They always raise their finger when you try to run your code and there's errors, right? That's very pessimistic. On the other hand, you have the dynamic languages like small, the Python, Ruby. They're more optimistic, right? They let you run your code even if it has errors in there.

Okay, now comes along JavaScript, right? Which adds new dimension to me. It's not only optimistic, it's also forgiving. And that kills you, right? It just tries to keep on trucking when you make a mistake and you might not know it. It has lots of funny stuff in JavaScript, right?

That maybe I show some, which I found kind of interesting. Let's just go here to the console. Oops, that wasn't a good move.

Just want to make it a little bit smaller. And then I want to show you some fun JavaScript. Like we can do some puzzles, right? What should happen now?

So, well maybe you don't see it all, but still the effect is clear. Right, what does that mean, right? Not a number, okay. What do you guess what that is?

Okay, let's try the other thing. Commentativity, right? What do you guess? What do you think? Zero. Anyway, we can go on, right? So JavaScript keeps on trucking, right? In fact, the right answer to all three expressions is error, right?

But it keeps on trucking, so that's not always a lot of fun, right? If you try to debug a problem. Right, so the good thing was when I switched from iPhone to Microsoft, I had three months of time to learn JavaScript nodes technology, and I really needed this time, so. And I was banging my head at the wall a lot.

So what are we doing quickly? So what we try to, whenever you see code in a browser, we like that you use our components. That's what you do at Microsoft. So when you want to see the diff in the source code control system, right? That's the diff algorithm, whatever. We write that. The TypeScript link, and it will show,

we write this what's behind that. Azure, when you write the script to validate your data, that's us. Maybe not by show quickly. That's the environment we write. Now in Office, you can write extensions, and these extensions are web apps, so it's JavaScript, HTML, CSS, whatever. So we're behind that, and we offer IntelliSense and all,

all this kind of stuff to you. Okay, things like that, right? So we built these online experiences, which make a lot of sense, and we want to try a platform, we don't want to install an SDK tool, you can just start in the browser.

Or the other fun scenario, I think, my website is broken, I'd like to fix it, right? So what do I do? So I'd like to do that without any tools. So that's what you work on right now, so this gives us quite some interesting scenarios and examples what to do with. So that's kind of our journey. We started two years ago to build all this infrastructure,

and we had different phases as we went through, right? Because we knew we had to grow up. We grew up from 50,000 lines to 100, about 250,000 lines a day. And, of course, the good thing is,

the real cool thing is we could do this as a grassroots project, right? So we really started from zero. We could pick the tools, we could pick the patterns, libraries, whatever you want, right? So Microsoft just gave us this freedom to explore this space. So the first frustration was that, no, JavaScript was really not designed

to go up to 250,000 lines of code, right? It was done for some form validation, whatever. And what you have to do to survive, you have to come up with patterns, how you do more scalable structures, like a module or classes. And the bad thing is people are very creative, right?

And everyone wants to have the coolest way to do classes in JavaScript. I was really getting annoyed, right? How many different approaches got discussed? Well, then give me just one way, right? So I was really getting tired of that. Another challenge is JavaScript is single-threaded, so this API gives you callbacks, you need to manage them in a way. And what we soon found after several months

is our code is not getting healthier, right? And the problem is JavaScript code tends to rot over time. Because, why is that? Because you cannot easily refactor it, right? Once a variable is written and has a name like count or whatever, renaming this a major endeavor, right?

Because you have no type information, you cannot find the references. So the best thing is to not touch it, right? So that's why I also kind of, I have just quotes from our development team here. So what they all say, you know, writing code in JavaScript is like carving code in stone because you're reluctant to change it. And you want to get over that, right?

So async pattern, that's just one pattern. I don't want to go into that, I think. Let's talk about how you want to tackle the JavaScript, this scaling up constructs for managing larger code base in JavaScript. What was funny is just at the time we started,

a new project emerged at Microsoft which was called TypeScript. And the language designer behind TypeScript was Anders Halsberg. Anders Halsberg did C sharp, right? So you can look at TypeScript is a view on JavaScript

as if a C sharp programmer would have designed JavaScript, right? So with a lot of nice, powerful mechanism because C sharp, if you come from Java, you must say, you're impressed, right? They have Lambdas, they have all the things which we talked about in Java for 10 years

and maybe we get in the next release. Or we get a watered down version of Lambdas, right? So this was very interesting for us, right? We were thinking, how can we survive, right? So of course it is new technology, new compiler. So we had to start gradually, right? We didn't put all the X on TypeScript

but we wanted to really use it. So what is TypeScript? First of all, a nice move is TypeScript is just a superset of JavaScript. So every JavaScript program is a legal TypeScript program which is a cool thing because rather than trying to change the internet, we evolve it, right?

Which is an easier approach. Now what you do to scale up and in particular how you can help me with maintaining the program, right? So when I do a stupid mistake, when I want to rename, when I'm refactoring, how can you do that? And what TypeScript offers for that is optional static typing.

And what's interesting, the goal for the TypeScript language is actually to support good tooling. I guess previously we thought about you add type to the language to make it more efficient, to make more efficient code. This has totally changed, right? We add type information to TypeScript to make your code more productively by having better tools.

And of course there's class and modules so that you don't have to reinvent your own pattern and have to pick them on among all these different proposal of classes versus traits, whatever. So what TypeScript does, it produces JavaScript that you can even read.

So even I can debug at the generated JavaScript level without any problem. It integrates in any JavaScript library which is a very interesting topic that I want to talk about later. And also it runs in any browser, right? You can say which ECMAScript version you want to generate from the TypeScript code.

Okay, let me quickly show you some demos on that. It's good.

Okay, TypeScript is open source, right? There is the portal. If you want to get the nice show on it, no, Anders Heilberg has a beautiful talk there. Play is how to get your hands dirty. And this is now using our infrastructure behind it, right?

So we have this circularity. We use TypeScript to implement the tools for TypeScript and to do that we even use TypeScript again. So we are, we highly depend on TypeScript now. So that's just, let's start with the easiest thing. JavaScript, right? On the left you see TypeScript, on the right JavaScript.

So what you see, what is the difference? None, right? That's the point, right? If you compile JavaScript with TypeScript, you get JavaScript, right? We preserve everything. So let's start with optional typing. Let's make it a little bit smarter and say this function greeter actually takes a string, right?

That's what you do. You add a type annotation and once you add a type annotation, type start to flow, right? Where is the greeter function? That's not what I expected. Return. Oh, sure, sure, sure, sure.

And give IntelliSense and all this stuff, right? As you expect, also notice. So, okay, now the type should flow. Come on, where is the greeter function?

Anyway, so the point is, you just add some type information and now when I change this into an object, then I should get an error, right?

Where's the error? Come on, baby. What am I doing here? Say hello, text content, greeter, greet. Well, it doesn't pass anything. And that should be an error.

What am I smoking here? Huh, did anybody see it? Oh, sorry, I'm stupid. Yeah, sure, I'm stupid. The function greeting. Yeah, okay, I was in a different sample, huh? This function isn't typed, right? So that's why it doesn't take any argument.

So when I instantiate it, greeter, greet, it still doesn't like me. I will not switch to browser. I will not switch to browser.

But anyway, no, trust me, we develop tons of lines of code with that. I don't know why there's all those down. So the point is here, it's erasure, right? You see kind of as you add this type information, it all gets erased at runtime, right? So that's the point here.

So that's types. Let's go next classes, right? So we add a class greeter and you will see also the code on the right, the generated JavaScript is very close to what you have, okay? So let's try that. So here, of course, it also has visibility. So if I say private greet,

then you see this quiggle, right? You see there is indeed, greeter, greet is not accessible because I made it private, right? You have visibility. That's also erased at runtime, it's not enforced at runtime, but you see how it works. Okay, the nice thing is really, it's very intuitive JavaScript that is generated,

which makes the adoption much easier, right? So that's the classes, generics, that's the new thing, right? You can now all the, I showed that another example for generics. The nice thing is now, if you want to type JavaScript libraries,

you gain a lot of more expressive power once you can add generics to it. And that's why a lot of effort was put into a TypeScript to add generics as a language feature. And finally, you have modules, right? The modules are open, just it's a single namespace. Again, this is idiomatic module pattern you see that generates,

very simple, very straightforward. Okay, what else do we have? Okay, we have inheritance. We should not go into, there is inheritance, as you know, with C sharp style. That's actually the only place when we generate some code at runtime, you see that. That's kind of the only place where we do this prototype then to get the superclass in there.

Okay, so that's kind of a quick intro in TypeScript. You saw types from all the classes, but what was missing is interfaces. Now, interface to me is the most exciting part about TypeScript because they add a lot of power, right? So let's first look at what happens behind the scene.

It's a formalization of common JavaScript pattern. You saw the left to right, very similar. TypeScript uses structural typing, not nominal typing, right? Which is very powerful to describe JavaScript and JavaScript APIs. It uses type inference so that you have, if you annotate your code, thanks to type inference,

you have to annotate less identifiers with types because it gets inferred. And a very nice thing is it works with existing JavaScript libraries. As I said, these JavaScript libraries, there is cool stuff in there, right? Angular, Knockout, whatever, jQuery. There is just, you wanna use this and you wanna have tooling support for it, right?

You wanna get IntelliSense for it. So you wanna work with existing JavaScript libraries, plus you wanna make them more easy to use. Okay, the most powerful mechanism to make these libraries for you to use is interfaces. And interfaces are a way that TypeScript gives us to describe stuff.

So this is kind of the Swiss Army knife. It's the Swiss Army knife of of the type system that we have in TypeScript. Of course, you can use it to describe interface in the traditional sense. Like you have an interface I render, which defines you have two methods,

getHeight and render, with some signatures. But it's way more powerful, right? You can use describe structures like this option object. And what you see is you have these question marks because Java API is often so fluid and made for the program and many things are optional. You can also say in Express,

this JSON structure has these attributes or properties and some of them are optional. We look into that when you see how we couldn't type a library with that. Callbacks functions you can describe and capture. Index access you can type and capture. That makes it very powerful

to describe something like jQuery. So let me quickly look into into the typing game.

I switch browsers now. The other one is really good too. So the typing game is this game, right? So on the right I write some code using a library. In this case jQuery. And on the left I want to type it. I want to add a type definition for the library.

And in TypeScript this goes into .d files, a definition file. And these .d files I can use in the tool and also when I compile to get type checking. Okay, so what can you do now? And you see here kind of jQuery is pretty complex API. And what you see is Ajax setting, right?

It's a long list where it all accepts. But on the other hand once I do that I can do things like dollar Ajax, get IntelliSense. I do an object. IntelliSense URL of what is it, right?

It takes a string and so on. So this is kind of the benefit of the typing game, right? You start to annotate and describe structure. You get IntelliSense and validation. Okay, so that's kind of an example of just an option. Option back. That's the callback.

The promise, so promises are interesting, right? So promises is a pattern how you manage callbacks, right? It's nicely specified. There is a single function which has well defined semantics. Now let me show you what you can do with promises and typing here.

Oh, I have to watch carefully. Not this one.

Oh God. That's the one. So the nice thing though, a promise is kind of a representation of a value that's eventually computed, right? And you see how I can now start to type it. They have really a promise has a then which takes a type

which gets me returned and passed as a value, right? So it's kind of here for instance, I do some asynchronous computation and for that I create a promise which in JQ is called deferred. They're not compliant with the promise spec so it's a good thing that they don't name the single promise.

But what you see is thanks to the generics and the type information I have here, the type flows, right? So this is when I make this a string, now help me, this should give you an error. Give me an error, right? And it does, right? Do not match. So I can describe with the help of interface and generics the semantics of a promise

and get the type checking and the type flows through the system, right? That's the nice thing, right? That's the function which computes the value on the consuming side result will be typed to a number, right? Because once you added some type annotation the type information flows in and that's really an exciting

thanks to structural typing, generics without a lot of annotation on the consuming side I get type information which is very important, right? To even get to a point that people are willing to annotate your JavaScript with TypeScript with optional types. So it goes on, right? It uses overloading. You can see I can different signatures

to describe all the fluidity you get in this API. Now what's even better? The community has really jumped off, right? TypeScript is open source. Now what people have started to do the community has added TypeScript type definition for existing libraries

and I think you get type definitions now for almost any library in TypeScript which is a nice thing, right? So as you evolve and if you want to use TypeScript you don't have to pay the penalty that you first have to come with typings for the library you want to use. They're just there on GitHub. So it's a nice open source game that took place here, right?

Okay, that's typings. So I think at that point we have grown up to 50,000 lines of code. So using modules, class, interface, promises, we only tipped the toe in the water of TypeScript because you know how painful it is now when the compiler has bugs

and you work for two hours to work around the compiler bug and so on. So we started slowly. But then we came to the point where we got up to 100,000 lines of code so we said oh, we invest more in TypeScript plus we have some other scaling problem. Because once you get grown up you have tons of scripts, right? You write all the scripts

and you have to come up with a way to manage them. You have a list somewhere. All of some order becomes dependent, right? Where do I add my new script? That the order is still correct because the dependency is very painful, right? If you write large-scale JavaScript not happy. The other growing pain is dependencies, right? So JavaScript is very soft language

if you want. It's real soft. It's so soft because it can add a dependency to anything very easily, right? And that was just in May I got this code. Our dependency was such a mess that each error had a dependency just about every other error. So it was not our approach. But we had the same problem, right?

Dependencies, even if you have modules the modules are open in TypeScript and JavaScript typically. You can very easily extend a module from anywhere and the other growing pain was startup time, right? You load all the scripts in the browser. This takes time, number of requests,

number of transmitted data. That's not free. So we had this growing pain. So what to do? What I think is really cool about JavaScript community, right? They're innovative. They provide you with technologies that you can survive and the asynchronous module definition is a way in JavaScript that you can define a module

and what's nice is it's just one function. So it's actually one of these other one function specifications. I showed promises before. Promises is also an example of a one function specification. So this one defines one function which is called define. And what they do is they define

on which all the modules depend. The loading is asynchronous. As soon as the module is loaded you get callback with the module object that has the exported functions and properties in there. So if you want to scale JavaScript, AMD helps you to do that because modules become self-contained

and the dependencies are no longer described in external script, arrays of script lists or in a list of scripts that are defined in the code itself which makes it very easy for us. For instance, we get consumed by many different customers. If they don't like a feature we just disable one module and just everything gets removed

that depends on it, right? Just in JavaScript, it wasn't like that. So how does TypeScript help us with that? There is one problem in JavaScript. There are different module standards. If you do kind of service side JavaScript and use Node.js,

then you have the common JS module system which has slightly different syntax than the AMD one. It's synchronous. And if you do in the browser, if you put it in the browser and use AMD you have another syntax again. TypeScript, how it helps us is it can generate the code for both module systems.

And for us, for instance, in the system we write, we have JavaScript code in the browser and on the server. We use Node.js in our products and we can actually write code that can easily move from the browser to the server and vice versa. Just one flag, right? So the compiler generates the AMD module specification

and basically that's in a transformation. Now in our code, before we used JavaScript, we had this highly compact syntax of a defined function translating an easy, understandable module statement. Actually I'm not sure if this is required now.

So TypeScript's still finalizing but that should be a required module anymore. Okay, so that's the benefit we get at the module level. So now comes the other pain. We had lots of code so we have to lazy load it. That's kind of the clips pattern, right? The clips pattern is that

you have millions of plugins. You want to lazy load them. We run the same problem here because we support many languages in our tool so you also want to support lazy loading of these languages, right? So the C sharp language mode, I don't want to load and open up the tool. It should only be loaded once you open a C sharp file, for instance. So what we decided not to do,

what we did in Eclipse, which is an XML that allowed you to find the extensions, we do this all else in JavaScript, right? So JavaScript is really nice. It describes structure using all these literals you have and basically that's what you do, right? We have a notion of contributions that you register in one place.

This thing gets always loaded, right? The contribution gets loaded on startup. That's kind of the tip of the iceberg it tells us what it potentially could all do and once you open a C sharp file, then you dynamically load the code for the C sharp mode, which is kind of under the water,

only added to the run time once you use it and that made a big difference for us because you also start to use other components of the UI lazily, right? Only if you need it, we load things. Okay, that's some of the scalability tricks we do. What the team thought after this migration,

I like this one. So I see this JavaScript code here as a large code base, it's hard to maintain, right? And we really felt the pain. It took us about two months to make this transition and what's really cool is kind of the team felt really good about that, right? It feels like fresh shower. That's a great compliment, right, on code if you feel like fresh showered off,

have done some change. And also know once you have this AMD self-contained code, no more globals, no more cyclic dependencies, faster startup. This is still the evil thing, cyclic dependencies, right? Happens in the best families, right? So then we came to the next phase where we really had to grow even further.

So we came up to 2013 when we got to 200,000 lines of JavaScript code. We had some other growing pains. The tooling slowed down and we had a decreased testability because our components are used in many different areas, right? So the first thing you do, you do componentization,

basically treat JavaScript like a generated code for a component and you have just one TypeScript definition file for the generated code, right? So you can treat it like a component which gives us scalability. Like our editor component is one object, one component, which is one .t.ts file

which is Travis interface. So that's what you have to do to scale up further. That's on the componentization. A lot of the API work we did, right? We had to kind of, we call this any hunting, right? And in our code we get the benefit from tooling when TypeScript can infer the type of your object because then you get IntelliSense

and then you can do refactoring. I haven't shown you refactoring but we can do it even in the playground you do refactoring. I guess it's the most powerful playground, right? So, but what we found is we really don't like it in our code. The TypeScript compiler doesn't know what the type is so for this reason we call this any hunting, right? When you hover over an object

we tell you what the inferred type is. I always give you a warning. And our code today is any free, right? Which means you have been added enough annotations so that the system always know what the type is and we can trust the refactorings, the reference searches, and all the things we do. Of course, you just dock the API and do all this goodness.

Dependency injection. Yeah, I always keep dependency injection. This is something, you know, it's popular in Java and also in JavaScript you might not need that but it helped us kind of to get some more decoupling. Now our components, they get injected services, the services are described in interfaces

and that's how we get all the decoupling. Now for testing purposes, right, you inject some dummy implementations, fakes that do the behavior, that gives us some scalability. Interestingly, you know, I thought JavaScript doesn't use it but I thought Angular also. The Angular JavaScript library, they also use dependency injection. Okay, so then you want to get the 100% TypeScript.

They say we invest one month to just convert our code from JavaScript to TypeScript. So read it all manually and we got the velocity of 300 lines per hour which sounds very slow but it's really code cleanup, right? It's code high G when you do that

because you find lots of stupidities, right? You find typos, you find that you describe objects in different forms, in different places. And see, my team are not bad programmers, it's just discipline is very hard. It's very hard to be with that discipline and I think Alex is nice. He found that his data was floating around

at least three different formats, right? Just in JavaScript. It's so easy to write an object literal. And also the typos, now you can bang the head against the wall, right? That's actually a beauty, right? Delete this marker range stat marker ID instead of start. Which of course means you have added a memory leak, so.

These are the things which once you have 100% TypeScript, we just got it, right? We captured, we get the squiggles and so on which is a good thing. Where is TypeScript today? So it's version 0.9.5 so sometimes next year the 1.0 version will come. Generics have shown they were added

and in particular the nice thing when you have a map function you can finally type the map function. You map an array of type U using a map function which generates T and you can finally capture that. Constant overloading. It's very pragmatic. Now TypeScript really tries to help you write good JavaScript code

and for instance when you work with the DOM then you often find that you have listeners that are dispatched on the string. So what you can also do now in the newer TypeScript, you can type based on a string, right? So that the mouse move handler has a different type, than for instance the blur handler, right? Which just takes the focus event.

Pretty nice stuff. Okay, so let me wrap up so that we have time for questions. So we knew kind of we were on the bleeding edge when you joined this TypeScript effort so we worked closely with the team on the module story because we used Node on the server, used AMD in the browser

and our code base so we worked heavily that this works for us with the team. So we were expecting it's bleeding to do it. In retrospect I think you would do it again. No, I'm sure you would do it again because without TypeScript I don't think we would feel as healthy and fit with a code base

of 12,000 lines of JavaScript code. So I don't think I will use TypeScript always so if I just want to try something out I just put it in JavaScript. It's just faster, more convenient and so on. But we had way more fun using TypeScript. We get code readability, confidence,

refactoring, tooling, fun and of course what we like the most as programmers, less stress. Okay, let me close with that. If you want to find out more go to typescriptlang.org. It's open source and use the playground, play with it and maybe you get the red squiggles as I was expecting in my demo.

Okay. Thank you very much. So we have time for some questions. Yeah, Milos?

It's very hard because the point is

there is actually no type information in the jQuery code, right? Because it's so fluid and it's really rediscovering the design you had when you write the library, what you do there. So no, the answer is no but I don't know what all the community uses that contribute to this database of all the library files.

They support source maps if you mean that. Yeah, that's supported now. Depends on the browser whether they support the source maps.

So I was wondering, I mean people who use dynamic languages typically talk about the flexibility that the languages give them. So how much code do you actually encounter that makes really use of that flexibility so that you cannot type it statically? Is that like a percent? Is that half the code? What I think is cool,

we are any free, right? Even our closures, our functional code, thanks to the structural typing we get, we can actually type it, right? It's kind of duct type on steroids, right? So we can actually type it and we haven't found a situation that we couldn't type. Now they have generics, right? Before we couldn't type the map function which was a hard coded implementation,

the compiler. But now with generics, in our code we haven't found it but to be honest, it's not that bad, right? So I think the flexibility, structural typing plus generics gives you lots of descriptive power.

Plus optional, optional, right? You want to say things are optional. That really is important. So you don't see lots of evals, for instance, that we don't type. Oh no, we don't use eval, right? That's security problem. That's evil, yeah. Any other questions? Yeah, in the back.

What we have are lambdas like in C sharp for this example, right? We have lambdas. Some of the other CoffeeScript mechanisms,

not sure, no, but the lambda is the most important one for syntactic convenience, right? Because CoffeeScript is how a Ruby designer would have designed JavaScript which is about typing less, right? So TypeScript is not like about typing less. It's about optional typing. So typing now is overloaded typing, right?

Yeah.

So there are two approaches how you can fix JavaScript. One is the more revolutionary approach which Dart takes, right? Giving you another language with some mechanism to somehow

use existing libraries or to really embrace JavaScript and make it very easy for you to use existing libraries. So the path that Microsoft is taking with TypeScript is really more the evolutionary path. And we see lots of adoption, right? Even the community contribution so it's an evolutionary path

to improve the quality of the programs, right? And if the quality of our programs improve I think everybody benefits from it. So that's the motivation, right? The better the quality programs I think the better our life is on the internet. And TypeScript takes the evolutionary route. So there was another question up there?

Sure, you lose some flexibility, right?

So we cannot fix all the problems that the JavaScript has. That's definitely true. You can clean up more if you take the more evolutionary path. That's definitely true. But it's a very pragmatic approach, right? So even the type system for TypeScript is very pragmatic to really add power.

But it's a pragmatic approach. I don't think you can even, it's even a sound type system. But it's very pragmatic and makes it more productive, gives you more better tooling support, right? John? I heard you just mention the word sound. Your program is any free people

want letters or is it... So Anders Heilsberg once described me TypeScript to be a type system like Swiss cheese. So that's not the goal to have fully sound type system.

Okay, that's a very good question. So right now, of course, TypeScript, you can use existing JavaScript libraries like implementation of the Promise specification like QPlus to implement that.

So for today, you get promises, right? Which what I showed. What you will get in the future is if you're familiar with C sharp, where you give it this async construct that allows you to kind of write synchronous code even if you're called async methods. That might come in the future because as JavaScript evolves

in the next version of JavaScript, there's a concept of generators which provide you with a mechanism that you can have better support for async programming. You don't have to invert your code all the time if you write an async function inside the loop. So for now, all you get is promises like I showed before, right? And there are JavaScript libraries for doing that.

And in the future, you might get something after TypeScript 1.0, something like async that is in C sharp today that makes the life of the program much easier because your code doesn't wander to the right.

Okay, if there are no more questions, then let's thank Eric again. Thank you.