Season 1 Episode 4 Aug 27, 2020

TypeScript 4.0, Gitee, Chromium, and Apple Drama

Pitch

We dive into the making of TypeScript 4.0.

Description

In this episode, we talk more about Appleā€™s ongoing App Store drama, a proposal to let Chromium talk to your local network, and Gitee, the GitHub of China. We also speak with Nathan Shively-Sanders and Orta Therox, engineers on the TypeScript team, about the newest version of TypeScript, version 4.0.

Hosts

Vaidehi Joshi

Vaidehi Joshi is a senior software engineer at DEV, and creator of the Base.cs blog series and co-host of the Base.cs podcast.

Josh Puetz

Josh Puetz is Principal Software Engineer at DEV

Guests

Nathan Shively-Sanders

Nathan Shively-Sanders is an engineer at Microsoft working on the Typescript team. He's worked on compilers for almost 10 years, most recently on Javascript support in the Typescript compiler, and Definitely Typed.

Orta Therox

Orta Therox is an engineer on the TypeScript team with a long history of OSS.

Show Notes

Audio file size

57578982

Duration

00:39:59

Transcript

[00:00:00] LS: Hey, DevNews listeners. This is Levi Sharpe, the producer of the podcast. We really want to benefit from your feedback on the show. So we’re gifting anyone who submits a review on Apple Podcasts, a pack of Dev stickers. All you have to do is leave a review on Apple Podcasts and then fill out the form in our show notes so that we have your mailing address for the stickers. Thanks for listening.

 

[MUSIC BREAK]

 

[00:00:30] JP: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Josh Puetz, Principal Engineer at Forem.

 

[00:00:38] VJ: And I’m Vaidehi Joshi, Senior Engineer at Forem.

 

[00:00:41] JP: This week on the show, we’re talking more about Apple’s ongoing app store drama, a proposal to let Chromium talk to your local network, and Gitee, the GitHub of China.

 

[00:00:50] VJ: And then we’ll be speaking with Nathan Shively-Sanders Orta Therox, Engineers on the TypeScript team, about the newest version of TypeScript Version 4.0.

 

[00:00:59] OT: We were trying to address a specific problem with that feature and then it turned out that that feature didn’t necessarily address the problems. So that’s like a feature that got dropped and is now an evaluation in a different perspective.

 

[00:01:11] JP: First off, we have two quick updates on Apple’s ongoing spat with Epic Games. Last week, we covered how Epic’s popular multiplayer game, Fortnite, was kicked off of the Apple App Store, as well as the Google Play Store for pushing an update that allowed users to make in-app purchases of game currency with a discount directly from Epic itself. After Apple kicked Fortnite off the App Store, they also threatened to suspend Epics’ developer tools. This would impact things like Unreal Engine, which is used to create many cross platform games that run on both iOS and macOS. Epic has sued both Apple and Google in response. Recently, Microsoft put out a statement of support for Epics saying that, “Apple’s discontinuation of Epic’s ability to develop and support Unreal Engine for iOS or macOS will harm game creators and gamers.” Of course, Microsoft’s not a neutral party in this. They have an xCloud gaming client that was recently rejected from the iOS App Store by Apple. Fast forward to this week, and courts granted Epic Games a temporary restraining order against Apple’s threat to suspend their Unreal Engine license. Judge Yvonne Gonzalez Rogers acknowledged that Epic “strategically chose to breach his agreements with Apple”, but argue that the dispute shouldn’t create habit for by standards. This means that Apple will be prevented from suspending Unreal Engine in retaliation against Epic. However, the ruling does not cover Fortnite at all. So it’s still off of the App Store for now.

 

[00:02:38] VJ: It’s so interesting to see more and more companies taking a side against Apple. I’m not sure if this is the first time that Microsoft has sort of jumped into this conversation, but I think it’s interesting that they put out the statement supporting Epic. Right? And we have the courts siding with them too. And it’s interesting to see this battle between large tech company and other entities. I’m not convinced that it will have a major impact on what Apple is doing. They still are going to like make money from their App Store and they’re still going to continue to charge 30%.

 

