TypeScript with Orta Therox

Episode Description

Orta Therox, a compiler engineer on Microsoft's TypeScript team, discusses TypeScript's growth, its deep integration with JavaScript tooling, and open source culture.

Episode Summary

This conversation with Orta Therox, a compiler engineer on Microsoft's TypeScript team, covers the evolution and philosophy behind TypeScript's design. Orta explains how TypeScript roughly doubles its users annually, largely thanks to decisions like enabling Babel and other tools to strip types without understanding the full type system. The discussion explores the tension between TypeScript's build complexity and the desire for a zero-configuration experience, with Orta explaining why TypeScript itself can never be zero-config due to backward compatibility commitments, but tools like TS config bases and frameworks like Next.js can abstract that complexity away. The hosts and Orta examine how TypeScript has become deeply embedded in VS Code, quietly powering JavaScript tooling even for developers who don't realize they're using it. They also touch on TC39's role in controlling JavaScript's runtime features, the "types as comments" concept that could eventually let types live natively in JavaScript files, and how the JavaScript ecosystem thrives as a "dancing landscape" of competing vendors rather than a single-vendor solution. The conversation closes with thoughts on React Native's multi-platform ambitions, Orta's approach to contributing to open source projects like Redwood, and his creation of the Danger tool for automating pull request culture.

Chapters

00:00:00 - Meet Orta Therox, TypeScript Compiler Engineer

The episode opens with introductions as host Christopher Burns welcomes Orta Therox, who works at Microsoft on the TypeScript team as a compiler engineer. There's a lighthearted exchange about the inflation of job titles from "developer" to "engineer," with Orta noting he's one of the few people who genuinely earns the compiler engineer label.

Orta describes his role as being less about writing compiler code directly and more about persuading the broader ecosystem to adopt certain approaches, then building small hooks into the compiler to support those changes. He mentions TypeScript 4.5 features he contributed to, emphasizing that his skills lean toward coordinating large-scale community efforts rather than purely writing low-level compiler logic.

00:01:47 - Redwood, Jamstack, and TypeScript's Flexibility

The conversation shifts to how Orta discovered RedwoodJS and its unconventional TypeScript integration. He explains that Redwood uses a pre-compiled type layer that maps onto existing JavaScript code, something he'd never seen before but which showcases TypeScript's ability to describe even highly dynamic systems.

Orta connects this to his background as a Ruby developer and his work on CocoaPods, noting that the concept of an invisible type layer on top of a dynamic language represents a compelling middle ground between scripting flexibility and large-codebase strictness. He draws parallels to how the Ruby community is beginning to adopt similar approaches with type annotations.

00:03:55 - TypeScript's Growth and the Build Complexity Debate

Christopher raises the ongoing debate about whether TypeScript should be compiled directly or have its types stripped by tools like Babel. Orta explains that TypeScript has been doubling its user base annually for nearly a decade, and one of the biggest growth unlocks was allowing tools like Babel, esbuild, and swc to process TypeScript without needing to understand the full type system.

This leads into a discussion about the friction TypeScript's build step introduces. Anthony admits this complexity still keeps him from fully embracing TypeScript, and Orta validates that concern. He introduces the "types as comments" concept, where JavaScript engines would recognize type annotation regions and simply ignore them, potentially eliminating the need for a separate compilation step altogether.

00:08:07 - The Pain of Early TypeScript Tooling

Christopher recalls his early experience using TypeScript with Gatsby, navigating the confusion of competing plugins and the era when ESLint didn't work with TypeScript. The conversation captures the messy reality of TypeScript adoption before the ecosystem matured, with separate loaders, incompatible linting tools, and configurations that required deep expertise.

This leads to a broader point about how smaller developers often feel pressured to adopt TypeScript because large corporations use it, without recognizing the substantial investment those companies make in tooling. Christopher asks whether TypeScript can ever reach zero configuration, setting up a key discussion about the language's design philosophy.

00:09:45 - Why TypeScript Will Never Be Zero-Config

Orta gives a definitive answer: TypeScript will never be zero-config because its backward compatibility guarantees mean old projects must continue working, and the language intentionally avoids being opinionated. He explains that TypeScript has no dependencies and must remain vendorable, so its defaults are essentially frozen once set.

However, he describes TS config bases, a project he maintains that provides pre-built configurations for frameworks like Svelte, Next.js, React, and Deno. This approach lets frameworks handle the configuration burden so developers only see the customizations specific to their project, effectively achieving a near-zero-config experience through tooling rather than through the language itself.

00:14:59 - The Theory and Practice of Types

The conversation turns philosophical as Christopher asks whether TypeScript's value is more theoretical than practically measurable. Orta cites Airbnb's audit finding that roughly a third of production bugs could have been caught by TypeScript, but notes the comparison is complicated because TypeScript powers JavaScript tooling regardless of whether you write TypeScript files.

Anthony picks up this thread, asking where the line between JavaScript and TypeScript actually falls in VS Code. Orta explains the layered system where VS Code first loads a fast single-file TypeScript checker, then builds a full project model in the background while simultaneously downloading type definitions for all dependencies. This architecture also powers VS Code's web version, where every file access is a network request.

00:20:52 - TypeScript's Relationship with JavaScript's Future

The discussion explores whether TypeScript's deep integration into JavaScript tooling represents a potential embrace-extend-extinguish strategy by Microsoft. Orta pushes back, explaining that TypeScript's explicit goal is to eventually make itself unnecessary through safe migration paths, including the possibility of migrating from TypeScript files back to JavaScript files once types-as-comments arrives.

He then outlines TypeScript's strict design guideline of never implementing runtime features that haven't been approved by TC39, using the optional chaining operator as an example of a feature requested for six years before being implemented. This principle ensures TypeScript remains genuinely "JavaScript plus types" rather than becoming a divergent language.

00:27:16 - Big Tech, Open Source, and the JavaScript Ecosystem

Christopher frames the JavaScript ecosystem as territory claimed by different tech giants — Facebook with React, Microsoft with TypeScript, and Google with the runtime. Orta reframes this through the lens of complexity theory and what he calls the "dancing landscape," where many independent actors contribute to a thriving ecosystem.

Drawing on his experience in the Apple ecosystem where a single vendor controls everything, Orta argues that JavaScript's multi-vendor nature is its strength. He notes that roughly half of all programmers use JavaScript or TypeScript, making it impossible for any single company to serve everyone. While TypeScript has the least competition in its space, the broader tooling ecosystem benefits from healthy competition.

00:31:50 - Contributing to Open Source at Scale

Anthony asks Orta about his approach to joining large open source projects. Orta describes a systematic method: reading all documentation, completing tutorials, checking if docs match reality, filing bug reports, and submitting a burst of pull requests to understand the team's workflow and culture.

