Amal Hussein: Okay. Yeah, this is fascinating. I mean, we’ll try to link to either this part of the code, or maybe the PR, or anything – we’ll try to get some info from Evan for folks who wanna dig into the specifics of this… But this is fascinating. I feel like it could be its own show.

So SSR support out of the box, for multiple frameworks. That’s huge. And fast SSR, for local development specifically… Very, very exciting. I don’t know, you haven’t said the word TypeScript yet, so we haven’t heard from Nick, but I can see Nick’s – that’s his magic word. You have to say the word TypeScript. He’ll be like “Did somebody say TypeScript?”

Nick Nisi: Well, I’m so productive with TypeScript I had time for this…

Nick Nisi: You mentioned designing APIs around TypeScript, and what it supports… I’m curious, does that complicate things as you’re looking to upgrade TypeScript, because of maybe workarounds, or ways that you’re reaching for the right type of inference? Does it make it harder to support later versions of TypeScript?

Nick Nisi: Suz, are you currently using TypeScript right now? I’m actually not sure.

Nick Nisi: It really does seem like TypeScript is one of the big winners of 2018. They had version 3.0 come out in the middle of the year, Babel supports it now in Babel 7, and a big thing is that Create React App ships with a flag where you can enable TypeScript support right in that. So it’s easier than ever to adopt it, and it really seems like more and more places are doing that.

Jerod Santo: I can’t believe this could possibly be the case… Is TypeScript the most popular programming language amongst JS Party listeners? [win alert] It absolutely is. Number one spot, TypeScript… Which to me is just proof that Nick Nisi stuffed the ballots, and answered the majority of these responses were all Nick, with different names, like Rick Nisi, Chick Nisi, Flick Nisi… Stuff like that.

[05:56] Nonetheless, the Whatnots have it. So one and two are gone. Chuck and Robbie will be playing this round… And we have three, four and five left on the board. Fellas, you’ve got to match all three of those, and you take home all of round one’s point. Let’s go down to Robbie, it’s your turn. What is our listeners’ most favorite programming language?

Nick Nisi: Meanwhile I’m just over here, writing TypeScript, and completely relying on transpiling.

Nick Nisi: Neovim is actually not written in TypeScript. It's written in – oh man, I don't even know… But it's a more modern version of Vim, meaning that the community is a little more open to contributions and to changes, whereas earlier Vim - they're kind of slowing down in some aspects. There was no way to really run asynchronous jobs; so Neovim came along and they dropped support for a bunch of old cruft, like not needing to run on old Solaris systems, for example… I don't know if that's actually the case, but being able to drop all of that cruft makes the project lighter and makes contributing and welcoming new contributors much easier.

Then they added their own async job support, and then that kind of –

Amal Hussein: Actually, I am too, for what it’s worth, Nick, because that means maybe we can stop saying TypeScript, and we can just go back to saying JavaScript, you know?

Nick Nisi: Yeah… I use ES module-like syntax in TypeScript. And then I rely on tools like Jest. And I haven’t looked at what Jest is actually doing, but it has the ability to mock your dependencies like this, which I assume is just relying on the fact that it’s just an underlying Common.js module that’s actually being run and being able to do that.

So do you see loader hooks as like the solution for those types of problems in the future, when theoretically we’re all just writing straight ESM?

Nick Nisi: Obviously, I’m a pretty big fan of TypeScript, and I think that it’s a great solution for a project like this, and for really any JavaScript project… But for this, I think that it’s really awesome because – there was Flow in there, so when I came in and started looking at the code, I was able to get a little bit of help with understanding what things were, and how things flowed through the application, and where to look for things. I think that having those types there really helped with that, and I think that adding TypeScript will probably only make that simpler… So that’s awesome.

Nick Nisi: As we discussed last week, I’m using TypeScript, which does kind of go in the opposite way and forces you into a build for everything… So the complete opposite of what Alex was saying, as a good starting point. But that’s trading off to give me a bunch more helpful tooling during development, I think. We discussed that last week.