[00:03:09] JP: I think what’s different here is we’re seeing larger tech companies line up behind Epic and say, “We support them.” They obviously have invested reasons for doing so. Spotify was another large tech company that before this put out a statement of support, Spotify, of course, competes with Apple, for music streaming services and would love, I imagine, to offer subscriptions in their app without a 30% cut. But I think the larger tech companies lining up against Apple’s App Store policies will have more weight and power to make Apple change than a bunch of independent indie developers.

 

[00:03:46] VJ: Yeah. Absolutely. And that’s something we’ve talked about on the show quite frequently, where smaller entities, indie developers have a hard time making things work in Apple’s App Store universe, but now we have larger companies sort of joining in and obviously valid reasons for doing so. But again, it’s funny that Microsoft joins in now, but they maybe don’t support a smaller developer earlier, but now they have a reason to join. So I always find that very interesting.

 

[00:04:16] JP: Right. Yeah. So in other App Store news, Apple does something really rare this past week. It issued an apology to a developer. Here’s the background, WordPress, which is an online blogging platform, had not updated their application in quite a while. Their founder, Matt Mullenweg, was tweeting that their updates to their iOS application were being held back by Apple in App Review. Apple claimed that WordPress had language that mentioned paid tiers. According to Mullenweg and WordPress, Apple was requesting that WordPress add an in-app purchase feature to purchase these tiers and then collect 30% off of those purchases simply because they were mentioned in the application. Now a little bit of background, WordPress is free to use. You got a website, you can create a blog or whatever you’d like, but they do offer paid tiers with additional features. I think the problem here is that the app has never supported in-app purchases. There’s no way to actually buy these paid tiers within their iOS application. It turns out they’re just mentioned on a support page somewhere. So it’s not like they were trying to do an end-around around Apple’s policies and support purchases elsewhere like Epic is, they just simply never had a way to purchase and obviously Twitter went nuts on this news. And over the weekend, Apple reversed course and issued an apology. In their statement, they said that the issue with the WordPress app had been resolved. They also said, “The developer removed the display of their service payment options from the app. So it’s now a free standalone app.” For his part, Mullenweg said that they didn’t change anything on their side, and it seemed like Apple just reversed course in response to public opinion. So it’s kind of a non-apology from Apple, but it’s still interesting to see that these issues with in-app purchases keep coming up and Apple’s default response to any hint of commercial activity in an application seems to be, “You need to put a way in there for us to get our 30% cut.”

 

[00:06:24] VJ: I’ll be curious to see whether this affects Apple’s reputation at all and how people in the public and in the industry perceive them.

 

[00:06:32] JP: Well, I’m sure this is not the last we have heard of Apple App Store drama. We will keep you posted.

 

[00:06:39] VJ: In other news, China’s Ministry of Industry and Information Technology recently announced that a company called Gitee had won a bid to work on a project. The project is called “The 2020 Open Source Hosting Platform Project”. As it turns out, Gitee has actually been around for the last seven years as a Chinese source code hosting platform. Very similar to GitHub. Gitee claims that it hosts more than 10 million open source repositories and supports over 5 million developers. Now Gitee will be working to build what the Chinese government calls “an independent open source code hosting plan for China”. The project itself health is led by a group called Open Source China, and it’s supported by universities and 10 private organizations, including the very large corporation Huawei. This project comes as a move from the Chinese government in order to gain more autonomy and support local open source communities in China. Back in July of 2019, GitHub actually blocked developers located in Iran, Syria, and Crimea due to US trade restrictions. So China has good reason to ensure that its software ecosystem is not vulnerable to these kinds of political conflicts. So it’s really interesting. I wonder how much of the current political climate is impacting China’s decision to put their money where their mouth is, so to speak, and support creating their own open source platform. Because currently, the current administration in the United States has a lot of anti-Chinese rhetoric. So maybe that’s speeding up something that was already at top of mind for them.

 

[00:08:26] JP: I would not be surprised at all. I mean, I think of it from a Chinese perspective, if you’re an open source creator, I think the threat is real that you could find your access to GitHub potentially cut off at some point, your project may be delisted, something happening with our government passing a law that would force GitHub to block developers in China like they did with Iran and Syria and Crimea. I think it’s a real threat.

 