He emphasizes the importance of capturing feedback during the initial onboarding period before familiarity makes friction invisible. For Redwood specifically, he spent a week porting an existing site to identify edge cases, then filed detailed proposals like improving generator reusability. His broader philosophy involves treating key dependencies as part of his personal stack and taking ownership of bugs that affect his work.

00:36:58 - Danger: Automating PR Culture

Orta explains his creation, Danger, a tool born from the challenges of maintaining large open source projects. Danger acts like ESLint rules for pull requests, allowing teams to codify cultural expectations — such as requiring changelog entries or confirming documentation updates — into automated checks.

The key insight behind Danger is that it neutralizes interpersonal friction by making a bot enforce team agreements instead of relying on humans to repeatedly remind each other. Available in multiple languages including Rust, Kotlin, Swift, and JavaScript, Danger provides only a runtime with no built-in rules, reflecting Orta's philosophy that tools shouldn't dictate team culture but should make it easier to enforce the culture teams choose for themselves.

00:41:31 - React Native's Multi-Platform Future

Christopher asks about Microsoft's involvement in React Native. Orta explains the three-way dynamic between Facebook (focused on keeping React Native small and mobile-only), Microsoft (extending it to every platform where Office runs), and Expo (providing the practical app-building layer). He contrasts this "dancing landscape" with Flutter's single-vendor approach.

The conversation wraps with speculation about whether React Native could eventually become the universal platform, with Orta expressing skepticism that any single framework can truly succeed everywhere. He closes by naming CocoaPods as his favorite open source project, calling dependency managers the tentpole of any ecosystem and crediting CocoaPods with pioneering systems that helped developers understand the code they were integrating.

Transcript

00:00:00 - Christopher Burns

What's your last name?

00:00:00 - Orta Therox

Therox.

00:00:02 - Christopher Burns

Sorry. How do you pronounce that?

00:00:04 - Orta Therox

The rocks. You know, like you have a drink on the rocks.

00:00:18 - Christopher Burns

Welcome to the show. Orta Therox. You are a TypeScript engineer. I don't want to say TypeScript engineer, because that's probably not your job title. But most TypeScript people like to say, I'm not a developer anymore. I'm an engineer.

00:00:31 - Orta Therox

Yeah. We all want to pretend that we're very important and try to steal the engineer status from those people who have a protected title.

00:00:38 - Christopher Burns

Very much so, because you go from being a JavaScript developer to TypeScript engineer, because now you're worth something.

00:00:45 - Orta Therox

Yeah. I do like to think that I actually, you know, I'm one of the few people that does get to say they're a TypeScript engineer. But on my team, we use the term compiler engineer. So I would say I work at Microsoft on the TypeScript team as a compiler engineer.

00:00:59 - Anthony Campolo

So you work on the compiler specifically?

00:01:01 - Orta Therox

Sometimes. There's a new release of TypeScript that's coming out. Probably by the time people have listened to this, it will be out, 4.5. I have a few sort of headline features there that are often about building a lot of infrastructure outside of the compiler, and then building a very small amount of infrastructure inside the compiler for that one feature, because most of my skills generally tend to be about persuading a lot of people to do a single thing in a useful way. And so sometimes it just requires a tiny bit of code in the compiler to get that working.

But I definitely understand the compiler pretty well from the two and a half years I've been doing this.

00:01:35 - Anthony Campolo

Yeah, so it sounds like you're a compiler politician.

00:01:39 - Orta Therox

Yeah. Just persuading everybody that's using the API that maybe this is the right way to do it, maybe. And if not, just sending the pull request to fix it.

00:01:47 - Christopher Burns

We recently met you because you started looking into the full stack Jamstack frameworks and you dipped into Redwood, saw that there's tons of TypeScript hacks and jumps and things that could probably be done a lot better. You've started making the pull requests, from what I've seen.

00:02:05 - Orta Therox

The TypeScript website is a Jamstack website. It's Gatsby, and I'm a big fan of almost all of these systems. They all have their pluses and minuses. I helped get Gatsby TypeScript support up and running. I didn't need it for Redwood, which, luckily, had already been done.

It's kind of interesting the way that it's structured. The system that it uses is actually sort of, it's like this pre-compiled TypeScript that adds this extra layer above your codebase. I've never really seen something like this that adds an entire type layer that sort of maps on top of existing code files. It's exactly the sort of answer you would get where you try to build the most dynamic system ahead of time with a perfect JavaScript API, and then you mold the TypeScript support around how JavaScript works at heart. That's exactly what TypeScript was built to do, right? There's so much existing JavaScript out there, and TypeScript needs to be able to map that in some way.

[00:03:00] If you play with it, it feels a bit esoteric, especially if you go and look at how all the pieces come together. But the fact that it actually works is, to some extent, a celebration of how weird TypeScript can be and can allow all sorts of interesting integrations.

00:03:12 - Anthony Campolo

Is it obvious that it was written by a bunch of Ruby developers?

00:03:15 - Orta Therox

Yeah, I'm a Ruby developer. I started building Rails apps. I worked on a dependency manager for iOS in Ruby for a decade. It's a really pragmatic language, but the moment that I sort of discovered TypeScript and JavaScript, at the time it was originally Flow, getting a bunch of the tooling on top of your existing dynamic languages, I was pretty much sold on that paradigm. And I know that the Rubyists are starting to take that approach now.

I think for a lot of programming languages, the idea of a type layer that lives invisibly on top of the existing code, it's probably this nice sort of halfway point between being really flexible, like the scripting languages are, and being really strict, like you want in a large codebase.

00:03:55 - Christopher Burns

To what I've seen of the TypeScript ecosphere recently, there's still a massive debate. Is it worth compiling TypeScript, as in, is it worth just having it in every tool and then chuck away all the types as soon as you compile, like Babel has done for a while? Or is it worth compiling it straight from TypeScript like tools like TS do? I've always found it a really interesting middle ground, because I wouldn't say TypeScript blocks certain tools from working great, but it does like to put a spanner in sometimes.

00:04:29 - Orta Therox

I don't disagree at all. I think there's many stages of how TypeScript has got as big as it has. One of the biggest unlocks for TypeScript to grow is that TypeScript roughly doubles its users every year, and it has done for almost a decade. It's an incredible amount of growth.

The most recent big one was because TypeScript added the ability for Babel and all these other tools to be able to implement TypeScript. Prior to those changes, you needed to know the entire type system in order to accurately convert a single file into JavaScript. After that change, then Babel, esbuild, swc, Sucrase, all these tools can integrate TypeScript without having to think about the type system problems.

