Have you looked at the latest GitHub Octoverse rankings lately? It is actually wild to see the shift. For years, we have seen this steady climb, but the numbers coming out of early twenty twenty-six are just staggering. Today is prompt from Daniel is about TypeScript and its massive rise, especially in this AI-driven landscape. It seems like everywhere you look, people are saying TypeScript has officially won the war for the web. In fact, the February twenty twenty-six State of JavaScript survey just came out, and the headline was literally four words: TypeScript has won.
Herman Poppleberry here, and I have been staring at those charts for days. It is not just a small lead anymore. We saw TypeScript overtake both Python and JavaScript to become the number one most-used language on GitHub back in August twenty twenty-five. When you think about the sheer volume of code being pushed to repositories every single day, that is a seismic shift in the industry. We are talking about over sixty million downloads of the compiler every single week now. That is a three-fold increase from where we were just four or five years ago.
It really is a massive number. And it is a bit of a paradox, right? Because TypeScript doesn't actually run anywhere. You can't just give a TypeScript file to a browser like Chrome or Safari and expect it to work. It has to be turned back into JavaScript before it can do anything. So why are sixty million people downloading the compiler every single week? Why add that extra step of complexity if the end result is just the same old JavaScript we have had for decades?
That is the big question. To understand why we are here, you have to go back to October twenty twelve. That was when Microsoft first released version zero point eight. It was created by Anders Hejlsberg, who is basically a legend in the world of programming languages. He created Turbo Pascal and C-Sharp before he turned his attention to the mess that was JavaScript in the early twenty-tens. At the time, Microsoft was trying to build massive web-based tools like Visual Studio Code and the Azure portal. They realized that JavaScript, in its raw form, simply didn't scale for teams of hundreds of developers.
I remember those days. JavaScript was the wild west. It was great for making a button change color or showing a pop-up, but once you started building massive applications with hundreds of thousands of lines of code, things just fell apart. You would change a variable name on line fifty and break something on line five thousand, and you wouldn't know until the user clicked a button and the whole site crashed. There was no safety net.
Microsoft saw that coming a mile away. JavaScript is a dynamically typed language, which means it is very flexible but also very dangerous because the computer doesn't know what kind of data is in a variable until the code is actually running. Anders Hejlsberg wanted to add a safety layer on top without replacing JavaScript entirely. That is why we call it a superset. It is not a different language as much as it is JavaScript with a set of glasses on so it can actually see what it is doing.
Right, so if you have a valid JavaScript file, you can just change the extension to dot T-S and it is technically valid TypeScript. But Daniel pointed something out in his prompt that I think we need to clarify. He mentioned TypeScript becoming one of the most popular languages for AI development alongside Python. Now, when I think of AI, I think of Python, PyTorch, and training massive models. Is TypeScript really competing in that space now?
That is a really important distinction to make, and it is one of the biggest misconceptions in the industry right now. If we are talking about training a large language model from scratch or building complex neural networks, Python is still the undisputed king. It has the libraries, the data science ecosystem, and the low-level integrations that you just don't have in the JavaScript world yet. But what we are seeing in twenty twenty-six is the rise of the AI application layer.
You mean the stuff that actually talks to the models? The interfaces and the logic that connects the AI to the user?
Most of the AI work being done today isn't training models; it is orchestrating them. If you are building an AI-powered dashboard, a chatbot interface, or a complex agent system that needs to call multiple APIs, handle user data, and manage state, you are likely doing that in TypeScript. Tools like the Vercel AI Software Development Kit or LangChain dot J-S have made TypeScript the primary choice for the glue that holds AI applications together. It is about the infrastructure surrounding the model, not the model itself.
I have noticed that with coding assistants too. If I am using something like Cursor or GitHub Copilot, the suggestions I get in TypeScript are often way more accurate than what I get in plain JavaScript. Is that just my imagination?
No, there is a very specific technical reason for that. Because TypeScript has a formal type system, the AI has a set of rules it has to follow. It knows that if a function says it returns a string, it can't suggest code that treats the result like a number. The types act as guardrails for the Large Language Model. It is much easier for an AI to write code when the codebase itself provides a structured map of how everything is supposed to connect. We are seeing a symbiotic relationship where TypeScript makes AI better at coding, and AI makes it easier for developers to write complex TypeScript.
That makes sense. It is like giving the AI a blueprint instead of just a pile of bricks. But let's talk about the friction. Daniel asked why TypeScript often feels so finicky to work with. I have felt this myself. You spend twenty minutes trying to explain to the compiler that yes, this variable will definitely exist at this moment, and it keeps yelling at you with those red squiggly lines. It feels like you are fighting the tool instead of building the product. Why is it so pedantic?
That frustration usually comes from a misunderstanding of how the type system actually works. TypeScript uses what we call structural typing. In most older languages like Java or C-Sharp, typing is nominal. That means if you have two things that look the same but have different names, the computer thinks they are different. In TypeScript, it is all about the shape. If an object has the required properties, it fits the type. It is essentially the duck test: if it walks like a duck and quacks like a duck, TypeScript says it is a duck.
But sometimes it is not a duck, Herman. Sometimes it is a piece of data coming back from an external API that promised it would be a duck but ended up being a null value or an error message. And that is where the finicky feeling comes in, right? The compiler says everything is fine because the types look good on paper, but then the app crashes in the browser.
That is the Great Divide. TypeScript only provides compile-time safety. It is a check that happens while you are writing the code. Once that code is turned into JavaScript and sent to a user, the type system is gone. It is completely erased. So if your API sends back something unexpected, TypeScript can't save you at runtime. Many developers feel the friction because they are trying to use TypeScript to solve runtime problems, but the tool is designed to solve architectural problems. You are essentially building a contract, but if the other party—the API or the user—breaks that contract, the compiler isn't there to stop the crash.
It is like a false sense of security. You see no red lines in your editor and you think, okay, this code is bulletproof. But you are only as safe as your definitions are accurate. And that brings up the infamous any keyword. I have seen projects where half the variables are typed as any just to get the red squiggly lines to go away. It feels like cheating.
The any keyword is the ultimate escape hatch. It basically tells TypeScript to stop looking at that variable and let you do whatever you want. It is a necessary evil for migrating old projects, but it is a massive technical debt bomb. If you use any, you are essentially opting out of the very thing you are paying for with the extra build step. In twenty twenty-six, we are seeing a lot of teams moving toward strict mode by default to avoid this.
Which is funny because many people don't realize that when you start a new TypeScript project, the strictest checks are often turned off by default for compatibility reasons. You have to go into your T-S config file and manually turn on things like strict null checks or no implicit any. If you don't do that, you are basically playing TypeScript on easy mode, and you are going to run into those undefined is not a function errors that the language was supposed to prevent.
It is a bit like wearing a seatbelt but not clicking it into the buckle. It looks like you are safe, but it won't help you in a crash. The real power of the language comes when you embrace the complexity. For example, using Discriminated Unions. This is a pattern where you define a type that can be one of several things, and TypeScript is smart enough to know which one it is based on a specific property. It allows you to model complex business logic in a way that plain JavaScript simply cannot.
I think one reason it feels finicky is that the community is still catching up. We mentioned that eighty percent of the top one hundred packages on the Node Package Manager now ship with their own types. But for the other twenty percent, or for older libraries, you have to rely on DefinitelyTyped. That is the massive community project that maintains type definitions for libraries that don't have them.
DefinitelyTyped is probably one of the most important open-source projects in history that nobody outside of tech has ever heard of. It is thousands of developers volunteering their time to write type definitions for other people's code. Without it, TypeScript would have died years ago. But because it is community-maintained, sometimes those types are wrong or outdated, and that is another source of that finicky feeling. You are fighting a type definition that someone else wrote three years ago that doesn't match the current version of the library you are using.
Let's look at the broader landscape for a second. If TypeScript has won the web, does that mean JavaScript is going away? Or are we going to see a world where they eventually merge? There has been talk about adding type annotations to the ECMAScript standard, which is the official specification for JavaScript.
There is a proposal for that, but it is not what people think. The goal isn't to make JavaScript a compiled language like TypeScript. The goal is to allow browsers to ignore type annotations. Basically, you could leave your types in the code, and the browser would just skip over them instead of throwing a syntax error. This would eliminate the need for a build step for a lot of people. You could write TypeScript-ish code and run it directly in Chrome.
That would be a game changer for smaller projects. It would lower the barrier to entry significantly. But for now, we are stuck with the transpilation step. And honestly, with how fast our computers and build tools like Vite have become, that step is almost invisible. It used to take thirty seconds to compile a project; now it happens in milliseconds.
It is almost instantaneous now. And the benefits for the ecosystem are just too big to ignore. Think about the geopolitical angle for a second. Most of the world's critical infrastructure now runs on web technologies. Having a standardized, type-safe way to build that software is a matter of national security and economic stability. It is no surprise that American companies like Microsoft and Google have poured so much money into making TypeScript the industry standard. It makes software more reliable and developers more productive.
It also makes it easier to hire. If you tell a developer in twenty twenty-six that they have to work in a large plain JavaScript codebase, they are going to look at you like you asked them to write code on a typewriter. It has become the expected baseline for professional development. If you are not using types, you are basically saying you don't care about the long-term maintainability of your project.
And that brings us back to Daniel's point about AI. If you are a developer today, you are likely using an AI coding assistant. Those assistants are trained on the massive amount of TypeScript code on GitHub. Because TypeScript is so prevalent, the AI has become an expert in it. We are in this feedback loop where the popularity of TypeScript makes AI better at writing it, and the AI makes TypeScript the path of least resistance for new projects because the generated code is so much more reliable.
It is a fascinating cycle. But I want to go back to the idea of TypeScript as the glue for AI. We did an episode a while back, episode ten twenty-one, where we talked about Python being the accidental king of AI. And I think the contrast there is really sharp. Python is great for the heavy lifting, the math, the tensors, the actual training of the weights. But when you need to handle ten thousand concurrent web socket connections and update a user interface in real-time while calling an LLM API, Python starts to struggle. That is where the asynchronous nature of the JavaScript runtime and the safety of TypeScript really shine.
That is exactly where the industry has settled. We are seeing this two-tier architecture. The heavy AI models live in a Python environment, often running on specialized hardware or in a containerized backend. But the application logic, the agents, the API gateways, and the user-facing systems are all TypeScript. It is the perfect division of labor. Python handles the intelligence; TypeScript handles the execution and the user experience.
So, for the listeners who are currently struggling with those red squiggly lines, what is the takeaway? How do they stop fighting the tool and start using it effectively?
The first step is to stop using type assertions. When you see a developer write as SomeType, they are usually lying to the compiler. They are saying, trust me, I know what I am doing. But usually, they don't. Instead of telling TypeScript what the data is, you should be proving it. Use type guards. Write a small function that checks if the data has the properties you expect at runtime. This satisfies the compiler and makes your app more stable. It turns that finicky feeling into a conversation with the code.
I also think there is a lot of value in looking at how TypeScript and JSON Schema are converging. We talked about this in episode eight seventy-four. When you define your data structures clearly using something like Zod or JSON Schema, you can generate your TypeScript types automatically. This bridges that gap between the network and the code. It takes away the guesswork and the manual labor of writing interfaces for every single API response.
That is the future. We are moving toward a world where types aren't something you write manually for every variable, but something that flows through your entire stack, from the database to the AI model to the frontend. TypeScript is the language that made that vision possible. It provided the common vocabulary for us to describe data as it moves through complex systems. If you embrace the strictness, the tool stops being an obstacle and starts being a collaborator.
It is basically the boring technology that makes the exciting AI stuff actually work in production. You can have the most brilliant AI model in the world, but if your application crashes every time a user enters a special character or an API returns an unexpected field, nobody is going to use it. TypeScript is the discipline that the web needed to grow up. It is the transition from the experimental phase of the internet to the industrial phase.
It is the maturity phase. We spent twenty years building things as fast as we could with whatever tools were lying around. Now, we are building infrastructure that the world relies on for banking, healthcare, and communication, and we need the precision that a type system provides. Anders Hejlsberg really did see the future back in twenty twelve. He knew that the web would eventually become the primary platform for all software, and he gave us the tools to handle that scale.
It is impressive that he is still involved in the project too. You don't often see the original architect of a language still pushing commits and doing interviews fourteen years later. He gave a great interview to the GitHub blog late last year where he talked about how the rise of AI actually validated the design choices they made over a decade ago.
He has a very pragmatic approach. He doesn't try to make TypeScript a perfect academic language like Haskell or OCaml. He makes it a useful tool for working programmers. That pragmatism is why it won. It met developers where they were, instead of demanding they change everything about how they work. It allowed for a gradual migration, which is the only way you can change an entire industry's habits.
Well, I think we have covered the why and the how. TypeScript isn't just a trend; it is the foundation of the modern web. Whether you find it finicky or not, it is the environment we are all living in now. And with the way AI is evolving, that type-safe foundation is only going to become more important as we let machines write more of our code.
I agree. It is the guardrail that keeps the AI from driving the car off the cliff. As we move toward more autonomous agents and self-healing code, having a rigid, verifiable type system is the only way we are going to be able to maintain any kind of oversight over what these systems are actually doing.
On that note, I think it is time to wrap this one up. It is a big topic, and honestly, we could probably spend five hours just talking about the nuances of the T-S config file or the difference between interfaces and types, but I don't think anyone wants to hear that today.
Probably not. But for those who do want to go deeper, checking out the documentation on structural versus nominal typing is a great place to start. It really changes how you think about your code. Once you understand that TypeScript cares about the shape, not the name, everything starts to click.
Thanks as always to our producer, Hilbert Flumingtop, for keeping the gears turning behind the scenes. And a big thanks to Modal for providing the GPU credits that power this show and our research. This has been My Weird Prompts. If you want to keep up with the show and get notified as soon as a new episode drops, search for My Weird Prompts on Telegram. We post all our updates and extra resources there.
It was a pleasure as always. TypeScript is a deep rabbit hole, but it is one worth falling down if you want to build anything meaningful in twenty twenty-six.
See you in the next one.
Goodbye.