[00:08:51] VJ: Yeah. And I remember back in July of last year, when those US sanctions did go out, a lot of developers that were located in those countries, Iran is the one that I’m really thinking about the most, I remember that they just woke up one day and suddenly they just didn’t have access to these libraries and frameworks and projects that they relied upon and where their livelihood and it was just a very sudden move and something like that could very much cripple a local software economy.

 

[00:09:23] JP: Yeah.

 

[00:09:23] VJ: So it definitely makes a lot of sense why they’d want to create their own. But how do you think this will affect GitHub? Do you think it’s going to like impact them at all? Do you think that they will respond to it at all?

 

[00:09:35] JP: I don’t know. So I’ve been looking around on Gitee for projects that I either recognized or looked interesting. I don’t speak Chinese or read Chinese. So it was a little hard for me to get around the site. There are English sections of the site and the support pages. Their support and their onboarding are all in English. I was able to create an account and create a repository. That all worked great. Obviously, most of the projects that are in Gitee right now are all in Chinese. Some of them have English documentation, but it’s kind of like a parallel universe. It feels like a parallel universe to GitHub. So I don’t know that GitHub would be like necessarily very concerned in terms of like open source Mindshare where I think they may be concerned is the enterprise market. There is a prominent enterprise tab on Gitee.com and they do have an enterprise offering for paid support and on premises. So I believe there were discussions about GitHub expanding into the Chinese enterprise market. If that’s something they’re interested in, this could definitely be a competitor to them.

 

[00:10:43] VJ: I mean, even shifting gears away from GitHub, the company, and more just towards the open source aspect, I’m curious to see how this is going to impact developers that are working in the open source ecosystem that now are going to sort of have to choose between these two different, but parallel platforms. Are they going to start contributing to projects that are on Gitee only? If something like a US sanction occurs, maybe they’ll have to. And then what’s going to happen to those projects that rely on those open source contributors that are located in China? They might lose like all of these amazing contributors and this momentum that they currently rely on because that’s the beauty of open source.

 

[00:11:31] JP: Yeah. I don’t think every country having their own version of GitHub is the open source utopia we envisioned. I can’t imagine many open source projects would want to maintain a repository on Gitee and GitHub. That sounds like a nightmare, but I mean a lot of open source projects have contributors from all across the globe. So if an entire country is cut off from GitHub, like we saw with Iran, it not only affects projects that are based in Iran, it affects projects that are based everywhere.

 

[00:12:01] VJ: Yeah, absolutely. And I’m curious to see if the politics seeps into the software side of things, whether we start to see a split or a crack in the open source world, because now people are going to start being potentially more isolated from one another, a developer in one location may not be able to do what another developer in a different location can. I can’t foresee that being a good thing at all, because to me, like open source needs people from everywhere in order to work the way it does. And I feel like this is not going to be a positive thing for open source, although I completely understand where they’re coming from.

 

[00:12:40] JP: Right. Right. I think about the libraries that are open source that I use on a daily basis and I don’t know where they’re from. I don’t associate a country or nationality with them. I think a big part of that is American privilege. Honestly, I don’t have to worry about that. In other countries, that’s probably more at top of mind. I just would want us as an industry to get away from that versus running towards it.

 

[00:13:10] VJ: Yeah, absolutely.

 

[00:13:11] JP: I mean, on the other hand, though, I could definitely see the value in having a language localized social coding site to support Chinese developers. Not everyone is going to speak flawless English or be comfortable navigating a site with all English. This could be a great way for developers in China that don’t have a lot of exposure to English and don’t have a lot of exposure to English speaking communities to create open source and share it.

 

[00:13:40] VJ: Absolutely. Yeah. That’s a good point. And I wonder if there’s a positive outcome here, maybe it’s that GitHub might be pushed to make their platform more inclusive so that if you’re located in a different country or if English isn’t your first language, the barrier to entry is still much lower because the platform exists for everybody. So I wonder if this will be like a push for them to release more interesting features and updates, sort of in the realm of inclusivity. Maybe this competition will be a good thing for GitHub ultimately.

 

