JavaScript Jam Live with Josh Goldberg

Episode Description

JavaScript Jam Live hosts Josh Goldberg to discuss TypeScript's rise, open source sustainability, and the future of typed JavaScript development.

Episode Summary

This JavaScript Jam Live episode features Josh Goldberg, full-time open source maintainer of TypeScript ESLint, alongside hosts Anthony Campolo and Ishan Anand, with contributions from several community members including Theo, Eric, Jason, and Dev. The conversation opens with Josh explaining his path to full-time open source work and the financial challenges of sustaining it, drawing an analogy between corporate open source funding and environmental responsibility — arguing that targeting companies rather than individual consumers is the key to solving the funding gap. The discussion then shifts to TypeScript's origins, why it was created to add intent documentation to JavaScript, and why it generates controversy despite its clear benefits. Contributors share personal experiences converting codebases and debating when TypeScript is worth adopting, with Josh suggesting a "rule of three" — three developers or three files — as a threshold. The group explores how libraries like Zod and TRPC leverage TypeScript's type system to move complexity away from app developers, and Theo explains the Create T3 App project that bundles these tools together. Later segments cover TypeScript's relationship with Flow, Microsoft's growing influence over the JavaScript ecosystem, object-oriented versus functional programming, decorators reaching TC39 stage three, and the exciting types-as-comments proposal that could eventually let browsers read TypeScript syntax natively without transpilation.

Chapters

00:00:00 - Twitter Spaces Troubles and Introductions

The episode kicks off with Anthony Campolo recounting his struggle to launch the Twitter Space, which got stuck in an infinite loop that required canceling and restarting. Ishan Anand jokes about being trapped in the "multiverse of Twitter Space Madness" before welcoming listeners and explaining the JavaScript Jam Live format as an open mic for JavaScript and web development topics.

Ishan introduces the show's format and notes that today's guest is Josh Goldberg, who recently collaborated on a TypeScript crash course video. Anthony briefly introduces himself as a developer advocate at Edgio before handing the floor to Josh, who describes himself as a full-time open source maintainer working primarily on TypeScript ESLint and the author of the book Learning TypeScript.

00:04:15 - Becoming a Full-Time Open Source Maintainer

Josh explains his journey to full-time open source work, noting it's simultaneously easier and harder than expected — easier because there's no certification required, harder because building enough experience and reputation takes years. He recommends gaining industry experience while contributing to open source on the side, then eventually transitioning if the passion is there.

The conversation turns to the financial realities of open source maintenance. Josh describes how he launched without much funding lined up and has been working to build sponsorships through GitHub Sponsors and direct outreach to companies. He candidly shares that he only recently hit federal minimum wage and still hasn't reached a living wage, highlighting how difficult it is to convince people and companies to financially support the tools they depend on daily.

00:08:29 - Open Source Sustainability and Corporate Responsibility

Ishan raises the broader question of open source monetization, referencing the Heartbleed SSL vulnerability maintained by just two people and Gatsby's recent acquisition by Netlify. Josh draws a compelling analogy between open source funding and environmental responsibility, comparing individual contributions to paper straws — well-intentioned but insufficient compared to what corporations could contribute at scale.

Josh introduces the Open Contributions Project he's building with Rizal Scarlett from GitHub, aimed at creating explainer materials for CTOs, CMOs, and other corporate decision-makers about why funding open source matters. The goal is to bridge the gap between engineers who understand open source's value and the business leaders who control budgets, providing data-backed arguments and practical guides for convincing companies to contribute financially.

00:14:33 - Brief Web3 Detour and Transition to TypeScript

A brief tangent emerges when Ishan asks about blockchain-based solutions for open source funding. Anthony quickly interjects that Ethereum itself is a massively funded open source project, while Josh diplomatically acknowledges blockchain's potential but expresses skepticism about current applications, noting the difficulty of wading through hype to find substance.

The hosts steer the conversation back to TypeScript, with Jason from the audience sharing his own recent conversion from JavaScript skeptic to TypeScript advocate after months of dedicated learning. Ishan reinforces TypeScript's dominance by citing the State of JavaScript and Jamstack surveys, where TypeScript stood out as both widely popular and universally loved among developers.

00:19:22 - Why TypeScript Exists and Why It's Controversial

Jen asks Josh to explain why TypeScript was created and why it took so long for widespread adoption. Josh explains that JavaScript lacks tools for describing developer intent — while you can define values and functions, you can't express what types those values should be. TypeScript fills that gap by adding type annotations that enable powerful development tooling like go-to-definition and automated refactoring.

Josh then addresses the controversy, attributing it partly to the natural resistance programmers have toward learning new things and partly to TypeScript's inherent complexity — because JavaScript allows wild and unusual patterns, TypeScript's type system must be equally complex to represent them. He notes the ideological tension between developers from strongly-typed backgrounds like Java who want runtime type checking and those from dynamic languages like Python and Ruby who resist adding types at all.

00:24:23 - Flow vs. TypeScript and Microsoft's Role

Eric shares a personal anecdote about choosing Flow over TypeScript for a library years ago, and the group discusses why Flow ultimately lost the competition. Josh compares Flow to Windows Phone — technically impressive in some ways but lacking the community support needed to sustain momentum. Eric notes that Facebook maintained Flow internally but didn't invest in the open source community the way Microsoft invested in TypeScript.

The discussion broadens to Microsoft's growing dominance over the JavaScript ecosystem, with Eric listing their ownership of GitHub, npm, VS Code, Copilot, TypeScript, and Playwright. Josh responds philosophically, suggesting that all major tech companies are fundamentally money-oriented rather than good or evil, and that the best we can hope for is companies that have learned from past mistakes and currently have good leadership.

00:36:08 - When to Use TypeScript and the CFO Perspective

Josh offers his "rule of three" guideline: if you have at least three developers or three files, TypeScript is probably worth adopting. He outlines the cons — learning curve, added conceptual complexity, and build chain overhead — against the pros of better tooling, bug catching, documentation standards, and even recruitment appeal. He emphasizes that the pros far outweigh the cons in almost every scenario involving long-term projects or team collaboration.

Theo joins to push an even stronger stance, arguing that TypeScript makes developers faster even in competitive programming contexts. The conversation shifts to a CFO-friendly framing, with Josh estimating that teams he's converted typically break even on productivity within about a month. Theo adds that having an internal TypeScript advocate dramatically accelerates adoption and that leadership buying into their engineering team's beliefs — even without fully understanding them — builds trust that pays dividends beyond the specific technology choice.

00:45:27 - TypeScript in Practice: Libraries, TRPC, Zod, and Create T3 App

Jason and the group discuss the distinction between writing TypeScript for applications versus libraries, with Josh explaining that library code often requires advanced generics and type system manipulation that can be intimidating. Theo provides concise explanations of Zod as a validation library that produces precise types from runtime checks, and TRPC as a tool for building type-safe APIs where server functions can be called from the client with full type inference.

Theo then explains the origin of Create T3 App, which started when his community asked for a template of his recommended tech stack. A contributor named Nexle — reportedly a teenager — built the initial version, which assembles a full-stack TypeScript project from selected technologies. The project grew rapidly to over 170 contributors in six months, and Anthony notes how it served as a learning tool by giving developers a sophisticated but usable stack they could explore and eventually understand deeply.

00:53:59 - Design Systems, Type Safety, and Advanced TypeScript Features

Josh highlights design systems as an underappreciated area where TypeScript's type safety shines, describing Codecademy's open source Gamut library where CSS-in-JS props are type-checked and responsive. The conversation turns to wished-for TypeScript features, with Josh advocating for dependent types that would let the type system understand how values change over time, and a Type Relations API that would enable more powerful lint rules.

Josh introduces the Ezno project, a Rust-based TypeScript alternative that implements dependent typing and effect tracking, where the type system can infer that adding one to three returns four, or that calling a function modifies an object's properties. While uncertain whether Ezno specifically will succeed, Josh sees it as pointing toward TypeScript's future direction — a faster, more powerful type system that understands code behavior at a deeper level.

01:05:01 - OOP vs. Functional Programming and Decorators

Dev joins the conversation and asks about everyone's most-wanted TypeScript feature, sharing his own desire for typed error handling similar to Java's checked exceptions. Josh pushes back, explaining that typed throws are fundamentally impossible to get right because any function can throw unexpected errors, making the only honest annotation the "any" type. The group discusses returning errors as union types instead of throwing them as a more architecturally sound approach.

Hacksor raises the question of object-oriented programming with TypeScript, and Josh clarifies that the OOP versus functional choice is orthogonal to TypeScript adoption. The discussion moves to decorators, which recently reached TC39 stage three, meaning the JavaScript community is encouraged to start experimenting with them. Josh explains that TypeScript 5's beta supports the new standard decorators, which are incompatible with the older experimental decorators that Angular popularized, and Dev notes limitations around decorators' inability to contribute to static type inference.

01:24:08 - Types as Comments, Pipeline Operator, and Closing Thoughts

Josh explains the exciting TC39 proposal for optional type annotations in JavaScript, sometimes called "types as comments," which would let browsers and engines read TypeScript-like syntax natively without requiring transpilation. He clarifies this wouldn't add type checking to JavaScript itself but would eliminate the build step for development workflows. Dev draws a parallel to how native ES modules revolutionized development servers through tools like Vite, suggesting this could have a similarly transformative effect.

The episode wraps with Josh noting the proposal is only at stage one, so changes won't arrive for years. He shares where listeners can find his work — his GitHub, Mastodon, Twitter, Twitch, and website all under Joshua K. Goldberg — and encourages TypeScript users to try and sponsor TypeScript ESLint. Dev plugs his YouTube channel and upcoming video on Domain Driven Design, and Anthony thanks everyone for participating in another lively JavaScript Jam Live session.

Transcript

00:00:22 - Anthony Campolo

Oh my God. Twitter Spaces, man. The worst. Just the worst. All right, let's bring some people up here. Thank you, everyone, for your patience. So when the app tells you, "Click this to start the Space," they actually mean, "Don't do this, because it'll break everything." You just need to go into the Spaces part and start it through there instead of doing it the way they suggest. Because the way they suggest you do it actually just breaks everything, and then you have to cancel it and start a new one. Now I know. What's up, Josh?

00:01:01 - Josh Goldberg

I got all worried when I saw the cancelation.

00:01:05 - Anthony Campolo