Jerod Santo: So the sign on the window says “The best way to build robust apps in TypeScript.” So if you’re wondering why I had to have Nick here is because this is a TypeScript-focused project, and Nick is a TypeScript-focused person… And so what exactly is Effect doing for people building apps with TypeScript?

Zach Leatherman: Nick gets commission every time he converts a project to TypeScript. [laughter]

Nick Nisi: Yeah, 1,204 lines, with 837 of them being TypeScript. Oh, wait. No. That’s the Dojo version.

Nick Nisi: I also just wanna give props to the TypeScript team for so quickly jumping on and supporting things like JSX with TypeScript. They even changed the casting. It used to be the open angle brackets for casting, and now you can do “as” whatever. That was just immediate so that you wouldn’t get confusing bracket syntax inside of your JSX.

Nick Nisi: That is one of the big things with TypeScript - you can go down that rabbit hole of wanting everything to be perfect, and if it’s something that’s pretty well out of your control, then you end up doing a lot of writing this code that never makes it to runtime, like I said, and that can be really demotivating if you’re trying to do something.

I was trying to use it on a project that was a Chrome extension. This was way back; things have probably gotten much better… But I couldn’t find any types for the APIs that Chrome would give you, and so I just started writing my own. And the ones that I found were broken, or the APIs had changed, so I spent so much time just fixing that. Before I knew it, four hours had passed and I had no code with these types that weren’t really even using right at that second… So I lost momentum on that side project.

Nick Nisi: And it’s TypeScript-first, and… Yeah.

Nick Nisi: Yeah. That’s music to my ears, TypeScript-first. Obviously. Yeah, I’m very excited about that.

Jerod Santo: [00:47:55.03] That’s the hard part for me, because I 100% agree with you… And I get quite curmudgeonly about it. And I think - even just yesterday, Nick Nisi from our JS Party podcast posted some AI-generated rap song into our channel about me and TypeScript, or whatever… And yeah, it was cute. He said, “Finally, a good use of AI.” And he’s just joking, we’re having fun… And my response was like “This is C+ rap. This rap is not good rap. It’s barely entertaining. It’s funny that you applied it to me and TypeScript. That’s what made it funny, was your creativity.” It’s C+ content, and that’s what you’re talking about, very mediocre. It passed the class, but it’s not going to change anybody’s life; it’s not going to be outstanding, or excellent, or any of the things that we desire in great art.

Then I asked myself, “But am I just looking at today’s AI-generated content?” And I’m correct - you guys can correct me if I’m wrong, but I think we’re agreeing - that it’s C+ content. But it’s going to be B+ in ‘25, it’s gonna be B-… No, that’s worse than B+. It’s gonna be A-… You know, it’s going to get to where now it’s indistinguishable from magic, and then we’re not going to be able to distinguish. We’re just seeing it in its infancy, and it’s going to be so much better quickly. And I don’t know the answer to that. Is it going to be so much better quickly? Maybe, Joe, you know more than we do.

Jerod Santo: It’s an entirely different conversation, and one that I’m sure our good friend Nick Nisi will want to be a part of as the TypeScript fanboy of our Changelog community…

Nick Nisi: I think you nailed it. I 100% agree with everything you said. Una, thank you so much for coming on and talking about all of this. There really is so many exciting things that I didn’t even know were there… And the problem with me – I wanted to bring this up, and I won’t get us onto another tangent or anything, but I end up treating CSS these days a lot I treat JavaScript, in that I don’t look at what’s coming new in JavaScript, I look at what’s in something that I can use today. And that’s for me “What does TypeScript support [unintelligible 01:08:48.27] Please support those features.”

Nick Nisi: I was gonna say that we would get to the 37th hour, the 37th straight hour, and we still hadn’t decided between JavaScript and TypeScript, and we’re just having a breakdown…

