Ep. #111, Learning TypeScript with Josh Goldberg

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Josh Goldberg of Typescript fame. Josh, hello.

Josh Goldberg: Hey, what's up? How's it going?

Brian: It is a pleasure. I've got a full cup of coffee here in my Someone Loves You In Oakland mug.

Josh: Oh, it's beautiful.

Brian: Yeah, yeah. It's-- Basically we decluttered our mug situation because that's the one thing that gets out of hand in our cupboards. But this one made it.

Josh: Oh no.

Brian: But speaking of made it, you made it on the podcast. It was a ping and a followup with a DM saying, "Hey, you should come talk about Typescript here on JAMstack Radio." So why don't you introduce yourself, tell us who you are, what you do and how you got here?

Josh: Sure, I'll start with two things. First, thank you for having me, I'm really excited to be here. Second, we are about to move but otherwise would be going through a mug cleanup. We no longer can fit all of our mugs into the dedicated mug cabinet, so it's really annoying. I don't want to get rid of any of them, I feel your pain.

But hey, everyone. I'm Josh Goldberg. I'm a full time Open Source developer, meaning I work on Open Source software instead of having a job, which is fun. I used to have jobs, I worked at Code Academy and previous to that, Microsoft. But nowadays I tend to do a lot of work on Typescript ESLint which is the tooling that let's you run ESLint on Typescript and a few other Open Source projects.

In general, I also stream on Twitch, talk at conferences and I recently wrote a book, Learning Typescript. If that's a thing you want to do and you like reading books, then I would recommend mine, it's good for that. Am I missing anything?

Brian: I don't know, I'm learning a lot about you just now. I didn't even know you were full time Open Source either, so what projects are you working on?

Josh: So Typescript ESLint is the big one, that's where more than half of my GitHub sponsorship money comes from, technically Open Collective. I also have this side project called Typestat, name probably to be changed, that converts JavaScript to Typescript and then can also improve your Typescript types. So it'll take your JS file, rename it to TS or TSX and fix up the types for you.

Brian: Wow, nice.

Josh: It sounds great, it's a literally unsolvable problem so it's kind of an approximate tool but it's really exciting.

Brian: Yeah. It just pushes you in the right direction, you still got to do some cleanup after the fact?

Josh: Yeah, for sure. There's no codebase that's sensibly written out in beautifully predictable types, everything has some weirdness to it.

Brian: All right. Well, I look forward to proving you wrong one day. Not today. None of my code is in that place.

Josh: Eventually, we all aspire to be there by the time we retire. One of these days.

Brian: Yes, exactly.

Josh: But yeah, those are the two main ones and then I have random other side projects. I have this library that hooks up with the Konami code in your browser to little fireworks of emojis exploding on the page that I'm trying to get sites to use as an Easter Egg. But those are the main one.

Brian: Cool, yeah. We'll circle back on the Open Source thing, but I wanted to actually just... Can we set the stage and say what is Typescript?

Josh: Absolutely. Typescript is a superset of JavaScript, which means it is the JavaScript language, you can write JavaScript code and it counts as Typescript, but it also adds type annotations which are ways for you in your source code to describe what things are supposed to be. For example, you might describe that a function takes in a single parameter who's type is String.