You used to have to have a TypeScript everything. So you had to use TSLint instead of ESLint. You used to use editor tools that were like this is TypeScript support and not necessarily this is VS Code with TypeScript built into it. And nowadays, you kind of can live with TypeScript in a JavaScript ecosystem. And yeah, there are definitely pains.

[00:05:29] But the real world thing here is like there's no types in JavaScript. And until there is some sort of proposal that goes through the TC39 process that says, here's maybe a way in which types could be added to JavaScript safely, then you'll always have that sort of tension. That's why something like Deno is kind of nice, because they'll just get rid of your types and just evaluate it automatically, as though it was a native feature of the runtime.

00:05:53 - Anthony Campolo

Do you think that it will ever actually get built into the language? I don't know how closely you follow TC39 and the politics of that, but I'd be curious. I'm sure there's people who want it and people who don't. So just as someone who kind of checks the wind, do you think it's ever going to blow in that direction, or will it always be fought against?

00:06:10 - Orta Therox

The way that I think it will probably end up working is that somebody that is not the TypeScript team will want to be in a buildless environment. Right. So think about the problem that we're talking about. TypeScript needs these extra tools in order to run in Node, for example, or any JavaScript.

00:06:26 - Anthony Campolo

And this is my biggest issue with TypeScript, and why I tend to still avoid it even to this day. As someone who now understands types and can handle TypeScript, the build complexity is still what makes me hesitate from using it.

00:06:38 - Orta Therox

Yep. And I do not disagree with that at all. Like, I think it's a completely legitimate opinion. And that's in part why we put effort into the JSDoc implementation of TypeScript. What people want is exactly what you've just said, which is a buildless version of JavaScript with types.

One way in which that could possibly be done is if JavaScript has support for knowing what designates a type area in it. The way to sort of think about that in your head is types as comments. JavaScript engines know where a type starts and where a type ends, and just ignore everything inside there in the same way that they ignore whatever's inside the comment. And so what that syntax could look like, Flow used to have types in comments as a potential route for that. But what about if that was systematically agreed upon at JavaScript level, and TypeScript puts some constraints on it in the same way it did for Babel support, that allows JavaScript to say, hey, this space is available for putting types in, and TypeScript to say, hey, if you don't put your types in this space correctly, then we're going to fail your build.

[00:07:38] And that would probably allow types to run inside JavaScript in a way that doesn't require a type system. JavaScript just says, hey, if you put code in this particular area, then types can be inferred by an editor but can be ignored by the language runtime, and that would sort of get you in that direction. So I've heard rumors of ideas around this from different people in different places. How it turns out, I don't know, but I think it's a very interesting approach to that problem.

00:08:07 - Christopher Burns

I would like to say, when you said about Babel being included, we quickly spoke in the pre-show and you said that you helped get Gatsby TypeScript support. I remember this, and that's when I actually started following you on Twitter. The first time I ever used TypeScript was with Gatsby, and it was a pain. I still remember it to this day.

You had Gatsby-plugin-TypeScript, and then you had Gatsby-plugin-TypeScript-two. And everyone's like, use two, not one.

00:08:39 - Orta Therox

Which one?

00:08:41 - Christopher Burns

Exactly. And it was like two was using awesome-ts-loader. One was using, I think, just a standard TypeScript compiler. It was all this complex stuff. And then it was like the thing where ESLint didn't work with TypeScript yet, so you had to have your own version. And then it was like, oh, but why would I want all the rules from ESLint? Now you're playing big games in circles.

00:09:03 - Orta Therox

Now you're playing dangerous games.

00:09:05 - Christopher Burns

Yeah, exactly. And I think the biggest thing that I think you will 100% agree on: small developers to medium-sized developers look at big corp and think they're using TypeScript. Oh my gosh, I should jump on TypeScript today. And you forget that they're spending, you know, $300,000 a month on paying for people to just sort out the tooling in the company, or more, to make sure it's perfect.

That leads me into my next question that I think is a really important one. What do you think of zero configuration? And do you think TypeScript will get to the point of zero configuration?

00:09:45 - Orta Therox

Okay. So I can start with the latter one because that's easy. No, it will never, in part because that's TypeScript's goal is to not have an opinion. The way in which we sometimes talk about TypeScript tends to focus on TypeScript and Node, but there is nothing specific to TypeScript and Node in TypeScript, just as there's nothing specific to TypeScript and React in TypeScript. There's only JSX support in TypeScript, and then React is a separate thing that can be added onto it later.

TypeScript can never be zero-config, because TypeScript backwards compatibility goals are to never break a project, which means something from, you know, seven or eight years ago will still, air quotes, work. They'll just get an awful lot of compiler messages. But the project will still work exactly the same as it did before, so there will never be a zero config. That one I can guarantee.

The question of, is zero config a good idea? Yes, definitely. I liked the idea of cosmic config, which is a dependency of projects that allows you to put config in, say, a YAML file, or in your package.json, or in a my thing, something like you'll see in Jest, for example.

[00:10:46] And I tried to see if I could get it, first of all, to have cosmic config support npm packages as configs. So like you could just, your config is actually just @author/config. Cosmic config will know to look in that folder for configs, for Jest, for Babel, for ESLint, because they all use the same one dependency. And TypeScript could do that too, in theory, but that's hard to pull off, and I couldn't persuade the cosmic config people to agree to that, which means that that probably won't be happening. But they might relook at that idea again at some point.

00:11:18 - Christopher Burns

As a novice to TypeScript, you obviously go, oh, I need to do tsc init, and then you go, I have no clue what all of these options mean. On, off, on, off. Oh no, no, no, no, no. I'm done. Leave it as that. You know, yes, we're talking to an expert here. But it's such a good question. What should I set the version to? ESNext? 2020? You know, 2017? Where do I want to compile down to? These things are like, what does your project want? And it's like, I don't know.

00:11:51 - Orta Therox

Yeah, I've tried to attack this problem last year, and I think I've done a pretty reasonable job at it, which is there's a thing called TS config bases. And for example, if you start a new Svelte project, it will create a TS config in your root with a link to a TS config Svelte. And that is maintained by me and the Svelte team. Whenever there's a new update to that, that gets applied to everybody, and it's just an npm package that downloads the TS config for your individual project.

So then the question for you is, okay, so you know you're going to have a Svelte project. So you would just use that TS config, for example. And we have the same for Node, for React, maybe even Deno and a few others.

00:12:33 - Anthony Campolo

You actually have Create React App and Vite React, and yeah, you have Deno in here too.

00:12:38 - Orta Therox

So those are built to try and help you get to that point where, like, you just need that in theory. And the config reference, which is like this massive mega document of hundreds of compiler flags, at the top is like, hey, you might want to use one of these bases instead if you know what your baselines are. And that's always the tricky bit, because TypeScript needs to run without any other stuff under the hood, because it needs to be a single dependency. It's got no dependencies, and it needs to be vendored. With all these editor tools and the website, it has quite strong opinions about the defaults when it gets to change them, but it never gets to change them once they've been set.