Yes. For some reason, it got caught in an infinite loop where I tried to start it, and it put me into a Space by myself, and no one else could see that it was on. And then when I got out of it and tried to start the Space through a different part in the UI, it was like, "Can't start the Space." And so the Space is just locked. And I'm like, all right, I guess I have to cancel it and make another one.

00:01:27 - Ishan Anand

You were trapped in the multiverse of Twitter Space Madness.

00:01:31 - Anthony Campolo

Yeah. Twitter Space is the buggiest app I've ever used in my entire life. It's kind of maddening.

00:01:38 - Ishan Anand

Well, they're going through some pains right now.

00:01:41 - Anthony Campolo

It was like this before, so that's.

00:01:44 - Ishan Anand

Yeah, that's true. Well, welcome, Josh. Welcome, everyone, to JavaScript Jam Live. As we're getting people in here, there are a bunch of people I saw who set the reminder. Hopefully they'll know to go check and see if we got the other one. If they set a reminder on that one, I think we've lost them, but hopefully they'll come back to the profile and see. For those just tuning in, JavaScript Jam Live is what we like to call an open mic for anything JavaScript- and web-development-related. Anything that's in those two buckets is on topic. And whether you're a beginner or an expert, we want to hear from you. We like to be audience-driven as much as possible, but sometimes we do invite a guest onto the Space to help educate us all on a particular topic and co-host along with us. That guest today is Josh, who worked with us on a TypeScript video that you can see. It's a crash course on TypeScript. But before we get to that, and before I let him introduce himself, I will turn it over to Anthony, my co-host, to introduce himself.

00:03:00 - Josh Goldberg

Hello.

00:03:00 - Anthony Campolo

Hello. My name is Anthony Campolo. I am a developer advocate at Edgio. Super excited to have Josh here with us. We just dropped a crash course with him about a week or two ago, so if you check out our... let me actually pin that. So yeah, go ahead and introduce yourself.

00:03:21 - Josh Goldberg

Super. Thanks for having me. Hi, everyone. I'm Josh Goldberg. I'm a full-time open source maintainer. I work on a few projects, most notably TypeScript ESLint, the tooling that lets you run ESLint and Prettier on TypeScript code. I'm also really passionate about TypeScript and generally writing JavaScript.

00:03:38 - Ishan Anand

Good.

00:03:39 - Josh Goldberg

I wrote a book, Learning TypeScript, and have been doing conferences and such, trying to evangelize both TypeScript and good TypeScript practices. So I'm excited to be here, both for the new folks who don't know TypeScript at all, all the way up to the folks who are going to scream at me about function return type inference or whatever other anger is on

00:03:56 - Anthony Campolo

Twitter these days. We're going to put that off limits for this one.

00:04:02 - Josh Goldberg

probably good.

00:04:05 - Anthony Campolo

Unless you really have a strong opinion on it.

00:04:08 - Josh Goldberg

I think the stronger my opinion, the less likely we should really consider talking about it.

00:04:15 - Anthony Campolo

So, quick question. How did you become a full-time open source person?

00:04:23 - Josh Goldberg

It's actually a lot easier and a lot harder than you'd think. It's a lot easier because there's no certification or company that you have to go through. I just quit my job and said, okay, I'm doing this now. But it's also harder because it's not something you can, I think, be very successful at out of the blue. You have to learn a lot about open source. You have to, I think, gain experience working in it. You can do it on the job, so to speak, but it's a lot easier to do open source full-time, like to really make an impact, if you have a lot of experience with it. So I took the path that I recommend to most, but not all, people, which is: get a job in industry, be supported by your mentor or manager, et cetera, at work, and at the same time, ideally in the job. If not, and if possible, maybe on your own time, do stuff in open source land, which will gain you experience there as well. And then eventually, if you really, really like open source, you can do it. I will also note that there are a lot of lessons and learnings that make open source a lot easier and better once you know them.

00:05:23 - Josh Goldberg

Things like how to effectively communicate even though you don't know anything about the people, and how to make good documentation when you have no time to do anything. We can get into that more if you really want.

00:05:37 - Ishan Anand

Yeah, I think that's actually really fascinating for the audience. But I'm curious: when you made that transition, did you effectively have Patreons lined up? How did you, you know... and what's kind of supporting you as an open source maintainer right now?

00:05:54 - Josh Goldberg

I did not have very much funding lined up. I had a few people sponsoring me on GitHub Sponsors, and the project that I intended on, and now still do work on a lot, TypeScript ESLint, had some amount of sponsorship, a lot from companies and people. But I think part of being an open source maintainer is evangelizing for yourself, getting yourself out there, posting on Twitter, Twitch, Mastodon, whatever your platform or platforms are. Because people aren't going to pay you money unless they know who you are and are convinced that you are worth it. It's kind of like the App Store scenario where we're willing to spend $600 on a phone, but $5 for an app? Get out of here. It's really hard to convince people to sponsor folks.

00:06:39 - Anthony Campolo

Yeah. So how do you convince people you're worth it? That seems like the key question.

00:06:44 - Josh Goldberg

Oh, it's a good question. It's a hard one.

00:06:47 - Anthony Campolo

I think for you it's just by being awesome and doing it consistently and in public for a while.

00:06:51 - Josh Goldberg

I would guess that's only part of it. And I mean, my self-deprecating instinct is to disagree with the awesome part, but I'll let that slide. Thank you. Doing it in public is key so that people can see what you're doing. This year I'm going to be trying to get better at posting the big stuff I do on Twitter and Mastodon, constantly reminding people in good ways and annoying ways that I should be paid. Like on typescript-eslint.io, we have our list of sponsors. A lot of those came because we just asked the company if they could sponsor us. And I don't know about you or y'all, but I personally hate asking for money. That was something that took me a lot of time and energy to get comfortable doing, and I'm still not really comfortable. But also part of, I think, the drive for getting people to pay me is I need to get my name out there a lot. I can work all on one project, but then only people who use that project deeply will know about me. And if it's a project like TypeScript ESLint that isn't super user-facing, like it's not TRPC where it's a core part of your stack you can't live without,

00:07:57 - Josh Goldberg

it's like a nice developer-focused thing. It can be hard to fundraise for that. So I'm trying to also get my name out there by contributing to and/or making other smaller packages that various other people might also care about. I don't know, though. I've been doing this barely a year, really less than a year. So I'm still new to this, and I still like to say that although I hit minimum wage, federally mandated minimum wage, in December, I still haven't hit a minimum living wage. So, you know, more learnings to come.

00:08:29 - Ishan Anand

It's actually a really important topic, I think, not just for you personally, but for the whole ecosystem, because we depend so much on open source technologies collectively. Anybody who uses something online... I remember when SSL had that bug in it, and it was like it was just two people who were maintaining it and hadn't realized that bug was there for the longest time. And even last week there was the news of Gatsby being acquired by Netlify, and we had the CEO of Netlify on last week's episode. If you want, you can go to our website, javascriptjam.com, and check it out and listen. But one of the key topics and immediate things that jumped to mind was, what does this mean for the possible monetization models for open source frameworks? Gatsby kind of tried that model in their case. They're building a popular framework and trying to monetize it as a cloud platform, but there's stuff where that doesn't make sense. So what is the right monetization model? Do you have other thoughts on that broader topic?

00:09:42 - Josh Goldberg

I do, and I think you really hit the nail on the head there. And I appreciate the way you phrased it. Some products are reasonable to monetize. I think we've seen this with the three most popular, or at least most mindshare-y, frameworks for React sites: Vercel owning Next.js, Remix getting bought by Shopify, and now, yeah, Gatsby getting bought by Netlify. You can't easily monetize those frameworks directly, but they're really well positioned with the hosting platform.

00:10:09 - Ishan Anand

Right.

00:10:10 - Josh Goldberg

But you couldn't monetize, say, TypeScript or TypeScript ESLint. TypeScript is sort of monetized in that it works really well with VS Code, and Microsoft then gets a lot of advertising space because VS Code and TypeScript are so integrated. It's not like you're going to be paying for a TypeScript deploy platform. And I have yet to see any way that you could possibly monetize ESLint or TypeScript ESLint. It's just not doable. People would never pay for this thing. There are services you could build on top of us, but not the core products. So I think the root of the issue is, yeah, it's a real problem in the industry, like a real problem. And what's amazing to me is that this is a great example of the difference between something that companies should do and something that companies need to do. Even after all these horrible security things came out, like Heartbleed, the security bug, most companies did not do anything. They didn't significantly change their stance at all because there is no need for them to. If you're a huge name like Microsoft or Apple, then yeah, people put pressure on you.

00:11:15 - Josh Goldberg

You have a responsibility. But if you're, like, a mid-sized company, maybe you're in tech, maybe you just happen to be a tech company because all companies now are tech, but that's not your core product, why would you, say, contribute to SSL or TypeScript or whatnot? There's no actual pressure. So one thing that I'm trying to do is I'm starting this project with a few people online, mostly Rizal Scarlett from GitHub. It's called the Open Contributions Project. Super early stage. I'm not asking people to go and contribute or take action now, but we're trying to figure out: how can we explain open source in terms that people who aren't already convinced about open source can get behind? How do we make explainers for, like, a CTO, a chief marketing officer, a chief whatever, a finance person? And then how can we write guides to say, let's say you're an IC and you want to convince your company to give $200 a month to some project, how would you go about doing that? And I think the reason why I'm excited about this, and going to be tackling this in the next year or two, is because I think that's a gap in the industry.

00:12:16 - Josh Goldberg

We have this problem that companies aren't contributing to open source, and that problem isn't getting better fast because we don't know how to ask people to do it right. We don't have the data backing our arguments. So that's a long-winded way of saying I agree, it's a problem, and I hope that we can figure out how to fix it soon.

00:12:35 - Ishan Anand

Yeah, it's a huge problem, and it's a little bit of the tragedy of the commons. Unless you're a big, visible tech company, like you said, everyone just seems to think, oh, somebody else is going to solve it. Am I correct in understanding that most of the people this initiative you're working on is targeting are companies, or is it individuals? What do you view that breakdown as likely to be?

00:13:03 - Josh Goldberg

I think companies. And I'll give you an analogy here: plastics versus paper straws. In theory, it is better for the world if we all use paper straws. I'm told that the math works out for the environment. But even if every single human as a consumer switched to paper straws, we wouldn't make a huge dent in the environment. The real issue is the big companies who are polluting and using plastics at corporate scale. And honestly, the fact that a lot of people have been forced to move to paper straws has made them angry about paper straws and maybe even weakened their resolve to help with the environment.