[00:14:15] JP: I think it will be a good thing for GitHub ultimately. I’m just saddened at the political forces causing the competition.

 

[00:14:22] VJ: Yeah, totally.

 

[MUSIC BREAK]

 

[AD]

 

[00:14:42] SY: Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

 

[00:14:59] JP: Vonage is a cloud communications platform that allows developers to integrate voice, video, and messaging into their applications using their communication APIs. So whether you want to build video calls into your app, create a Facebook bot or build applications on top of programmable phone numbers, Vonage has you covered. Sign up for an account at developer.nexmo.com and use the promo code DEVTO10, that’s D-E-V-T-O-1-0, by October 10th for 10 euros of free credit.

 

[AD END]

 

[00:15:31] JP: Next up is something that piqued our interest this week, there’s a proposal out of Google’s Chromium team that would get this add support for the browser directly accessing TCP and UDP ports. In a post by Chromium Engineer, Eric Willigers, he explained that the proposal is intended to support web applications that need to communicate over protocols that aren’t traditionally in browsers like HTTP or web sockets. He mentioned some use cases that I hadn’t heard of before, things like a webpage communicating with legacy equipment or talking to servers behind firewalls or, I thought this was wild, serving as a proxy for a server behind a firewall. So for example, if you have a mail server somewhere, the webpage could use UDP and TCP to talk to a mail server and then talk to the general web over HTTP. So as expected, several security experts raised concerns about this on Twitter. They’re talking about this opens a real possibility for things like a web-based distributed denial of service attack or ways for webpages to bypass cross origin resource sharing. The Chromium team pointed out that this capability kind of already exists in something called Chrome Apps. That’s a legacy way of extending Chrome’s functionality. That’s actually going away in a couple of years. They’re prototyping the feature now and their intention is to initially ship it on ChromeOS before they ship it for other versions of Chrome. So Vaidehi, give me your nightmare security scenarios around this feature.

 

[00:17:14] VJ: Oh, well, I mean the worst-case scenario that I can think of is just like having a webpage that somebody can like inject a JavaScript script tag or something into invoke it, fill out a form, and like if you haven’t thought about security enough and like if it’s just open and out there, maybe it has access to your printer or your front door or literally any kind of the internet of things device that really crosses a privacy line. I don’t know what’s so terrible about somebody having access to your printer actually. I can think of a way worse versions of this, but any kind of like hardware within my own network, I would not want any web based application to be able to just communicate directly with that without having any kind of like security around it.

 

[00:18:00] JP: Yeah. So there was a mock-up of how they would handle that security. And I was envisioning maybe you see this on mobile devices, something pops up and says, “This application or this website page would like to look at your location.” The mock-up the Chromium team had was a box that would pop up that would actually prompt you for the IP address and the port. What some commentaries found interesting was nobody else could really think of an example of a security prompt that required user input like that. So that’s interesting.

 

[00:18:31] VJ: Is it that you would need to know the IP address and the port of the server or the device that you’re talking to and the idea is like hopefully most people don’t have that information or you should only have it if you own the device?

 

[00:18:44] JP: Yeah. Yeah. That seems to be the intent that if you were in one of these very special circumstances and the webpage needed to talk to your printer, you’d have to actually put in the local IP address and port of your printer. That could cut down on, I think, some security problems. It still seems real dicey to me.

 

[00:19:03] VJ: Yeah, absolutely. I still have doubts, but I could think of like a lot of cool things you could build with it, but just because you can build it doesn’t make me want to go down that path.

 

[00:19:16] JP: So if people are interested, there are some really interesting discussions on the Chromium mailing list about this, and there’s a GitHub repository that has a document explaining their rationale. And some of the use cases they pointed out were wild to me. They talked about webpages communicating with like factory equipment, legacy like routers and switches, like older equipment that doesn’t communicate over HTTP. What was the rationale? They also pointed out in the past way the way webpages have communicated with these devices have been through extension technologies like ActiveX and Silverlight and Java Applets. And those are technologies that were used maybe 10 years ago and of course totally fallen out of favor. There’s really no replacement for them right now.

 