00:13:15 - Christopher Burns

And it's that thing of including libs in the config. I like to think of it, and this sounds like the worst thing ever, but you will guess your way to it. Then find a tutorial, add in the settings you're missing from the tutorial into it, having no clue what changes, and then hopefully it works.

The favorite one is, it's not building. Oh, have you added this into your config? No. I've done that. It built. And it's like I've just looked at it now and it is really active. Your Next.js version only got added eight days ago, I think. Yeah. So it seems like a really good way to get it right. And I think that's what Next.js does well is that if they detect a TS or TSX file, it just goes, here's a TS config.

00:14:01 - short split/interjection

Here's all your stuff.

00:14:02 - Christopher Burns

Exactly. While TypeScript can never be no-config, like you just said, the tools could potentially make it no-config.

00:14:10 - short split/interjection

Yes, exactly.

00:14:11 - Christopher Burns

As in bringing that level of complexity away. As in, if you're an expert and you need to tweak it, here you go. You don't need to tweak it. Never touch it.

00:14:22 - Orta Therox

Exactly. And we can hide those settings away in these TS config bases. You're using a Next site, so you just use that TS config base for Next. And then the best bit here about this is that the changes that you make in your TS config therefore reflect this thing specific to your project, right?

So if you followed some tutorials somewhere, then the actual changes that are in your project are the changes from your project to Next. Whereas previously they were all sort of embedded in this one sort of thing, and you don't know which ones are yours and which ones are the project's. It's one of the hard realities of just trying to use a very config-heavy setup that just tries to be everything for everyone.

00:14:59 - Christopher Burns

One of the big things I always wonder, as Andy will know for sure, is TypeScript is much more a theory problem than an actual practical problem because I use it every day. I understand the uses for it, but if you asked me to quantitatively give, like, here's how many hours it saved me, here's how many errors it's fixed, I would personally find that quite hard.

So then it's not necessarily a functional thing that it's fixed. It's more of a theory of I'm bashing my head against JavaScript. So I would love to hear your thoughts as if you think half the battle with TypeScript is more the theory of types than the actual functions of the types.

00:15:42 - Orta Therox

It's nuanced, right? Like Airbnb, when they were adopting TypeScript, they actually did audit all of their bugs for, I think, a month where they then tried to state, is this something that TypeScript would have caught? And I think they said about a third of those bugs that got through were things that TypeScript could have caught, which is a pretty solid number.

Quantitatively, if you will, I think what makes the underlying comparison a little complicated is that TypeScript is used probably regardless of whether you're using TypeScript or not, because TypeScript provides all your JavaScript tooling. To what people are usually talking about, there is the incremental jump from type-assisted JavaScript to TypeScript, which is great. Like, honestly, if you roll back from TypeScript to JavaScript and your tooling is still great, that is still TypeScript providing you all the tooling and assistance that you want and that the integration provides. It's really good to show Microsoft that all these different tools just elegantly sort of go between the different levels of migration that you want.

[00:16:37] That's why TypeScript talks about migration steps.

00:16:39 - Anthony Campolo

Yeah, we should talk about this, which is TypeScript is just so baked into VS Code now that a lot of people are getting typing in their JavaScript without really realizing it. So what is happening inside my browser? What is JavaScript? What is TypeScript? Where is the barrier between that? At what point am I actually using TypeScript? Is it possible for me not to use TypeScript if you're saying it's actually just baked into the editor?

00:17:03 - Orta Therox

Until very recently, I was maintaining the Flow for VS Code extension, which actually had this problem of, from Flow's perspective, we are providing a different language to JavaScript, and TypeScript is a different language to JavaScript. And we want to provide all the editing tools for autocompletions, for inference, and all these other things. But TypeScript actually gets in the way there because the syntax is different in a few different cases.

And so VS Code actually added support for turning off TypeScript in VS Code. There is a way that you can go into what they call the built-in extensions. And you can disable the built-in TypeScript extension, and then you truly are in a TypeScript world there. And it's basically like you'd open Vim, you press dot, you get no autocomplete or any sort of thing.

00:17:44 - Anthony Campolo

Just as God intended.

00:17:45 - Orta Therox

Yeah, exactly. And that's great. You can disable it if it's not your thing. But realistically, pretty much nobody's going to do that. TypeScript doesn't take metrics from whether people do these sort of things, because including metrics in a compiler is still not something that people really do. And I think that's an okay thing to not do. I'm glad that we don't, but I think being able to turn it off was very important for Flow specifically. Now, if you're in a Flow project, you can turn off TypeScript. You can just have Flow there.

So the question of how integrated is it into VS Code? The TypeScript team has a person that constantly is integrating TypeScript into VS Code. On the VS Code side, their job is basically to make sure that TypeScript rocks and JavaScript rocks, and they both use the same thing together. So for example, TypeScript, when you're in a JavaScript file, will first load up a sort of super fast version of TypeScript that just tries to do the inference in that single file.

[00:18:38] The moment that you open a JavaScript project, you'll get autocomplete in a single place, but you won't get autocomplete across your entire project because it first loads up one and then it loads up a second one in the background that's generating the entire project and trying to understand the full semantics of your system. And at the same time, it's also downloading to a private cache a copy of every @types/ something that relates to all of the potential dependencies in your project also. So it's first downloading all these extra things in the background so that it knows the definition shapes of all of the libraries that you're using. Then it can start building out this sort of weak TypeScript project to represent your actual project, and then your autocompletions and tooling from that then start being used there.

This two-step approach is actually very useful now that we live in a world where VS Code Dev exists, or GitHub Dev, where you have VS Code in a web browser where you do not have fast access to a file system, and every single call to another file is a network request, which could take forever. And who wants to download all of somebody's node modules over a network request each time?

So we have this sort of incremental build approach where, when you need it, it gets grabbed, or we do grab the entire world and do very accurate system checks. JavaScript support in TypeScript is kind of magic. I wasn't there when it turned on, but it was pretty wild to see.

00:19:57 - Christopher Burns

Well, when we talk about, like we said, JavaScript tooling in TypeScript, TypeScript tooling in JavaScript, the first time I saw this, it confused me even to this day, because I don't really have the answer to it without obviously researching it.

When Redwood, when they were kind of working on TypeScript support, so it wasn't full TypeScript support, they had jsconfig.json, and I looked at it and I was like, this looks like the TypeScript compiler. But this is a JS compiler. I'm confused. And it was because it's doing that inferring for the VS Code.