00:13:39 - Anthony Campolo

I think it's the same with electric cars. People want to buy more gasoline cars now because they hate the fact that people are making them buy electric cars.

00:13:46 - Josh Goldberg

Yeah. It's not that we shouldn't invest and work on our future in that way. I'm very behind helping save the environment and reducing our dependency on, you know, polluting and world-ending oil. But that's not the way that's going to convince people or make a huge impact, at least for the straws. And then, similarly with open source, I think asking individual consumers to give $100 a month to open source would really make the world a better place. It's not wrong. But companies are the ones that have the big pockets and who are really profiting off open source without giving back as much. So I think, yeah, consumers could give. It's nice. But the real people we need to target are the million-, billion-, trillion-dollar companies that could or should be doing more.

00:14:33 - Ishan Anand

Do you think there's a blockchain-based solution here on the horizon or something like that? Or Web3? People talk about investing in protocols and making it... that might be a way to get the consumerization of open source to work. Or is the jury still out on that in your mind? Do you think there's potential there? Let's put it that way.

00:14:55 - Anthony Campolo

No.

00:14:56 - Josh Goldberg

Okay.

00:14:57 - Anthony Campolo

Okay. Ethereum is an open source project with like $700 billion. And so it's already a thing.

00:15:05 - Josh Goldberg

I will... okay, I'll give you an actual answer. I recognize that blockchain is cool technology with a lot of potential and promise. I think the vast majority of its applications today, this year, are not a waste of time, but not going to pan out. And because there's so much... My brother is real into crypto. Every time we talk about it, it's a whole thing. I don't want to get into it personally too much because it's not an area I deeply understand. And the reason why I haven't taken the time to deeply understand it is because there's so much crap to wade through that I don't feel confident that I will get anywhere good anytime soon. If you want to discuss it, I'm happy...

00:15:43 - Anthony Campolo

I would be happy to explain some things to you. I mean, I would say you don't need to, like, drink the Kool-Aid, but if you feel like you don't know much about it, don't feel the need to say, "This is useless," first of all.

00:15:59 - Ishan Anand

Okay, I'm gonna say I apologize for taking a step there. Yeah, exactly.

00:16:05 - Josh Goldberg

It's a dangerous road.

00:16:08 - Ishan Anand

Yeah.

00:16:09 - Anthony Campolo

This is the last time we talk about Web3 on JavaScript Jam. This is why I don't work at a Web3 company anymore.

00:16:17 - Ishan Anand

We did have Jason come to the stage. Did you have a question? I do want to get us to TypeScript, which is ostensibly why Josh is here. Jason, did you have a question or comment?

00:16:29 - Theo

Let's see.

00:16:29 - Jason

Yeah. In the effort of transitioning us to TypeScript, I'll keep my comment brief. But I think the key problem with monetizing open source is finding the buyer. And the people that actually have the money are the corporations and the people that know how to sell into those corporations. Microsoft is probably top of that pile. And given that Microsoft now owns a vast majority of the developer ecosystem and mindshare via npm and GitHub, yeah, it's shocking that there hasn't been something more substantial there. Not that it surprises me that Microsoft wouldn't be able to move on something like this, but it seems like they would be in a really good position to offer something more than just sponsorships. But I'll keep it at that, as someone who spent a good chunk of the last decade selling open source software commercially.

00:17:32 - Josh Goldberg

Yeah.

00:17:33 - Ishan Anand

Jason was at Sencha, which was actually trying to monetize a JavaScript framework back in the day.

00:17:39 - Josh Goldberg

Yeah, yeah.

00:17:40 - Jason

And we were quite successful at it. But the funny thing we found out after many years of doing this is our smallest package was for a solo developer. You could buy an individual developer license, and we'd find out that there were these massive corporations that, because the cheapest thing on our website was the solo developer license, that's all they bought.

00:18:00 - Ishan Anand

Yeah.

00:18:00 - Jason

So okay, onto TypeScript. I personally, as a longtime JavaScript developer, have finally made the transition myself to TypeScript and spent the last three or four months really trying to learn it. So yeah, I'm pretty bullish on TypeScript now after being... I'm actually kind of a laggard, I guess, at this point.

00:18:19 - Josh Goldberg

But yeah, let's talk about TypeScript.

00:18:23 - Ishan Anand

Yeah, definitely. I'll get to Jen in a second. I just want to emphasize again and remind folks, if you're just joining us, Josh did a crash course on TypeScript with us. You can find it on our YouTube channel. It's in our newsletter this week. You can go to javascriptjam.com, pinned to the top. Thank you. And it's pinned up at the top of the Space here. If you haven't gotten on the TypeScript train, now is the time. If you're looking at the State of JavaScript survey, if you looked at the Jamstack survey, it was TypeScript, TypeScript. It was like the only thing that was both popular and growing, and everyone loved it. It was a clear winner in the space. And so it's been a huge success over the years. So, you know, with that said, let me turn it over to... we've got Jen, and then Eric came up to the stage. I'll let them come before I or Anthony jump in. Jen, go ahead.

00:19:22 - Jen

Hello. Hello, beautiful humans. And Josh, I feel like I've asked you this question like a million times, but I'm excited to ask you with many, many different people here: why was TypeScript created? This is like a three-part question. Why was TypeScript created? How long has it been around? And why did it take so long for people to get on the bandwagon, since it's been pretty controversial whether people should use it or not?

00:19:56 - Josh Goldberg

Hi, Jen. Good to see you again. Those are three great questions. I'm going to try to be good at answering one at a time and pausing, but someone scream at me if I screw this up. So why was TypeScript created? Great question. JavaScript is not good at writing big applications. JavaScript does not have a lot of development-time utilities that other languages, more tailored to big apps, do have, like, say, ways to indicate what types of things are supposed to be. And the difference there, I like to call it the difference between documenting your values versus your intent. JavaScript lets you define values, functions, classes, variables, whatever, but it doesn't let you describe the intent of them. Whether a function is supposed to take in a string or a number or some particular object shape, TypeScript adds the ability to describe your intent in your code to JavaScript. It adds it in a way that is very good. Unlike some of the community-maintained standards for JavaScript, like JSDoc where you write things in comments, TypeScript gives really good development tooling. So you can do things like go to definition, find all references, and rename automatically, things that are really nice for developers.

00:21:08 - Josh Goldberg

And because JavaScript needs all those things added, TypeScript was created, and later on became very successful because it does a good job of letting you build larger applications with fewer bugs and speedier dev efforts by adding those things. Does that answer the question you were looking for, that kind of marketing spiel?

00:21:30 - Jen

Yeah, I guess I think it's a good answer as a marketing spiel. But why such a controversy around it then? So many people are like, "TypeScript is really, really difficult." I will say I've been fortunate enough to have a really great teacher. Thanks, Josh, as I'm learning TypeScript. Yet hearing so many people say that they don't want to touch it, it's crazy. It's really hard to understand.

00:22:05 - Anthony Campolo

Well, do you remember the first conversation you had about TypeScript? Like that's why.

00:22:11 - Jen

But it wasn't just me. There was a lot of people like that. Yes, my first conversation was rough.

00:22:20 - Josh Goldberg

That's because we're programmers and we are salty and angry about everything. JavaScript is a wild and wacky world. There are lots of wild and wacky things people do with JavaScript, and TypeScript has to represent them. So most of the time when someone complains about TypeScript, they're either complaining generally about the fact that they have to learn a new thing and it's not clicking, which happens with every new thing, whether it's a language or a framework or anything, or they're complaining about some wild and wacky part of TypeScript that's there because it needs to be there to let people write their existing apps in TypeScript. So from a technical perspective, TypeScript, not marketing spiel, TypeScript's type system develops an understanding of how your JavaScript code is supposed to work: all the variables, all the possible object shapes, all the places that you might call those object shapes in particular ways, and then yells at you if you do something that seems like a mismatch, if you declare a function that's supposed to take in an object and then pass in a string instead, or something. But because people do such weird things in JavaScript, TypeScript's type system has to be complex and have weird and wacky things, like logic in the type system.

00:23:27 - Josh Goldberg

People have literally implemented TypeScript, the language, in its type system, and that's normally what people yell about. I'll also say that there is a big ideological debate, again because we're developers and we're angry about everything: should you add types to JavaScript? What's the right way? TypeScript has an opinion where its types are only at development time, not at runtime, the way other languages like C and Java do, which then means that people coming from those languages hate it. And then people coming from more purist languages like Python or Ruby, pre this era before they had types, didn't like that they were adding types to JavaScript. So there's no way for any one language, especially a language in the JavaScript space, to make everyone happy. But TypeScript, I think, has made a lot of really good choices that let it straddle the line, which is part of why it's been so popular.

00:24:17 - Ishan Anand

Jen, I take it that that answered your question.

00:24:20 - Jen

It did, thank you.

00:24:23 - Ishan Anand

Okay, cool. Eric, I think you're up next. Another regular here at JavaScript Jam. Eric, go ahead and do a comment or question.

00:24:34 - Eric

Yeah, sorry. This is just a beautiful example of what types mean to JavaScript. JavaScript is such an organically grown thing from a long time ago where anything goes, and a string and a number, because we're dealing with inputs, are sort of the same thing, you know, equals-equals.

00:25:12 - Anthony Campolo

Equals.

00:25:15 - Eric

It's a difficult world to build a strongly typed thing around. And I remember four years ago where it wasn't clear whether Flow or TypeScript was going to be the dominant way of typing JavaScript. And in one of my libraries, I chose poorly because I thought, oh, Facebook's going to maintain Flow forever. But it's an interesting problem. And today, literally today, I made a big refactor in a code base that I'm still new to, and TypeScript was like, you forgot all these other 17 things that you didn't realize. But with JavaScript, JavaScript would have been like, yeah, whatever, fine. So I don't know, I think it's wonderful. It's a shame that it's still a layer atop JavaScript. I don't know. There are pros to not strongly typed languages that, you know, the Python people will tell you all about. But for building large applications, as one of you mentioned, it really is superior.

00:27:09 - Josh Goldberg

Plus one. I'm sorry that you chose poorly on one project. I really do wish Flow had more legs. For those who haven't played with it, which is I think probably many, Facebook had its own equivalent to TypeScript called Flow. Flow actually did really well at the beginning because it had quite a few features TypeScript did not, like supporting plain JavaScript files much more nicely. But they haven't been supporting Flow in the open source space as actively and proactively as TypeScript has been. It's a pity.

