Orta, an open source legend who has worked on CocoaPods, React Native, Flow, and many more popular libraries, joins us to talk about his work making TypeScript more accessible to people through documentation and community outreach.
Orta, an open source legend who has worked on CocoaPods, React Native, Flow, and many more popular libraries, joins us to talk about his work making TypeScript more accessible to people through documentation and community outreach.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Jamon Holmgren:
Hey everyone. Welcome to the React Native Radio podcast, where we explore React Native together. I'm your host, Jamon Holmgren, and I'm joined today by two of my prodigious... Is that how you say it?
Robin Heinze:
Prodigious?
Jamon Holmgren:
Prodigious?
Robin Heinze:
As in a prodigy?
Jamon Holmgren:
Prodigy. Yes. I'm sorry, I don't use this in normal conversation. I just looked it up. But my co-hosts Harris and Robin, Adhithi isn't here today. Harris, how are you doing today?
Harris Robin Kalash:
I'm good. How are you?
Jamon Holmgren:
Doing well. Are you still in Montreal?
Harris Robin Kalash:
Yep. Yeah, I am.
Jamon Holmgren:
Okay. We'll follow you around your travels once you get moving again, but so far you've been staying put.
Harris Robin Kalash:
Once they lift the curfew. We're under curfew. If you walk out past 8:00 PM, you can get a $6,000 fine here.
Jamon Holmgren:
$6,000 fine? Okay. All right.
Harris Robin Kalash:
Yeah.
Robin Heinze:
Wow!
Jamon Holmgren:
Well, they don't mess around up there. Robin, how are you doing this morning?
Robin Heinze:
I'm doing great, Jamon.
Jamon Holmgren:
Good, good, good. And I am very excited to bring on board Orta Therox, which I believe I butchered correctly.
Orta Therox:
Yeah, that's perfect. You got that just right. Thank you, Jamon. Welcome to be here everyone.
Jamon Holmgren:
You're very kind. I'll do a little more intro of Orta here. He is a legend, but I'll do that in a bit here. This episode is sponsored by Infinite Red. We are a premier React Native design development agency located fully remote in the USA and Canada. We have years of React Native experience, deep roots in the React Native community. We are the hosts of Chain React. We publish the React Native newsletter, and we, of course, do the show. Infinite Red is the best choice for your next React Native app. Hit us up at hello@infinite.red. If you want to, you can just email me directly, jamon@infinite.red. Learn more on our website infinite.red/reactnative.
Jamon Holmgren:
Awesome. So yes, I want to introduce Orta. I've known him for, or at least of him and then certainly I met you it was probably 2014, something like that.
Orta Therox:
Yeah.
Jamon Holmgren:
Back in the RubyMotion days. One of the most prolific... I was going to say prodigious, and I don't even know if I said that right... Prolific open source contributors on GitHub. In fact, you let us know, which is amazing, that GitHub even follows you on Twitter. This is how important you are to their ecosystem. I think if Orta stopped working then pretty much all of open source would stop.
Orta Therox:
Yeah that would be the end of the iOS community, React Native.
Jamon Holmgren:
It's done. Yes. Everything. It's pretty cool to have followed your career as you go through. Of course, part of that was you worked at Artsy and a big part of Artsy's culture is working in open source. You were able to do it almost full time with the work that you were doing over there. So very cool. Awesome to have you on the program.
Orta Therox:
Thanks. Honored. A lot of this stuff is just working on the community and community work is some of the most satisfying work for me. For a lot of people, they have hobbies. My hobby is programming and being able to do that with my friends, so fun.
Jamon Holmgren:
Yeah. Totally. And you've been into React Native of course, which is something that we're obviously going to be talking about on this program. I met you again, 2019 at React Native EU in Poland while you were there. Did you give a talk there? I forget.
Orta Therox:
Yeah.
Jamon Holmgren:
Yeah, you did. You did.
Orta Therox:
I gave a talk on Xcode and all of the different build systems involved in native programming on iOS.
Robin Heinze:
I have definitely watched that talk on YouTube.
Jamon Holmgren:
Yes. I actually make people watch your talk because it was so good. So I shouldn't have even asked the question because that's one of my favorite talks. So I do recommend people check that out. Orta's talk in React Native EU 2019, where he talked about Xcode. You're going to learn a lot more about Xcode in 30 minutes than you ever thought possible so go check that out. But we didn't necessarily bring on just for your React Native experience, you're also on the TypeScript core team now, working at Microsoft on TypeScript. How did that come about?
Orta Therox:
It's the React Native issue actually, at root. Me and the team Artsy, we were a bunch of Native developers at the time wanting to use React Native. We wanted to use React Native so that we could get access to Relay. And we were willing to put in whatever work it was to get access to basically that library. And we were sort of looking through all these different flavors of JavaScript and actually opted for Flow. And I started trying to make a few commits to Flow and really, really struggled with OCaml and trying to own that dependency, is the term that we use, like Artsy which is, if you're going to depend on something, you should be able to contribute and improve it yourself.
Jamon Holmgren:
I like that.
Orta Therox:
And we just realized that that was just not feasible with Flow for us. So we took basically the work to get a React Native and TypeScript working together. This predates TypeScript and Babble support.
Orta Therox:
So we had to build this sort of multifunctional chain, a tool chain that would go from TypeScript that would generate something that Babel could then kind of use. We wrote the docs for TypeScript support and React Native, and eventually it just sort of... TypeScript just became this language that really felt like what I believed programming language should be. Sometimes it's too strict, sometimes it's not strict enough and you get to choose when you want that. A lot of programming languages, they just offer this sort of box that gives you a certain experience. Typescript has over a hundred compiler flags that give you this really mixed projects feel, because of the way that they can be added incrementally. Vary of a programming language and environment so we give you that use as much strictness as you want feel that really resonated with me for TypeScript.
Orta Therox:
And how I ended up on the TypeScript team is, it felt like a good time to leave Artsy. I'd been there for about eight years and I was looking around at all these different large ecosystems. And it was very obvious, to a somewhat insider, on lots of large tools that everyone was moving to TypeScript but TypeScript sort of... The set of people that work on TypeScript are compiler engineers, not necessarily the sort of people that are out talking to people, seeing how... Well they are obviously talkative and interesting fun people, but what they don't care about as much is the documentation, onboarding process, deep migration strategies, working with all these other communities simultaneously.
Orta Therox:
And I pitched to the TypeScript team that this is what I do. I've done this in multiple massive developer ecosystems. And I would be very interested in helping TypeScript scale because you look at some of the results of something like the state of JS survey that came out yesterday. This is very leading edge people, of sort, that respond to a survey like this one specifically, but 70% of people say that they use TypeScript and JavaScript is one of the biggest-
Jamon Holmgren:
70%?
Orta Therox:
70%.
Jamon Holmgren:
That's incredible.
Orta Therox:
And their customer satisfaction on that was 90%. 90% of people would reuse TypeScript of the 70% of all code bases using it.
Jamon Holmgren:
I think I know the few people who don't like it, but everybody else does.
Robin Heinze:
They are very vocal on Twitter.
Orta Therox:
And honestly for us that's totally okay. TypeScript was never about taking over the entire JavaScript world. It was about providing great tools for the JavaScript world. And they might not like TypeScript, but I'm willing to bet they're probably using TypeScripts tooling under the hood. That makes them a user.
Jamon Holmgren:
I find it kind of funny when people say "I don't like TypeScript and VS Code gives me everything I need." Well, what do you think VS Code is using through the hood?
Orta Therox:
The answer is they're a TypeScript user. They're just on the loosest possible interpretation of TypeScript.
Jamon Holmgren:
Yeah, totally. And one thing that is just fantastic about TypeScript is because of that sort of practicality and the ability to just progressively enhance your developer experience as you move forward into it. And that's something where I've gotten into fun sort of discussions about how strict you should be with TypeScript. So one question I have for you is when you look out, now that you're on the inside, when you look out across the landscape and you see people having all these arguments about how you should use TypeScript, how does that make you feel? How does that make you react?
Orta Therox:
I'm now a very senior developer so my answer to every question is the same, which is, it depends.
Jamon Holmgren:
It depends. Exactly. Could've seen that coming.
Orta Therox:
I know it's just a lot of people with strong opinions. I know, but there's no other way. There's no other true answer. I would write with... Oh, here's a good example. TypeScript has always had a concept called strict mode, which I would say represents the types of code bases TypeScript would like you to build. Prior to the last two releases, we had never thought of stricter than strict mode things. We don't externally call it this, but generally we tend to call it pedantic flags, which is I would like to put things in my way, in a way that is not necessarily ergonomic so that we wouldn't recommend it to everyone.
Orta Therox:
So TypeScript is actually shipping compiler flags for folks that want to go even further than the TypeScript strict would be. So the spectrum here is massive. It is like JavaScript on one side and it is now sort of pedantic mode strict which is now even further than what you would think strict is. And all of that depends on the level of risk, how slow you want the project to potentially go. And I don't mean compiler speed. I mean, like...
Robin Heinze:
How long it takes a developer to ship a feature.
Orta Therox:
Yeah. If you have to be very certain about undefined, then that already slows you down a little bit and that's what we generally say for strict mode, but if you have to be very certain when you've pulled an object out of an array that that object exists, that slows you down even further, and you really do have to add additional syntax to that in ways that may be unnatural in order to make sure that you are guaranteed, guaranteed to be runtime free.
Orta Therox:
So some of that is ergonomics, so again, no easy answer. The easy answer is always, it depends on what you want and unfortunately that's not very satisfying and it's definitely not like a calling cry, right? People would like to be fighty on the internet and telling someone it depends on your project is not really a good way to get traction.
Robin Heinze:
But I think that's one of the things that makes TypeScript shine so much is because it's so versatile and you can really use it to the extent that you want. Because at its core, it's JavaScript. And if you want to basically use it as if it's JavaScript, you can. And that's kind of what I tell people when they're like, "Oh, should I switch? I'm scared to switch, it seems like a big..." I'm just like, okay, well just write JavaScript then. Just switch your files to dot-ts and just write JavaScript. And then just try adding a type here and a type there, and eventually you'll see the magic and the value, but you don't have to jump into the deep end right away which I think is really powerful.
Orta Therox:
Yeah. A lot of the docs I've been writing recently are about the migration strategy from JavaScript to TypeScript and a lot of people don't really know that the first step is actually just to write a special comment at the top of a JavaScript file, like dash-dash ts-check. And then you get the TypeScript type checker running on your JavaScript file. That's it. You literally can't add those type annotations because the syntax won't be allowed, but you'll get a lot of the power of TypeScript sort of strictness, but it will force you to only write JavaScript.
Orta Therox:
And that's how you start to get people to...
Robin Heinze:
Actually, I didn't know that.
Harris Robin Kalash:
I didn't know that either. Today I learnt.
Orta Therox:
Yeah, man, that's the thing, right? We're documenting such a big system. A hundred compiler flags runs in anywhere that JavaScript runs, so consider the scale or scope of that. Most of the time we only think about Node or React Native or something like that, but TypeScript runs on anywhere JavaScript runs and JavaScript runs, what is it? I heard that people use JavaScript to maintain space suits.
Jamon Holmgren:
What?
Orta Therox:
Tesla's car is JavaScript, that uses TypeScript. Those environments have to be mapped in TypeScript in some way, because there's no way that you're going to run JavaScript-JavaScript on those cases. You're going to be running it guaranteed that you've got something.
Robin Heinze:
Yeah. I really hope the space program uses strongly typed.
Harris Robin Kalash:
Yeah. I remember seeing a tweet about that. I was shocked, but does anyone know to what extent or how true that is that they're using JavaScript on SpaceX?
Orta Therox:
Well, I definitely know in Tesla but it was NASA that was using Node on...
Harris Robin Kalash:
NASA was? Wow.
Orta Therox:
Yeah. I think it was in the arm of the space suit for something. It could just be for a small control thing. Non-Mission critical. They wanted it to test the system, but it's there. It's literally out there.
Robin Heinze:
That's pretty... There's like literally JavaScript in space. It's pretty cool.
Harris Robin Kalash:
Non-critical systems, right?
Robin Heinze:
I hope so.
Jamon Holmgren:
So speaking of the documentation... The documentation efforts that you've been pushing toward, in August you came out with a brand new TypeScript website, as well as branding. And you wrote a blog about it back then. That was a tremendous amount of work, I'm sure. And so do you want to talk a little bit about that?
Orta Therox:
Yeah, sure. I'll first talk about the logo because that's the thing I really wanted to change most first. TypeScript, everybody thought this logo was TypeScript's logo but the blue square that looked like the JavaScript unofficial logo was not TypeScript's logo. And so I basically made it TypeScript's logo, but change it just enough that Microsoft could retain copyright over it.
Orta Therox:
But the TypeScript website was a closed source website that only a few people in the TypeScript team could edit and I had quite a frustrating time learning TypeScript, trying to improve the tooling and documentation for TypeScript as an external person which made it my first target open source it, take over the playground. If you'd been around TypeScript for a while, the old playground was nothing like the new playground. It's like, you could see the kernel of the idea in the old playground. But all these people were building third party documentation systems, third party playgrounds, and just being able to take the time to build an incredible documentation system that works offline, it uses Gatsby, it generates EPUBs and PDFs of all the docs that you can take them with you on the go.
Orta Therox:
Starting to rewrite the handbook now. Starting. We're wrapping up the end of the new handbook now. It's got all the new tools that we have for building documentation because it's TypeScript. So a lot of the type work is actually quite invisible and so we now have the same hover systems inside the documentation as you would in an IDE, and a lot of these things, no one has done before. So I didn't really have much precedent to try and find how do I do this stuff? And so I just had to build it all in TypeScript.
Orta Therox:
And so the TypeScript mono repo website mono repo] like 10 libraries that do all sorts of random things that nobody else has had to try do yet. And the entire website is now runs through the TypeScript compiler. So every code sample is guaranteed to be accurate. And up-to-date in ways that like previously, prior to like me working on it, they were pretty outdated. There was no reference to a lot of stuff. And now it's just, now it's stunning. I'm really proud of it.
Robin Heinze:
I just opened up the handbook and it's super slick.
Harris Robin Kalash:
Yeah. I'm doing the same. Yeah.
Orta Therox:
Yeah. That's my design. That's my implementation. I also designed the React Native web homepage, if you've seen that.
Jamon Holmgren:
Yes, I forgot about that. That was really cool. So let's talk really quickly about your React Native experience. Just segue into that for a bit, and then we'll come back to TypeScript.
Orta Therox:
Sure.
Jamon Holmgren:
You said at Artsy you switched over from-
Orta Therox:
Native.
Jamon Holmgren:
Native code, even though I think...You told me in Poland. You weren't doing Android, so it wasn't necessarily because you wanted to go to like-platform, which is unusual. Like most people go to it because of the cross platform, but what was your impetus to move into React Native?
Orta Therox:
It was about the time that Swift was coming out in Native world and we sort of ran a sort of side experiment on a separate app that tested out Swift, Swift build tooling, and what that would look like and sort of came to the understanding that Swift was an incremental improvement of building an objective C app, which is what we were doing at the time. And at the same time we were looking at Relay. I don't know. All of this, literally, was because of Relay. We were building these JavaScript JSON heavy apps that just make this really... It was a beautiful experience, but at the end of the day, we were just making a pretty JSON parser, and that's my unpolite way of describing my app. My general belief is that like 90% of all non-game apps are probably pretty JSON parsers, right.
Orta Therox:
They take an API and they present it to you in some form. We found that Relay, I know this is the Relay podcast. It took the graph QL, all the best bits of graft QL and it took all the best bits of building a really tight react tree, and we were willing to build all the tooling for React Native and go try and figure out this new language, just so that we could test it. We tested it on one screen and said, "We're just not going back from that." So from there it was just like we have Native improving in different ways and so occasionally I would contribute to call. And that was it.
Jamon Holmgren:
Yeah. That makes sense. And one of the pieces of the React Native experience is obviously you're writing JavaScript and JSX but, and we started off doing that in 2015. We were writing JavaScript JSX. Later we wanted to... We saw TypeScript and we really liked what we saw and it was something where you get to bring back in the static analysis of your code that was helpful without necessarily having to go to a brand new language, completely different language. It was still JavaScript at its core. And so that's why we ended up switching over and I think early 2017. So we've been doing it for four years now.
Robin Heinze:
I barely remember doing plain JavaScript.
Jamon Holmgren:
Yeah, totally.
Robin Heinze:
I didn't do it for very long cause I switched from Ruby and then we adopted TypeScript pretty soon after that. So I know TypeScript better than I know JavaScript almost.
Jamon Holmgren:
That's so funny to hear. Cause I started using JavaScript in 2005.
Robin Heinze:
Yeah, same.
Jamon Holmgren:
And jQuery and went through all those iterations and stuff and for me, TypeScript, and how I like to do TypeScript is I like to show, and there are many different philosophies but mine is, I already know how to write JavaScript. I can already build apps on JavaScript. I can do a good job building apps on JavaScript, but TypeScript brings the experience up. And so every flag that I enable, every little thing that I do, it needs to be in service to that, not get in the way, but also helped me. And I've found that, for the most part, it's fantastic. You can just start by just enabling it on JavaScript files and see what it does. And then when you need to start annotating to give hints to the compiler and the type checker then you move that direction and pretty soon you're sucked into it. Like, okay, I'm typing all the things. It's great.
Robin Heinze:
Well, yeah. Right. I'll try and do just a plain JavaScript app. Like I did one the other day. Just, I was doing a minimal repro for something and I struggled. Every time I would compile it, something was wrong. Cause I'm so used to TypeScript, just holding my hand.
Jamon Holmgren:
Exactly.
Orta Therox:
Yeah. Even on the compiler team, we still use JavaScript files that read so often, but we turn on that thing that makes you get the compiler settings and it's just like, you don't have the build step then. You can just run it straight away, hopefully.
Jamon Holmgren:
Is the compiler, itself, written in TypeScript?
Orta Therox:
Yeah, it's a Typescript, self hosted project. So, perfect. It's good to see what a compiler looks like. It's good to see what a TypeScript code base looks like at scale. Right? Because TypeScript, for people that have never seen the code base, there is like a file that I think is 40,000 lines long in TypeScript, it might be 60.
Jamon Holmgren:
Wow. Is that it?
Orta Therox:
It's one of those two.
Robin Heinze:
Wow.
Jamon Holmgren:
We just... the episode before this one we were talking about organizing your source files into folders and stuff and we talked about putting everything in one file as an option.
Orta Therox:
Yeah. Is that a question? I could guess what the question is.
Harris Robin Kalash:
Actually what I'm curious about, I've worked on a large TypeScript project monepo and at some point my type checker was just getting really slow and I remember seeing a Twitter thread about like preferring interfaces versus types and other stuff like typing the return of a function. I wonder like since you're running such a large TypeScript project, how's that working for you? Is it slower?
Orta Therox:
So TypeScript performance in TypeScript.
Harris Robin Kalash:
Yeah.
Orta Therox:
It's actually not too unreasonable because TypeScript to compile it is actually built using TypeScript projects. So you might not have had to use this, but this is one way to really get your perf is to just sort of box off parts of your code base into different sub projects. So like working on the compiler only needs to know certain files so the scope of the amount of knowledge it needs to have is drastically reduced.
Harris Robin Kalash:
One thing that's interesting about TypeScript is that it came into this ecosystem that was already very well developed and so you had to have a way to type libraries that weren't typed and the definitely typed project was a big improvement and there are features within TypeScript that allow you to declare module. And you can say for that from this module, we have these classes and these functions and it gives tools that allow you to back into types on your dependencies, which has been extremely useful for projects to adopt. Because if you had to wait for every third-party library to do release types, it would just never work. Like you would never be able to use TypeScript.
Orta Therox:
A very consistent path to do that and some languages and now sort of copying TypeScripts approach. Ruby free for example, has similar types of types and allows for definition files in a similar way. Python has a similar thing. Guido who create... Guido Van Rossum.
Jamon Holmgren:
Yup.
Orta Therox:
He's he now hangs out in the TypeScript meetings where we chat about some of these side of things. Because he's now at Microsoft.
Jamon Holmgren:
Interesting.
Orta Therox:
And a lot of the problem domain is the same. Like we're all trying to figure out how to map on typed languages to type systems, I guess.
Robin Heinze:
That's a really big testament to the community, I think. Like, how crucial the community is to TypeScript's success.
Orta Therox:
Completely.
Robin Heinze:
Is how much we're relying on these completely community driven type definitions for pretty much every library I've ever used. I'll be like, "Oh man, this isn't typed." And then I'll look and there's a DefinitelyTyped. Somebody added it and I'm like, "Thank you for this."
Jamon Holmgren:
Probably Orta did.
Orta Therox:
You'd be surprised I haven't added that many, but I initially built most of the tooling, the powers, the way that you can interact with DefinitelyTyped nowadays.
Jamon Holmgren:
Interesting.
Orta Therox:
So DefinitelyTyped is one of the most active repos on GitHub. Full-Stop. We'd probably-
Robin Heinze:
That's huge.
Orta Therox:
It's huge. Yeah. It was like 10, 20,000 modules in there and from our perspective, it is a full-time job maintaining DefinitelyTyped. So there is always a compiler engineer on rotation on DefinitelyTyped either merging or helping out on complex PRs because change to React, that could have drastic performance simplifications all over the entire ecosystem just by merging something instantly.
Jamon Holmgren:
This is the sort of thing that has led to TypeScript sort of quote unquote, winning over flow. That sort of focused on the ecosystem. Also, the deep integration with Visual Studio Code has been amazing and I think that that is cited often. I see it often. This is why I use TypeScript and this is why I use VS Code. It's kind of a self reinforcing cycle because of that deep integration. Yeah.
Robin Heinze:
Sometimes it's easy to forget where the line is and all these features that I've gotten used to, I don't even know what's what it's like pure TypeScript and what VS Code is giving me anymore because it's all so seamless.
Orta Therox:
What’s interesting that I am still the maintainer of VS Code Flow.
Jamon Holmgren:
Okay.
Orta Therox:
I took over that when we were using Flow back at Artsy because-
Jamon Holmgren:
And no one wants to take it over from you?
Orta Therox:
Yeah. Basically. I've been trying to get a release out but they revoked my access. We're friends, so it's not like any... I think it might be like a Facebook security thing or something. But I really struggled to set up a great development environment in part because I couldn't contribute then to the Flow code base and to get it set up with VS Code, but Facebook originally bet really heavily on Electron. And that didn't work out very well in part because VS Code versus Electron is a really interesting technical debate. VS Code won on technical merit, which is a rarity in engineering world.
Jamon Holmgren:
It's true. Yeah. Because I remember using Atom and I remember before that Sublime, which is not a JavaScript. It think it's... Was it Python or something like that? But yeah, I used Atom for a little while, but there were some real problems with performance for sure and not that VS Code doesn't sometimes have performance issues, but it's an engineering marvel, in my opinion, how they've been able to eke every bit of performance out of what they're doing there.
Orta Therox:
And how they just don't let extensions slow your experience down much. You can have as many extensions as you want, effectively, and your auto-complete will feel slow and sludgy but your editor probably won't, and that's the power of JavaScript and it's also... And the scale of which JavaScript can run, but also it is clever, smart engineering by the VS Code team. They know what they're doing.
Jamon Holmgren:
My co-founder Todd Werth. He's been coding for 25 years, something like that. And to him the idea of Microsoft engineering was always like proprietary, very almost developer hostile in some ways. Kind of had a really bad connotation in his mouth and so it was this is not a... "I don't trust Microsoft", is how he approached it. At the same time as sort of a new generation of programmers has come on as well as a complete, I would say, shift in philosophy from Microsoft. It's amazing how much amazing Microsoft technology we are using in our day to day. It is like, I would not have guessed that I'd be basically working on a Microsoft stack all up and down.
Orta Therox:
Yeah. Bandicam, GitHub.
Jamon Holmgren:
Right. Even React Native itself. Microsoft is one of the biggest contributors to React Native. I'm in the open source core discussions and Microsoft engineers are right there, helping drive it forward. It's really cool to see how that has turned around.
Orta Therox:
Yeah. Another person from Artsy left to go work on the React Native team at Microsoft and he maintains React Native for Mac. That's like all of it.
Jamon Holmgren:
Yep. Yeah, totally. Exactly. It is funny. Although, obviously...
Robin Heinze:
React Native for Mac is a Microsoft product.
Jamon Holmgren:
Microsoft has always been the biggest third-party Mac app developer in the world. People don't realize that but...
Orta Therox:
Office, yeah.
Harris Robin Kalash:
They've also done a really good job at not killing projects they acquire. Like, I almost forget that they now own GitHub
Jamon Holmgren:
That's true. They've actually done a much better job with it than I would have expected.
Jamon Holmgren:
So when you're working on TypeScript, how do you know how to prioritize things? There are a number of ways that you can gather feedback. You can obviously just listen to what's happening on Twitter. People complaining about stuff. You're actually extremely fast. I try not to abuse this, but you're ridiculously fast at replying on Twitter. And so once in a while I'll tag you and you'll just be like, "Oh yeah, yeah. You know, there's this. Or maybe here's some, or maybe we should document that better or something", but I'm sure there's a never ending list of things that you could add to change about TypeScript. How do you prioritize that in your day to day?
Orta Therox:
So, I'll ask this from two angles. One is like from TypeScript as a project and I'll answer as myself. So TypeScript as a project has this sort of, it has a very small domain actually. People ask us things all the time and we just get to say, "No, that's for TC39 to decide". We care about the type system of TypeScript. We don't necessarily care about adding some new feature to JavaScript or adding that thing you want, which does make sense. I would like it to, but it's got to go through TC39. And that actually narrows down the scope quite a lot. So then from TypeScript's side, a lot of it tends to... A lot of the headline features tend to be about taking existing design patterns, that exist in JavaScript, and finding a way to type that.
Orta Therox:
So some of the key features that have come out in the last six months have all been about back tick, strings and the ways in which you can generate strings at type time. And being able to create stringly typed APIs in a sort of, elegant way. Nope, Nope. People probably came out a long time ago and asked for those features but to build something like that, you have to build like four or five versions in advance, all this infrastructure to eventually get to it. So the TypeScript team sort of aligns every quarter, half year to try and get a sense of like what a longish term roadmap looks like to try and get some of those like hard, hard things in. And then some of the other team members are constantly on TC39 trying to get some features that TypeScript users really want.
Orta Therox:
So the question about dot operator, the TypeScript team were the ones pushing that in the end. And that gave a really great type system tool that actually is really useful for JavaScript developers, regardless. And so from there, it is just like someone triaging full-time issues. So we always know what the bugs are and what feature requests look like. But then from there, it really is like everybody thinks of their own sort of key features. There's one person that does the JavaScript documentation, JS docs, syntax. There's some people that care about Emmet. Sorry, that's our version. Our word is of transpile. Yeah. Transpile. And they've just focused on how do we make sure that the JavaScript that we ship is actually as good as if you'd hand wrote it, which it can't be perfect, but it... That used to be TypeScript's main goal, was to show you the JavaScript and show you that Microsoft is not screwing with your JavaScript.
Jamon Holmgren:
Sure.
Orta Therox:
And then for me personally, a lot of the time it is pressure that I felt when I was an external contributor. And that still powers quite a lot of stuff that I do on a day-to-day basis now. And I still talk to people that are building tools and trying to understand like where their pressure is building and to try and sort of vent that in some way. Like the style components changes recently is a good example of that. I tried multiple times to fix style components in React Native and every time, I couldn't find an elegant answer and then out of the blue an internet rando, thank you for this, fixed it. Figured it out. And so I helped like guide that through the process, make sure that everybody felt like this wasn't going to break the entire ecosystem. And now style components works well in React Native and it works well in Node. That's the other environment.
Jamon Holmgren:
Yes.
Orta Therox:
And so that's like venting pressure is generally why and that's how the TypeScript team can scale.
Jamon Holmgren:
Yeah. I'd imagine a lot of the low hanging fruit is already been addressed.
Orta Therox:
Yeah. It's been eight years. That's a lot of...
Jamon Holmgren:
Yeah, right. And it's been... You're really now working on long tail stuff, things that are... You're really pushing the bounds of what's possible with the type system. And there are a few things that come out, like I think 4.1 came out recently and it brought in the idea of being able to type using string literals and being able to interplay-
Orta Therox:
Interplay string literals. Yeah other string literals.
Jamon Holmgren:
Right. Exactly. And there, there's a warning in there, like don't abuse this. There's ways you can really slow yourself down if you try to do this too much and often, and sometimes it's better to just be a little more vague about your types and not yeah. Don't be too specific just for performance reasons, but yeah.
Orta Therox:
Yeah. That's the thing though. So somebody that's not a senior engineer starts reading some of these release notes and they're just like attacked template literals, interpreted string. And it just sounds like all pure jargon. And to some extent it is pure, it's industry jargon, right. But a lot of the major features that TypeScript ship to some extent focused on DT and focused on allowing people to build the stuff so that these libraries are completely typed in a way that you never see, and they never even actually affect the code you write on a day-to-day basis. And so it can be hard to write release notes and sort of try and describe these features in a way that says, "This actually probably isn't for you at all. This feature is in the language, but you probably might not ever need to use take type template literals or whatever." And that's totally okay.
Robin Heinze:
I'm glad you brought that up actually because I think for people who are beginners or less experienced, it can actually be pretty intimidating to read release notes and feel like you don't understand a single thing and it can be tough. And you feel like it'll fuel your imposter syndrome a little bit but I'm really glad you said that because it gives those people permission to be like, "Okay, it's okay if the release notes don't seem like they're for me, especially with a library like TypeScript, which is so mature." Of course, of course the release notes, aren't going to be like the day-to-day features because those were added five years ago.
Orta Therox:
Yeah. ConstA equals a string is now a string type.
Jamon Holmgren:
Yeah. It's been in there for awhile.
Orta Therox:
Yeah, but we have been trying in the last two release notes to try and explain from scratch for some of the things, rather than just be like this thing built on this thing that we've built like five years ago. Read the release notes for that thing so you can understand the next bill. But at the end of the day, yes, the release notes are somewhat targeted at the sort of people that could actually understand it because they have to be. It could be feasible to do a beginner release notes, an advanced, and maybe that's feasible inside the website, but not necessarily in the in the release notes system that we have.
Robin Heinze:
You're more likely to put something like cool and flashy and exciting that most users are going to actually use. That's more likely to show up in like a blog post or some like other, more marketing style release.
Orta Therox:
Yes.
Robin Heinze:
So yeah. Don't feel bad if you don't understand release notes, kids.
Orta Therox:
We have to be the reference. That's the important part. We have to be explicit. We have to be exact and we have to let people know exactly what and how it does. Other people can have opinions on it. But we can't.
Jamon Holmgren:
I noticed that it started with, "If you're unfamiliar with TypeScript, it's a language that builds on type on JavaScript." This is the release notes for 4.1, but it's actually like, this might be your entry point to TypeScript. This might be the first time you look at it is you see, "Oh, 4.1. Maybe I should finally take a look at this and you go and look at it and it starts with a paragraph about what it is."
Orta Therox:
Yeah. It's a tricky balance. It's like the same with all documentation, right? We could have hundreds of documents describing TypeScript in many different ways that change every release because TypeScript suddenly changes, but we have to make decisions on what to document and what to make references and what to consider tutorials because the needs of people change and the target audience shifts. TypeScript used to be a very early adopter audience. So you could be quite technical in it, but nowadays those early adopters have brought in the rest of the late majority early, like late stage. And we have to make sure that we attack those people. Attack those. We have to target those people. Sorry. That's the new hook. That audience, not fans.
Jamon Holmgren:
You're very transparent about your roadmap. It shows what's happening with 4.2 and when it's coming out. 4.3, when it's coming out and also what's done, and there are links to each of the different things. There's a future part. I noticed the first thing in the future was investigate nominal typing support. I clicked through to that, and it was an issue from July of 2014. So this has been around a while. This is probably a tough one. If I had to guess.
Orta Therox:
Oh, it's a really tough one. It's like one of those... It's... Oh, Oh, okay. Just in case people don't know the difference between nominal types and structural types, which would make total sense unless you're a type person, the way TypeScript does types is that it says if all the fields in an object are the same, it is the same object. That's it. But if you write something like C++, objective C, Swift, Java, it doesn't matter if the class you make has the same fields, they are different inherently. So a rectangle having a position and a size is different from a playground, having a position and a size.
Orta Therox:
Well, the other one is the difference between the two is nominal. So we call that nominal typing, and TypeScript basically doesn't have that at all because JavaScript doesn't have nominal objects, except when it does. That's what makes it tricky. Classes now that can have private fields and those private fields create a nominal instance of something because it's not the exact same as any of copy of the class in a way that JavaScript didn’t used to have. So the semantics of JavaScript are evolving and changing. So the semantics of TypeScript had to evolve and change with it.
Jamon Holmgren:
Yeah, that's... I'm glad there are very smart people working on that instead of us trying to bumble through. So I'm of the maintainers of MobX-State-Tree and one of the interesting things, and I think one of the superpowers of MobX-State-Tree, is the ability to use TypeScript to generate, or just infer, I guess, static types from our runtime type checker, which we actually check at runtime the types that are being fed into the model and make sure that they're the right type. And obviously if you have to write it twice, if you have to write it for the runtime type system and you have to write it for the static types, then it becomes annoying. Luckily, some very smart people before I became involved, came up with a way to infer that, but it's a few years old and I'm looking at it and it's not ideal. The types that it comes up with feel kinda messy and hard to read and whatnot because of how they were implemented, I guess.
Jamon Holmgren:
And I know that TypeScript has evolved the challenge in front of me right now is learning enough of the new TypeScript to know how could we improve this type checking or this type inference on the runtime types. And it probably doesn't help that it's also sort of a builder system where you're not defining everything all at once. You can actually build upon types or models and you can... I'm going to take this model and then I'm going to extend it and that's going to be a new model and I'm going to... And every time you might define your properties first, but then you extend it and you define your actions and then you extend it, you define your views. And so every time you're doing that, you're picking up previous stuff and you have to be able to like, "Okay, in this action, do I have access to this property?" So it's a very, very difficult problem. And it's been on my list for a long time to just be like, okay, I got a deep dive into TypeScript and figure this out.
Orta Therox:
Yeah. Like that's the thing, TypeScript makes that sort of thing feasible. Even if it might not necessarily be an optimal thing to do, right? TypeScript allows you to do anything, more or less, but it still has an opinion on what is easy and what is hard and, in part, because static type systems... Because whether it's structural type system, those things are really computationally expensive. Remember, I said a nominal type system, right? A playground is different from something of a rectangle.
Jamon Holmgren:
Sure.
Orta Therox:
In order to know the difference between a... That they are different, in a nominal type system, you can just say, "Oh, is the class name different". In a structural type system, we have to check every single sub property in case...every single thing. So mix that now with your inferred objects, where we have to go back through this massive tree, AST. So we have to go back through all these different bits of code to eventually get back to where it was defined. And then that then has to come back out before we can start doing comparisons in every single part. And as you mentioned, it's multipathed, right. So it's like each different part has different parts of the inference to run through all that is just extremely computationally expensive. And not even like fun, computationally expensive that could go into rust.go or something. It's just like straightforwards, if this, then that. Next, next, next, next. Over every field.
Orta Therox:
And so TypeScript is always trying to be like, "You could use an interface instead of a type here, and then we could do less work for you."
Jamon Holmgren:
Right.
Orta Therox:
But we're trying to map JavaScript and that's legitimate JavaScript. So TypeScript needs to find a way to describe it.
Jamon Holmgren:
I suspect a lot of JavaScript when people move to TypeScript people write code differently.
Orta Therox:
JavaScriptyTypeScript. Yeah.
Jamon Holmgren:
Yes, exactly. And so, if you did JavaScripty TypeScript, you're going to run into the edges much sooner than if you do it in a way that really feels idiomatic to TypeScript itself. So it's almost like TypeScript really is, in some ways, its own language or its own culture.
Orta Therox:
Yeah. Culture is a good one... I think it pushes particular design patterns that require that... It makes those design patterns easier so people are more likely to move towards them. Like the TypeScript website, we never try and force you in one design pattern or another. I never write classes. Everything for me is just functions and objects, but TypeScript has ways of making it easier to do those things that will just make you do those things.
Robin Heinze:
I think we would do ourselves a disservice if we didn't touch on the thing that most people probably tune into this podcast to get an answer about. And this is referring to a specific member of the community who tweeted a few days ago or week ago, a controversial opinion about generics and whether or not generics should have single letter variable names. From Orta himself, what's the right answer?
Orta Therox:
No, you shouldn't. You should use long names. I've slowly been moving all of the TypeScript documentation to use long names everywhere. I agree. I sometimes use I as an index. I think there's ways in which we can get away with it, but especially in our stage of giving you documentation, we should not be using like very short generics in the way we describe things specifically because so many people are going to see that and you need... It's like trying to not use this or that in a sentence, in order to force people to not keep track of that thing that you were talking about all the way through multiple sentences and paragraphs. We have to do the same thing for generics. Generics on their own are intimidating, and mix that with then making it harder to actually interpret because it's now Ts, Us, Vs. It's just not worth it.
Robin Heinze:
It took me a long time to really grok generics, partly because I would see them in documentation and it just wouldn't register to me what I was even seeing, because it's not clear that it's a reference to a variable essentially.
Jamon Holmgren:
Yeah. Like I thought for a while when I was learning static typing, and it wasn't even TypeScript, it was previously, but I thought that T was some sort of magical reserves
Robin Heinze:
I did too, actually.
Harris Robin Kalash:
Me too.
Jamon Holmgren:
And it seems to be a common thing. Oh, tea is a magical thing. No, it's literally like writing foo.
Robin Heinze:
It's T. T for type. T for TypeScript. It seems like it's a magical keyword.
Jamon Holmgren:
It's some type that someone else gives me, it's a type that someone else gives me.
Robin Heinze:
Yeah, someone's decided this.
Jamon Holmgren:
Someone else's type and I'm going to then pretend like I know what it is and it would be nice if that's what it said or it was just more obvious. So, I would agree.
Robin Heinze:
By simply switching to a context sensitive word you can really communicate that, "Hey, this is literally just a variable. It's a placeholder for whatever you're giving it. And you're going to pass it along to where it needs to go." But...
Jamon Holmgren:
I'm usually not like super dogmatic about specific rules. If I use I for an index... For i equals whatever. Most people know what that is. It's not going to trip people up. I'm not going to-
Robin Heinze:
I also use I for index.
Jamon Holmgren:
Yeah, yeah. And then even if I'm just using it. If it's in a small function, that's like four lines long and I need an element and I call it EL for element. It's not going to kill anybody. It's okay.
Robin Heinze:
If I map over a collection of like users in my little map function, I'll do you.
Jamon Holmgren:
If it's small. Now, if it gets bigger, then clearly it's just like Orta said, if you have to track it over the course of paragraphs, then you better have a better name than just you, U.
Robin Heinze:
T.
Jamon Holmgren:
Yeah, T.
Orta Therox:
That was one of my first changes once I got right access to the documentation. Types can touch this thing called the utility types page and the advanced types page.
Jamon Holmgren:
Yeah, I've looked at it.
Orta Therox:
And just made those not T, U, Z, E. I think it's just like an easy way of trying to decouple the magic of generics to people. It's hard enough to get your head of the idea that these things are variables and that... So for variables. Yeah, I agree completely.
Robin Heinze:
I think it's a really important step in sort of moving TypeScript from early adopter, really advanced users to more of a general audience.
Orta Therox:
Yeah. It wasn't that long ago that I had to learn generics. Some people just had to learn them quite recently as more and more of these languages added it because it's a really great idea but it definitely is like a complication step on top of like what you previously used to have. Trade-offs.
Robin Heinze:
Definitely.
Jamon Holmgren:
Orta, I can definitely talk to you all day about this. I hope that you come back. This actually your second time on the show prior to us taking it over and relaunching it. You were actually on with my business partner, Gant Laborde as well as Nader Dabit back in the early days of React Native Radio. So appreciate you coming on again with us and we're going to, if we can lure you back here again, we're going to hopefully get you back at some point. I know that there's a lot more to talk about what TypeScript is. We barely scratched the surface.
Robin Heinze:
I think React Native in general.
Orta Therox:
Yeah.
Jamon Holmgren:
Yeah, Native as well.
Orta Therox:
Didn't even talk about CocoaPod support in React Native.
Robin Heinze:
I know.
Jamon Holmgren:
CocoaPods. You're in everything. There's no way that we can keep up with you.
Orta Therox:
Yeah. Ran that dependency manager for a decade.
Jamon Holmgren:
Ever heard of CocoaPods? This is one of the guys responsible for that.
Harris Robin Kalash:
This was very informative. I actually learned a lot in this talk. I couldn't contribute as much because I'm realizing how much I don't know about TypeScript, but thanks a lot.
Orta Therox:
You're welcome.
Jamon Holmgren:
So I'm going to really quickly shift gears into a part of the program where we talk about weird bugs. Does anybody have a weird bug they want to bring up? It doesn't have to be about TypeScript.
Robin Heinze:
I have a weird bug. Fundamentally, it's not really a bug. It's just a feature that doesn't exist, but it manifested as a bug in the application that we're building. And it's related to a UI Kitten, which is a component library that we've been using and using UI Kitten, specifically there pop over component, which is basically a tool tip or where you click a button and another component pops up. Using that pop over component with react portals. So if you're not familiar with react portals, it's a feature that allows you in react JS to essentially insert a div at the end of your document and we're using it in order to basically display a full screen modal on top of our entire site content. However, the screen content that we're putting inside our portal had a pop over in it.
Robin Heinze:
And the bug that was filed against our app was that they just don't open. You click, nothing happens. So I went and I did a minimal repro to show the UI Kitten team and apparently it's just not a feature that exists. They just aren't compatible. They don't work together. And the reason is that UI Kitten relies on what they call an application provider, which is at the root of your app, and basically acts as a host for the popovers and the components that are inserted, but because of the portal we were outside of the application provider. So what was happening was the pop-over was rendering behind the modal in the regular app. And so it was there, it was popping up, but you couldn't see it. And so after talking to the UI Kitten team, what they would need to do is basically expose this like modal host service so that you can use it in other places besides your main application provider.
Jamon Holmgren:
And Z index 9,000 didn't work?
Robin Heinze:
It didn't. I tried that.
Jamon Holmgren:
Yeah, and this is one of the things we're using UI Kitten, which is actually fundamentally a React Native library, but we're using our React Native web and so we're in a context that they don't generally use it in. And yeah. That was a fun one.
Robin Heinze:
We're pushing the library forward.
Jamon Holmgren:
Yeah. So I think you fixed it, Robin, by just writing your own...
Robin Heinze:
I fixed it by not using pop-over, unfortunately.
Orta Therox:
Nice.
Jamon Holmgren:
Working around it.
Robin Heinze:
Working around it. But they...
Jamon Holmgren:
I'm sure they'll fix it eventually.
Robin Heinze:
And that we did that mostly just because the UI Kitten team just doesn't have time to prioritize it at the moment. And I think they probably will work on adding it and so we may be able to go back to using their pop over. Yeah.
Jamon Holmgren:
And I do have to give a shout out to the UI Kitten team. They were very, very friendly to talk to very cool people. I think they're based in Belarus and they're good people.
Robin Heinze:
Yeah. They've been great to work with. They actually... They helped us solve a couple other issues with our bundle size, our web bundle size was like 10 megabytes or something ridiculous because we were adding custom theming and they... We met with them and they pretty much instantly got us the right configuration to reduce that bundle size down to, I don't know, less than one, I think.
Jamon Holmgren:
Yeah. This is one of those things, by the way, where we're using an open source library, but then we ran into a problem and we could just file an issue on the GitHub and then complain, grumble internally, "Oh, they're not fixing or whatever", but I was just like you know what, if we have to pay them to fix this, that's worth it to us so.
Robin Heinze:
I could have easily just worked around it and-
Harris Robin Kalash:
Moved on.
Robin Heinze:
And sort of rolled my own custom and not even talk to them or let them know. But now they know that there's an issue and they have a plan to improve the library and so even though I'm not taking advantage of it quite yet. Yeah. I feel like we've done good service to the community.
Jamon Holmgren:
Very cool. All right. Where can people find you? Orta you said you were just @ O-R-T-A on Twitter.
Orta Therox:
Yep. Twitter and GitHub and Instagram, though my Instagram is a little bit abstract. Yeah, I just take pictures of walls and things like that. It's like hands. But yeah, yeah, mostly on Twitter.
Robin Heinze:
Instagram has a very different community than Twitter.
Jamon Holmgren:
Yes, and that's a good thing. Harris, you are @nomadicspoon?
Harris Robin Kalash:
yes, that's right.
Jamon Holmgren:
And Robin @Robin_Heinze with an E. You can find me on Twitter @JamonHolgren. Also on GitHub. I do not have as impressive of an open source profile is Orta as much as I try. And as always thanks to our producer and editor, Todd Werth, our transcript and release coordinator, Jed Bartausky, and our social media coordinator, Missy Warren. Thanks to our sponsor, Infinite red. Check them out at infinite.read/ReactNative. And a special thanks to all of you listening today. Make sure to subscribe and tell a friend. They're definitely going to want to listen to this episode. Orta has always been a open source hero of mine so I'm really happy to have him on the program.
Orta Therox:
Thanks.
Jamon Holmgren:
Thanks so much.
Orta Therox:
Welcome.
Jamon Holmgren:
All right. See you all later.
Robin Heinze:
Bye.
Harris Robin Kalash:
Thank you. Bye.
Orta Therox:
Ciaos.