[00:20:07] VJ: It’s a unique idea to think about how you can tap back into that technology that exists, but it’s sort of like not being used to its fullest extent. I’ll be curious to see how it’s received after it ships to Chrome OS, if that indeed ends up happening.

 

[00:20:24] JP: I thought that was an interesting choice as well to ship it first on Chrome OS because if you think about communicating with local devices, one answer would be, “Well, why would a webpage need to do this anyways?” Just download an application that could directly talk to a device. But of course, on Chrome OS, you can’t do that. Everything is in the browser on Chrome OS. So almost wonder if there’s a very specific use case that the team might have in mind for this. Like the choice of Chrome OS is really, really interesting as filling a gap that Chrome OS can’t really do right now.

 

[00:20:59] VJ: Yeah. And I wonder if this ends up actually happening, if we’ll start leaning more towards browser based communication and eliminate the need to create and download native apps to communicate with devices, because you just mentioned that Chrome might be building this feature out for a very specific use case, but if it works and if it’s adopted, now maybe we don’t necessarily need to have native apps to do everything. Maybe things just can sort of pivot back to the web. That’s just a theory who knows if it’ll happen, but I wonder if that’s what they have in the back of their minds.

 

[00:21:38] JP: That’s an interesting because communication with local devices like this is really one of the areas that web technologies haven’t been able to make inroads against native applications.

 

[00:21:48] VJ: Yeah, absolutely. And coming up next, we’ll chat with Nathan Shively-Sanders and Orta Therox, Engineers on the TypeScript team, about the latest version of TypeScript Version 4.0.

 

[MUSIC BREAK]

 

[AD]

 

[00:22:18] SY: Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

 

[00:22:35] JP: Vonage is a cloud communications platform that allows developers to integrate voice, video, and messaging into their applications using their communication APIs. So whether you want to build video calls into your app, create a Facebook bot or build applications on top of programmable phone numbers, Vonage has you covered. Sign up for an account at developer.nexmo.com and use the promo code DEVTO10, that’s D-E-V-T-O-1-0, by October 10th for 10 euros of free credit.

 

[AD END]

 

[00:23:08] VJ: And with us today, we have Nathan Shively-Sanders and Orta Therox, Engineers on the TypeScript team, to tell us about the new version of TypeScript Version 4.0.

 

[00:23:18] OT: Hi.

 

[00:23:19] VJ: So before we get into the new version of TypeScript, can you tell us a little bit about your backgrounds and your roles on the TypeScript team?

 

[00:23:27] NS: Sure. So I’m Nathan. I’ve been at Microsoft, working on compilers, for about 10 years and 5 of those have been on TypeScript, sort of my two main areas that I work on in TypeScript are one in JavaScript support. So actually TypeScript supports JavaScript editing and VS Code and a bunch of other editors as well. And I also work on DefinitelyTyped, which is the community repository for types. If you have a JavaScript library that doesn’t have types, you can download types from DefinitelyTyped instead and that way you can like edit your support for old or just libraries that don’t support TypeScript.

 

[00:24:00] OT: And I am Orta Therox. I’ve been at Microsoft for a year and I’ve been at TypeScript for the entire time. I came in with a focus on sort of ecosystem and sort of how TypeScript interacts with the public as my sort of perspective. So sometimes that has touched on DefinitelyTyped with Nathan, but the thing that most people will know is the new TypeScript website that came out a week or two ago, and that’s been one of the big things that I’ve been working on for this entire year.

 

[00:24:25] JP: So for the uninitiated, could you explain to us what TypeScript is and kind of talk about its place within the developer ecosystem?

 