00:27:39 - Eric

And it was all, like, super... it was written in some other language. It wasn't Rust, but it was some other thing that was more clever than JavaScript could be. And anyway, yeah, it's a shame that it sort of died.

00:27:54 - Dev

Like why?

00:27:57 - Ishan Anand

Oh, well, first off, just for the audience, so people are aware, Eric is the creator of at least two popular React libraries, Redux Form and Final Form. So he's speaking as a maintainer. But I guess I interrupted you. The question I want to ask both of you is: why do you think Flow didn't win?

00:28:18 - Eric

It's a matter of maintenance. In the same way that Angular was sort of backed by Google, but not really because they weren't really building all of their stuff with Angular inside Google, whereas Facebook was actually building all of their stuff with React. They had a lot more invested in that, and it felt to me like, oh, in that same way, Facebook is going to continue to maintain this Flow thing for the rest of us.

00:28:57 - Josh Goldberg

But.

00:28:59 - Eric

And as far as I know, they have maintained it internally. It just didn't feel like sharing it with the rest of us. I don't know.

00:29:10 - Josh Goldberg

Yeah, that's a good point. I think the amount of success Facebook has had with React is incredible. There's a funny irony here that I like, the analogy of Windows Phone compared to iPhone and Android, where Flow was a little bit of a Windows Phone in that it had some legitimately great points to it, but it wasn't supported as well as the actual popular phone platforms, and it just didn't have the community support. People didn't support it in the community because it didn't have great community support, et cetera, et cetera. I will also note, though, that one of the core maintainers on TypeScript ESLint actually was on the Flow team until recently and is a really big fan of the language, and can probably give a very good set of answers that I don't know as to why that language is fantastic. They still are working on Flow, it's just they're targeting it more, I think, for very big applications, like really, really big. So it's not as publicly oriented and polished the way TypeScript is, which is probably another reason why it's not so widely used anymore.

00:30:14 - Eric

And TypeScript came from the .NET, C-sharp-y land, right? Which, as a JavaScripter, feels kind of gross to me. But that's where it came from, right?

00:30:33 - Josh Goldberg

Some of the people, yeah. Anders Hejlsberg, the creator of C#, also created TypeScript. I'm curious, did you have a bad taste in your mouth when you first read it, thinking, "Oh, we're all going to get converted to .NET style now? Object-oriented programming?" When you started first on TypeScript, it...

00:30:48 - Eric

was just like, wait a minute, Microsoft is doing something in my JavaScript land. It was gross at first, but now Microsoft owns JavaScript, so it's like, okay, I will do your bidding.

00:31:08 - Josh Goldberg

Yeah, funny how that reputation has changed. If TypeScript had come out in 2002 instead of roughly 2012, then I don't think anyone would have adopted it. But the Microsoft rep has really improved.

00:31:21 - Anthony Campolo

It's nice to see now they get to run Intelligence for the rest of our lives.

00:31:27 - Eric

Yay.

00:31:29 - Ishan Anand

How much do you think Visual Studio and their other influence were key contributors here to the dominance and success of TypeScript? What do you think was the reason TypeScript succeeded? Even ignoring the Angular conversation, was there a key inflection point in TypeScript's history that you think was crucial? Was it, as Eric is suggesting, when Flow failed to get traction as a community? Are there key inflection points you'd point to where, in your experience at least, you felt, Josh, that it's definitely picking up over its history?

00:32:17 - Josh Goldberg

The problem with asking one person is that because it's such a wide... what?

00:32:25 - Eric

I'm sorry, I'm trying. Twitter gave me a soundboard and I'm

00:32:34 - Theo

trying to get rid of it.

00:32:35 - Anthony Campolo

I'm sorry.

00:32:36 - Josh Goldberg

That was fantastic. I loved that very much. I think the problem with asking any one person, such as me, is that TypeScript is so widely used that no one perspective really encompasses everything unless you ask, like, Anders or someone on the team. But I think there are a lot of really important inflection points that added together nicely to make it continuously get more and more and more good. Angular adopting TypeScript was a huge one that was very successful. The fact that there was no strong competitor to TypeScript for years and years was a huge one. I mean, it took a while until Flow came out. Flow not really jumping forward and competing with TypeScript as nicely as it needed to to succeed was another one. Flow never really nailed the day-to-day quality. There were a lot of small performance or user-experience bugs that just lasted a while. I think the TypeScript community really was a huge inflection point. There's this huge repo, DefinitelyTyped, that stores all the community-authored type definitions, which is not what was always used for TypeScript's community types, but now is the thing and is very fantastic.

00:33:44 - Josh Goldberg

And yeah, just generally the synergy with VS Code meant that if you wanted to be a web developer, you didn't have to choose between five different good editor options and three different JavaScript variants that somehow were like Java or coffee puns. It was okay, you start a project with React and TypeScript and VS Code using npm, maybe later Yarn, and that was just the thing to do. So it hit that kind of community saturation point the same way that React did, which was really good for it.

00:34:11 - Eric

I mean, it's kind of... I'm a little uneasy with, you know, how Microsoft had their whole monopoly problems

00:34:24 - Josh Goldberg

a long time ago.

00:34:26 - Eric

At the moment, Microsoft owns GitHub, npm, VS Code, you know, Copilot and TypeScript and Playwright. And it feels a little like we're putting a lot of our eggs in the one basket. I don't know, now later we should talk about how React is now being purchased by Vercel.

00:34:59 - Ishan Anand

But.

00:35:01 - Eric

But it feels a little scary that everything is going to the one owner.

00:35:10 - Josh Goldberg

I don't know.

00:35:11 - Eric

Opine.

00:35:14 - Josh Goldberg

Yeah, you either die a hero or live long enough... I think all these major companies are at their core not evil or good, but money-oriented. And all the major tech companies either have learned or are currently learning the hard way that if you are too money-oriented, to the point of being evil, it will have a negative impact on you. Look at Microsoft's monopoly shenanigans, their capitulation to open source, especially Linux. Then look at Google and Apple going through other monopoly things. I think that we don't have any good options out there. We just have options that have learned their lesson and, for the time being, have a good leader and aren't so bad. So maybe this is not the right attitude, but I've kind of hit the point of shrug when it comes to which evil mega-corporation is owning all of our assets.

00:36:08 - Ishan Anand

That might be a good thing for TypeScript. It is clearly the dominant choice here, other than JavaScript. How do you make the decision? If you're on a project, when is a good project for TypeScript and when is a bad project for TypeScript? Or should all projects be on TypeScript? What's the decision criteria you'd suggest?

00:36:31 - Josh Goldberg

I really wish I could answer that with every project, because that would be easy. But that's not the case. Per project, I try to go with, vaguely, generally speaking, a rule of three. If you have at least three developers, or if you have at least three files, you should probably maybe go with TypeScript. But it's really very project-dependent. If you're on a team of developers who have never touched TypeScript and you're in a hurry, you have big deadlines, a lot of pressure, whatever, maybe don't switch to TypeScript. It is an investment in yourself that you might not have the budget for. So it's always a pro-and-con case. But the pros for TypeScript are really, really good. And the vast majority of the time, I think theoretically, and at least in my experience, the pros far outweigh the cons because they're smaller. I'll start with the cons. The cons are: it's a new thing for you to learn. It adds complexity conceptually to your code, sort of. At least it makes it so that you have to describe the complexities of things in your code, even though they were probably there to begin with.

00:37:31 - Josh Goldberg

That adds complexity to your build chain. And it's just, you know, it takes time to learn a thing. But the pros are: you get much better development tooling, you get better bug-catching, you get good doc standards, which means that it's easier to describe your intents and easier for developers to share knowledge. You get, I mean, just the swag of saying TypeScript, which at this point is a positive when you're trying to recruit. There are just a lot of really good things going for TypeScript. I think it's not super useful if you just have, like, a couple of Node files, or it's just you working on some small thing on the side. But anytime you need to work long-term in a project or work with multiple people or both, then those pros really start to get quite valuable. And I find it hard to make the case against TypeScript.

00:38:17 - Eric

I love the three files bar that's so ridiculously low. I love it.

00:38:25 - Josh Goldberg

Thanks. Yeah, I mean, as soon as you have one file importing from another file, you now have to keep track of two things in your mind. You have to keep track of file A and the fact that file A imports B. And then while you're looking at file A, you also have to mentally keep track of file B, which may be complex, may be simple, who knows. And then whenever you change file B, you also want to be notified in some way that file A may or may not need to be changed. So it makes a lot of sense that, okay, you've got TypeScript to let you know if you screwed something up and need to adjust.

00:38:58 - Eric

May I politely request Theo come up to the stage? Because I really enjoyed Theo's latest video about typing functions and stuff, and hi, Theo. I kind of want to say hi and thanks.

00:39:27 - Ishan Anand

Hello.

00:39:29 - Theo

I had to come up for the when-should-you-use-or-not-use-TypeScript conversation because, as per usual, I'm taking a slightly harder stance than Josh here.

00:39:40 - Josh Goldberg

It happens.

00:39:41 - Anthony Campolo

Yeah.

00:39:42 - Theo

I'm at the point where, if it can be in JavaScript, it probably should be in TypeScript. I agree that if a given set of developers hasn't learned TypeScript yet, and you have deadlines and priorities that are slightly higher than significantly improving their agility in the future, significantly improving the safety of your code base, and significantly improving the livelihoods of anyone whose job it is to touch code, if you have a priority that's higher than that, yeah, you should take care of that priority. But the second that priority is done, you should start teaching your team TypeScript, because it will make them better.

00:40:16 - Josh Goldberg

I agree with that, actually, Theo. I think we might have a very similar level of intensity here. I'm just hesitant. I'm not good at displaying the intensity. I also think that if your team can't learn TypeScript because of timelines for, like, whatever, a year, a year and a half, that's a problem with your team's timelines. You should be able to take the time to learn and use TypeScript.

00:40:35 - Theo

To that beneficial and crazy thought, maybe if you did learn TypeScript, your timelines would suddenly start getting closed way faster. I know I personally code significantly faster even on small things. With TypeScript, I compete in Advent of Code every year, and I regularly break top 200 in the world, and I do that with strict TypeScript. I don't have any any in my competitive programming challenges.

00:40:56 - Eric

Yeah, I recently went through some coding interview stuff, and when they wanted me to do it in JavaScript, I was like, ah, I feel like I'm slower with this, and it was just so, so hard. So yes, I totally agree. Once you're used to it, TypeScript is way faster.