So there's me in Redwood going, I'm using TypeScript so all my things are really imported for me. And you know, I don't get lost easily. All them people that are saying JavaScript is, you know, it's still okay, I'm like, how are they doing all this? And it's, oh, it's because all them features have leaked in. And if you've just used TypeScript for four years, you've probably not noticed that they've leaked over.

00:20:52 - Orta Therox

I mean, that's the goal, like incremental migration towards TypeScript when I talk about that. It also seems like we're forcing people into this TypeScript world where Microsoft can then be like, hey, now everybody's using TypeScript. Let's just drop JavaScript support or something like that and do like an embrace, extend, extinguish, somehow force people to pay for TypeScript compiler. I'm not entirely sure what that could look like, but the reality of the situation is still that it's very hard for Microsoft to be able to pull that off, and especially imagine the reputation hit.

But if TypeScript's goal is to get rid of TypeScript and give you the best code possible, it's like its entire goal is to get rid of itself in a safe way so that you can migrate your project away from it if you ever need it. And that process of migration is also the downwards migration from TypeScript to JavaScript. So when and if types as comments ever arrives in the world, people will want to migrate from TypeScript files to JavaScript files.

[00:21:43] And that will be a very safe evolution, because TypeScript already has all of that infrastructure inside it to help people migrate to JavaScript files.

00:21:51 - Christopher Burns

Talking about the future, I think is really interesting because back when I started, obviously it was where Gatsby was, and yeah, it was TypeScript compiler or Babel. It was like these two things are going to compile my ES6 into ES5. And whatever the question that I'm going to ask is, it sounds stupid, but is the TypeScript team working on future things they want in the compiler and then compile it into like today's browsers? And are you like working on tomorrow's ES6? So seven, whatever we call it these days, 2022, yeah. You know what I mean. As in like the features that are coming that have gone through all these things, they're kind of different features to TypeScript's features, as in like we're bringing this feature today.

00:22:36 - Orta Therox

Yeah. So this is actually a really good time to talk about TypeScript design guidelines. So when TypeScript first came out, it had pretty strong opinions about what it thought the future of JavaScript was like. Now remember, this is ten years ago. Ten years ago, JavaScript was really stuck in a rut. It was the transition between ES3 to ES5, where a lot of people thought that ES4 was going to be this massive thing that had classes and types and systems and everything that you saw in ActionScript 3, if you ever used that.

Today, TypeScript design guidelines are straight up: will not implement new things that are language runtime specific. TC39 have to agree on it to such a strong extent that it is guaranteed to ship, and only then will TypeScript introduce those language features. You know, when the question mark dot operator came into TypeScript, that was a big thing because it's very common in a TypeScript project to have to do a lot of faffing around undefined and nulls. But you don't have that so much in JavaScript because you don't feel that problem because your editor doesn't show you.

[00:23:36] You only find out when you take a production down by accident. And so that feature was requested in TypeScript for about six years. Eventually, the TypeScript team took over that project in TC39 and helped push it through. And that also started to introduce this idea that TypeScript should be actively involved in the TC39 proposal system.

So right now we've got a few things like regular expression improvements, as well as talking to people that are actually interested in shipping new JavaScript features and saying whether it's feasible or not for it to be typed in a useful way. The pipeline operator is a really good example of that. Lots of people were leaving feedback on the pipeline operator in the TypeScript repo, even though we're not influencing what the pipeline implementation is going to look like. But by providing the tooling for what a pipeline operator looks like and feels like, people feel like there's a very large connection between the two. Like as developers, we know, as compiler engineers, maybe I should say, we know what is going to affect the runtime of JavaScript versus types-only stuff.

[00:24:32] So the introduction of a new type concept we know will be erased, and thus will be safe to be added to TypeScript because it won't affect the JavaScript output. But a new feature like the question mark dot operator could never be added to TypeScript unless it was agreed upon by JavaScript.

So to some extent, TypeScript doesn't have control over what features it is actually implementing, at least especially on the expression side, on the runtime world. And that is totally okay. TypeScript thinks that that is so important that it is one of the top design guidelines for the language that we don't control, that a group of people control that, and they are in charge of what JavaScript is. TypeScript could not realistically be what TypeScript is, which it claims to be JavaScript plus types, unless it agrees to that underlying principle.

00:25:20 - Anthony Campolo

So you keep saying TypeScript wants this, TypeScript wants that. Who is TypeScript and how do they have these opinions and where are these opinions expressed?

00:25:30 - Orta Therox

Yes, as a TypeScript team member. So TypeScript roughly is about ten engineers nowadays. We leave meeting notes and things like that in the TypeScript GitHub repo, so anybody can see what we're talking about and how we're trying to sort of make design decisions that require more than two or three of us to be discussing a particular topic.

And I describe it as TypeScript wants in the same way as Kevin Kelly. His book is, what is technology and what does technology want? The direction of technology is always an interesting discussion point, but generally I think of it as for TypeScript, the choices that we make that are influenced by the design guidelines for TypeScript influence what I say that that is what TypeScript wants as a concept.

TypeScript was founded by very serious programming language people, including Anders Hejlsberg, who built Pascal, Turbo Pascal, I think he built C#, he built TypeScript as well, as well as a bunch of people that have come from stuff like F# and C# on our team. And they all come with different influences, like the vast majority of us are functional programmers, realistically.

00:26:34 - Anthony Campolo

So you're nerds?

00:26:35 - Orta Therox

Yeah, I'm surprised a bunch of compiler nerds exist. A lot of TypeScript introduces quite a lot of high-level functional programming concepts to people, because that's the only way that you can describe types for code that already exists and not code that you are writing.

Because we have to make these definition files that describe extremely complicated types, like Lodash's types are mind-blowingly hard to get your head around. They all interlink in interesting ways. It was very complicated to implement Lodash support into TypeScript Playground, for example, but that introduces programmers to these functional concepts even without necessarily calling them the functional programming concepts, which I think is kind of neat.

00:27:16 - Christopher Burns

Well, I've been thinking in my head that I just love to hear your opinion on because for someone working at, you could call it MANGA these days. You know, Meta is that, you know, to me, it kind of feels like, as I said earlier, like the big corps decide the path. But it's when we say the big corps decide the path, it looks like confusing because you're like, Facebook has put their flag down and says, we're the view controller of the open source community. And then Microsoft's put that flag down going, we're the compiler of the open source community language. Yeah, yeah, we're the language. And Google has said we're going to interpret it all for the rest of you.

00:27:55 - Orta Therox

Yeah.

00:27:56 - Christopher Burns

And it's like the thing, it's like whenever someone asks me, like, what is TypeScript? I always just say, oh, it's kind of like a different form of JavaScript, like it's a different language unto itself. But this conversation has really put me in the mind of it's not necessarily that anymore. It's more about morphing TypeScript into JavaScript more naturally than saying no. It's a hard cutoff, as in C and C++, or C and C#. As in, it's a totally different thing, but it's similar.