If you ever use JSDoc, little /** comments on top of things to declare what they do and their types, it's just the types portion of that. And because it let's you declare types, it then enables a whole bunch of awesome features like really good editor tooling that let's you to go to definition, find all references, do refactor stuff like that.

Brian: Excellent, yeah. How long have you been in the Typescript space? Because we can do a little bit of storytelling, I'm curious as to where did you inject yourself in the story?

Josh: I started, I think, in maybe 2014 or so. Maybe 2015.

Brian: Wow. I didn't even know it was around at that. So 2015 is around when I started toying around with it. I think about 2014 I actually rewrote the app. The company I was working at the time, we went from Coffeescript to JavaScript, so the ES6 at the time. I didn't actually know JavaScript very well until that experience. You had mentioned your JavaScript to Typescript converter, I used a tool very similar where it was Coffeescript to JavaScript and I still had to do a lot of cleanup.

But it got me pushed in the right direction to understand, "Okay, this is what prototypes are in JavaScript and et cetera." I think at that time ES6 forced us into classes for a hot minute. But what I'm getting at is I learned JavaScript pretty well in 2014. Typescript I think I didn't actually start really touching until 2015. I didn't even know it was around prior to that, because I remember doing React Flow was the thing that everyone was pushing towards.

I honesty don't know if Flow is still around. But it was basically adding types to your React components and enforcing things like props. There were some native features inside of React that did some of this, but I guess what I'm getting at is there was a point where everyone was trying new things out now that we have this next level JavaScript and it seemed like we were slingshotting tasks at Typescript.

I wrote some Go, I wrote a little bit of Rust, I messed around in types in Objective C when I was doing mobile apps and I knew enough that I didn't want to do that again. I didn't know the value of why you would have types versus... I want Dynamic JavaScript, let me just put whatever I want as an argument, and then we'll move on.

Now, fast forward to this point for, man, math, six years later, seven years later, now I totally get it. I got it for libraries, being able to when you export stuff, doing this sort of integration with VS Code, you identify, "Okay, this is what the API is going to give you. This should be a string, whatever." But now I get it even more, where I just know my site is going to run. If I deploy it, I know it's going to run consistently and there's not a weird, undefined issue somewhere, which has plagued my React code for years.

Josh: Same, yeah. Typescript has got a lot more powerful over the years. Fun fact, it actually was first made available publicly in 2012. There are so many features of Typescript now that seem incredibly important and essential, that you wouldn't be able to use Typescript effectively without, but a lot of them came out in the last few years.

I also kind of miss the time when everything was in flux, is it going to be Flow or Typescript or whatever? Flow is still around, most Open Source projects don't use it, Facebook's Meta still uses it, I guess. It's apparently an excellent language.

One of the other Typescript ESLint maintainers actually is at Meta and I believe either works on or heavily with Flow and is in love with the language for many good reasons that I don't know. But yeah, Typescript has gotten really good and I'm excited that it's become the standard for enterprise apps the last few years.

Brian: That's interesting to hear too as well, because I love the fact that it's still alive and well, because I'm also a GraphGo user and Relay is an excellent tool. Relay has advanced by so much further than so many other tools, consumer GraphQL. But it's an Open Source project and it's mostly used only by Facebook at this point, or the Facebook team inside of Meta.

Yeah, it's one of those things, maybe it was just too soon for us because I was a huge Relay fan, and same thing with Flow. We actually started using Flow when I was early days at Netlify, as a test. It became more of an annoyance for us, so we ended up ripping it out, but we tested it in a few different places, tested Typescript, and made the ultimate decision like, "Lets not move forward at that time with something."

I don't know if we were recording at this point, but it's the difference between starting with Typescript versus bolting it on after the fact in a legacy app is a completely different experience. So I'm just curious if you could further comment on that?

Josh: Yeah, I think that was before we were recording. Yeah, Typescript is very different as an experience.

I think the two polar opposites I see people go through is their first Typescript experience when they have a large app which was not designed to be type safe, when it has what I would consider to be architectural defects. Type safety is not a thing unique to Typescript, it's not like you convert to Typescript and now you care about the types of your code. Typescript is just exposing the value types, the things that were already there in your codebase.

So if it's hard to type your code in Typescript these days, it might be that your code is just weird and wacky and hard to conceptualize. So you start off with a codebase that is older, pre Typescript and you yourself don't know a lot about Typescript, that is just a heck of an experience in positive and negative ways, right?

It's a good learning experience. But then the other side is you know Typescript now and you either start from scratch or join a project that is made for Typescript with type safety in mind, with modern principles, and it's just a pleasure. It's a real breeze, right? You've been doing Typescript recently and I'm guessing, has your experience gotten more positive as you've gained familiarity in codebases?

Brian: Oh yeah, once I stop avoiding it. So my introduction to Typescript as of recent, so a couple years ago GitHub had a bunch of third party libraries like ProBot, very Typescript heavy, a lot of their earlier GitHub actions, examples were all Typescript heavy so I knew it from... If somebody had already set it up, I'm like, "Okay, I'll just make it work."

Actually it's a good rails, I don't know if rails is a good term, but basically guardrails to add new code or adjust code or leverage the library. But as of recent, OpenSauced had a rewrite to go directly... it's one of those things where it was a meme, where people would try, they would open an issue and be like, "This project doesn't have Typescript. Issue, convert project to Typescript." It's like, "Okay, cool."

Josh: Oh boy.

Brian: If you want to do that, feel free, create another branch, but try to keep up while we're still shipping more features. So that was one of those things that it was not obtainable to convert legacy projects to Typescript without halting production altogether. But we did it, we did it in OpenSauced because we had a project that was feature complete, it was a web app that was getting contribution but it got a slowdown, one of my contributors were like, "Hey, I converted everything to Typescript."

I was like, "Cool, let's get it merged, let's try it out." And it was nice, it was actually really nice to interact with. We converted another project to Typescript and I started learning Typescript based on those two projects as I was contributing. I kept doing everything wrong and then just this week I realized that we had this singular indexed .DTS file that had all of our interfaces and types in there, and I was like, "Oh, that makes so much more sense. We can just import from here and then we can pass this around to even new projects."

And then everything just clicked, and I was like, "Oh, this is extremely valuable because we're building the same stuff over and over again in multiple projects. We could just have this file walk around with us and share this thing."

Josh: That's beautiful. Out of curiosity, one of the features that Typescript has gotten much better at over the last few years is incremental conversions. They support Allow JS, which allows you Include JS, even Check JS. Did you experiment at all with partial conversions, one file at a time type stuff?

Brian: We did, for the first project we did do some partial... I was basically introducing more JavaScript after Typescript was already around, and the agreement that we had was this one contributor, Ted, shout out to Ted, he was actually just converting stuff for me on the fly. He opened a PR, he's like, "Okay, here's types." And I'm like, "Okay, cool. Thanks so much. Appreciate that." So I don't think we were using any of those tools like Allow JS or anything like that, but those are good to know.

Josh: Yeah. I go back and forth in my mind on them, because they do allow you to incrementally adopt, but then it's hard to get it right. You have to know the standard order to do things. You shouldn't convert to Typescript, your core, most important file and then have it depend on JavaScript files, your types get all messed up. It's a whole thing. But when done right it's very pleasant.

I did a conversion recently where I basically started up the Leaf nodes, the React components that were like the buttons and the lower level things and then worked towards the pages in this Next JS app, and it's so incredibly satisfying, getting that GitHub JavaScript number down to whatever, zero or 0.1%. It's a really good feeling.

Brian: Is it common for folks to even approach converting Typescript projects from JS to Typescript nowadays? Are people seeing the value?

Josh: I think so. I think the Typescript evangelism has won pretty heavily. Typescript, like every technology, goes through a hype cycle where people get really excited at first and then they all hate it because they try it out and have found the flaws, and then it plateaus to a reasonable level. I think we've hit the reasonable level for Typescript, I think the term is Gartner Hype cycle. I've been using it.

Typescript is really good once you have more than a few files, and it's kind of annoying if you don't know it well and/or you only have one or two files. So people I think have stopped getting annoyed at it for not being a great experience on their tiny, little Node apps, but enough of us have fixed and/or found bugs at scale by converting to Typescript, that we've realized like you said, this is the way now, this is the right thing.

Brian: Yeah. The one most recent one, and it's almost comical because I was just doing work just last weekend where I was importing data from the API, the API is giving me proper data, but then I was basically... There's that thing in React where you're importing data, it's not in React, it's a JavaScript thing. But I'm importing data and it starts at undefined first, and then it fetches the data.

So I'm not doing async stuff, I should be, and that was the fix. But it was that moment where the data that I'm trying to get from the API is undefined, so what do I do with that? Well, I should probably instead of checking a type for undefine, which is probably a code smell, we actually have a Is Loading type, which is a Boolean. So if the Boolean for Is Loading is true or false, that works, and then if it's True we don't even attempt to fetch the data or put the data on the page.

So now we've circumvented the undefined, but I wasn't pushed in this direction until my types were like, "Hey, guess what? There's a possibility this is undefined. What are you going to do about it?" It's prodding me and telling me to do something better.

Josh: I love it. That's the startup Ah Ha Moment that everyone is going for. And actually tying back to the history of Typescript, I think people have gotten much better at understanding how to market Typescript, in large part because we understand much better what it's really good for.

When Typescript first came out, transpilers like Babble were not very popular. SWC was years and years away. I don't even know if Rust was stable at that point, back in 2012. So Typescript was advertised both as having types, which at the time were pretty useful but not nearly as useful, good as they are today, and that also you could use classes and other new JavaScript features. Wow, classes! What a great thing.

Then a lot of people started resenting Typescript, "Oh, are we just a bunch of Java programmers now? Classes?" But now we advertise Typescript as, "Oh, it'll find you bugs, it'll help you develop." These really key, useful things, that if Typescript were a startup these would be the bullet points just above the call to action on the homepage.

Brian: I was just having a conversation with Theo who's running Ping.DG. He's a big Typescript fan, a big TRPC fan and he had mentioned in passing, he's like, "If you have Typescript, you don't need Unit Test." And I'm actually testing that theory right now in my project, as I'm going through my unit tests and when I'm actually testing, that also backs up with types. I'm on the fence on it at the moment. But I do feel a lot more confidence even when I don't have tests, because I have types.

Josh: Yeah. Theo is a fantastic individual with great opinions. This is one of the opinions where I see its value on certain types of projects, especially if it's the type of project you can easily end to end or integration test. But I don't agree with it as a blanket statement, and I think it's... I don't want to say harmful, I think that's more accusatory than I'm trying to come across here, that we are.

But I think the marketing can confuse people when you say, "Typescript replaces the need for unit tests," because a lot of people, especially new folks in tech, they just take what they're saying online as an opinion and go with it. Typescript can't always replace, most of the time I don't think it can replace well written, logical unit tests. Sometimes maybe.

But I don't want people to think that Typescript is a replacement for it. In my experience it works best as a trim down where you don't have to unit test dumb stuff, "What if we pass undefined? What if we pass null to this thing?"It really just verifies your types, it doesn't check for application correctness.

Brian: Yeah. A lot of my libraries, and this is actually where I got my teeth cut on Typescript, is I have these lib folders. It's the utils, the functions folder that you pass around. In the context of OpenSauced, we show GitHub stars and GitHub stars can be in the tens of thousands, hundreds of thousands, or it could be like 1, 2, 3. We have this one function that takes the number and humanizes it.

So taking 10,000 stars and make it 10K instead, basically add the K to the end of the 1,000 mark. It's just a practice I learned in displaying data on the page. I haven't put it on NPM because I just basically copy and paste it everywhere. I should probably share it as a cool, little tool for anybody. But there's other solutions people can use. What I'm getting at is I ended up adding types to that, and then I wrote tests for that.

Then I think to your point, I don't need to test for undefined, or I don't need to test to see if this thing is a string. If it's a string or if it's a number, I can already coerce it into what I need it to be so I can stop testing that. But then I can test what happens if it's a million, what happens if we get a bazillion stars. What does that look like?

So I can test those bigger edge cases, functionality as opposed to... And that's the unit testing I expect to do when I walk through my... I don't need to do TBD all the time, but for small things like this, I'll start with a test and then try to get it to work. TBD is an old habit that I pull out every now and then when I want to feel cool on livestreams.

Josh: Oh, you livestream TBD? That's intense.

Brian: It's been a while, but yeah. Every now and then if I'm feeling dangerous, we'll start with a test.

Josh: I love it. Yeah, I think it's unfortunate that types and tests both begin with the letter T because I have been playing around with the idea of types driven development where you write the types first and then the code to satisfy it. It's not unique to me, other people have mentioned this, and I think both are pretty awesome ways of doing things if you can both remember and force yourself to do them right.

That's such a great example of a unit test, by the way. Plus one to you, that's something where both Typescript helps you not have to satisfy or test for silly edge cases, but is also something that that's an application correctness concern like what do you do at 12 million or whatnot?

Brian: Yeah. I guess it's funny, because I haven't been full time coding for a long time. I just recently got back into writing code full time over the summer, and yeah, it's just one of those practices as a junior engineer years ago, I kept writing dumb stuff and I kept getting pushback on how useful, how not useful this stuff is because it just becomes a code smell or whatever.

But yeah, I guess it's just, again, old habits. But the one thing I'd actually mention, we've kind of covered how Typescript embedded itself in the JavaScript community. I'm curious, is there no turning back at this point? Should everyone invest their learning into your book and just take the plunge into Typescript?

Josh: Well, obviously yes, everyone should buy my book and also rate it 5 stars on Amazon. You would not believe how helpful that is. Actually, surprisingly helpful for us independent publisher people. Just kidding, it's through O'Reilly. I don't know. I think short term, 100% yes, absolutely. Medium term, like 90, 95%. Typescript is here to stay, same with JavaScript, and there's no reasonable, good competitor to Typescript out now, nor do I know of one in the making.

There are other languages like Reason and is it Rescript now? Or was? I forget. And Helm, that are supposed to be fantastic, but they don't have a lot of adoption because they don't interact super well with your existing application. So I don't see Typescript going anywhere. Long term, like years and years and years from now when Wasm can directly manipulate DOM and all these other wacky things have happened, then maybe not.

But all I see on job boards are enterprise, Typescript, new startup, Typescript, mid scale business, Typescript. Everyone is using Typescript, and those who aren't are oftentimes trying to use Typescript. So yeah, I'd say go for it. You don't need to know it, there are a bajillion things you can learn in tech, and within that in web. But no, it's top of the pile. I've been wanting to learn TRPC, I just keep not having the time to do more than the Hello World. That looks fantastic too.

Brian: Yeah. That's the thing, I don't know how long it's been around. It's one of those technologies that I'm still waiting for the infancy to die off a bit, because I've definitely adopted GraphQL, being one of them. I've adopted a couple different tools early on in its infancy, and then get burned on just trying to keep up while I'm also trying to do some other stuff. So TRPC is something on my list of things to implement in my new projects moving forward, but I don't have any new projects yet. I'm still trying to get this current one shipped.

Josh: For sure. By the way, good luck on that. I'm very excited about OpenSauced, signed up. There's also a really interesting parallel between how... It's weird calling GraphQL old. I remember a time ago when it wasn't old. But slightly older approaches like GraphQL to slightly newer ones like TRPC, TRPC almost assumes that you're using Typescript, the way it's setup. Maybe you can use it with vanilla JS, but it's so much better with TS, and that's an assumption that would not have flowed at all, like five years ago.

People would've confused it, or thought of it as a niche library. But now because so many people are using it in the way it's meant to be used, with Typescript, with a fully typed application, it's so much more powerful and amazing, and you can get all these great features from its dev experience. It's really cool. It's where the industry is going I think.

Brian: Yeah, yeah. And honestly, I wanted to take us just a step aside from just the JavaScript community as a whole and talk about that. So you mentioned Babel, and then you mentioned SWC. We've now evolved into a new compiler, we also have new run times, we also have Typescript. I'm curious, where do you see the future of JavaScript heading towards?

Josh: I'm so excited about this. For context, my answer on these types of questions are never going to be as good as Swyx's. So Third Age of JavaScript, shout out that talk series. But here's my medium term prediction and then I'll give you my long term. Medium, I think we're going to continue to see waves of improvements, alternate between primitives like Typescript, JavaScript itself, CSS, and then the things that build those primitives for you like Remix, Next JS, Astro.

As we keep getting better primitives, we learn new ways of doing things best, and then frameworks can use those new ways of doing things best to make the experience better for you. A lot of people like to complain about JavaScript tooling now, "Oh, in the olden days it was simpler." First of all, look at a common jQuery application from 2010 and you will vomit compared to today's code in your least favorite framework.

Second of all, things today are so nice compared to how they used to be for tooling. You can just startup a new Remix or Next project in like, what? 30 seconds? Whatever the Yarn install time is. Beautiful. So my prediction is we'll keep going higher in the stack, higher, better abstractions that make you take less time and code to do the common things. Medium term.

Long term, I think once WASM is able to directly target DOM, meaning you can write a Rust thing and not have a weird performance overhead of having to go through JavaScript to talk to the DOM, people are going to start writing applications more and more. We actually have already seen this with Blazor, which I guess is like a Microsoft thing but I've started to see companies use it.

Brian: Yeah. I think it's C# based.

Josh: Yeah. I mean, C# is a lovely language. I miss working in it sometimes. Yeah, so I think long term we're going to, for better or for worse, lose the standardization on the web or slowly chip away at that standardization. My hope is that we'll replace it with a language that's like JavaScript, but doesn't have all the dumb things like two null values. That would be nice. But I don't know, it's going to be a Wild West and impossible, I think, to predict what happens once that gets mainstream. What about you, out of curiosity?

Brian: Yeah, I agree with you. There's the idea of primitives in the JavaScript ecosystem, so obviously JavaScript being one of them, but if you want to go down to runtime primitives, I think that we're going to have a lot more flexibility. The thing that I'm excited about is the runtimes. All these edge functions and these edge runtimes, like Deno and now Bun is up and coming as well. Still not production ready but it'll get there.

That opens up the game, because what I do is I've been doing a lot of livestreaming as I mentioned, one of the things about livestreaming is the first thing you do is you build a chat app, you livestream that because it's like getting your light saber as a Jedi. You've got to build a chat app and then livestream that. But what I've learned is that OBS, it also runs another offshoot of V8 and it gives you some limits of what you could do in JavaScript if you want to write a simple interaction with it.

If you bring in one of these edge runtimes, so think about streaming on the edge with all these services and the cool tools that are coming out, now you can do really interesting things. Imagine shipping a quick Netlify function to update your overlay that's just JavaScript and CSS, or it could be Eleventy or whatever it is. But also interacts through your edge functions to then trigger back and forth, like someone says something in chat.

That's what I want to see, but I don't think anybody's paying attention to livestreaming services and OBS, but I think once Deno becomes ready for prime time, Bun gets ready for primetime or even WASM gets ready for something like that interaction, now I can do this regular Hello World JavaScript enough to make cool interactions on a livestream.

Josh: Wait, I actually love this. I've been getting into OBS, I only relatively recently started understanding anything with streaming and that's such a cool idea. I had no idea it had a V8 shenanigan in there, though. That's awesome.

Brian: Yeah. It's running JavaScript, it's got a server. Once you look in the hood, I think it's written in C++ to be honest, so it's got some other bells and whistles that you can work around. But I know folks who've built stuff on top, that plugs into stuff like OBS, I've got enough people I can ask questions to. I just don't know all that low level stuff, so if I have an extraction that I can be confirmed my JavaScript will run or whatever code I write will run, that opens up the game for any...

Just like what the web did, or even things like Next did to the React ecosystem, or what jQuery did to the frontend. It's basically giving you an abstraction that you can interact with, without even needing to know what's happening in the Chrome tab. I think that future is what I look forward to, you can go through a boot camp and start shipping production code for Twitch or for Facebook or whatever.

Josh: Yeah. So many companies for years and years, one of their biggest dev problems which I'm sure you, as a dev advocate person have seen a lot of is, "Well, once you finish your three week intensive training to learn how to ship code to internal QA and then the other two weeks for production, then you're ready to go." That's the length of an internship for some people. But now with code spaces and Next JS and all these other fancy innovations, yeah, plus one. It's really exciting. Velocity.

Brian: Yeah, yeah. Absolutely amazing and exciting. We're almost approaching time, so I could probably talk forever about this subject but I do want to go back into your really quick conversation about your Open Source work and how you got into Open Source full time. How did you basically make the plunge to say, "You know what? This insolent Typescript stuff, this is what I want to do with my free time, we're going to figure out how to pay the bills"?

Josh: First of all, shout out to my spouse, Mariah, who I'm picking off of for health insurance. Without her health insurance I would probably not be doing this. But I've always really had a passion and excitement and enthusiasm for nitpicking at enterprise scale, as I call it. I like taking a piece of code and being able to tell as much information about it as soon as possible. I don't like having to wait until I've hit some 14 mysterious commands to get this onto a production website before I can really debug it.

So getting that live feedback and telling me, "Oh, you caused a bug here because you created a promise and never awaited it or whatever," that to me is a beautiful thing. We were talking about primitives, every low level thing helps improve the higher stuff above it. The further down you go in the primitive layers, if you're talking about Typescript rather than, say, React or NextJS above that, then you can really make a large impact with every change you make.

So between really enjoying the work and feeling very positive about the scale of impact, I just loved it. I started with TSLint, which for those who don't remember, is a Linter that was like ESLint for Typescript, it was Typescript native. It had a couple problems with it. One, it was made by Palantir which is a company that a lot of people don't feel comfortable taking code from, so even though it was Open Source and I was never employed or paid by Palantir, that was still a thing.

The second is that TSLine is not the same as ESLint, so any time anyone wrote anything for one, we'd then have to port it to the other and ESLint was way more popular so it was just not as good on TSLint. So after TSLint got deprecated and Typescript ESLint became the standard tooling, that's after a while where I started helping out with maintenance.

I also do a lot of random other things like contributing to Typescript itself, which is actually really fun and I'd highly recommend. So I just did more and more over time until eventually I realized I don't really want a full time job. I miss parts of it like having coworkers and mentors and mentees, but Open Source just makes me happy. I feel like I'm doing good work.

Brian: Excellent. Yeah, looking forward to chatting more about your Open Source journey and I'll definitely give you a sneak peek of the OpenSauced platform that we'll be shipping in a few weeks. So folks, definitely follow me on Twitter, follow OpenSauced on Twitter if you want more details on that. But with that, I wanted to transition to picks.

These are Jam Picks, things that we're jamming on, could be music, could be food related, all of the above. If you don't mind, I'll go first, I've got a couple picks. One thing that I wanted to mention is the OSRG Open Source Rig Guild. This is a community, a community of only a handful of folks, maybe 20 folks in a Discord and what they do, what they have fun with is they've actually been converting JavaScript projects to Typescript for nonprofits.

So there's a lot of nonprofit sites that were built in whatever web framework of choice, and they recently converted Youarerad.org, which is a... Sorry, I'm not going to pitch the actual nonprofit well, but basically they provide mental health services or streamers and gamers and E sports folks. Yeah, it's built in NextJS, they wanted to update to be able to provide extra features on their site.

The Open Source Rig Guild actually got together and converted the entire project to Typescript. It's a group of 20 people, just attacking the problem all at once. Pretty cool, check it out. The other pick I want to mention is I actually just got a new car and it's the Tesla Model Y. I waited 10 months for this thing. It was more of like a spur of the moment, it was like, "I know I'm going to get a new car. I know I don't want a gas car. What are the options? Let me just go ahead and put a pre order on a Tesla Model Y because I watched a YouTube video."

Lo and behold, 10 months later it's like, "Hey, your car's ready." I completely gave up hope on this thing because of all the shortages. I actually really like the car. Actually, Josh, have you been inside of a Tesla?

Josh: I don't think I have, actually, in my life. No.

Brian: Okay, yeah. For whatever reason, Ubers and Lyfts, they're all Teslas now. I think because of gas prices. So I got to ride in quite a few Ubers and Lyfts locally. Yeah, I'm a big fan. I've got a lot of friends who have Teslas. The price point is slightly high, it's a lot higher than the one I pre ordered a year ago, so definitely pay attention to the price.

But yeah, I ended up getting the blue, Model Y, long range model. The inside is almost as if you're driving inside of an iPhone, basically, if I explained that correctly. It's super limited situation, no bells and whistles, except a giant iPad-like screen in the middle that does everything for you.

The thing that's concerning, I guess my review, is every now and then if it's too cold outside at night the screen sometimes freezes so I have to hold the two buttons on the steering wheel to refresh it and I've probably done that like 10 times since I got the thing two months ago. So that's a little interesting, but luckily I know how to use an iPhone and I know how to refresh devices.

Josh: That's scary. Do you worry about that happening at an inopportune moment?

Brian: Yeah, the car still works. It usually happens when I first start it, so if it's frozen I'll just refresh it before I hit the road. It's never frozen mid drive or anything like that. But the only thing that I think shut down is your turn signal. I don't know, maybe I'm just exposing this stuff for whatever the safety regulations.

But the turn signal and stuff like that doesn't work when it's refreshing the screen. Everything else works, you can still drive the car no problem. You just don't have your speedometer, you can't see your speedometer and you can't use a turn signal.

Josh: That only makes me feel a little better, but I'm glad it's not quite as bad.

Brian: Yeah, I don't have the full self driving. I don't agree with that, so that's a scary thing. Everything else is pretty cool.

Josh: Can I shout out your first pick? The Open Source Rig Guild? I had no idea these folks exist. First of all, because podcasts are audio only, I want to verbally describe their logo. It's an angry, I believe koala, on top of a shield with two swords. This is a building thing. Second of all, converting JavaScript to Typescript has been one of my sub passions within Open Source. I wrote a tool to do it somewhat okay. I'm joining these people, thank you very much for this introduction.

Brian: Excellent, yeah. Jacob who runs this organization, this little group. He's a gamer himself, he likes esports and things like that so he set it up in a way that's just like raiding, if you play Starcraft or whatnot, or World of Warcraft, League of Legends. I don't know all the games that are out there. You usually have a group that you get together and you all attack a problem or attack a boss the same time, and Typescript has been their recent boss. Which I love the concept so much that I'm looking forward to partnering with them with OpenSauced in the future.

Josh: That's awesome. I like the description of Typescript as boss also, it's a nice, little bonus.

Brian: Yeah, excellent. Do you have any picks for us?

Josh: I do. I have a couple of picks. One, DocuSource which is a lovely... I don't even know how to describe it. It calls itself a docs site generator, akin to Next JS or Remix but for static sites, so maybe closer to Gatsby. But it's also just really good for static sites in general. LearningTypeScript.com, shout out, buy it and rate five stars, is built on DocuSource. TypeScriptESLint.IO is built on DocuSource.

They just had a 2.0. It's fantastic, they do so much stuff for you. It somehow at the same time is also super configurable, so it feels seamless when you're just getting something spun up quickly where you just want to write a few markdown files and have a really good looking doc site. But then also if you want to auto generate those files or have tables of whatever based off of them, it's also doable. So shout out. They, congrats, had a 2.0 release recently.

Brian: Nice. Yeah, we were using DocuSource for Docs.OpenSauced.Pizza as well. Wonderful service. I knew the original team that put them together inside of Meta, and happy that this thing is still going along.

Josh: Also, wonderful URL. Oh, there it is. You can sort of tell now when a site is DocuSource. I think it's good, it's nice to standardize. They're also super accessible if I need help, which is hard to find in smaller, less maintained projects. So it's really nice to have a solid, really good doc site on the web.

Brian: Yeah. We actually have a GitHub action because DocuSource, it's structured the same way, the generation. There's a GitHub action that exports your DocuSource site into a PDF. So if you wanted to turn your docs into a book, you could pretty easily.

Josh: That's so smart. I would love that. It would be cool to have a book version, a service worker PWA version, you could install. I remember at Code Academy we made a PWA version of the Code Academy site, which is a little silly because you need an online service to execute a lot of the environments. But it's still very nice, at the very least for performance, just to not have to load pages when you load pages.

Anyway, my second pick is Notion and Obsidian. I use Notion personally. People keep telling me to use Obsidian, and I will eventually. But yeah, Notion, it's like Google Sheets and Docs/Word Web and Excel Web and whatever. They had kind of like a mark down, newer version come out so you can make documents and then each document can have just regular text, bold emojis, little call outs and quotes, but then you can also embed tables with sorting and filtering and formula equations.

I do everything in Notion now, I plan my vacations, we're moving to Philadelphia soon, my moving schedule is a formula sheet on Notion based off of where different items are in the move in the original house. Very exciting stuff. Then Obsidian is like that, it's either Open Source or more self hosted based. I forget exactly. Okay, there you go. You've used these things before.

Brian: Yeah. I've used it from somebody else at Netlify, they're a big fan, and did a whole Learn With Jason about it. That's where I learned of how it works. I actually started using it, but anyway, I was going to recommend my other thing but I'll save that for a future pick. I use a similar tool, but it's quite different.

Josh: Oh, similar but quite different. I'm excited to learn this in the future.

Brian: Yeah. Anyway, we'll just add another pick. Why not? StashPad, StashPad. I started using Notion and then because for the show notes for anybody who's ever been here on this podcast knows, I use PaperDocs out of inertia. I started using it like eight years ago, just kept doing it. But for any sort of engineering, trying to keep historical record of how I approached a problem or my to do list in my 101s with my coworkers and stuff like that, I put it into a StashPad.

Just like Git Stash, very similar. That's my new tool. But I didn't want to supersede your Notion pick, because I'm also a big fan of Notion as well. It's a rabbit hole you can get into, linking stuff together.

Josh: Talking about primitives, in 10 years this will have been a solved problem with two or three major, main players. But for now, this is wonderful, these are all different and beautiful. Their landing page has deep sea creatures on it. This is awesome. Thank you for the pick.

Brian: Excellent. Well, with that, those were our picks. Josh, thanks so much for catching me up with the world of Typescript. I'm actually going to pick up your book, to be quite honest. I love having hard copies. Actually I have a bunch of Manning and O'Reilly books right behind me, so yeah, I just love having the book, laying on the couch, scrolling through ideas. Maybe pulling up a laptop next to it. But yeah, going to definitely check out the book. Remind me, the book is Learning Typescript?

Josh: Yes. And it's LearningTypescript.com, with or without a hyphen.

Brian: Perfect. Well, with that, going to check that out. And listeners, keep spreading the Jam.