00:41:25 - Ishan Anand

So we have Gaurav who has his hand up. Gaurav, do you have a question or a comment?

00:41:30 - Gaurav

Yeah, I just wanted to comment on TypeScript. I used to not like TypeScript until about a year back. And then in my current company, we have huge monorepos, which is when I realized it's actually quite useful, because we have so many files and so many contributors working on the same repository, and most of the time not a lot of people have the full idea when touching a different file. But what comes in handy and is super useful is the TypeScript types, which don't let people check in improper arguments or miss mandatory arguments, which is the best part I like about it. Yeah, very handy in the case of huge repos. Thank you.

00:42:18 - Ishan Anand

Thanks for sharing. Maybe let's think about this the way a CFO might, like your chief financial officer. What is the amount of additional ramp time, if your team doesn't know TypeScript, it's going to take for the team to ramp up? And then how long does it take for that to pay for itself in, say, productivity of the team down the line?

00:42:43 - Theo

I'll address it first.

00:42:47 - Josh Goldberg

I was about to say the same thing for you. It's tough to answer in absolutes. It depends on the composition of your team. Senior people learn things faster, or more experienced people as a whole learn things faster. Some people are just better at learning faster than others. I'd say in the teams that I've converted to TypeScript personally, they're pretty efficient. They've broken even. They're at least as efficient as they were within, let's say, a month of passive conversion and within a couple of weeks of active conversion. And they're still learning TypeScript, invariably, for the first few months. There's no way to learn a new language, even if it's a superset language that builds on another, in less than a couple of months unless you're really, really, really focusing on it. But I'd say that it's probably financially worthwhile, in my experience, at least within the first month. Just in terms of developer efficiency, as Theo said, it's much better. And I have never seen a TypeScript conversion of a real project that did not find bugs. So no matter what, just the fact that you got it converted to TypeScript, even if you don't merge that pull request or set of pull requests, means you found bugs that would have cost you revenue.

00:44:02 - Theo

I would say there's a couple of really big factors that determine a lot of the success and timelines here. One that I think we don't talk about enough is: is there already someone experienced with TypeScript, or like a TypeScript advocate, within the team or company? If there is, that could exponentially increase the speed of these conversions and the onboarding success of a given team moving to TypeScript from a code base that isn't on TypeScript yet. So hiring in people who already know TypeScript, or just giving more buy-in to the people who know already. Even if it's like you have two juniors on your team who know TypeScript already and a bunch of principals who don't, if your team and your company are architected in a way where those juniors can lead the charge, you're probably going to find success with these conversions faster. The other side, this is something I've learned a lot about now as a CEO, is the value of buying into the things that your team believes, even if you don't fully understand or believe them. So as a CFO, there is a really cool opportunity here to listen to the engineers who are pushing for this and say, yeah, I trust you, you can take ownership of this.

00:45:05 - Theo

If you truly believe this will make us faster, do it. And even if it fails, the amount of trust and buy-in and energy you can give an engineering team by buying into them like that is almost always worth it, even if numerically the actual success of the project doesn't...

00:45:27 - Ishan Anand

That's really helpful and powerful. Jason, you have your hand up.

00:45:32 - Jason

Yeah, I'll agree with everything that Josh and Theo were just saying. I think from a purely CFO- or CTO-level decision-making process, the size of the existing code base matters a lot. So while it's relatively easy to adopt TypeScript incrementally, it is a cost that you're going to have to go through to convert everything. So if you have a really large code base, it could take years. Well, maybe not years, but it could take person-years of time to get your code base fully converted, even though you don't have to. So that would just be the main thing I would add from a purely financial standpoint. But I do agree that the improvements in efficiency will accrete very quickly if you think of it purely from a financial standpoint.

00:46:21 - Jason

And after my personal conversion to being a TypeScript promoter, now I'm pushing my teams to start to use TypeScript wherever possible on our projects. So I can definitely see the benefits now. The one sticking point I've had is TypeScript, for me, as someone who's been using JavaScript since the Clinton administration,

00:46:46 - Theo

it

00:46:46 - Jason

was easy to build apps with, and it didn't take me that long to figure it out. But once I started trying to do any kind of library code, that's where I really hit the valley of the shadows of darkness. And it took me a while to come out of it, but I feel like I'm starting to get onto the other side of that now. Libraries and generics really started to get really wacky for me as someone with lots of JavaScript experience.

00:47:15 - Josh Goldberg

You know, this was a Twitter thing over the summer. I think TypeScript for libraries does differ from TypeScript for apps. You're absolutely right. Plus one in general, libraries can sometimes be some of the most complex code in terms of concepts in the code. When you look at libraries that are generic data handlers or schema validators, things like TRPC or Zod or io-ts, they do wild and wacky things, like they operate on generic pieces of data. They take an object and, based on those object keys, make a new one with keys that have names modified based on the original names, and values modified based on the original types, things like that that are very difficult to conceptually describe in plain English, let alone in syntax or in code. So yeah, you end up having to learn this whole new fun area of TypeScript, the generics type-system shenanigans that can be tough for people because it's an investment. And it's not a way of thinking that most of us come into JavaScript or TypeScript with, being able to describe in the type system a generic function that takes in an object and returns a new object with a type based on the original one.

00:48:23 - Josh Goldberg

But once you do know those things, you can write these really nice libraries that wrap and encapsulate those shenanigans so that users writing their apps don't have to deal with them. And I think that libraries that do a really good job of that are the ones I mentioned, like Zod and TRPC. I think that kind of speaks to a larger truth in industry: that we are constantly, in web dev and programming as a whole, moving complexity away from the app writers, moving things like UI management or state management into these libraries where, even if the libraries have a simple API, they may or may not have a complex, type-shenanigan-y internal core that is hidden from the user as much as possible, and that lets us be more productive. So I'm happy about it.

00:49:08 - Theo

Yeah, that touched on the one point I wanted to add, which is that one of the reasons TypeScript is such a pleasant experience for app writers and user-facing developers is that a lot of the complexity and scope of concern that we used to own has now been moved to TypeScript. By moving it to TypeScript, we've also now moved a lot of that complexity and concern into the hands of the developers of those libraries. So we're kind of standing on their shoulders as we have this better experience. If the goal is to get to the top, TypeScript gets us halfway, the library developers get us another third, and then what's left is what you're doing. It's like, oh, this is so much easier than it was before. But that's exclusively because of the hard work those other developers and systems have done to make it easier for us to iterate.

00:49:51 - Anthony Campolo

Could you take a second and, for people who are maybe newer to this ecosystem, explain TRPC and Zod and kind of how they relate to TypeScript and how they're enabled by it?

00:50:04 - Theo

Can I just do this one quick because I have to run to go prep for stream.

00:50:06 - Anthony Campolo

Yeah, go for it.

00:50:07 - Josh Goldberg

Yeah.

00:50:08 - Theo

So TLDR, Zod is a validation library. It's similar to, if you know, Yup or libraries like that. It's for taking an object, usually data you're submitting from a form or something, and making sure it fits a specific shape. The libraries that existed before Zod for this were pretty boring and generic and would just give you the type of the data you're passing in. Usually what Zod did differently was write a custom type, not really a generator because it's not codegen, but a really complex type system where, based on the validation and parsing you have done on data, it will give you the exact correct type on the other side, which makes it trivial to parse, validate, and modify data that you're getting through places that might not be safe, like an external API or a user submitting it. And TRPC was originally created by the person who created Zod, and it was built around using Zod as kind of the source of truth for building APIs, where you build a function, you use Zod to validate the input, and then you can call that function from the client. And the goal was to do something similar to the experience you have with GraphQL, but instead of having a contract system that you define through something like a schema, or you generate through something like [unclear],

00:51:28 - Theo

instead of that, you use your type definitions the same way you would if you were calling a client function on a client or a server function on a server. The only difference is you're calling a server function on the client. And TypeScript's kind of being used as a hack to tell the client which endpoint to hit.

00:51:48 - Josh Goldberg

Plus one. Good explanation.

00:51:50 - Anthony Campolo

Yeah, if you want to add anything to that, Josh, or if not, feel free to continue on.

00:51:55 - Josh Goldberg

No, 100%.

00:51:58 - Ishan Anand

Maybe one thing. I'll jump in here. It's interesting how TypeScript becomes a level of abstraction, giving us Zod and TRPC sitting on that. To what Theo was talking about, standing on the shoulders of giants with a new abstraction layer, with what Tanner Linsley did with his router and now making the router based on types, it's just something you may not have thought of adding types to. And getting the leverage out of that in yet another domain is just really fascinating to me. I don't know if you guys want to comment on that, or if there are other examples you can think of that come to mind of really powerful layering on top of once you've got types into the system.

00:52:42 - Josh Goldberg

Yeah, I haven't poked at Tanner's stuff too much, but what I've seen from the surface seems awesome. I've been complaining over the last year that I don't have visibility into any design-system tooling that I really, really like. They all have some flaw, like performance or not-great types. But I will say, the way that we did the design system at Codecademy, it's open source, it's called Gamut, is really nifty. It's a CSS-in-JS lib where you have box-style props, meaning you write components and then instead of defining your styles elsewhere, you just pass things like color= as React props on the component, and those props are then type-safe and responsive. So you can pass an object like small, md, and large to indicate that in the mobile viewport it's whatever prop small, and in the medium viewport it's large. And I think that design systems are a fantastic place to have good type safety, where you can enforce at development time that people are passing in the right constants or whatever references to your design-system tokens. I apologize to all the backend developers who zoned out for that entire spiel, but it's really a beautiful thing.

00:53:59 - Ishan Anand

Jason, you have your hand up.

00:54:01 - Jason

Well, I was just gonna plug Theo's T3, or Create T3 App, as an excellent example of a double plug, combining all of those pieces together of TRPC and React and TypeScript and having it all kind of put together out of the box. So I just built an app over the last couple weeks using it, and it was a very smooth and pleasant experience.

00:54:23 - Anthony Campolo

So super sweet, right?

00:54:26 - Jason

Yes. Yeah, TRPC is pretty clean. I'm very happy with it.

00:54:35 - Ishan Anand

My card is now complete, but we should explain for people what... oh, sorry, what T3 App is. Do you want to do that?

00:54:44 - Theo

I have to drop for another meeting,

00:54:45 - Jason

but I'll take my plug and run with it.

00:54:49 - Josh Goldberg

My stream is delayed because...

00:54:52 - Theo