I think it's because, yeah, we had the common thing of, well, they both had the same co-creator, you know, C#, TypeScript. It's just Microsoft wanting to make C# of the web. And we see this with, like, open source communities saying, I write code in JavaScript, so why should I add my types for the big corp? And that brings it on to: do you think that it's all this open-source harmony? As in, well, every corporation...

[00:28:54] Yes, every corporation puts their own company first, mostly. We're seeing really good handholding right now, and it's really moving everything further, faster.

00:29:04 - Orta Therox

Yeah, there's a really interesting system of thinking called complexity theory that talks about how I like to think about the JavaScript ecosystem, which is they call it a dancing landscape, which is that there are just tons and tons of people doing interesting work that comes and goes as frameworks change, as the languages evolve. All these tools, I love it.

Like personally, I came from working in the Apple ecosystem where you only use Apple tools. If they don't have everything that you need or want, you can try and fix some of those problems, but realistically Apple will come and take it if they need it, and they will not normally give you credit for that work either.

Whereas in this one, Gatsby on my app is using React from Facebook, it's using VS Code and TypeScript. I know that my dependency stack is going to come from all sorts of different people with all sorts of different motives. So it's like, you know, taking Redwood as an example. There's Prisma in there, there's Apollo.

[00:30:01] The people obviously working on Redwood have their own opinions on how all these systems should come together. It's not just a single vendor. And I think that's what really makes JavaScript succeed, even if it is starting to feel a little bit more like a Microsoft stack a lot of the time. Like realistically, the end code that you run is never really Microsoft, right? Like Microsoft has no big killer frameworks for things. In fact, the closest we've got right now is like some web component stuff. I'm not particularly wild on web components, so I'll let that do whatever it does.

I think having an ecosystem with many people doing lots of different things is absolutely great, considering how big it is. There are estimates that 50% of all programmers are programming in JavaScript or TypeScript. You can't really cater to that many people and that many types of projects with a single vendor. To try and do so would be folly. Realistically, everybody sort of laying claim to certain areas is great.

[00:30:53] There's so much competition in almost all of the spaces. TypeScript is probably the place with the least competition. Nowadays it is very hard to make a competitor to TypeScript. Just think of the editor tooling, the compiler. Maybe if you took ESLint and tried to turn that into like a full-on editor tooling space, but everywhere else there's just great competition for that sort of tooling. And that's great.

00:31:16 - Christopher Burns

I think it's time for the return of CoffeeScript. Return of CoffeeScript?

00:31:21 - Orta Therox

Yeah, Iced CoffeeScript was an attempt. CoffeeScript 2 actually did come out in the last few years. It was a legitimate need, and they really set a tone that did a really good thing for the rest of the ecosystem. Even if a lot of people cry out in pain at having converted CoffeeScript to JavaScript, I converted a bunch of CoffeeScript straight to TypeScript when I first started using TypeScript to really get a feel for JavaScript in general.

Kind of wild, but if you know Ruby, if you know its type system, and you know JavaScript, how easy is that to migrate?

00:31:50 - Anthony Campolo

Obviously, I'd be curious to get a little bit of your perspective coming into Redwood when you approach a large open source project like that. How do you look to add value? Or do you kind of start poking around in the codebase? And just how do you approach that? Because it's been really great getting your perspective and opinion on all sorts of things in Redwood. So we really appreciate that as a very, very experienced open source maintainer. I'd be kind of curious how you think about that.

00:32:16 - Orta Therox

This is a really interesting one. I have a history of trying to pick a dependency and call that part of my stack. Sort of the Orta stack. In doing so, I sort of lay claim to any bugs inside that that affect me; they're bugs I need to go fix myself.

In the process of doing that, I really need to feel like I have an understanding of who are the sort of core maintainers, how do they work, what does it look like to get something approved, and what does it look like to fork and run that project myself if I need to? Sometimes it's less needed, but TypeScript is probably the best example of something that I didn't need to do any of that. But yet I still went to go work on it full time afterwards, because I saw a different problem in that area that needed full-time commitment to pull off.

But, you know, for Jest or for Storybook or for Prettier, what I did for all those projects is ship enough PRs to get added to the core team, and then redesign the home pages and try to handle what the documentation looks like at scale.

[00:33:12] I do that for GraphQL as well, for example, for Redwood. I'd heard of Redwood, having been a Rails developer earlier in my life. I wanted to get a sense of why did they add TypeScript support late, because I had been following it for a while and I wasn't going to jump in until the TypeScript support. I didn't necessarily want to have to build it myself, especially as the thing that I'm working on. I want to somewhat concentrate on the thing I'm working on, not necessarily all the tooling for it.

Normally I get paid to fix other people's bugs too. In this case it would be me paying for fixing my own bugs.

So for Redwood, I've read every single bit of documentation, went through two separate tutorial projects, tried to get a sense of does the documentation actually match reality? Because especially pre-1.0, there's a lot of really low-hanging fruit for improving documentation that doesn't match reality anymore. Once I'd gone through all the documentation, I sent a few PRs their way and then started looking at, okay, so if this is something that I'm going to adopt, I spent roughly a week trying to port an existing website over to RedwoodJS to get a sense of what sort of edge cases am I hitting when I'm using this in active development.

[00:34:15] That could be something as simple as every time I press save, I see the entire Webpack output for a particular file, which is generally never useful. Maybe if it crashes. And so it's like, okay, so this is a design issue. I can file a bug report that says, hey, if we think about it from this direction, then here's how this abstraction can be used in this particular way.

I did one like a day or two ago that was like, hey, generators are really useful in scaffolding your project and an idea very quickly, but the moment you do it once, that area, you never get to go back and use that scaffolding again. And so that idea is somewhat wasted. You only get to use it once. So I started thinking to myself over the course of a day, like, what does it look like to try and reuse those generators on projects that already have had something generated? You know, you change your schema and how do you give additional information?

[00:35:02] That makes some sense. I tried to spec those out at a level that I would expect to spec it out at TypeScript, enough to give enough context for somebody that might be interested in actually doing it. Not sure if I'm interested in doing it yet, but if it annoys me enough times, then yeah, I'll just go and do it.

So that's kind of how I edit. Like send a bunch of PRs. It's sort of like a blitzkrieg style approach and then get a sense of how everybody works, figure out the people behind it. I don't necessarily need to be the one actively contributing, but being useful to the team by just being somebody that uses it, somebody that understands TypeScript very well. Most places need to integrate with TypeScript to get their tooling support in some way, and so just somewhat providing useful feedback.