Amal Hussein: Yeah, I mean, it’s a win/win for everyone. It’s a win/win for users, it’s a win/win for developers, it’s a win/win for the Earth, because that’s literally like less resources and like less bytes across the wire, less internet trash… All kinds of things.

But to get back to the TypeScript problem here, and some of the issues that you described as consumer pain points… I think when you publish these blog posts, you’re airing out the next piece of dirty laundry to go live in the JavaScript community, which is these pain points. So I know you published this blog post on August 8th, it’s had a lot of circulation, and actually, one of our Changelog++ listeners - Nick, if you’re listening - actually requested this episode. They were like “Hey, I’d love hear a discussion on this topic.” And I was like “Well, why don’t we just invite Mark back onto the show? I love my main man Mark, you know?” So you kind of going viral with this post means that yeah, people are feeling this pain as well as you. So can you share some thoughts on that?

Debbie O’Brien: [50:22] Okay. So yeah, Cypress is great. I used to use Cypress for many years, so I come from that world as well. We are newer, so therefore the community is smaller, which is my job, to grow the community. So Playwright’s been around for about two-and-a-half years now, so obviously, we do not have as much workshops out there, and examples, and videos, and stuff, which we are working on and we will have, and thanks to our ambassador page, you’ll be able to find more content there, if that’s what you’re looking for.

When it comes to differences, I guess browser support - now, I know that Cypress has recently added WebKit support, because they’re using the Playwright WebKit to be able to get that… So they’re kind of a little bit on par, I guess, when it comes to the browser testing thanks to our open source work, of course…

Then there’s other things, like multi-language. So this is something that I think is very important if you’re working with a team of many developers who work in different languages. So you can use Playwright in JavaScript, TypeScript, or you can use Playwright in .NET, or you can use Playwright in Java, or in Python. So you now have a team, and maybe - Nick, you’re a Python developer, and Amal, you’re a C# developer, and I’m TypeScript. So now we have different applications, because companies have different applications, and you want to write the test and the code that you’re comfortable with. So you write your tests, we all write different tests, and they’re all different languages, but we have the same library, the same API, the same – everything works the same. So if I read your test, I would understand it; just the syntax is a little different, so I might struggle kind of writing certain syntax, but I could read your test and understand it; you could read my test, Nick, and understand it. And I think that makes it really important that you have one workflow, one way of doing things, one library that people are just – you just have to learn Playwright, and now you can work–

Amal Hussein: Oh, yeah. Let’s talk about that. I wish Nick Nisi was on the show. He’d just perk right up right now. “Did somebody say TypeScript?”

Nick Nisi: [laughs] Okay, so I’ll start off… And I’ll say that something that I learned - I think in the last show I brought up Obsidian, and was talking about that amazing note-taking application, and some cool plugins that they have. Well, I’ve been looking at their plugin API, and trying to write my own, which has been a lot of fun. It’s all in TypeScript, which is just super-easy. You clone a project and get running with it right away. It gives you an ESBuild script that will compile everything for you; you create a manifest and then you can just load it into Obsidian and play with it. And I’ve been creating one that just makes it easier for me to work with GitHub links, because going there, copying like a pull request link and then putting it into my notes for later, just so that I can click on it again to check the status of it, or whatever… Like, it’s just tedious.

So this will just let me type like gh: and then like the repo and the PR number, and it will auto-create a link for it right there, and put a status on it just by hitting the GitHub API and checking all of that. So it makes it really easy to create more of a dashboard of what I’m working on, right from within Obsidian. So I’m pretty excited about that.

I’ve gotten the pieces all together, but nothing tangible as in “It’s doing exactly what I want”, but I get the response from GitHub that I want, and I have made some fake things to inject into the Obsidian renderer… And now it’s just a matter of putting it all together. But I’m pretty excited about that. So I guess that’s the TIL, is the Obsidian plugin API. It’s really cool.