Yeah, my stream's delayed because there are a bunch of sirens outside. There was a small accident, so I'll wait until that's over. I can explain this quick. T3 App is that a lot of people in my community were asking me to make a template for the technologies I use and recommend for stuff. And I put my foot down and said, no, I'm not doing this, because if I do this, y'all are going to start installing auth libraries and database systems on your blogs. The only thing I would consider is doing something more dynamic where you pick the technologies you want and we assemble a template based on that. But that's a lot of work and I don't feel like it. If anybody wants to go do it, though, feel free. Nexle stepped up to take the challenge and made Create T3 App, which was my way of using these technologies together. You select the ones you want, and it would assemble it for you.

00:55:42 - Josh Goldberg

And then...

00:55:43 - Theo

Yeah, as soon as I tried it for the first time, I was like, oh yeah, this is dope. I will be using this for every project now. I opened some issues with some things that I thought we should change. Slowly the community started noticing, especially when I started using it on stream. We're now at like 170-plus contributions in six months. We're outpacing Remix for new projects started, and it's just a really pleasant way to get started building full-stack, type-safe Next.js apps.

00:56:08 - Anthony Campolo

You already almost have as many stars as Redwood, which is over three years old. And also Nexel is like a 17-year-old Indian high schooler who created it.

00:56:19 - Theo

He was 15 when he started and I think he just turned 16, not 17 if I recall. I could be wrong.

00:56:24 - Anthony Campolo

I think he was 16 when he started, now he's 17, but I could also be wrong. But yeah,

00:56:31 - Josh Goldberg

Sweet.

00:56:34 - Anthony Campolo

I first started using it right around when it came out, and it totally blew my mind. Because I hadn't really used TRPC yet. I had heard about it a lot, and I really wanted to get into it, but I didn't really have a lot of TypeScript knowledge yet. So it was a lot like when I saw Redwood. It was like handing me this whole combination of things that allowed me to use cool tech that I didn't quite understand or know how to configure myself. But then by using it, I eventually learned it and could configure it by myself. So that is a super cool part of it, that it gives you a really sophisticated stack in a very usable way that allows you to actually learn how it functions.

00:57:11 - Theo

And it puts you at a good enough starting point that if you make mistakes, you can bring them to the community. And it's usually pretty easy for us to figure out what's going on. For us, it makes the process of debugging and helping people significantly better.

00:57:23 - Anthony Campolo

Just make sure you use the Questions channel.

00:57:27 - Theo

Yes, please use the Questions channel.

00:57:34 - Anthony Campolo

We got someone hopping up, actually, possibly to ask a question. They have zero followers. Hopefully they're not a bot.

00:57:43 - Josh Goldberg

Excuse me, I would like to talk about how SpongeBob is the best TV show ever.

00:57:51 - Theo

Can you. Why did you.

00:57:55 - Eric

Yeah,

00:57:58 - Anthony Campolo

All right. About that, I'm gonna need to kick this person. Yeah, as soon as I put him up, I was like, this is probably not someone I actually want up here. It's the first time I ever hit the mute-everyone button. I felt so powerful.

00:58:16 - Josh Goldberg

I was interested in where that was going. I like SpongeBob, but I agree with your decision.

00:58:20 - Anthony Campolo

You know, I always feel like they might be a newbie. Maybe they just created a Twitter account. Maybe they really have an important question. So I regret it.

00:58:31 - Ishan Anand

It's happened. It's Twitter Spaces. It's the fun of being live. Well, we are at the top of the hour, and I just want to thank... I actually have to run as well, but I leave you in Anthony's hands, along with Josh. And just thank Josh for being our guest today, and thank all the speakers. I encourage everyone here, if you are getting any value out of anyone here, click on their face and follow them, even if maybe they're talking about SpongeBob and you love SpongeBob. And then also check out javascriptjam.com. That's where we have our newsletter. We usually have a list of topics that we'll talk about and what we'll look forward to, as well as a link to the previous week's recordings. With that said, I'll turn you back over to Anthony. Thank you, everyone.

00:59:22 - Anthony Campolo

Yeah, I would say, Josh, are there any big topics that you want to hit on that we haven't talked about yet? Otherwise, I'll open it up to any more questions if anyone has it and then we can start wrapping it up.

00:59:34 - Josh Goldberg

Oh yeah, I'll blaze through these. TypeScript is great. However, it's very configurable. You don't have to use the super-strict, awesome version of it. You can ease into things. If you are using TypeScript, I highly recommend linting your code with ESLint and formatting your code with Prettier. I mean, that's just true for JavaScript as a whole. And then use TypeScript ESLint to get nice, good ESLint rules and infrastructure for your TS code. I'd say if you have a problem with your types getting too complex and unreadable, it might be because your code is too complex and unreadable, or just the concepts behind it are hard to represent. Types that are complex are a symptom of complex code. Those are my main soapboxes. I yield.

01:00:19 - Anthony Campolo

I did have this actually, a question from Ishan, but I think it's a good one. Do you think that there are any criticisms of TypeScript that you agree with?

01:00:28 - Josh Goldberg

Wait, people criticize TypeScript somewhere, at least once? Absolutely nothing is perfect. The TypeScript team is a team just like any other. They have finite resources, constraints, and things they have to work with. I think the type error messages in TypeScript can sometimes be very difficult, especially unfriendly to newcomers. Performance is good. It's actually getting a significant percentage faster in the next major version of TypeScript, 5.0. But I mean, it's written in TypeScript and compiled to JavaScript, so it's not as good as a Rust-native library, although that will probably get better and better. They do have someone working on perf. I think the TypeScript docs are good, but not great. They used to be not particularly good, and then Orta Therox did a lot of great work on them.

01:01:16 - Anthony Campolo

Yeah, yeah, he's like the TypeScript hero.

01:01:20 - Josh Goldberg

Yeah, truly. It's funny to think of someone in terms of how many thousands, millions, whatever, of dev minutes or hours they've saved the world. But yeah, I mean, there are always criticisms. There are some things the type system doesn't do particularly well, maybe because they haven't implemented it, maybe for backward compatibility with old versions, maybe because it's not fast enough to do well, like dependent types, which are a really fancy way of saying types that understand what code you might have called. If you call a function that updates a value, the type system would understand that the value's been updated. That's just not in TypeScript. That's not something most people understand or ask for, but it would be really nice. So yeah, TypeScript's not perfect. There are some architectural things that aren't perfect, and there are just some things that are not great.

01:02:06 - Anthony Campolo

And then, are you familiar... there's a post that Ryan Carniato wrote called The Trouble with TypeScript. I'll pin it to the top. You ever read that one?

01:02:17 - Josh Goldberg

No, but I'm frantically googling.

01:02:21 - Anthony Campolo

Yeah, it's funny. When I first heard that he was kind of a TypeScript skeptic, I was like, sweet, I finally met another one, and someone who's actually respected. But yeah, I mean, I wouldn't say I was TypeScript-skeptical so much as that I was in a position where I really didn't need it and didn't feel the need to use it. But once I kind of started using it, I got it, and I got why people found it valuable for the things they used it for. I still don't think I really need it for the things I'm doing. I know Theo would disagree with that, but yeah, I kind of like dynamic languages. I don't know. I mean, there are developers who've been writing Ruby for like 20 years and never used a typed language, and they seem to be doing just fine. But there's a couple people hopping in a little bit if anyone wants to ask some questions. We're probably going to be getting close to closing it out in a bit, but I think we still got time. You don't have a hard stop at any time, right?

01:03:19 - Josh Goldberg

No, no, I'm good. I'm reading, I'm skipping through the post now. And yeah, I agree with some of these points. It is funny that there are legitimately people who are extremely productive in untyped Python, Ruby, JavaScript, PHP, and that's just fine. Works for you.

01:03:34 - Anthony Campolo

Yeah. I'm gonna go ahead and pin this to the top. It's so hard to do anything on your phone through spaces. All right, cool.

01:03:47 - Josh Goldberg

I will say, while you're posting that, though, that I try to be very balanced in discussing or responding to points against TypeScript, because there are very many good ones. And this is just reading the post and knowing Ryan, or knowing of Ryan. I'm sure this is very good and well thought out. But there's a reason why TypeScript is so popular. It is fantastic. And I personally would be horrified if I had to join a team that did not use TypeScript at scale, whether it's front end, back end, full stack, whatever.

01:04:16 - Anthony Campolo

So would that be a reason for you, like, to not take a job

01:04:20 - Josh Goldberg

if they weren't using TypeScript. At this point in my life, if I were to join a job, the two options would be: they're on TypeScript, or they're excited about me converting them to TypeScript. Yeah.

01:04:34 - Anthony Campolo

Sweet. We got Dev up here. Dev is another member of the whole T3 cult, and Hacksor is requesting. Let me see if this is a person. They look person-like.

01:04:52 - Dev

Hey, how's it going? How's my audio sound?

01:04:55 - Anthony Campolo

Good.

01:04:57 - Eric

Cool.

01:04:57 - Dev

Heard you're talking about TypeScript.

01:05:01 - Anthony Campolo

We are.

01:05:05 - Dev

Sorry, what did you ask?

01:05:08 - Anthony Campolo

Have you ever used TypeScript before?

01:05:10 - Dev

Yeah, like a couple times. I've been using TypeScript for less than two, three years and stuff.

01:05:20 - Anthony Campolo

Do you have a question or thoughts or you just want to come chill?

01:05:26 - Dev

Mostly just wanted to come chill. I guess we can talk a little. I really love TypeScript, but there are certain things that I really, really wish it had. So I guess that's something that we can explore. What is something that you wish TypeScript had that would make your life easier? And I can go after everyone else.

01:05:49 - Josh Goldberg

Oh, you've activated my trap card. So dependent types would be really nice. I mentioned a few minutes ago, and it's kind of a... I don't know, it's fine without it, but it would be really nice. It would just give TypeScript a better understanding of how values change over time. Functional programmers don't care about this because all their values are constant. But from an API standpoint, TypeScript's Node APIs, or JavaScript APIs that you might call when you import something from the TypeScript package, don't provide a way to check whether one type is assignable to another type, which most TypeScript users don't care about, what I just said. But from the tooling perspective, it would be really nice to have a Type Relations API, as the TypeScript issue calls it. In TypeScript ESLint, we have a bunch of lint rules that use TypeScript's type checker to yell at you if you do something probably wrong in your code, like if you create a promise and don't handle it properly, or if you use a for-in loop on an array instead of a for-of loop. And then there are just so many lint rules that we want to write but can't because TypeScript doesn't have a type-relationship API.