I think I've already been in like three or four private video chats with different Redwood maintainers about like why Redwood was a good choice for me for this particular project, where I would like to see it evolve, what parts of it fit and what parts of it don't necessarily fit.

[00:35:55] And where do I see the documentation improving and things like that. It's a lot of stuff that's really hard to get once you've been working on it for a long time. I try to use a lot of my initial velocity to try to give as much of that feedback as possible before I know too much of the system to be able to work around those problems and not feel like it's friction anymore.

00:36:13 - Christopher Burns

It's a really hard thing when you've looked at it so many times. As in the Redwood team says, you know, we like to pride ourselves on our documentation, and they sure do. But when you're trying to change the framework and add breaking things, upgrading things almost monthly, it's quite hard to then go back and remember all the reference places where that one function was used, especially with things like hooks. Say you're adding new props. Remove props. Deprecate props. Keeping all that stuff up to date. Moving around. It can be such a challenging problem and we're yet to see, I think, a full solution.

00:36:50 - Orta Therox

Maybe not for Redwood, but for TypeScript. We have a solution for that now for 1.0.

00:36:55 - Christopher Burns

I'm sure they'll get closer to it.

00:36:57 - short split/interjection

Yeah.

00:36:58 - Christopher Burns

One of the other things I did want to quickly bring up is a tool that I believe you created called Danger. Yeah, I've seen a lot. I've heard a lot about it. I used to do a bit of React Native, so I've heard a lot about it from that. I never actually implemented it, but I would love to hear your thoughts on that, because the people that I spoke to said it's pretty useful, and I never went past that.

00:37:22 - short split/interjection

I never.

00:37:23 - Orta Therox

Got further. Yeah, it sounds to me like you're not actually in an environment where Danger is super useful to you. Danger came from the tension of working on very large open source projects and not having an infinite amount of time, and especially, and this one is sort of key, a lot of maintainers think that every user deserves the maintainer to fix their problem.

And I only don't like it if someone submits an issue to me, it's marked as a bug, and it's not a bug that I would ever touch or ever actually hit. I'll just say, yeah, it's great, marked it as a bug, you're welcome to fix it if you want.

Now Danger comes at this problem in a similar way, which is you get so many incoming PRs that just need a tiny little tweak. And so what Danger does is it gives you a way to almost have ESLint rules for a pull request. So you take that entire changeset and you say, hey, what rules can we make around what that interaction looks like? That can be programmable. So think of it as a runtime for checking the PR, not checking your unit tests, not checking your integration tests, but checking the PR.

And Danger is available in multiple languages. It has Rust, Kotlin, Swift, JavaScript, and the idea being that maybe it's as simple as you need to have a changelog entry on every PR. Realistically, you could have, you know, almost every Danger system has had like a million GitHub Actions being rebuilt to recreate every single one of these little bits. But Danger just provides a runtime. It provides no rules. And that was part of my golden concept here was that, like, I am not going to tell you what your culture looks like.

We had an iOS project where every time somebody edited a single particular file, you had to go and edit a Google document. So I had been living in Microsoft for so long that I don't know what the Google version of Word is, a Google document, which was how all the analytics came through. This Google document was given to the analytics team that says where all the analytics come through.

And so we just made it that if you make a PR and edit this file, then you have to tick a box in GitHub. I've updated the Google doc, and so it adds a bit of friction to that flow. But in doing that, you've guaranteed that it has been done, and maybe not by a human, because a human always has to be the one, like, oh, did you add tests for this change? Or did you add a changelog entry to this thing? And like as a human, first of all, that kind of sucks because you have to keep remembering it on every single PR and you eventually become the, hey, the other changelog guy. And hopefully everyone remembers that.

But realistically, if you can offset that to a bot that you as a team have agreed that this is what we do, then by having Danger do that, then it becomes a neutral thing, right? It doesn't change the relationship between me and you because I keep telling you to add a change. But we agreed that we do changelog entries, so we added a linter for that at the PR level, and that's what Danger sort of fixes when you're doing big JavaScript projects. Any project, you really need some way to just tell people ahead of time the sort of cultural rules without them having to read these massive contributing guidelines.

00:40:16 - Christopher Burns

Well, the places that I saw Danger originally was like, here's all the tools you need to be a productive dev. That Medium article should be called, here's how to bash yourself over the head with a rock and get no work done. You've implemented all these tools to help you, and great. But now they're stopping you doing your work.

00:40:34 - Orta Therox

Yeah. Did you get anything done?

00:40:35 - Christopher Burns

Yeah. You know, spent all the time on tooling and no time on actually fixing the problem.

00:40:40 - Orta Therox

But that's the thing. If you're in a team with like 20 people, then it becomes worth adding that lint, right?

00:40:46 - Christopher Burns

It's super useful. Exactly. Have you got any more questions, Anthony?

00:40:50 - Anthony Campolo

Oh, plenty. But this has been good so far. Like, I have so much respect for people who put as much time and effort into open source as you do.

00:41:02 - Orta Therox

Thanks, man.

00:41:02 - Anthony Campolo

We were so happy to see you pop up into the Redwood community and to start helping out. And, you know, we have said many times that we're not really TypeScript experts, so even having just a TypeScript expert at all is great, but then having one who really gets open source especially has been awesome. So just thanks for hanging out and contributing in the ways you have. I'm sure it'll be great to just have you around and have you as a source of knowledge to tap, so really appreciate all the stuff you do.

00:41:31 - Christopher Burns

I would say my final question, what's your opinion of Microsoft trying to kind of take over React Native?

00:41:39 - Orta Therox

I don't see it that way at all. I think Microsoft does a really good job of sitting alongside React Native. It's like Expo in some ways. I spent a lot of time with the React Native team, because that was also one of the projects that I took as a dependency and took very seriously. I redesigned their homepage, for example, and implemented their CocoaPods support.

React Native wants to be a lot like how React wants to be, which is they want to be this small integration tool that just sort of adds this virtual DOM thing on top of an existing problem. That's why React DOM is different from React. That's why React VR is different from React. That's why React Native is different from React.

But by doing that, they only try and attack a small, small problem. But in reality, the things that they actually need to attack are often much bigger, right? Like, there's a lot of debate recently from [unclear] that was like React tends to be a library, but if a library influences everything that you do, then it's not a library anymore. It is a framework. And I think that is quite an accurate way to think about it.

React Native tries to not do everything. If you've been using React Native for a long time, you'll know maybe two or three years ago, they started to deprecate a lot of APIs that were inside React Native and moved them out into the community-owned projects. And in part, that was due to the vision of React Native being tightened to be able to support larger projects inside Facebook, but also to allow projects like Expo to take over the responsibilities of handling things like, what does a React Native project look like with notifications? How do we handle webviews? How do we handle navigation?