[00:24:33] NS: TypeScript, at first glance, it kind of sounds like a new language, one of the many compiler JavaScript languages, and there is a compiler step, but its intent really is to take JavaScript and just add an additional layer of safety and support around it. When you start writing a large program in JavaScript, you very quickly find out that you can’t keep the whole thing in your head and you start making mistakes that are just really annoying. They feel like trivial mistakes. And in fact, they are trivial and can be prevented by a machine. And so you sort of feel like you’re doing groundwork essentially. So TypeScript’s intention is to provide support in your program so that an editor can figure out what everything is and then just tell you when you misspelled a first name incorrectly. So like the example that we always use is you’ve got an object and it has a property name and you forget and call it first name and last name. Well, we’ll put a little red sticker in your editor and tell you, “Don’t do that.” And just beyond that basic level of support, there’s also just a lot of support for type programming, which is just not trying to stop mistakes, but also to take the concepts that you had in your head when you were writing your program and sort of turn them into an explicit type so that other people can see it. And that really does help structure your program in a slightly different way that makes it able to grow. You can go from a medium-sized program to a large program and without having any growing pains.

 

[00:25:56] OT: I think the easiest angle for people to understand if they’re coming in from scratch and don’t know much about TypeScript is that TypeScript tries to be exactly the same as JavaScript types. So chances are of all the JavaScript you’ve been writing your entire life you already know TypeScript because it’s the same thing but then a little bit more on top of that. That’s how we can provide all the tools that Nathan starts talking about earlier.

 

[00:26:20] JP: So one of the things that was mentioned in the blog post announcing TypeScript 4.0 was there were no breaking changes and that this was a great time to start using it, I wanted to ask, was there anything specific with this release that you designed in order to make it easier or more friendly for new users? And was there a specific push to make sure there were no breaking changes?

 

[00:26:45] NS: So talking about breaking changes, we’ve actually, at any given time, I got sort of a queue of breaking changes that we would like to make.

 

[00:26:52] JP: Oh, interesting.

 

[00:26:53] NS: And our PM, Daniel, in our design meetings, somebody will say, “Okay, I want to make this change. It’s going to be this breaking change.” And Daniel will say, “Nope, we’re pull up for 3.9. Nope, we’ll pull up for 4.0.”

 

[00:27:05] JP: So you have an idea that you kind of want to cap the amount of breaking changes in that release?

 

[00:27:11] NS: Oh, definitely. Yeah. We ideally would keep that to zero, but there are always things that we want to do that make things better for most people and then break a few programs. So yeah. We try to keep breaking changes small and then we ration them per release, basically. So here’s a good example. There’s a new feature. You can delete properties in JavaScript. If you have an object, you can say, “Delete object.prop,” and then it will delete prop from the object if it’s there, which I don’t know, maybe you want to do that one in a million times. It’s not super common. But in TypeScript now you’re required to declare that property as optional because you could delete it. So if you want to delete something, you must now declare it as optional. And there were some programs, I think, even VS Code, maybe you delete a couple of times and they had to update their code to declare in a couple of properties as optional, meaning that, yeah, they could be missing because in the code we saw that they called delete only a couple of times. So it’s a nice new feature. It gives you some nice safety. But on the flip side, it involves some programming.

 

[00:28:12] VJ: So since we’re just sort of talking about new features and updates to this version of TypeScript, what are some of the most notable ones, just anything that you think stands out to you?

 

[00:28:23] NS: There are some really cool but esoteric type system features, which are good for library authors. They were having to write tons of overloads and things like that. And it’s an advanced feature, but for new people, actually, one of the coolest things is that we now have a refactor that tells you when you should use the new optional chaining operator. It’s this thing called “question dot”. So normally when you say object.property, JavaScript actually crashes the object if it’s not defined and it says, “Oh, there’s no property called prop on undefined.” So there’s this new operator called “question dot” where you can say object?.prop and it won’t crash anymore. Instead it will just propagate the undefined. So if an object happens to be undefined, it’ll just skip looking at prop and it will say, “Oh, well, that’s just undefined.”

 

[00:29:07] VJ: Nice.

 

[00:29:08] JP: Nice.

 

[00:29:08] NS: And so in the past, people have written a lot of code that says, “Okay, if object is defined, then you get object.prop. And if object.prop is defined, then you can get object.prop.net, and if it’s not defined, and blah, blah, blah, blah, blah. So you can replace that all with object?.prop.question.nested, which is cool, but you may not know about this new feature. So in new 4,0, there’s actually a refactor that if you select something with a bunch of net guarding type of code that checks at each step, it’ll say, “Hey, you can turn this into a series of question dots if you click it,” and it converts it into a series of question dots, which improves the discoverability feature because there’s a feature that you may not have even known about and it’s helping you shrink the amount of code you have.

 