01:06:55 - Josh Goldberg

Like, we would want to be able to have a lint rule that lets you know if you add a type annotation that doesn't actually change the type, or even worse, makes your types less precise. Like if you declare a variable as a constant string, which TypeScript can infer to be the literal string type, like "hi" rather than the general string, but then use a type annotation to switch it back to string, that's not just useless, that actually hurts your code. So yeah, I would love that. But to actually answer what most people here would care about, I think if TypeScript had a better command-line interface combined with a better VS Code editor experience explaining errors to you, that would be so nice. If you look at the Flow or Rust command lines, that's what I want TypeScript to look like.

01:07:44 - Anthony Campolo

Yeah, the errors are a little rough.

01:07:49 - Dev

Yeah, definitely agreed on the second part, but I'm not sure I'm aware of the type relations or dependent types. Can you give a few more examples of why that is useful, and what other languages have it?

01:08:06 - Josh Goldberg

Yeah, I'm not even gonna... I don't know how to use Twitter Spaces in my weird setup now, but there's this really cool project from someone named Ben called Ezno, E-Z-N-O, which is like TypeScript. Yes, thank you. There's this blog post introducing Ezno. It's like TypeScript, but it's got a lot of cool type features, and it has a really nice explanation of dependent typing.

01:08:35 - Anthony Campolo

The fact that you're bringing this up... I've heard of this, and I was like, this is one of those things that seems very ambitious, and if it does actually take off, though, it could be a really big deal. So I think this is something people should pay attention to.

01:08:48 - Josh Goldberg

Yeah. I don't know if this particular project will be successful, but I hope it is, and I know someone eventually will.

01:08:53 - Anthony Campolo

It points to the way where things are going regardless, right?

01:08:57 - Josh Goldberg

Yeah. The example in this article that I really like for explaining dependent typing is if you search for add1, A-D-D-O-N-E, there's a function where add1, as a function, takes in an x number and returns x + 1. And then Ezno would be able to infer that if you pass in 3, the function returns the literal value 4. So that's just really nice. TypeScript doesn't do that. It's not powerful enough. It's too slow. Another cool thing, if you look for effects, get5 is the search term, Ezno would understand that if you call a function called get5 on an object that says object.x = 1, after calling that function, that object's x would in fact be whatever it was before plus one. It understands effects, or effect tracking, where the type system understands how your values change over time, which means that it understands much more deeply how your code looks as it changes over time. I don't know if I'm explaining that well, but that's the best I got. And this post is a really cool exploration of what you could do in TypeScript if it were, you know, much faster and written in Rust.

01:10:15 - Dev

Actually, speaking of effects, have you heard about Effect TS?

01:10:19 - Anthony Campolo

Actually, let's take a pause for a second and take Hacksor's question.

01:10:23 - Hacksor

Yeah, I think mine was controversial. I was going to ask: I think it was said before that if you were working in a code base that wasn't TypeScript, it would be bad and you might not want to do it. But what is the stance of everybody on object-oriented programming with TypeScript? It seems a bit controversial in some cases. Do we like it?

01:10:42 - Anthony Campolo

Do we hate it?

01:10:44 - Josh Goldberg

I think the question of whether to use OOP is completely, as they say, orthogonal to whether you use TypeScript. TypeScript is equally beneficial in functional versus object-oriented versus just the normal code that the rest of us, myself included, write. I personally do not have the [unclear]...

01:11:06 - Anthony Campolo

It doesn't stop you from doing one or the other. It gives you the option. But whereas using TypeScript doesn't give you the option to not use TypeScript, it still gives you the option, at least, to kind of pick your preference.

01:11:18 - Josh Goldberg

Yeah,

01:11:21 - Dev

Yeah. That being said, as for object-oriented versus functional, I don't think any strong arguments of one being objectively better than the other really hold. I think it's a lot more about personal preference than a lot of people think. Currently I'm trying to look into both. I'm trying to study what exactly object-oriented means, how people develop it, and the other way for functional programming. What are people talking about? What are the core concepts or values that both of these sides hold? And it really comes down to personal preference. Which one do you know better? Which one can you think about or use to guide your design or guide your code in a better way? For me, that is object-oriented. I'm working on a few projects, and I'm taking a really object-oriented approach in designing the backend for them. But in other projects, I can see going for a functional-programming approach as well. So it's really about how you prefer thinking about your code design.

01:12:33 - Anthony Campolo

I'd also say it's going to depend on... some front-end frameworks will lead you in the direction of one or the other. If you're using Solid, you're writing functions. It's not technically functional programming, of course, but if you're writing web components, you're going to be doing a lot more classes. So I think that sometimes whatever you're going to be writing will have certain conventions already baked into it. And I think it makes sense to kind of just go with those conventions for the most part, because as you're saying, there's not really an objectively better one or the other unless you care about immutability.

01:13:08 - Josh Goldberg

Yeah. I also think a lot of people

01:13:11 - Anthony Campolo

mess up both of them.

01:13:12 - Josh Goldberg

Oh, sorry, go ahead.

01:13:14 - Anthony Campolo

No, that's a totally good point. I feel like most people... everyone writes code with functions and objects in it. And the idea of separating the two as paradigms, that you only write one or the other, it's just not how we work as devs.

01:13:31 - Josh Goldberg

Yeah, yeah. A lot of people conflate object oriented programming with just having a lot of classes or functional programming with writing pure functions. But there are real design traits for both of those that get lost in the conversation. It's kind of sad.

01:13:44 - Theo

Yeah. Maybe on a similar theme.

01:13:46 - Anthony Campolo

What happened to decorators?

01:13:48 - Theo

Why does no one use them?

01:13:51 - Dev

Yo, what do you mean?

01:13:52 - Josh Goldberg

No, we only just added them. They finally got adopted in JavaScript.

01:13:57 - Anthony Campolo

Those are actually like in the language now.

01:14:01 - Josh Goldberg

Yeah, so they hit TC39 stage three recently, meaning the community, besides the standards committee that works on JavaScript, collectively has gotten enough confidence in the current leading decorators proposal that people are encouraged to start trying them out and implementing them. TypeScript's next version, or yeah, TypeScript 5, which is in beta, in addition to having really nice performance improvements, has support for the correct new JavaScript decorators. The reason why people used to use decorators so much in TypeScript is because they added this experimental decorators compiler option that let you use an old version of the decorators proposal, in large part because that let Angular folks use TypeScript. Now that old decorators version is not compatible with the new, correct, good decorators. So it is very much an old thing that should go away.

01:14:53 - Anthony Campolo

Everybody knows what that is.

01:14:56 - Josh Goldberg

Yeah, it has some quirks, but yeah, we should expect to see over the next five years or so a slow and steady rise, probably with a few spikes in the next year, of people writing decorator-based libraries.

01:15:11 - Theo

Yeah, Angular definitely pioneered it, but I feel like a lot of other libraries don't take advantage.

01:15:16 - Dev

Yeah, and I think decorators have some limitations, which is why they're not adopted as widely. I think recently Alex, the creator of tRPC, really highlighted that. Alex was basically looking into an alternative API to create tRPC routers with classes instead of how we do it right now. Obviously that brought up some discussions around, should we use decorators like NestJS or Angular does? The problem is that decorators are good for dynamically adding functionality later, but they don't do much in terms of static analysis. Adding a decorator will not give you an extra type, or you cannot infer types out of it. For example, in NestJS, if I add a body decorator to a parameter, it still isn't any more type-safe, and I still need to do all the type checking and type annotations around it on my own. And well, tRPC is all about full-stack type safety and inference across the board, and decorators don't really allow that.

01:16:26 - Theo

So decorator hell soon? Maybe. It depends

01:16:32 - Dev

on what the new decorators look like, what functionality they bring. But yeah, decorators, it's a nice pattern.

01:16:39 - Anthony Campolo

I just think I gotta be this guy. I do not know what a decorator is. Can someone explain what a decorator is?

01:16:47 - Dev

Yeah. So let's say that you have a function or a class you've defined. On the line just above the definition, like let's say you have a function getUser, so the line right above the function declaration, you will have the decorator, which starts with an at-sign. And then you would have the name of the decorator, which is just a function. And what that does...

01:17:15 - Anthony Campolo

Directive in GraphQL?

01:17:19 - Dev

I'm not sure what a directive in GraphQL is.

01:17:23 - Anthony Campolo

Yeah, okay, I think I know what it is then.

01:17:26 - Dev

Yeah, it's something you put on top of function or class declarations. And basically it kind of has a proxy-like API where it will give you all the details of the class inside the decorator when you define the decorator, and you can add additional functionality to it. Like if you decorate a class with @controller, you can just have a regular class, but then within the decorator you can add additional functionality that tells the framework that this is a controller class and this needs to handle HTTP requests somehow. Hope that makes sense.

01:18:02 - Anthony Campolo

Yeah, it makes sense in the abstract, and it's one of those things where it's hard to map it to something else I already know. I think it's like a GraphQL directive. They both use the at-sign. But that's fine. I get it. I think they're just the same. So, but yeah, continue on. Did you have any other questions, Hacksor, before we get back into whatever Dev's next question was?

01:18:24 - Josh Goldberg

Nope. Thanks, guys.

01:18:26 - Anthony Campolo

Yeah, thanks for joining.

01:18:29 - Dev

Yeah, I think before this we were just talking about what's your top wanted feature in TypeScript. Anthony, do you have any

01:18:42 - Anthony Campolo

Top wanted? I mean, I thought what Josh said about a better CLI and error messaging is good. I mean, for me, most of the issues I had with TypeScript were honestly solved by Create T3 App. My issues were about tsconfig and just, like, how do you get a project started? And once you have a legacy code base that you need to figure out how to work with, how do you know how to configure that? So it's conventions to simplify that. That is what I want. But to me, that's not TypeScript's job, that's a framework's job. So I feel like TypeScript... I'm not deep enough into the language to know what I would even want from it. So yeah.

01:19:19 - Dev

Yeah, I think a lot of these end up coming around to: is this TypeScript's job? My top feature that I would kill for is typed error handling, which is that along with the type of what value something might return, you also get the different types of errors that it might cause. I saw this pattern in Java first, and most other languages have some sort of either-or result data type where you can give it both the result type and the error type. I mean, obviously you can use a third-party library for this that has the type, but JavaScript has built-in error handling, try/catch, and maybe there's some way to embed typed error handling there somehow.