The project React Native wants to be small and wants to only focus on Android and iOS. But the reality of the situation is everybody else wants to do a lot more. You have Microsoft saying, hey, what would it look like if you could make a React Native app that would run everywhere? Because guess what, Microsoft have React Native inside Office, and guess where Office runs. Everywhere.

[00:43:31] So the question there is like, hey, do we get Facebook to be like, okay, we'll make Windows be a default target inside React Native. And like realistically that's a big sell. And it didn't happen. Canonical added Ubuntu support for React Native at one point.

React Native tries to be this small, focused thing that only focuses on trying to provide React primitives to mobile things, but everyone else is doing so much more around it. And so you have this sort of trifecta of Microsoft providing all these extra platforms, you have Facebook trying to provide this small view library, if you will, and then you have Expo being like, okay, so what do you need to actually make an app next to that?

The three of them together make a very interesting set of platforms. But if you think of like it's competing with something like Flutter, which is a single vendor providing huge amounts of marketing and engineering just with a single vision, then you end up in a very similar sort of perspective as I talked about earlier, which is like JavaScript is a dancing landscape.

[00:44:26] React Native is a dancing landscape, but Flutter is not a dancing landscape because it's a single vision. It's a single person, single, like, this is how it all works, and it works across many different platforms, and you just have to make a tradeoff. Like, do you want to go a bit faster at the tradeoff of living entirely in a Google world? That sometimes is a good tradeoff. Or do you want to be like Office integrating React Native into literally everything, and the only way you can do that is by integrating across many different stacks, using many different tooling baselines.

So yeah, I'd say it's complicated.

00:44:58 - Christopher Burns

I completely agree. I like to put the tinfoil hat on and say within the next five years you won't be using React anymore. You'll be using React Native on the web, on everything. Just React Native everything. And it just builds to everything. And everyone can just be quiet now because JavaScript has taken over everything. You start seeming like that meme with the pins and the wire. Yeah, we're going to get to the point where I will write code once and it will compile on everything.

00:45:27 - Orta Therox

Will compile, but will it be good?

00:45:29 - Christopher Burns

I've obviously looked at React Native. I actually started with React Native, not React. It was this thing where I've never actually touched React Native Web. Well, sorry, I touched React Native Web and I thought, this is interesting. This has legs, you know, but it's not quite there yet. No.

And then I look at React Native for Windows plus macOS. It's like, what is that naming? Because it's not just Windows. It's like Xbox now as well, isn't it? It's like just run it anywhere.

00:45:58 - Orta Therox

Anywhere that Office could run.

00:45:59 - Christopher Burns

Exactly. I honestly think within the next five years, there needs to be a Thanos Gauntlet moment of like, now this is it. This one React component will now run on every platform you could imagine. We're not quite there yet, but I think the tooling is heading in that direction.

00:46:15 - Orta Therox

The idea that the core of React lives inside React Native is something that they have debated internally. I'm not sure if that has won out now, given that React is still so web-focused. I don't see that. I can't see a single platform ever succeeding across everything.

Flutter is the best case for this. It's a single vendor. It goes across all this stuff, but that traps you. The idea of all of these different things is not a trap. Microsoft's supporting Windows is an official API for the platform. It is like on Microsoft Docs, docs.microsoft.com. It is not like the Apple version, which is like, hey, Microsoft are providing one of the main APIs for people to migrate React Native apps. Apple are just like, no, you just take your iPhone app and you put it on your M1 Mac.

Everybody is all trying to compete for developers in very different ways, and I don't think Facebook will ever want to expand bigger than mobile, even though they support Messenger on Windows, which is a React Native Windows and macOS app, but it is still not owned by them.

00:47:15 - Christopher Burns

It's a really interesting landscape because, as I said, will it be the future? Will it not be? It's currently like, you know, if you want to put some Star Wars, you know, you have your inner worlds and your outer worlds of like, you know, your outer worlds. React is like Windows apps and web apps using React Native. And your inner worlds are like just React.

It's a really interesting time. It's going to be exciting to see where it goes. I've really enjoyed having you on to talk about these things.

My final question would be, what would be your absolute favorite open source project? Because as you've said in this episode, you've worked on a lot.

00:47:49 - Orta Therox

Oh, it can't be any of mine, because that's like choosing between your children. Don't want to do that. Honestly, it's a tough one. Although maybe I would actually choose CocoaPods. It is one of the most mundane problems to build a dependency manager, but a dependency manager is the tentpole of an ecosystem. The better your dependency manager, the better the rest of your ecosystem ends up being.

The JavaScript ecosystem was pretty trashy before Yarn came out, and I was lucky to arrive just like six months before Yarn came in and cleaned up a lot of the JavaScript ecosystem.

CocoaPods always was good, and I'm sure everybody feels tension about it because CocoaPods has the same problem as TypeScript, which is that it tries to do everything for everyone, and especially it has no control over the underlying iOS infrastructure because Apple changes it every year. But CocoaPods always tried to do the best job of being an open source first, making sure everybody understood the code that they were integrating.

We built really clever systems to help you understand the dependencies that you were using in ways that no other language has really tried to integrate. And because it was a smaller ecosystem, we could get away with a lot of heavier rules on validation and systems like that. And so I'll still take CocoaPods even though I don't actively work on it so much anymore.

00:49:02 - Christopher Burns

CocoaPods, I remember CocoaPods from my React Native days, is like the more complicated way of integrating extra packages, but it was the way that always worked because Link was a bit interesting.

00:49:14 - Orta Therox

Yeah, Link was complicated. It genuinely took me and the CocoaPods folks at Alloy like ten minutes, sitting down with the React Native team to come up with AutoLink and then like two hours to ship it. And then that became the entire foundation for all of this. The improvements that fixed using Link [unclear]. You could just get away with all sorts of crazy stuff with Ruby. You can't do that with other programming languages. Well, you could do it with JavaScript, I guess, but you can't do it with other programming languages.

00:49:38 - Anthony Campolo

You've got a nice Twitter handle. It is just Orta, so if anyone wants to find you, they can find you there. O r t a. Is there anywhere else on the internet you would want to direct?

00:49:48 - Orta Therox

People now just use Orta for everything. So that search term I have to compete with a lake in Italy, and we follow each other, me and the lake. And I generally tend to beat them.

00:50:27 - Christopher Burns

Have you ever been to the lake, though?

00:50:29 - Orta Therox

I tried. I went to a conference in Italy and it was like four hours away, and I just didn't have eight hours to get there and back.

00:50:37 - Christopher Burns

Maybe next time.

00:50:38 - Orta Therox

Yeah, some JavaScript conference in Italy. Let me know.

00:50:44 - Christopher Burns

Okay.