(De)coding conventions · GitHub Skip to content Navigation Menu Sign in * Platform * AI CODE CREATION * GitHub Copilot Write better code with AI * GitHub Copilot app Direct agents from issue to merge * MCP Registry Integrate external tools * DEVELOPER WORKFLOWS * Actions Automate any workflow * Codespaces Instant dev environments * Issues Plan and track work * Code Review Manage code changes * Code Quality Enforce quality at merge * APPLICATION SECURITY * GitHub Advanced Security Find and fix vulnerabilities * Code security Secure your code as you build * Secret protection Stop leaks before they start * EXPLORE * Why GitHub * Documentation * Blog * Changelog * Marketplace View all features * Solutions * BY COMPANY SIZE * Enterprises * Small and medium teams * Startups * Nonprofits * BY USE CASE * App Modernization * DevSecOps * DevOps * CI/CD * View all use cases * BY INDUSTRY * Healthcare * Financial services * Manufacturing * Government * View all industries View all solutions * Resources * EXPLORE BY TOPIC * AI * Software Development * DevOps * Security * View all topics * EXPLORE BY TYPE * Customer stories * Events & webinars * Ebooks & reports * Business insights * GitHub Skills * SUPPORT & SERVICES * Documentation * Customer support * Community forum * Trust center * Partners View all resources * Open Source * COMMUNITY * GitHub Sponsors Fund open source developers * PROGRAMS * Security Lab * Maintainer Community * GitHub Stars * Archive Program * REPOSITORIES * Topics * Trending * Collections * Enterprise * ENTERPRISE SOLUTIONS * Enterprise platform AI-powered developer platform * AVAILABLE ADD-ONS * GitHub Advanced Security Enterprise-grade security features * Copilot for Business Enterprise-grade AI features * Premium Support Enterprise-grade 24/7 support * Pricing Search / Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert THE README PODCAST // EPISODE 32 (De)coding conventions The evolution of TypeScript and the future of coding conventions, AI’s role in improving accessibility, and practical advice on encouraging non-code contributions. Skip backward Play Skip forward Elapsed time: 00:00 / Total time: 00:00 Download Subscribe: * * * The ReadME Project Open ReadME Project Menu Browse by story type * Featured Articles * Developer Stories * Guides * The ReadMe Podcast Explore Topics See all topics * AI * Application Security * Career Development * DevOps & Automation * Maintainer * Programming * Nominate a developer // * Support the community The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day. * * * The ReadME Project // @GitHub Programming languages are always in flux, and so is the way we use them. In this episode, we dive into the rise of TypeScript, with The ReadME Project’s Senior Editor Mike Melanson outlining its history and evolution. Hosts Neha Batra and Martin Woodward discuss the pros and cons of static typing, and Jordan Harband from TC39 shares his views on the benefits and limitations of TypeScript. We also hear from Aaron Gustafson on AI’s potential to enhance accessibility and the projects leading the charge. And Kingsley Mkpandiok from the CHAOSS Project responds to an #AskRMP submission with tips on encouraging non-code contributions within open source projects. Here’s what’s in store for this episode: * 00:00 - The hosts discuss the challenges of establishing web standards in open source communities when new technologies emerge.  * 02:38 - First Commit: The transformation of the world of stock trading from a chaotic, bustling floor to an automated and computer-driven environment. Our hosts highlight the role of open source, particularly Linux, in powering high-speed trading systems and enabling advancements in performance and speed. * 05:40 - Feature release: The ReadME Project’s Senior Editor, Mike Melanson, discusses the rise of TypeScript and the pros and cons of statically typed languages. * 18:24 - The interview: Aaron Gustafson joins the hosts to discuss the role of AI in improving accessibility. He highlights initiatives such as Microsoft's AI for Accessibility Grant Program, which invests in research and startups to drive innovation in accessibility. * 36:10 - AskRMP: Kingsley Mkpandiok answers a listener’s question on encouraging non-code contributions. The key? Communicate that everyone’s skills matter. Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out: * TypeScript and the dawn of gradual types by Mike Melanson * Advancing inclusion with progressive enhancement by Aaron Gustafson * From fixing computers on farms to democratizing DevOps by Kyler Middleton * Turbulent times call for adaptive leadership by Tramale Turner * Make your first open source contribution in four easy steps by Ruth Ikegah Special thanks to Jordan Harband for sharing his insights on TypeScript, Aaron Gustafson for outlining the role that AI will play in accelerating accessibility, and Kingsley Mkpandiok for answering a listener question about encouraging non-code contributions.   Check-out The ReadME Project for more episodes as well as featured articles, developer stories, helpful guides, and much more! Send your feedback, questions, and ideas to [email protected]. Martin: I say, "GNU." Neha: The animal is gnu, but we also just... I think it's G-NU because we've decided to go with G-NU. It's like the Jif versus GIF thing, so yeah. Okay, cool. Martin: Okay, cool. I'm getting an official pronunciation. Give me one second. Neha: Yeah. Martin: GNU, it is GNU. Neha: I like to imagine it's coming to your brain. Okay, cool. GNU. Martin: GNU is the official pronunciation.  This is The ReadME Podcast, a show dedicated to the topics, trends, stories, and culture in and around the developer community on GitHub. I'm Martin Woodward from the GitHub Developer Relations team. Neha: And I'm Neha Batra from GitHub's Core Productivity team. And Martin, today's words of the day are standardization and automation. Martin: Awesome. Well, I can spell one of those two words, so this is exciting. Neha: I didn't expect you to say that. Martin: That's okay. Neha: I think that goes for both of us. Martin: Yeah. Neha: Regardless, we're going to be taking a closer look at web standards and conventions, and how we come to a consensus around those when a new technology emerges, especially in open source where there are no limits to who your community is, which adds a special layer of complexity around making decisions. And one of the things that we're going to be talking today about is TypeScript, which, Martin, I know you have some history with. Martin: Well, yeah, it was a super small part. The reason Microsoft have an account on GitHub, which I created, was actually for the TypeScript project to open source. And I've got this vivid memory of Anders Hejlsberg and Amanda Silver coming to me and saying, "Hey, we're going to release this new JavaScripty thing. It's going to be amazing. The world's going to adopt it." And I remember coming in, "Yeah, right. Okay, good luck with that." Well, just goes to show, you should never bet against Anders Hejlsberg or Amanda Silver, that's for sure. Neha: I can't believe you created the Microsoft GitHub account. It's like a flex, which I think is totally valid, and I think what's really interesting about that is that things change over time. Now, TypeScript has become pretty ubiquitous and it's the fourth-most popular language in GitHub, and there's still some limitations. We're going to be talking to GitHub's, Mike Melanson, about the rise of static type checkers, the pros and cons, and how the standards could change soon. Martin: Yeah, and we'll also be diving back into how technology is changing, especially for developers with disabilities. This time, AI is playing a role. We'll talk to Aaron Gustafson from Microsoft about all that. Neha: Plus, as always, we'll hear about what is going on at The ReadME Project and get some advice in #AskRMP, but first, first commit. Martin: Picture, if you will, with me, Neha, the world of stock traders. Now, what that probably conjures up is the view of New York Stock Exchange. People crowded, screaming at each other, wearing blazers, and maybe it's like the future's exchange with Eddie Murphy in Trading Places or something like that. Neha: Honestly, in today's day and age, I absolutely cannot imagine it because it sounds nothing but stressful for me. But luckily in actuality, today it sounds a lot more like this. But that makes sense, because over time, the world of financial trading has increasingly left their pocket calculators behind and begun relying more and more on computers and other technology. So as the algorithms advanced, the trading floor got quieter. Martin: Yeah, and actually today, the world of trading is so automated and fast because of the use of powerful computers. These arbitrage opportunities are found and executed in the milliseconds and fractions of milliseconds between trades. So you've guessed it; this requires some pretty powerful computers to take advantage of it. Neha: And in the early 2000s, milliseconds really started to matter. Michael Lewis wrote about this in his book, “Flash Boys,” that organizations were increasingly getting the upper hand in this battle of time with better software and even better physical infrastructure that was slightly closer to the Stock Exchange itself. And we're talking a few feet of cable making the difference. Martin: And the ability of these firms to conduct superfast trades, they owe it, at least in part, to open source. In that same time period, Linux was being quickly adopted by many in the financial sector to power their high-speed trading systems. Because of the system's ability to send messages really quickly, some have even argued that high-frequency trading wouldn't exist without Linux and without open source. Neha: Even today, the New York Stock Exchange, which is the biggest stock market in the world, is run on GNU Linux, and Linux was also beneficial because it allowed these companies to continually improve performance and speed, giving them the upper hand and making the billions. Martin: Of course, there are some downsides to the dependence on fast-moving automated systems like this. We've seen a few times where a small error can actually cause a whole market to dip. Back in 2012, the Knight Capital Group lost around $440 million during a mass sell-off of stocks. That happened by accident because of a proprietary software glitch that got pushed to production. Neha: And while this kind of high-frequency trading has become the standard in markets, people continue to innovate and the technology continues to develop. Today, algorithmic trading accounts for around two-thirds of US equity trading, for example. And with the growth of AI, the speed and power of some of this kind of financial trading will only get bigger. Martin: So Neha, I mentioned it in the intro, but I've been around TypeScript for a little while now, and it's become this really important tool that we all depend on, not just for the systems that we write here at GitHub, but also for a lot of the systems that we're using on the internet today. Neha: Yeah, I feel like TypeScript is something we use a lot at GitHub, and I actually started playing around with it as a developer before I joined GitHub and I really liked it because it brought some order into how we were working and making sure that we were speaking about the same things in the same type of way, especially because we weren't all working as closely together. It allowed us to hand things off to each other in a very effective way. Martin: Yeah. It really excels when you're working in a large team. Some of those static errors kind of show up a lot more when you’re collaborating with interfaces somebody else wrote. We're going to dive a bit more into how TypeScript became so popular and where it goes next. Mike Melanson is joining us. He's the senior editor of The ReadME Project and he's back with us now. Hey, Mike. Mike Melanson: Hey, how's it going, Martin? Martin: It's great to have you here. A lot of people have kind of used TypeScript now. In the last Octoverse Report, it's like the fourth-most popular language on GitHub now, but that's come a long way in a very short period of time. Do you want to give a quick history about some of the background and where this came from? Mike: There's been some swings in paradigms in programming languages over the years, and if you go back to the very beginning, you have Fortran and COBOL, some of the very first languages, and they came out and they were statically typed, and that meant that those languages checked the types, which is Boolean string integer. It checked that the types matched the operations that are being run on them during compiled time. That was the dominant thing for a long time because it helped companies find certain types of errors and do certain things. And then the web came about in the '90s and we had JavaScript show up. We had Python, PHP, Perl, Ruby, all these different languages, all dynamic, where the checking happened at runtime. Also, the time of Agile happened. And so like Facebook said at the time, "Move fast and break things," these were the languages where you could move fast and you might break things, but you were moving fast at least, right? Neha: For sure, yeah. Mike: Yeah. But then companies like Google tried to make maps and docs in JavaScript, and Microsoft realized early on that they were going to have to bring the Microsoft Office suite to the web, and when they realized that and that they would have to use JavaScript to do it because that was the language of the web by then, they said basically, "No way. We're going to have to find a better way to do this," and they built TypeScript. Martin: I think that's always amazing to me, the computer science that happens to solve internal engineering problems at companies. It's a lot of the reason why we have things like codespaces and some of the things on GitHub is to solve our own problems. Neha, you were actually using this back in the day. Did you find that it was helping you resolve a whole set of issues when you were coding in TypeScript versus just raw JavaScript? Neha: I did. So to put myself out there a bit, when I was working at Pivotal and we were working with different companies and trying to basically make sure that on day two and three we were picking the right languages and frameworks that would work with these teams, we were pairing together, but we would just completely merge to main. We wouldn't actually have to do a code review or any of that formal processes. So when it comes to making sure that we are all working in a similar manner and we're able to understand each other's work, as you're picking up someone else's work that just got merged in maybe an hour before, either you had to have really strong similarities in coding styles, or with TypeScript and other things, you could easily place it into the languages of preference and the languages of familiarity, but you could scale a lot more because now all of a sudden, we can see what the types are, we can check our work a little bit better, and we're not spending as much time debugging and QAing the system because it's right from the beginning. And I think there's something really interesting here. As Mike said, you have to move fast and break things. We wanted progress and then we wanted scale. And if you want scale, you need some constraints and order to make that scale happen. It was the biggest criticism of JavaScript was not having types and not being able to scale beyond a certain level and needing to adapt something else, but now you didn't have to. Mike: And one of the things about TypeScript is that it helped do that, but without going all the way back to the Java and the C++. You didn't have to write all that boilerplate code and the big interfaces and think all just in abstractions. You could still have that sort of self-documenting feature that you're essentially talking about and all those other things, but not go back to what some people at that time saw as the dark ages. Martin: Well, I'd say some people were quite skeptical about this at the time. There was a reason why we created dynamically typed languages, or dynamic languages, to be fast. So everybody can't be a fan of doing it this way, are they? Mike: No, not necessarily. I talked to Jordan Harband about this, and he's a member of TC39, which is the committee that determines ECMAScript, the standard behind JavaScript. And he definitely acknowledges the benefits of type systems, but he also says that types can essentially become a crutch that you rely on in place of doing proper testing on your code. Martin: Yeah, just because you are type-safe doesn't mean you are safe from bugs. I have plenty of bugs in my TypeScript code. Mike: Yeah, for sure. Types help you find them during development. You have a tighter feedback loop often, but things still slip past. Here are some of the downsides Jordan told me about.  Jordan Harband: The cons of a type system, I think, are less objective and less broadly understood or agreed upon. TypeScript is not a superset of JavaScript. It does not have the capability to fully represent JavaScript semantics. You can have programs that type check that still throw type errors, and you can have programs that TypeScript complains