01:20:12 - Josh Goldberg

So I will go ahead and jump forward in saying I, as a former Java programmer from high school, used to really enjoy the error-throwing annotations. But they are completely unsafe. It's impossible to get right. There's a reason why Anders refused to add them to C# and TypeScript. Any function can throw a shocking number of different errors, ranging from array-out-of-bounds to null-reference exceptions, in code that is otherwise completely type-safe. There's no actual way to represent in the type system that a function will only ever throw a certain specified set of errors. You can't even ensure that a function is guaranteed to only ever throw an instance of the Error class, because sometimes someone might throw something that is like a string or an array because they're

01:20:58 - Anthony Campolo

Just what if you made an enum?

01:21:03 - Josh Goldberg

Let's just throw more spicy takes in there. So in actuality, the only guarantee that you have with functions throwing errors is that they might throw anything. So it's the any type, which is kind of implicitly there already, that a function might throw any. So until we have the ability to have 100% type-safe code, which no language in the world, even the fancy, like, '90s-era functional-programming languages, is able to accomplish, we're not going to be able to have actual good type annotations for thrown errors. It's just practically impossible.

01:21:40 - Dev

Yeah, and that's why I prefaced this with that. Is this even TypeScript's job? Is this something even TypeScript can do? Or I think at the very least we can have some sort of native result data structure, like promises were added into the language. Maybe we can add Result to the language so that at the very least we have a de facto way to define if a function can return an error by ourselves instead of just throwing it and hoping that someone catches it.

01:22:14 - Josh Goldberg

Yeah, I think you touched on a really good architectural point that I'm excited to see a lot more people be in agreement with. Go-style: return an error instead of throwing the error. Because I think try/catch is almost always the wrong choice architecturally. We kind of sort of do that with just native unions, where if it's like, let's say a function can either get the text from a file on disk, or it can get an error for why it couldn't read the file on disk, you could just return Promise<string> | Error, or if it's synchronous, then just string | Error. And that's kind of a native result type. Anything more than that...

01:22:53 - Anthony Campolo

That's what I was thinking when I said enum. I meant to say union.

01:22:57 - Josh Goldberg

Oh, I thought you were being...

01:22:59 - Anthony Campolo

I feel like I'm actually not saying something stupid right now, but I've seen... not the right word in that case.

01:23:05 - Josh Goldberg

You were spot on, both of you.

01:23:09 - Dev

Yeah. It's just that it's not really a good API to deal with. What try/catch allows you to do is to just have your happy path and then do the error handling separately. I think some result types can do the same thing in a functional way where you can just say if result.ok, or I'm not exactly sure how... I've looked a little bit into some result data types, but not all of them. But there's a nice API to deal with it instead. If you just return a union of a result or an error, you'll have to do a bunch of if statements after every function call, which doesn't sound the best.

01:23:51 - Josh Goldberg

Yeah, I know this is not actually what you're asking for, but have you poked at the pipeline proposals for JavaScript? I feel like they're kind of sort of overlapping with some of the same intent.

01:24:02 - Dev

I absolutely love that we are getting pipes in JavaScript. I'm very happy about that.

01:24:08 - Josh Goldberg

Yeah.

01:24:09 - Anthony Campolo

Can we talk about optional typing? Continue, Dev. But then we should hit on that at least a little bit.

01:24:16 - Dev

No, we can go now. Go ahead.

01:24:21 - Josh Goldberg

I meant to say pipes, like plumbing, like the piping operator. But I'm also separately very excited about optional type annotations. So, you know, whatever goes.

01:24:30 - Anthony Campolo

Let's hit. Let's hit the pipe first and then we can talk about optional typing.

01:24:36 - Dev

Yeah. So pipes: imagine that you have code where you call a function, but when you're passing in the parameter, that's also a function call. And basically you can have function calls inside function calls inside function calls, and whatever the result of one function is, it goes as a parameter into the second function, and that keeps on happening. The pipeline operator is basically a way to invert how you write that. So basically, instead of calling A to B to C, you would first call C and then you would call B and then you would call A. I think it's really hard... I'm not sure if I'm doing a good job of explaining it, but it's basically a better way to think about nested function calls because it's more in the order of how we think about it. I think Josh can do a better job at explaining it.

01:25:31 - Josh Goldberg

No, I think you actually... that was actually a really good explanation.

01:25:34 - Anthony Campolo

I really think it made sense.

01:25:36 - Josh Goldberg

Yeah. I mean, I don't know of a better way to describe it. I would just Google it. The syntax sort of kind of speaks for itself. It's just a really clear way to do what you just described. Yeah.

01:25:48 - Anthony Campolo

Yeah. Talking about TypeScript is one of the hardest parts about it, I swear.

01:25:54 - Josh Goldberg

Yeah.

01:25:54 - Anthony Campolo

Like Josh, they pay the big bucks.

01:25:57 - Josh Goldberg

Oh, yeah. I earned so much money in open source.

01:26:00 - Theo

That's.

01:26:00 - Josh Goldberg

That's right.

01:26:03 - Anthony Campolo

You'll get there, I'm sure. So, yeah, you want to talk a little about what this optional typing thing is? What's kind of the timeline for it? Why are people excited about it?

01:26:12 - Josh Goldberg

Sure.

01:26:13 - Ishan Anand

Yeah.

01:26:14 - Josh Goldberg

So there are two main components of TypeScript that are important to people. One is the code you write, and then the other is the system that understands that code. The code you write is a superset of JavaScript. Some would call it a subset of JavaScript from a different perspective. Shout-out to that post from Ryan. But yeah, anyway, it's JavaScript plus some syntax for types. That syntax, just the raw code, is pretty much standardized in the JavaScript ecosystem. Both Flow and TypeScript did a lot of very similar syntax-y things. So there's this proposal going through TC39, the JavaScript standards committee, to add a way to indicate types in your JavaScript code native to JavaScript. So an engine or browser, Chromium, whatever, would be able to read JavaScript code that has those types annotated and treat them just like comments. Another name for the proposal was "types as comments." Now, to be clear, this does not add a type system, the other half, to JavaScript. It doesn't add a runtime difference where your code would throw if you pass a string to a function that needs a number.

01:27:24 - Josh Goldberg

It just adds a nicer way to describe, as comments in your code, what you intend your values to be. It's like JSDoc, but better, and it looks like TypeScript. That's really exciting for a few reasons. One, it means that you can just run TypeScript files once this goes in, or you will be able to mostly just run TypeScript files. You won't have to transpile them. It also means that competitors to TypeScript, which I think would be healthy for the ecosystem at this point, would have an easier time. They won't have to reinvent the wheel with syntax parsing. It also means that a lot of tooling around TypeScript and JavaScript will be simpler. We in TypeScript ESLint have to add in a bunch of logic to core ESLint functionality, its rules, to handle TypeScript-specific syntax. It'd be really nice to just move that into ESLint itself. Again, this does not add type checking to JavaScript itself. You would still need another tool such as TypeScript or Flow or Ezno to do that at development time. But it does add the types as comments. So I'm really excited about that.

01:28:27 - Dev

I think this can have the same impact on developer workflows that native ESM modules did, where instead of bundling everything into a single bundle and sending that to the browsers, what things like Vite did was completely ignore the fact that you have to bundle things and just use native modules. What this might do is that you don't even have to transpile TypeScript to JavaScript anymore. You literally just write TypeScript and your source code is what the browsers are looking at, at least in the development workflow. Another huge step of the bundling process gets removed, and the development servers just run so much faster with one less huge step involved.

01:29:22 - Josh Goldberg

Can't wait. I should also... oh, you also asked about timelines. It's going to be a long time before this is in JavaScript. It's a very contentious issue. Even though this "types as comments" approach is similar to the ones taken by, like, PHP, Ruby, Python, to various extents, it's only in stage one, the very first of the four stages for TC39. So don't worry, we're not going to be changing our JavaScript to this in the next year or two.

01:29:48 - Anthony Campolo

Awesome. Well, we are a bit over time here, so I think we're going to close it out here. But thank you so much, everyone, for being here and listening. Thank you, Josh, for joining us. Thank you, Dev and Hacksor and everyone else who came up and asked questions. Please click people's faces and follow them. Where would you like people to go to see your stuff, Josh?

01:30:11 - Josh Goldberg

Ooh, thank you for offering, and also plus one. Thanks, y'all. This was a great discussion. Dev, I'll speak to you now because you're here. This was really fun. I liked chatting with you. Also the other people who chatted, Hacksor, Theo, that SpongeBob kid, et cetera. Thanks for hosting us, JavaScript Jam folks. For me, my GitHub, Mastodon, Twitter, Twitch, and dot-com website are all Joshua K. Goldberg. So, like, follow, subscribe, et cetera there. In a couple weeks I'm going to resume streaming open source stuff on Twitch. I'm almost done setting up my camera. You can buy my book, Learning TypeScript, if you want to learn TypeScript. It's made for people who know JavaScript but maybe don't know TypeScript or other type shenanigans. I work on TypeScript ESLint, which is a website, typescript-eslint.io, that you can visit for the tool. And you should definitely, if you write any TypeScript code, sponsor us. If you don't use us yet, use us. Please use us. If you do use us, let us know how we can make it better for you. I think that's everything.

01:31:16 - Theo

Yeah.

01:31:17 - Anthony Campolo

Awesome. Dev, you want to do a quick little pitch for anything you want to do? I know you're always working on a lot of things. You got a channel, you got stuff to pitch?

01:31:27 - Dev

Sure, yeah. I have a YouTube channel. Last week I made a video about TypeScript return types because that was all the hype. So you can go and watch that. The link is in my bio, my Twitter bio. Today I'm working on a video that I might have out either tonight or early tomorrow. It will be on Domain-Driven Design. That's all I have to pitch. Thank you very much for hosting.

01:31:52 - Anthony Campolo

Then just for fairness' sake, Hacksor, if you got anything to pitch, feel free. You're the last speaker. Then we'll close out.

01:32:01 - Hacksor

Frantically trying to get back to Twitter Spaces. Nothing for me. I mean, just click my head and see if anything I'd built is cool, I guess.

01:32:09 - Anthony Campolo

Thanks so much. Yeah, thanks so much for joining. We do this every week, same time. And yeah, thanks again, Josh, for coming, and we hope to see all of you next time.

01:32:21 - Josh Goldberg

Thanks, Anthony.

01:32:23 - Anthony Campolo

Bye.