[00:29:51] VJ: Yeah. I can definitely think back to previous projects I’ve worked on and that question would have been super helpful. I’m very glad it’s a thing.

 

[00:29:59] OT: Yeah. It’s not something that people generally consider a feature of TypeScript. They generally consider those to be like, “That’s a thing that VS Code provides.” But nearly all of the refactorings inside VS Code in the context of JavaScript come from the TypeScript, like code base, if you will. So that’s like an area that like TypeScript owns and with releases, then you get new features like that too.

 

[00:30:22] NS: Another interesting feature that I thought I would hate, but it turns out it’s actually really good is we now put strikethroughs on things that are deprecated. Actually one of our community members did this feature and it was surprisingly involved. But what it does is any time you see this app deprecated tag on something, it tells the editor, “By the way, this particular thing is not really an error, but you should put a strikethrough through it.” And so if you use a deprecated thing, you get a strikethrough, and then when you hover over it, hopefully the person who put the deprecated tag tells you what you should use instead. And I ran into this problem myself two weeks ago when I was using something that was deprecated. Well, it wasn’t marked as deprecated. And it turns out the API was really hard to use. And when I asked our team, one of the other team members said, “Oh, yeah, yeah, use that other new thing instead.” I was like, “Oh, that should have been deprecated and then I would have known how to use it.” So it’s kind of a basic feature, but it’s cool to have it.

 

[00:31:21] VJ: Orta, is there anything that you’d like to add in terms of features that you’re excited about or you think are notable?

 

[00:31:26] OT: Yeah. So this one is subtle, but it affects all users of like JavaScript and TypeScript. And that is that if you have a really big project, then TypeScript will sort of launch itself twice instead of once, which means that you get results in the current file very quickly. So think about it as like I’ve just opened the code for my website that has, I don’t know how node modules to an average website, but let’s put it in the hundreds to thousands maybe. During that time period, when it launches, TypeScript has to go and read basically a good chunk of all of that JavaScript and all of your projects in JavaScript in order to accurately understand the entire type system. Right? So it has to know that what globals are available, what things you can import automatically, all that stuff. And once it knows all of it, then it can actually do some really clever type understanding. But the problem is that that can take a very long time. So that’s the sort of full version that gets loaded at start. And now with 4.0, we load a partial one that only looks at the file that you currently have open and like it sort of close its dependencies, if you will. And so what that means is you’ll still get autocomplete, you’ll still get navigation, you’ll still get whether this thing is deprecated or not, in your editor, more or less instantly, as opposed to waiting for the entire type system to be set up and be available, which should speed up the responsiveness of a TypeScript project when you first load it considerably.

 

[00:33:00] VJ: Yeah.

 

[00:33:01] JP: I wanted to ask if there were any themes around this release that you were targeting with the features. I know sometimes teams will have stability or a push towards resiliency or even a set of features that they’re driving towards. Was there anything like that with this release? Alternately, could you talk about how you decide which features get included in a release of TypeScript?

 

[00:33:25] NS: I guess there wasn’t so much strong theme. We’re old-fashioned and 4.0 felt like a big milestone, even though it happens every three months. And one of the things that we’ve wanted to have for a long time is that this fancy type system feature. It allows you to type some interesting functional programming patterns pretty closely. It’s also really hard to do. So our architect, Anders, has managed to do it and that sort of felt like the headline feature of 4.0 to us because we’re type fixed.

 

