Two leading TypeScript experts, Marius Schulz and Basarat Ali Syed, discuss their initial reactions and excitement for TypeScript and how it has evolved and earned their trust over the years. TypeScript has been the main focus of many of their products and trainings and they’ve gained their expertise by closely following the project and digging deep into the TypeScript compiler code. As TypeScript continues to improve with features, tooling, and performance they share their opinions on what they’re most looking forward to in the near future.
Two leading TypeScript experts, Marius Schulz and Basarat Ali Syed, discuss their initial reactions and excitement for TypeScript and how it has evolved and earned their trust over the years. TypeScript has been the main focus of many of their products and trainings and they’ve gained their expertise by closely following the project and digging deep into the TypeScript compiler code. As TypeScript continues to improve with features, tooling, and performance they share their opinions on what they’re most looking forward to in the near future.
"Using TypeScript with Basarat and Marius Schulz" Transcript
John Lindquist: This is an egghead.io podcast featuring Basarat, Marius and John discussing TypeScript. So to start off, let's introduce yourselves. Marius if you want to go first since you're at the top of the list on my screen here. Watch it. Why don't you introduce yourself with your experience, where you're from, that sort of stuff?
Marius Schulz: Yeah. So, my name is Marius Schultz. I live in beautiful, Munich, Germany, and I've been doing this JavaScript development thing for almost 11 years now. And yeah, for the last two years I've been getting heavily into TypeScripts. So this is why we're talking about TypeScript today, I guess.
John Lindquist: Yeah, you've been around for 11 years. That's a lot of change.
Marius Schulz: It is. And it has been. Yeah.
John Lindquist: And Basarat. How about you?
Basarat: So, my name is Basarat, I live in Melbourne. Just another day really, nothing special about me, just a little writing code.
John Lindquist: Oh, come on.
Basarat: Having been born [inaudible 00:00:58] I guess.
John Lindquist: You don't have to be modest.
Basarat: No, honestly that's pretty much it, I'm just a dev.
John Lindquist: Okay. Maybe you should put that into your Twitter bio, just saying, "Hey, just a Dev." I smashed my keyboard and hopefully stuff shows up. Well, cool. So we're talking about TypeScript today. So what is, just to kind of open question to either of you, what's your initial experience with TypeScript and how did you kind of get hooked on it and why are you all in TypeScript right now?
Basarat: You want to go first Marius?
Marius Schulz: Yeah, sure. So, I think it was October 1st or October 2nd in 2012 when Anders Hejlsberg announced TypeScript. And I remember watching his presentation and I was the worst fan girl in the room at that day. I don't know, I was immediately hooked by TypeScript, it sounds really cheesy I know. But I have a C# background. I come from a statically type world. I love what Anders Hejlsberg has been doing. So I was really excited to see what he has been doing to JavaScript.
John Lindquist: So you knew him before TypeScript because if his C# work and all that?
Marius Schulz: Yes, because of his work on .NET and C#. Yeah.
John Lindquist: Awesome. So, there was no convincing you, you saw Anders, you saw JavaScript, make my JavaScript life better and you just went for it.
Marius Schulz: Yeah, I went for it and I thought it was good that we finally get static types in JavaScript land. I'm used to really good tooling in the C# world. So, this is what I hope to get from JavaScript and TypeScript as well.
John Lindquist: All right, Basarat. How about you?
Basarat: So I was working with .Net at the time, again like in October, 2012 when TypeScript released. You really have to know Anders to jump into it that fast. So, I knew that ended had released it, he was a part of the team, it was his new baby. So I got myself involved as much as I could. I opened up the language Spec, read the whole thing cause that was the only docs available at the time.
Basarat: Summarize this into my own little word document to know all the points that people might have questions about. Introduce this to our team. Then started helping people on stack overflow, and that's pretty much the reason why I'm known in Tech is because of my contributions there. Found a lot of common questions going around, starting to write notes about that, that got converted into TypeScript dev. But really like the initial reason and the reason why I jumped in has to be Anders.
John Lindquist: I totally get that. And yeah, by the way, thank you for every time I Google something TypeScript, your name comes up.
Basarat: Thank you.
John Lindquist: So, thank you for saving me a bunch of time. It's anyone listening out there. If you just get involved with a project and you answered questions on stack overflow and write up what you learn, I mean it, it opens up so many doors for you. It's a perfect way of helping out, especially if you don't want to get in and start writing your own open source projects and all that. So what have you guys seen from other people adopting TypeScript? Have you seen them hesitant to start with it or that they love it, they hate it. What have you seen other people using or their experience adopting it?
Basarat: So, originally the companies that I was working with were all .Net shops and Microsoft shops. So convincing them to use TypeScript was definitely not a problem. And as I wanted to evolve in my career, the jobs out there were all about JavaScript and I was so spoiled with TypeScript that I really didn't want to jump anywhere else. So I held onto that job for around four years and stuff, even though I was possibly not as happy as I wanted to be.
Basarat: But recently since England adopted TypeScript that's when I was like okay the world is open to me. Anybody who is going to do any fund in Dev is definitely going to be exposed to TypeScript and would be at least willing to explore that with me. So then like right now after Angular is written in TypeScript and there are a lot of React TSS that are using TypeScript attached again as I mentioned in the react docs as well.
Basarat: A view is adopting TypeScript for a number of it's sub projects as well. It's not even a question anymore. I don't see any hesitation from anybody that I work with. Outside of my circle that people do sometimes complain about TypeScript, but there're mostly people that haven't actually tried it seems to be the case.
Marius Schulz: Yeah. That's my experience as well. So once people try TypeScript, they're convinced pretty fast I would say. But many people have initial, I don't know, they're careful about it. You know, they still think, "Oh it's a Microsoft product. It must be super commercial and closed source and proprietary," and that's just not the case.
John Lindquist: Yeah. I think initially when it released, it seemed like there was that migration happening of okay, everyone needs to learn front end dev now. And there was that all the Java people, all the C# people wanting to get on the Front End Bandwagon and TypeScript was just the, almost the bridge to get there because otherwise what are you going to do without types when you come from a type background and-
Marius Schulz: Yeah, I think angular too was the big-
John Lindquist: It feels like you're missing an arm or something. Sorry. I think Angular two was the big push for TypeScript to be honest. So just to be clear, because I get this question a lot in my workshops, TypeScript is in no way tied to Angular, not an in any way.
John Lindquist: But it's the default language. It can use Angular two or angular four, Angular five, whatever the current version is. Five, just today.
Marius Schulz: Yeah. It was released two hours ago when we recorded this. Yeah. So, it is a no way specific to angular, but Angelo was the big push because they doubled down on TypeScript and I think this just helped TypeScript spreads so, so, so much.
John Lindquist: Yeah. I remember that when Angular tried to introduce its own, can you remember though the name of it?
Marius Schulz: A Script. It was called script.
John Lindquist: Yeah, tried to introduce that, then TypeScript was growing at the same time and they just, they need a decorator's like decorators were the just, it was how you're going to configure a class.
Marius Schulz: Yeah, I remember.
John Lindquist: And so they were so set on decorators that they wanted to do ad script and then TypeScript came along like, well it's just, you know, Google and Microsoft. Yeah, let's do this together.
Marius Schulz: I remember the big revelation, at script is TypeScript. I think it was a couple of months after they initially introduced ad script and then decided to drop it. So, they decided not to develop their own language. And then there was the big slogan ad script is TypeScript.
John Lindquist: So I think that leads well into my next question. So, how have you seen type script evolve and grow since its initial release?
Basarat: So we've seen three or I guess four complete compiler rewrites and they've mostly been around performance. So it used to be really slow. It used to take around three seconds for three files or something like that. And now it takes two seconds for 100 or 200 files. It's just crazy how fast they've made it. The tooling has improved a lot and I guess it's at a stage where it's a fairly mature ecosystem in terms of they can add new features quite easily.
Basarat: As new ECMAScript features come out, they can add those to touch it quite easily. At least that's my external perception of how the team is operating. So they really have built a very solid foundation there, and what they are focusing on now is adding a lot of refactorings and good analysis tools into the language services that come with a compiler. And that's when I studied the original compiler and found some value in it doing my own open source work.
Basarat: It was in use the compiler and then built tooth that use the analysis that the compiler has done to do further analysis on probably like the dependency deed, creed to the user or quick, smarter refactorings, five baht imports. But all of these things that I did, they are actually now being done by the TypeScript team themselves because they've got the base so solid that they can use their resources towards helping developers use those solid base features of the language into more intelligent good tooth.
Basarat: And I'm really excited for it. They've added this thing called code actions, which is essentially a quick fix and I think they've also done, they've integrated fall system handling quite a lot into the compiler. Like blobbing is something that is traditionally done with a lot more code than is probably required. They analyzed what globe that the standard node module did and wrote something that does a subset of that but does it really well, and quite commonly when I want to use just clubbing in my notebook as well, I actually just input TypeScript and use their glove functionality.
Basarat: But again, so it's evolving into more code analysis tools and I love that.
John Lindquist: Yeah, I think of it as I've seen it evolve. They've been pretty patient as far as not rushing out features and really making the base fantastic to build. Like you said, tools on top of, and I'm glad my initial experience was there aren't enough features in here to be worth it for me to adopt right now. And but I'm glad that they took kind of a slower approach so that they could get everything a really solid and now it just seems like it's exploding with tooling around VS code and like you mentioned, auto importing and they've had completion for a while and all that stuff.
Marius Schulz: Yeah, the completion is just fantastic and it just keeps getting better, especially with TypeScript 2.6 now, we can get even better auto completion, but this is the tooling side of things. But since TypeScript 2.0 which I think came out late last year, so late 2016, maybe Octoberish timeframe, they introduced big changes and additions to the type system that are really, really worth it.
Marius Schulz: So I disagree a little bit with the definition that you just gave that they weren't really hesitant to add features. I think 2.0 in 2.1 we're crammed with good type system features. So they introduced non nullable types. The best thing that has happened to TypeScript since the one old then they did control flow based type analysis, which is just a really, really clever control, slow tracking mechanic of the compiler and the the type checker to really deeply understand what you're doing in your JavaScript code.
Marius Schulz: So we can keep riding idiomatic JavaScript the way you would write JavaScript and have the compiler understand all the effects of things like brakes and continues and ifs and else's, and that is just really, really powerful and it makes her code looked like Java script and not so much like a different language. Which is really, really valuable I think, because you don't have to teach people so much about TypeScript.
Marius Schulz: So I often get the question in my workshops, how do I do this and TypeScript? And I always answer that this is sometimes the wrong question. The correct question would be, "How do I do this in Java script," right? And then you just do it the exact same way in TypeScript.
Basarat: I love that question though.
Marius Schulz: This is, this is one of the things that I see people struggle with a little bit because I have a lot of devs that have a Java or .net background. And they tried to ride their Java script and type script code the way they would write their Java code, which is not always perfect. You have this impedance mismatch or what do you call it? So, they tried to build deep class hierarchies and sometimes TypeScript encourages that because if it does have keywords like abstract and public and private.
Marius Schulz: So it's kind of reminiscent of C#, although it's really not. So my point being here, we have plenty of powerful features in the type system and I think that the best ones are not nullable types and control flow analysis. And on top of these features we can do so much.
John Lindquist: Yeah. I'm always amazed that if you get into like a switch case and then you have some sort of conditional logic deep in there and it's like this shouldn't be a number, and like, "Well, I didn't even know that's what I had written." Like how does TypeScript know that that should be a number when it's so deeply nested into some of my spaghetti code or whatever-
Marius Schulz: Do you want to hear a funny anecdote.
John Lindquist: It's amazing.
Marius Schulz: Yeah, after they finish this feature, they found a bug in the compiler itself. I don't recall exactly what it was. I think it was about parsing octal literals or something, so a really, really, an edge case if you will, and control flow analysis. I don't want, I don't want to say something wrong here. I think it was control flow analysis. Anyway, one of the futures they build surface bugs in the compiler itself, which is I think just proves the point that even the TypeScript compiler developers who really know JavaScript well, who know TypeScript as well as as you can, even they make mistakes and TypeScript helps them find them much earlier and much cheaper.
John Lindquist: That's kind of awesome. I like that a lot.
Basarat: I've done a few open source projects where I've just gone in and converted existing JS files to DS and I always find back, it makes me feel really happy because it means that-
John Lindquist: Oh yeah, I'm sure.
Basarat: And it helps convince them as well that this is going to provide you some value. Another thing that is quite commonly on stack overflow. People will ask how do I do this in TypeScript and I just answer it, even though the question is really about how do I do this in JavaScript. So I love getting those questions because they're easy to answer.
John Lindquist: Easy points for Basarat.
Basarat: Yes. Literally. Another thing about going back to, your statement John about like TypeScript figures out this cannot be a number over here. That's sort of why I love JSX in TypeScript as well because when I'm writing JSX it's, and thought as the tooling is concerned, for TypeScript is just JavaScript.
Basarat: And if you have a dairy operator with one thing you want to render one item with the other choice, you want to render something else and you try to use available that might have been ruled out based based on previous conditions that should be pointed out. It cannot possibly be a number of overhead and you're trying to pass it as the number two or this component innocent error. So I love that.
John Lindquist: Yeah that sounds, honestly even if I have not used TypeScript with JSX yet. So, that's something I definitely need to check out. I've been using it a bit with some of the view features where some of the decorators you can put on the class properties are just so helpful as far as shorthand, like mapping a class property to like your story state is just a decorator with like a string key in there versus writing a method which returns an object, which returns the key, your turn.
John Lindquist: So my typical usage of TypeScript has been the like the helpful shorthand stuff. And I think that's what angular was kind of going for when they adopted it was they really wanted the decorators for the easier to map components for injection and for linking the class to a template and all that sort of stuff. Like that's honestly, that's been my exposure to TypeScript. I haven't dove super deep into the type systems and using all the features. But I've always thought of it as just JavaScript with additional features.
Marius Schulz: Yeah, I kinda like to use TypeScript for exactly the cases that you describe to you weren't using so much. So, I love to use, let me put this differently. I like to leverage as much as I can from the type system and the types that we have available to tailor my statically type models as well as I can. So, the idea is that I want to make illegal states on representable and the type system that doesn't always succeed to 100%, but you can get really, really close with the most recent TypeScript versions.
Marius Schulz: So if I can already express the type system that a certain combination of properties can never occur at the same time, then I can have the TypeScript compiler check that these bugs just don't occur. So to make this a little more more concrete to them, I have an example for you.
Marius Schulz: So oftentimes when you get an API response, you either get some sort of positive status code, so say 200 and a value or you get a bad status code like 400 or something and an error message, right? And previously in very early types of versions, you would model this as well. You get a response type and it has an optional property of type, some generic value and maybe an arrow string, right?
Marius Schulz: But they can never be set at the same time, because you either get an error or you get the value, but not both. So the way I model this today, I model exactly the two cases I can have. I can say, I have the success case where the success property is true and I have a value or I have the failure case where success is false and I have the error message and that is really valuable if she can do this to a great extent.
John Lindquist: Yeah, I haven't used it that way, but I can definitely see the appeal there. I mean it's to know that it's a fail type or if their request game or response came back as something not working.
Marius Schulz: Yeah, and the beautiful thing is, the compiler will not expose the properties so it will not make them show up in the auto completion lists until you've checked in which case you are. So, until you've checked that success is true. You cannot access the value property. It just doesn't show up in the auto completion list and it'll get the red squealy if you try it. So this is really, really powerful because it just can't forget it.
John Lindquist: That is cool, forcing you to handle the state before you write the code for it.
Marius Schulz: That's exactly.
Basarat: The data transfer objects between the front end, the backend, documenting them using TypeScript is one of the key use cases that I used to convince backend and they'll set the knee TypeScript. So quite commonly I'll ask them that you gave me this end point, what are the things that it returns? They do follow something like open spec or something like that. So I go to APIs but like in code.
Basarat: If they want to read their own code in JavaScript and tell me the answer, the answer would be much easier if they had written this tingle Jones and object of these union types in TypeScript. And originally this is no longer a discussion that I have with people but originally this would be, I would write it for them and then be like the mind will be blown away that in this particular case, I had written the wrong thing. I'm sorry for that. So documenting the details and touch scape. Great use case for backend.
Marius Schulz: Yeah, we do the same thing.
John Lindquist: Are Your backend developers using node? Like, are you able to share those type or interfaces between your front end and back end projects?
Basarat: Yep. So a lot of our backend and how all AWS LEM does at my current job written in TypeScript.
John Lindquist: Yeah. If you can adopt it across the full stack. I can, I haven't worked on a project like that yet, but I imagine the having confidence that the objects coming across are what they say they are. That sounds amazing. So what have you seen as far as tooling is concerned for people coming from like C# visual studio backgrounds or Java and IntelliJ and eclipse and all those. The history there has been with refactoring you're able to move methods around renamed classes, renamed properties and just to kind of have it magically fix or intelligently fix across your projects.
John Lindquist: Now that's something I've never quite seen in JavaScript land because you're never certain that the name of one thing, in one place is the name of another thing and in other place, especially with, you know, accessing something with a race in tax or what not. Are you using refactoring tool's that come with TypeScript? Do you, are you confident in them? Are you seeing them being adopted?
Marius Schulz: So the one thing I use all the time is the renaming refactoring, because I'm always trying to find better names for all my symbols. So it'd be that types or variables or functions. It doesn't matter, I'm constantly renaming things. And that's not a string replace. I mean, That is the proper refactoring like you note from Java and C#, the one refactoring.
John Lindquist: You're finding that working across all the files in your project properly?
Marius Schulz: Yeah, so rename works really well if you write modern JavaScript in a certain way. It's almost, it's kind of statically, no, erase that part. It's stupid, I'm sorry. So yeah, renaming is working really well for me, especially with the IS 2015 modules because then you're not relying on some sort of global variable that you know is hopefully going to be there and runtime. You're constantly doing imports and exports, so you can track really well where things come from. So the renaming works really well.
Basarat: Yeah. For me-
John Lindquist: Yeah, I take the modern stuff, imports, exports and all that for granted all the time though. I forget so quickly what JavaScript used to be with required.
Basarat: That's a good thing.
Marius Schulz: It was a different time five years ago, it really was.
John Lindquist: Oh yeah. And being able to know those names across files and how things were aliased across files anyway, good riddance. Right?
Marius Schulz: And building off of that, the new auto completion and automatic imports, they worked really well because the TypeScript conserve can know what exports we have, what imports we have, and if you just start the beginning of assemble name, you know, if you do something like get B for example, then you will see, get books in your auto completion. Even though you haven't even imported that method yet or that function yet. That all works because the modular system is really static.
John Lindquist: Basarat, I think I interrupted you.
Basarat: So, Rename works for me 100% of the time, never issues. When I click even do quite commonly is I'll name variables very explicitly like always accepts the name for the person, literally name the variable like that. Cause I know that I almost never have to type that full thing as well because that'll get auto complete from TypeScript.
Basarat: And then once the thing that the whole code section does what it's supposed to do, then I can look back and say, "Okay, is this always the case that this variable is really used like that?" If not F2, type in a new name, enter, done.
John Lindquist: So what do you think TypeScript has to do to become more popular in JavaScript land? I think I've seen more project templates using it, more starter templates and I think that really helps. Do you think there's anything else that's-
Basarat: I think it's on a meteoric rise right now. There is absolutely no stopping it. If you look at the trends for TypeScript on, trends.google.com it's amazing. It's exponential. Super exponential. So, and it actually shows up on like on the growth radar for GitHub in the OCTA universe for the last year. It's had a growth of 134% whereas its nearest competitor had a growth of I think 50% so it's a language that's going to self sustain for quite a while.
Marius Schulz: It's literally off the charts.
Basarat: Yes.
John Lindquist: So you're saying I should stop using coffee script then?
Marius Schulz: Please John Keep using coffee script as long as you want to, know flame wars here. Yeah, but do you use TypeScript?
John Lindquist: Yes. Yeah, I'm just trying to keep my job man. Job Security.
Marius Schulz: I think it's key for TypeScript to work well with the popular frameworks. I think this is what is really important, so it has to work well with angular, React, Vue and all the other ones. They're doing a great job there. And don't get me wrong, I just think this is something you'll always have to keep investing in because as you said before, decorators were crucial for angular. So as soon as TypeScript supported those really well, it was a great fit for angular.
Marius Schulz: For react, they needed JSX, so now he can use TypeScript with react really well. And sometimes I see a feature in the compiler and you can, you can tell why the team built it. So for example, they built a feature to accommodate redux reducers a little bit better. So if you're doing redux with react, TypeScript can help you do the switch cases a little bit nicer with the flow analysis.
John Lindquist: I've actually been really impressed recently in the past six months or so with the typing's improvement for four projects that don't ship with their own typing's files or you know, the definition files and being able to just find some random package. I need my project, whether it's a date utility or whatever it is. And then I'll see the auto completion pop up. I'm like, oh, I didn't, I wasn't expecting to have any help from my editor in this.
Marius Schulz: Where did that even come from?
John Lindquist: Yeah. So, seeing that the migration whenever that was, where it went to the at types packages and the community supporting them and cause that, that was, personally for me a hassle for a long time as the typing support for the third party. But that seems pretty much resolved now.
Marius Schulz: And honestly I think they're settled on a pretty elegant solution, because we had TSD before. So the TypeScript, what was it, was it TSD?
Basarat: Yep.
Marius Schulz: Yeah, TypeScript definitions I think. And then typing another TypeScript definition manager. So this is another tool, another package manager and now we just rely on NPM, which is I think a beautiful solution.
John Lindquist: Yeah, I remember seeing the definitely type GitHub repo and scrolling down for pages and pages and pages. It has been like, what is this? What is this project? It just kind of laughed at it at the time. It solves the problem, but it wasn't as elegant as NPM is for sure.
Basarat: Yeah. GitHub up, doesn't even show the route number of projects and definitely typed ... is at 3000 and they only show an X amount, 4,000 root level files.
John Lindquist: Oh wow. I wonder if that's unique to that project?
Basarat: I would assume so.
Marius Schulz: Yeah, maybe.
Basarat: So, like to increase tax ships adoption within other frameworks as well. Frameworks need to make a few better choices in the API designs as well. For example, string literals are not really statically analyze, well, if you're using string literals everywhere. And another thing that I see quite commonly in the libraries out there, especially in the CSS and JS libraries, is that they'll take objects that have key values with the keys being the name of properties for CSS properties, like a background color, color, font size and all that combined with selectors for nested elements such as on colon focus, go ahead and do this.
Basarat: Now, colon focus is something that is analyzable, but when you combine it with arbitrary selectors like on call and focus with Dev under it and a span under it, on that particular span at these particular set of Caesar's properties. What they essentially are doing there is combining these random strings with well use that are from a predetermined set. And if you want type safety for that year essentially can't have that cause you never know if the user is actually making an error in spelling a CSS property or are they going into a nested structure there.
Basarat: So this is something that we fixed with adding a special selector called dollar nest with Thai style. But is quite commonly in other CSS and JS solutions, I don't see it there and I can't really add 100% type safety to those libraries. Quite commonly like, if you want great safety, you have to think about it upfront in your API design is something worth mentioning.
John Lindquist: It's amazing to me that TypeScript is even useful for CSS. Like, what I saw and introduced at, that's not anything that ever crossed my mind or even the whole CSS and JavaScript, all those projects is one of those words that come from who had that crazy idea. And now it's a wildly, people just want to use JavaScript everywhere. JavaScript, all of the things I guess, and always been on JavaScript and it's amazing that CSS, analyze my TypeScript is a thing like that's blows my mind.
Marius Schulz: Yeah. JavaScript is now literally running everywhere. So even in astronauts helmets, we have JavaScript running, although I'm not entirely sure I would want to depend on Java script in then situation, but yeah.
Basarat: Yeah, CSS and JS is very similar to HTML being analyzed by JavaScript, which is essentially what GSX is. So like once Facebook came up with the concept of GSX, it was natural for people to see, oh, there's just one more thing we do in the front end web development, which is CSS, why can't we do that Intel script and that's where it came from.
John Lindquist: So what do you two use as far as you start a project, and web pack, and all that sort of stuff with TypeScript or if you were to just start a project from scratch right now, what would you turn to?
Marius Schulz: So I'm currently heavily invested in react, so I usually use react with web pack and TypeScript. And to Hook TypeScripts into web pack I use TS loader, so just the loader for TypeScript, which compiles all the files and let's meet import type script files. It works super well. I can strongly recommend this setup.
John Lindquist: Is there like create react app template for that?
Marius Schulz: There is a create react app port for TypeScript, although I'm not using that. So I usually start from scratch with an empty folder, and just set it up myself.
Basarat: That is pretty much what I do as well. So just copy the webpack.config.js from the last project, paste it into the new one. And I recently did a lesson on this, so it's really not that hard. It takes three minutes, to like literally write everything. And the Web pack Configuration that I have is essentially following the docs in TS loader which is the TypeScript loader for web pack. The reason why I don't use the solid cases is that they evolve really fast and they come up with a lot of things that I don't actually need.
Basarat: For CSS I use types you don't need any configuration for that study, just imported as a module, start using it. That's literally NPM install TypeScript type style, type shell shallow style, blah blah, blah, done. I like pictures like that.
John Lindquist: So, what's you're saying is when you're the person who answers all the questions on stack overflow, you don't copy and paste from stack overflow, you copy and paste from your own previous projects?
Basarat: Thank you for that.
Marius Schulz: Because this where this is like overflow answers came from in the first place.
Basarat: Yes.
John Lindquist: Let's see what else. So, is there anything upcoming in type script on the roadmap that either of you were super excited about that you can't wait to use or any reason to use this is there a prerelease usually there's at next version that has some new things to play around with.
Marius Schulz: Yeah. So we have the preview, releases every night. The Nike bills with the gift next tag. I'm really looking forward to JSX fragments, now that react 16 has landed, we can finally returned arrays from components when we render and Facebook standardized an extension of JSX, which formalizes fragments, right? And this is the new syntax and JSX and the TypeScript team has built this test of this committed this feature, and they're thinking about back porting it to 2.6.2 TypeScript. Or maybe we'll have to wait until 2.7 either way, I'm really looking forward to fragments.
Basarat: So, alien tooth the ID that I wrote for TypeScript. Always chips with TypeScript nightly. The reason why I wrote alien tooth is that I wanted a reliable ID for myself, And it comes with very strong opinions. And one of those strong opinions is that you should be on TypeScript nightly cause they're doing a great job. It'll find more bugs in your code. And it really does help me personally as well in the projects that I work on, even though the package that Jason has TypeScript 2.6 as an example, which released two days ago, ALM would be running TypeScript the next day after and if the new version of types could find more bugs, Ellen will highlight those for me and I'll fix them.
Basarat: So I would essentially be fixing bugs a bit known. What do you even know how I came up with the idea to fix this bug, but it's really just tight ship telling me that this thing cannot be this in this particular context and fix him. In terms of new features in TypeScript like JSX fragments would be really nice. But really, I'm very happy with it. Every single time a update they find more bugs in existing code bases.
Basarat: And other thing that they found recently was genetics used to be when they couldn't be inferred, they used to be inferred as any, but they changed that to now it's infant as an empty object. So if you don't specify a generic, and you try to use its value in, for example, in the promise Shane, you intellectually complained that property food does not exist on an empty object. What is the genetic that you expect?
Basarat: And, this makes sense in for example, in affects your quest to the backend. There's no way for to infer what's the return response is going to be. So you have to actually put the generic position in there, that is going to be an object that has just these particular properties. But yeah, just update to that script nightly new stuff comes up every single day.
John Lindquist: That's amazing. I have working with a nightly build in production type apps is like a horror story for most people. And it's incredible to me that you're actually advocating that. Like you're, so TypeScript has proven itself so well to you that you're confident to use the nightly and that it will actually help you find bugs sooner. That is a story that's hard to believe but wow. I mean.
Marius Schulz: But I can attest to the quality of the master branch. So I have the same experience. I did the same and one of my projects never did I see anything fail. So it was a really high quality build. And the fun thing is, or the funny thing about this is, if they want to cut a new TypeScript release, they simply pick the newest master commit and attach a tag to it. This is what releasing a new types group version looks like.
Marius Schulz: So it's not like they're pulling off different branch, stabilizing that for six weeks. They're just picking the top most master commit at a certain point. And then that's TypeScript, you know, 2.6 there you go.
Basarat: They never release a new feature without breaking anything. And all new features come with new tests as well. So if the master bill succeeds, you got to go, and it's probably going to affect some obscure issue that you had in your code previously that you didn't know about.
John Lindquist: I'm sure the TypeScript compiler and language services and all that, like their test covered is probably a great place to learn how to test your code. If you want to get on GitHub and look at their tests.
Basarat: Maybe, maybe not. It's probably too aggressive for many of the projects out there. It's kind of very opening at a test harness as well, and that's specific to types of course, like if you want to build a compiler, and you want excellent test for that, and then yes, TypeScript is the place to go to, to read the source code.
Marius Schulz: Yeah, I agree. For typical crud apps or a typical web development apps that we ride in everyday, web development jobs, the tests width of the TypeScript compiler is a different beast. They even have their own test harness framework because they test everything about TypeScript, right? They test that the red squeegees that an editor would show exactly in the right place and not one character to the left or to the right and this is so much customization. It's, yeah, not what you would use for your everyday projects.
Basarat: The test auto complete shows up the right things. The test that the symbols that TypeScript has inferred, for example, that this thing is out numbered at a particular position. They have a test harness to do that as well and their own language to do that as well.
Marius Schulz: But it's perfect because for them, it's a really good tool to catch regressions because if you're working at this breakneck speed, do you want to make sure that you don't break all this stuff from, you know, previous releases.
John Lindquist: Yeah, for sure. Do either of you have a wishlist or is there a feature that you think or that you would love to be implemented other than the fragments which you mentioned earlier that if you had someone from the TypeScript team, he'd be like, "Please get this done."
Marius Schulz: Let's see. I'm pretty happy with the general state of affairs to be honest. And I also respect their decision very much that they don't want to deviate too much from the current ECMAScript standards. So they're not making up any new syntax anymore for nonstandard JavaScript features because if TC39 standardizes new features, test has to accommodate all of these features so they can't constantly make up new syntax. Otherwise, we might run into conflicts there. So I respect that decision very much. I think it's a good decision.
John Lindquist: At what stage does a feature have to be in before TypeScript considers it?
Marius Schulz: Pretty stable. Correct me Basarat if I'm wrong, but I think they're not looking at features before stage three and onwards. I would say. So it has to be fairly stable.
Basarat: Yep. So, the features that I'm looking forward to are all telescope features because of the reasons that Mary's explained, they don't add new features and they stay gels and the features in JavaScript that I want are the [inaudible 00:39:51] operator, also called the existential operator, the question mark dot. That would make life so much easier, especially with TypeScript, straighten all jacks.
Basarat: It would actually infer that how the Nelda flowing to the whole thing as well, but just giving a syntax to deal with knows a bit better with the Elvis operators just would be so much easier working with, especially with the dom where quite commonly things are, for example, document.getelementbyid, this element may not exist. Dot Style, Dot the index read me that really like ... if you want to write code like that, you have to do document that get element by ID doesn't exist.
Basarat: If it does not, then either you do the query twice, which would be a bad idea, but what you'd actually do is you store it in a variable. Then you take the nail in the variable and then you go to style and then you go to the index with existential, you could just write document.getelementbyid?.style.zindex and that shouldn't go further. This value maybe a number of maybe a now and then when you try to use it as a number, you can get you on the Elvis thing of your code if you wanted to.
Marius Schulz: Yeah, I agree. That is a fantastic operator. So if that's coming to JavaScript when that's coming to JavaScript, then TypeScript will definitely have to implement it and I'm really looking forward to that one. Also there is one other proposal for the pipe operator. So the operator is a pipe symbol, and a great than sign and I think currently it's at stage one of the TC39 process. The idea of the pipe operator's that you can pipe values on the left into functions on the right.
Marius Schulz: So say, you have something like A pipe B, then this means, call the function B with A as an argument. So this is a really functional style of developing and it's really nice if you have a chain of transforms that you want to apply to a certain value. So, say you read an input from a certain text field and then you convert it to an end and then you maybe check it and then you transform it and then you transform it some more.
Marius Schulz: And if we do this in current JavaScript, we have to write it from the inside out. So if you write A opening prem, B opening prem, C prem, you basically have to read it from the inside, right? Because you apply, C first, and then B, and then A. And it will be much more natural if you could say, take this value X and first pipe it into X and then pipe it into B and then pipe it into A. So you can read it an execution order.
Marius Schulz: This one is huge. So if it ends up being standard JavaScript, we'll have it in TypeScript as well of course, because we're a super set of JavaScript and that will be fantastic.
John Lindquist: Yeah, I'd love that as well. I mean it's available in some libraries like [inaudible 00:42:37] as methods are, but having a native feature on it would be fantastic. I agree.
Basarat: The other thing that I love about the types of TypeScript team is they add all these features with static analysis as well. So people use the rest of operator to death even before it was in TypeScript in other [inaudible 00:43:00] and when TypeScript edit the same feature, they did it with the static analysis associated with that as well. For example, if you have an object that has [inaudible 00:43:11] A, B and C, and you destructure it into something that takes a variable A out, and puts everything else into arrest using spread.
Basarat: TypeScript knows that react has the properties B and C, and similarly with like this as well, I would assume that they would add all the static analysis associated to that, with the binded, make sure that the thing that you're bonding to take same arguments that would be get passed to it if you had written in the function inside out men and stuff like that. I would not use any of these features without TypeScript. And just waiting for them to get to TypeScript.
John Lindquist: Yeah. If we had bind and pipes and you showed that code to me five years ago or whatever, I would just have no idea what it even meant.
Marius Schulz: Just look up partial application, the proposal for partial application and it gets even more functional. It looks really funny. So, maybe take some time and read that proposal.
John Lindquist: Yeah, I'm really natural to people coming from that background.
Marius Schulz: Yeah, I think so. There's one more thing that just popped into my mind that I wanted to say about future features that I wish to make it into TypeScript. I think it would be good if we had more support for nominal typing. I know it's on the roadmap, but it's been on the future section of the roadmap for ever basically. The thing is, the type script type system is a structural type system.
Marius Schulz: So if you have two types and they're similar in structure or the same instructure, there is the same for TypeScript mostly. So if you have, for example, a pet type that has a name and an age maybe, and you have a person type that has a name and an age, the two types are the same for TypeScript, because both describe an object with a name, and an age property. That is good in some respects and is usually in JavaScript plan what you want, because you can access the correct properties, they have the same types, yada, yada, yada.
Marius Schulz: But, sometimes it might be helpful to distinguished types by name. So nominal typing means telling types apart by name. And I think that would be really cool if we had some sort of, I don't know, maybe a keyword when declaring types or whatever. I don't care about the implementation. I would just like a certain degree of support for nominal typing. What do you think Basaratd?
Basarat: Yeah, that would be excellent. It's something that we send nominal typing for keys in databases. Essentially user ID is not the same as table ID, even though they're both underlined by a string, you don't want to ever assign one to the other that it sounds ridiculous, but it's a mistake that happens quite commonly in code bases out there. And having support for that entire script would be excellent.
Marius Schulz: Yeah, just think about units of measurements or currencies. You can have two amounts of money. One is in US dollar is one is in euros maybe, you shouldn't just be able to add those. That should be a type error. You can't add a US dollar amount, and euro amount and get something reasonable out of it. So this would be really helpful if you could say this number is not the same as that number.
Marius Schulz: You know at runtime, they're both going to be numbers of course. But one has the name USD maybe, and the other one has the name EUR for the currency symbols. And we can tell them apart and not mix them by accident. So I don't know how many rockets have exploded because people have conflated miles with kilometers.
Basarat: So, basics you know.
John Lindquist: We almost made it to the moon, but we used kilometers instead of miles and such.
Marius Schulz: I wasn't joking about this. Honestly, this is not a joke, sadly.
John Lindquist: Oh, okay.
Marius Schulz: There was a case of, I don't know what mission it was, but one rocket I think exploded or went loss or something caused billions of dollars in damages because part of the team was using the metric system and part of the team wasn't, and when you add distances and you're off by a factor of 1.6 between the two systems, that's really not good.
Basarat: It was a Mars orbiter.
John Lindquist: All right. Let's see, is there anything else either of you would want to talk about or discuss or bring up?
Marius Schulz: I want to thank the TypeScript team, just maybe as the last thing here. I think there been doing a phenomenal job over the last years. All in the open, I don't want to say break neck speed, but at a really, really high velocity, at a tremendous quality. And, I think we're not even close to being done yet. So, thanks to everybody who was involved with the TypeScript project.
Basarat: All of the TypeScript team.
John Lindquist: Awesome. Well Great. Okay, well for the conclusion like the end of the show thing, I'll do a pitch for both of you, both of you and your courses on egghead and all that, and say go to this URL for that and find out the best wording for it. So, I'll add that in later.
Marius Schulz: That was fun. Can you maybe provide some sort of Bitly, or how do you want to do this? I thought about this before. So how do you direct somebody who's just listening to one of your courses? You just say type in, TypeScript in the search box or do you want to create a Bitly or?
Basarat: He'll probably have links.
John Lindquist: Not quite sure yet?
Basarat: He'll probably have for dekagram.
John Lindquist: Yeah, we'll figure something out as far as where the podcast is hosted, and what sort of URLs we can include with that around it, and how all the marketing works around it. We'll, sort that all out as we have to get this edited and stuff around. So thanks for your patience and everything getting around the initial goal of this.
Marius Schulz: Yeah. Thanks for inviting us. I had lots of fun.
John Lindquist: And thank you for all the excellent stuff you've done. You guys are both amazing.
Basarat: Thank you, thank you for having me.
John Lindquist: All right guys. We'll talk soon.
Marius Schulz: Talk to you soon. Bye.
John Lindquist: Bye.
Announcer: Learn more about type script from Marius and Basarat on egghead.io.