[00:33:54] OT: We have sort of iteration plans, which tend to be very tactic based. That’s what a lot of what Nathan was talking about there, but we also have sort of roadmaps that last about half a year. And so we try and hit like a few headline ideas with those to make sure that we continually push different parts of the type system along. Right? So like we’re always making sure that there’s some sort of JS dock feature every six months-ish and we’re always trying to make sure that the type system is always a little bit better every six months. We always make sure that we attend like the node committees for things like modules or specifically TC39, where we’re pretty active members. We’re always trying to push for like developer tools and editor productivity, making it easier for working with other vendors and trying to improve on speed. We try and make a six-monthly document that summarizes the things that we’re trying to do to address each one of these problems over that six months. We call them like the TypeScript Roadmaps and they’re like very high level strategy of things, rarely do they go down. This exact feature will be in there. But like our iteration plans tend to just be what Nathan said, like the sort of things that people have asked for with the things that we think we’ll need for the long-term roadmaps and they’re just sort of combined together. So they never seem to necessarily have a theme over than some language features, some infrastructure, and some editor productivity generally.

 

[00:35:23] VJ: Were there any major challenges that you came across while working on this new release?

 

[00:35:29] OT: It’s a good question. We had debated that maybe placeholder types, which is a feature that a few people want to list something that we could release with this. But TypeScript, as a team, tend to do experiments of like type ideas that tend to sometimes just not work out. And so we were trying to address a specific problem with that feature and then it turned out that that feature didn’t necessarily address the problems. So that’s like a feature that got dropped and is now an evaluation in a different perspective maybe for 4.1, maybe for 4.2. It’s like a lot of our challenges tend to be like, “Is this thing feasible?” And the type system in a reasonable way that doesn’t affect performance, I’ll break too many people’s code bases.

 

[00:36:16] JP: Was there anything that you were hoping might’ve made it into this release that didn’t and can you hit at some of the things that may be coming further down the pipeline with future versions of TypeScript?

 

[00:36:26] NS: One of the interesting things that, Anders, our architect showed off last week was another attempt at mapping properties to other properties with a new name. So I don’t know if you’ve worked with something like Aria or the accessibility framework. Basically Aria will take some type and it’ll take all of these properties and create new properties that are prefixed with Aria-, so the Aria-, whatever, and that’s a hard thing to represent in a type system. Normally people like generate code or something use it. So before you compile your program, you’ll say, “Okay, here’s all my types. Please wrap them in an Aria wrapper.” But we would kind of like TypeScript to be able to do this at compile times so you don’t have to generate a bunch of code. And in the past, Orta said, we do experiments that worked out or don’t work out. In the past, we had had something called Regex types. It was an experiment that’s sort of an attempt to do this to say, “Well, here’s a Regex that’s like /Aria-.star/,” then you can mount properties that way. We ran into some problems with being too complicated since its Regex and we just sort of let it sit for a year or so. And now we’re trying again. Anders showed off a prototype of string templates, which they’re not nearly as powerful as Regex. So it does the same thing where you can say, “Hey, here’s a string which is Aria-,” and then use a dollar and then we’d put in some variable name. So that’s an example of something that might work out and it might not. It still has some of the same problems as a Regex proposal, but because it’s simpler, we might be able to actually get it out the door.

 

[00:38:06] OT: I think a feature that quite a lot of people are interested in that might be coming in for fall one, might be fall two, is we’re trying to get ES modules resolving working. It’s a very complicated system, but Node has just started supporting it out of the box now. And for people that don’t quite know what I mean when I say that, if you’ve used Deno, you’ve definitely used ES module style imports. But if you’ve ever had to put .JS at the end of an import statement, then you’re thinking in terms of ESM modules, basically, and TypeScript doesn’t necessarily support them out of the box. And in order to conform to the JavaScript’s spec, TypeScript needs to add support for that. But it’s one of those things that’s like, yeah, it sounds very easy on paper, but it’s very, very complicated to do it. Right? So that’s the thing something we’ve continually evaluated, but we think that things have settled down enough that TypeScript can stop to adopt that pattern.

 

[00:39:07] VJ: Well, thank you both so much for taking the time to come on and join us. This was super informative and we’re really excited about this new version of TypeScript.

 

[00:39:17] NS: Thanks for having us.

 

[00:39:18] OT: Yeah. You’re welcome. Thanks for having us.

 

[00:39:30] JP: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe. Editorial oversight by Saron Yitbarek, Peter Frank, Ben Halpern, and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929) 500-1513. Or email us at [email protected] Please rate and subscribe to this show on Apple Podcasts.