A Nick-level emergency

Hello, party animals. I’m Jerod, your internet friend, here with an emergency pod that’s not really an emergency, but Nick declared it a state of emergency in order to continuously troll me… Nick, welcome to this emergency podcast.

Ahoy-hoy. Hi, Jerod.

How are you doing, man?

Fantastic, today.

You look happy, you look excited… There’s TS emoji flying in our JS Party channel on Slack, so I feel like something’s going on in the TS world… I’m not sure what that means, what it stands for, but - Kball’s also here. What’s up, Kball?

Hey. I’m excited to have a tech emergency, and not all the drama life emergency stuff that’s been going on in the world the last couple weeks.

Yeah, it’s been exciting times here in these United States, and probably all around the world…

Any of you crowdstruck?

I did not get crowdstruck. Nick, did you?

I was on vacation. I was on a boat and I didn’t know that anything happened.

Did the boat reboot?

Nope.

Nice. Very, very nice. Well, we are not here to talk global IT outages, although we certainly could. We’re here to talk about Node.js, because this is JSParty, and we’re talking news… And the Node team’s been making some moves, man. I mean, they’ve been doing stuff, and so we’re here for it… And Nick is here for this first one, which is that they’ve added an experimental feature to strip TypeScript from the face of the Earth – oh no, to strip TypeScript types from the code it runs. Honestly, I don’t even know what that means. I’m not sure why everybody’s freaking out in the channel, and saying we have to record a podcast about this… So Nick, please. Illuminate.

Yeah. So when you write TypeScript - fun fact, it’s not really runnable, because there’s no runtime that actually runs it. So any runtime that does converts it to JavaScript, which effectively just removes the types and then executes it. So the types are just there for your pleasure, as you’re developing… But we use a bunch of third party tools, and now we get to use less third party tools, because Node can just do it natively. And that’s what this flag does, which is –experimentalstriptypes. That will just strip the types, exactly what it says. It sounds exciting, but we’ve been able to do this for a long time, with either other tools, just running it through Vite, for example, or something else… Or just using a custom loader, like tsimp. It’s effectively like the same. You just pass it a flag.

Tsimp.

Yeah.

I heard about that on your podcast with Josh Goldberg.

Now you don’t need a build step, though.

Yeah.

Yes! Okay, now I’m getting excited, Kball. See, Kball knows how to speak my language. Nick, you do not. You only speak the language of TypeScript and other various Vim things.

I was just listening to your Adam Lisagor podcast, and I don’t think that you explained what your love language is. So… Is it no build step? Is that your love language? [laughter]

My love language, it turns out, is English. That’s my favorite. It’s my best. It’s my first, my last, and my everything. But I’m here for no build step. I’m also here for stripping TypeScript out of things. But if this is already available in a bunch of stuff… Like, people are genuinely excited about it; is it just because it’s more official, it’s more proper, it’s less third party, and becoming more first party? Is that what the assignment’s all about?

Yeah, I think that anytime that there’s movement from the tool itself into this, it’s going to – this is an experimental flag for now. We’ll see what it actually culminates into… But I think that this is probably – you probably trace this feature back to just competition working; having other runtimes like Deno, like Bun, that more natively support TypeScript. They don’t want to be left as the only ones, and TypeScript has pretty much won, so it should be supported in this way. The browser has plans, potentially, with the type – what is it, type annotations?

Type annotations…

Yeah. So it’s getting there.

Mm-hm. Kball? Additions, subtractions? Multiplications?

I mean, I was just admiring that masterful trolling by Nick, of “TypeScript has basically won.”

[laughs] I did not engage with that sentence. I moved on.

I know. That’s why I brought it back for you.

Thank you. I appreciate that.

No, I mean, honestly, I’m team build step. I mean, we know this from previoys pods. I think I’m more in favor of doing interesting things with the build than vanilla stripping TypeScript types out with a build. But if you’re building already, does it really matter? So I’m not sure this is quite the emergency level that I would have flagged, but you know, once again…

Me neither.

Where’s your sense of excitement…?!

See, we have to have reasons for people to tune in, Kball… [laughs]

But Jerod, actually, I have a way forward for you to do TypeScript, and not worry about TypeScript so much, which is LLM-based coding tools are the future. And you don’t have to deal with TypeScript, you just tell the machine learning model “Write this in TypeScript”, and then you’re done.

[06:10] I could be convinced of that, perhaps. If I didn’t have to touch any of the artifacts either… Like, if we got far enough away that I don’t even effectively have to know that it’s TypeScript, but it just works - and that’s a big if; if it just works - then yeah, I’m here for it. I’m here for it. I’m happy to move higher up the value chain at all times. I don’t think we’re there yet, but I think we’re getting there. Here’s an experimental flag that I would like: –experimentalstripbugs. Would you guys be here for that, strip bugs? [laughs]

That’s just called TypeScript.

I mean, why can’t we have nice things, like strip bugs? Even better.

You just write it, and express what you’re trying to do… You’ll write less bugs.

Kyle in the chat says –fixsemicolons. I think we kind of have that at this point, don’t we? Sort of… Kind of, sort of… Pretty much. Nick, let me ask you a serious question. Personal question. Real question. Have you been working this week?

I have.

Have you been writing code?

I have. I won’t tell you what kind of code I’ve been writing, but I’ve been –

Have you been writing TypeScript?

Nope.

[laughs]

This ruins my line of questioning…

Hold on, hold on, hold on… Let me guess. Have you been writing PHP again?

Yes, actually.

Via a comment form on your website? [laughter] Okay, so that ruins my line of questioning. Well, how about last week? Did you write some TypeScript last week? I’m trying to really bring this home.

No…

Alright, let’s move on.

I probably write less TypeScript than even you, Jerod, now.

Really? Because I’m batting zero over here.

Me too.

Okay. So we’re just merely playing the parts now at this point. Kball, we’re shadows of our old selves… Although I’m not. I’m representing exactly my side. I do not write TypeScript, and I don’t write TypeScript. So I guess, Nick, you’re the –

I still like TypeScript. I would rather be writing TypeScript, but…

Oh, you should get one of those bumper stickers that says that… Like those “I’d rather be fishing” bumper stickers, or something. “I’d rather be TypeScripting.”

Yes. That’d be a good laptop sticker.

How about SQLite? Do you guys like SQLite?

Absolutely. Underrated.

Yeah. This one’s cool. So they’ve also been working on another experimental flag. This has been merged, it’s out there on the nightlies, but not released yet in Node. Built in SQLite module. So… Batteries included. Database right there. Bam.

Do they bundle SQLite, or this is just the interface?

That I do not know. Let me see if I can get that answer quickly, via a quick look at the actual files changed.

BenGL in the chat is saying that it is bundled.

That’s even faster.

That is super-cool if they’re bundling it, because that really then lowers the barrier to writing simple, persistence-related, relational code. And unlike the build step/no build step - we’re all doing a build step anyway - this is talking about like deployment hack. Do I have to deal with figuring out where I’m deploying it to? Do I have to install SQLite on my Mac and not have it break? I don’t know. I mean, actually, SQLite is pretty simple regardless, because it’s just a binary. But…

It’s simple, and it’s pre-installed in almost every operating system in the world. But still…

So never mind. I’m not sure where this gets us, except you can not have to do that step.

Sure. And it also is the API as well, right? So you do not have to go out and grab whatever the Node SQLite library, whatever, whatever.

So there’s a bigger actual question here, which is sort of philosophical, around the extent to – like, what should live in a core, versus what should be actual libraries?

That’s kind of what I was thinking as well. Yeah, good point.

Like, we’re going into this –

Boundaries. You’re defining boundaries, Kball. Remember, I want you to do an episode on this.

[10:08] Yes. And I think it’s an art more than a science. JavaScript land has historically defined lots of many small modules, which is way on the end of one spectrum, where you’re saying essentially like there’s no standard library, or there’s a minimal standard library; everything is your choice, everything you have to configure. That’s a lot of cognitive load.

On the flip side, you put everything in there, in the core… Like, it slows things down, it’s hard to innovate; if they get it wrong, it’s a mess… And if I’m using this, I can’t necessarily just say “Okay, I’ve been prototyping with SQLite, now I’m gonna swap in Postgres and it all works fine, because I have an abstraction between my database and the data manipulation”, or whatever I’m doing. Instead, now I’ve got to rip out SQLite and do other different things with it.

I mean, you could code that way anyways, if you were forward-looking.

You could.

How many times have you ripped the database out though, honestly? Out of an app. Either mid-dev or mid-prod. [laughs] Mid-flight.

It’s actually not that uncommon to use SQLite for development, and then just swap into something like Postgres or something like that for…

I think that’s cool when you’re cowboy-coding. I think that over time that bites you in ways. I’ve definitely been bit. Even just going –

Well, no, totally. I mean, once you actually get to the point where you’re deploying, you’re going to swap your local to be Postgres too, so that you’re not –

Yeah, you want to be as close as possible to production as you can, I think.

But when you’re rapid-prototyping your first initial stuff, you might do it in SQLite, because it’s super-simple. You don’t have to deploy a database or deal with all of that. So that’s gotten easier, too.

Right.

And then at some point, you want to swap it out.

Well, there are people now that are really putting SQLite into production in ways that used to be frowned upon, and there’s certainly places - as a warning, there are places where SQLite will not do well in production. Write-heavy web applications, I just don’t think that’s a place for that. But there’s lots of places where it can do just fine, especially at small scales, which most of our websites/businesses are. And so people are really starting to take this seriously, and maybe never swap it out. Maybe that’s just your production database, too. Who knows? It depends on the use case.

I think this is good for Node though. I do think it’s difficult to define the boundaries, and I saw this and I thought “Great idea. Executed well. Looks good. Ship it.” I mean, Node is better with a built-in embedded database in there, for sure.

To your point, a lot of the uses for using it in production are you’re shipping like Electron apps, or you’re shipping little desktop apps, or things like that. And if I don’t have to worry about bundling it myself because Node already does that for me, that is one headache removed.

Yeah. One of the people in the comments of the PR for this actually made that exact point, that they really struggle with their Electron app, because the SQLite adapter with Electron, the third party thing is flaky, and it disconnects a lot, and blah, blah, blah… And having this built into Node just makes their life easier. So I think that’s a very good point.

JavaScript. It’s not just for the web anymore. Node times 5,000. They keep saying that.

[laughs]

Is this comparable to… Like, I know that Deno shipped a key-value store as part of their core. Would this be a comparable thing, but more open? I haven’t used the Deno KV at all.

Neither have I. I know what a key-value store is, so I can comment on comparing that to SQLite… I don’t know if they have like way more functionality than a typical key-value store, but if they don’t, and it’s passing a key, maybe you can do some indexes if you’re forward-looking, but not real relational tables, and ACID, and blah, blah, blah. It’s just like key-value, key-value. If that’s what Deno’s deal is, this is dramatically more functional as a data store.

Sure.

They’re also not trying to charge you for it.

Yeah.

Fair.

[14:00] That’s just like the comparison that came to my mind, with inspiration for this, potentially. Like, I don’t know where it came from or anything, but that’s…

Right.

…with like the TypeScript thing in the previous segment, Deno and Bun both support that. Just, I’m probably drawing correlations where they don’t exist.

Hm. You think Node’s playing catch-up on all fronts, perhaps?

I think it’s exciting to see a lot of new features coming like this.

Well, Node is not the only one getting new features.

Well, wait, I have a last-minute add there. I don’t know if you saw that…

Oh, okay. I didn’t see it.

[unintelligible 00:14:35.08] My mouse just died.

You use a mouse?

Well, now I use a trackpad. [laughter] Yeah, I wanted to sneak this in, too. I saw it from a tweet. I think it was Matt Pocock on Twitter, talking about styled text. Have you seen this?

What’s Twitter?

I won’t call it the other thing.

[laughs] No, I haven’t seen styled text. What is this?

Have you ever used Chalk before, or some way to create command line applications with colored text in the browser – or in the terminal?

You threw me for a loop in the browser, but when you went back to the terminal, I was with you. I have not, but I have seen them, and I used them, and they’re beautiful.

Well, it looks like as of Node 20 dot something, dot 10, that now exists.

It’s in there?

It’s just built-in. Now you can just say styled text, and you can say styled text red, and then give it a string to print out, and it’ll print it out in red color.

Okay… So here we go, again, Kball, bringing more stuff into Node core… Things that were previously libraries. But maybe they are just generally useful for anybody making command line apps. I don’t know.

Now with no extra dependencies, you can build a command line app that stores all of its config into an SQLite database, and you write it in TypeScript, and you have no third-party dependencies.

I thought you were going to say “no bugs”, and I was about to go back to our previous conversation.

And no bugs! [laughter]

You can have one of those configurations be “What color do you want the outputs to be?”

Yeah.

I mean, I don’t know… I feel like the danger, as always, is you get to a place where it’s like bloated, and it’s too much disk, or it stores things down to the cognitive load of keeping in mind it’s too high… These things are like opt-in, in a lot of ways. Like, I don’t think the cognitive load piece is a huge problem. You have that one way or another. We’re installing Node… I don’t think it’s causing any – I don’t see any major problems here. It is just like that’s the path that things travel, right? We see this with software all the time. They start out very slim, and have core functionality, and then they add more, and they’re doing this for this power user, and that for that power user, and at some point you have Adobe products and you’re like “What the heck do I do with this? There’s 20 million options, I know how to use three of them, and yet I can’t get rid of the rest of them from my screen.” That’s not really as big of an issue for –

I thought you were talking about Git for a second there. [laughs]

But that is the trajectory. And then a competitor comes along and does a simple version again. And we’ll probably see that. But yeah, it definitely feels like JavaScript land - we are currently in a consolidation of bringing more things into core… And the same thing’s happening in the language, which - maybe you wanted to move into that area.

I did. But Nick snuck in some styled text on me.

Oh, [unintelligible 00:17:26.17] No, I’m kidding. I don’t have anything else.

[17:30] I just think it’s interesting. I think it’s cool. At a certain point you just wonder how much stuff can you shove in a box, you know? But this is what happens with mature ecosystems. You wouldn’t want this when Chalk just first came out. It’s like, all of a sudden it’s in Node core. Because things in the core are going to move slower, they’re not going to have as much iteration… I mean, this is what happens when Apple sherlocks things, right? Like, Apple has sherlocked x. No, not the platform, but the variable x. And everyone that loved x is mad, and then they realize “Oh, Apple’s doing an 80% version of what this is.” It’s never going to actually reach parity. They don’t even want to. They want to provide kind of a baseline feature set that that thing provides… And there’s a place in the world for it. But once it gets mature and there’s not much change in – I mean, SQLite’s a good example. It’s like lower risk. Anyways, moving on… Moving on to the language. What’s new for JavaScript devs in ECMAScript 2024? This is a nice write-up from Mary Branscombe at The New Stack, all about new features in JavaScript itself. Most notably to me, what’s not in there? See how I’m always discontented? I’m like “Here’s the first thing. What’s not in 24?” which is Temporal and decorators. The big ones.

I want Temporal. Time still continues to suck. When is it going to be in there?

Right? I mean, I felt like – when was it that we asked Jordan Harband when Temporal was going to land? And he said “Soon.” [laughs] It was a long time ago. It was long enough ago I can’t remember. I think it’s feature-complete, but there’s just things in the way, things that only, I think, ECMAScript insiders and those people understand. Maybe it’s drama and politics… I don’t know what it is. Maybe it’s certain browsers not doing things… But yeah. 2025 for those things. But let’s not poo-poo the effort that has gone in.

So there is some cool stuff that’s new. Promise.withResolvers, which is something that’s fixing a pain point for a lot of people, which is basically having to do this small little wrapper around their promises, according to Daniel Ehrenberg, who’s been on the podcast. I think he’s an ECMA vice president. He’s definitely instrumental to pushing the language forward. What he says about this - he says “Previously, when you created a promise, the ways that you resolve it and you give it its final state where the API is only accessible inside the function that you built it with.” But with this new static method called Promise.withResolvers, it gives you a way to create a promise, and it gives you direct access to those resolution functions… This is going to remove a lot of boilerplate for a lot of people. Nick, you’re nodding along. Is this something that’s going to cause a little bit of happiness in your life?

A little bit… I’m mostly excited because I get to say a classic line from the early days of this podcast, which is “Dojo already did that.”

Oh…! Classic. [laughs] Didn’t jQuery do this as well?

Yeah, I think so.

Yeah, it’s not exactly new, but it’s new to the language. And when broadly available, it will let people remove some of their little shim code, wrapper code.

I can’t think of the last time I had to do this, but I have had to in the past create a new promise, and then inside of that callback assign the reject and resolve to variables that I declared outside of the callback…

Yeah, exactly. You’re basically doing closure manipulation in order to keep things in scope… And at that point, I just turn over to the LLM. I’m like “Can you write this real quick?” Why is this null right here, or undefined, or whatever, when it’s not supposed to be? Oh, because you didn’t do your closure correctly, blah, blah, blah.

Well, and this sort of topic of dealing better with asynchronicity and data loads is one of the areas that I think… So at a conference earlier this summer there was a roundtable conversation with Q&A that had both one of the folks really up in Angular, and then it had Ryan Carniato… So a lot of sharp front-end people, and I asked them, “What are the big unresolved problems?” It seems like there’s a lot of consensus moving towards signals, and doing these other things, but what is still out there? And this was a thing that was raised, is like dealing with asynchronicity well is something that all the frameworks are sort of looking at. React took a stab at this with suspend, and what are they doing there… Angular has all that complexity with the baked-in - whatchamacallit… What is their observables framework that they use?

[22:18] Rx?

Yeah, RxJS. You’re right. It was Rx. So that’s like the big hammer in this space right now… And so this just in some ways feels like it’s fitting into that queue of we just need better tooling for dealing with things that are asynchronous and outstanding, and how do you handle them in different ways, and being able to manipulate your resolvers, as for example maybe a different promise resolved, and so now the promise that you had for this outstanding one, it needs to do something slightly different, or other things. That is the tooling that we need to be able to deal with multiple layers of asynchronicity.

Yup, agreed. Also new, array grouping. Array grouping. Groupby, perhaps, that’s the name of it. What’s the exact function name here?

Groupby. Object.groupby.

It is groupby. I thought that’s what it should be.

Okay. So something that those of us who’ve been writing Ruby or other languages are pretty familiar with.

Yeah. Well, I was just going to say, normally you would pull this in with Lodash, or something. I’m sure Lodash has a groupby. Sometimes function names are slightly different, and super-useful. Needed all the time. This is basically where you have a list or an array of things, and you want to split them into multiple groups based on some property about them, or their ability to pass or fail a function, etc. And it’s not groundbreaking stuff, but again, it’s just taking things that everybody needs, and probably at this point still uses Lodash for, and throwing it right in there so you don’t have to pull it in that particular function.

Now, there is a new – have you guys heard of this? There’s a new competitor enters the chat. A Lodash alike. I’m looking it up now… I’ve covered it in Changelog News recently… And it was new to me; so maybe I’ll say it’s new and Nick will be like “I’ve been using this forever.” ESToolkit. Are you guys familiar with ESToolkit?

I do remember it from Changelog News…

Yeah… So I obviously haven’t used it, and you haven’t used it, but this is pretty new. It’s a state-of-the-art high-performance JavaScript utility library with a small bundle size and strong type annotations. That’s where Nick started really perking up, when I said that. And it’s cool because it has built-in tree-shaking support, which means if you just need that one groupby function, it’s going to shake out everything else. And bundles down 97% further than Lodash, according to the author… Now, I haven’t done any fact-checking on this. We’ll take their word for it. And built-in TypeScript support. So… Pretty cool. If you’re still using Lodash, I think it’s probably worth a look. It’s just maybe a more – I won’t say modern, because everybody does, but I’ll say a more recent addition to that particular utility library. Remember, it all started with underscore. Nick, do you remember _js?

I sure do. I was in the Backbone world once…

Yeah, man. Backbone and CoffeeScript author, Jeremy Ashkenas, created underscore. No?

I was never into CoffeeScript…

[laughs] It’s weird that you hated CoffeeScript so much, but you love TypeScript so much. I mean, there’s a lot of similarity. And I was the opposite, because I wasn’t on – see, I already had a build step when CoffeeScript came around. And you know how I like build steps, Kball…

CoffeeScript lost me at the lack of a ternary.

Oh, you’re a ternary guy? Wow… You lost me, Kball, when you just said that.

No, so coming back to ESToolkit… I think there’s actually something interesting here from a branding perspective. So they say built-in TypeScript types. The whole thing is built in TypeScript. Why is this not TS Toolkit?

Ooh… I don’t know. [laughs]

I’m going to pause it so that Jerod will use it and shout it out on Changelog.

[25:54] Oh, that would be like metagame. That would be super-smart. Nick, what do you think?

The same reason that it’s not TSLint anymore. It supports all ECMAScript variants.

I see. So they’re trying to–

…meaning JavaScript and TypeScript. Probably not ActionScript, or anything like that.

Or CoffeeScript, most likely.

But don’t all TypeScript…? It all compiles down to JavaScript, so it all supports all forms of ECMAScript.

Yeah, I don’t know. I already thought that Lodash was highly tree-shakable, so I don’t know. I haven’t used Lodash probably since the Backbone days, since the Underscore days.

How do you get your groupby on, Nick? How do you get your groupby on? Is that in TypeScript?

No. And you’re not going to like this answer, but I just write my own. [laughs]

Well, I actually don’t mind that at all. I’ve got no problem. I mean, if you have map and reduce, you can pretty much write all the other ones… Which is what Lodash is.

Exactly. Yeah.

I mean, it’s just a series of map reduces in order to provide nice wrapper functions that are more directly doing that thing that you know that they do: filtering, rejecting, blah, blah, blah. Grouping… I’ve got no problem with you writing your own.

Writing these two is the number one place to level up your type game for TypeScript, because –

Now you’re right. Now I don’t like it as much. [laughter]

Because you’re writing like these mapped types and conditional types that are all globbed together to give you the exact output that you would expect, but only in types.

How many lines of code is the Nick Nisi groupby?

It’s probably exactly what you said, like a map and a reduce, a couple of lines of that, and then probably triple the lines for the type annotations.

Exactly. I’ll never use that. Despicable.

It’s amazing though… [laughter]

Well, I will just use the built-in groupby, thank you very much. Now that we have array grouping in JavaScript, which is what we’re all here to party about. There’s also some more stuff that’s smaller, that I did not write down… But we will link up to Mary’s entire New Stack article for people who want to get the full rundown… Because there’s much more coming, or that came in ‘24. And stay tuned, y’all, because Temporal is 2025. You know, it’s just right around the corner.

Is there anything beyond Temporal and decorators that you’re excited for, that’s been promised forever?

Me? Type annotations.

Yeah?

I don’t know, sort of. Not that I’ll necessarily use them, but I’ll be happy that they’re there, for people who need that kind of thing. [laughs]

Yeah.

I don’t know. I can’t think of anything off the top of my head, but I’m also not looking at a list of like things coming down the pipeline. So if you could give me a few examples, I would say excited/not excited.

There’s one for me that I can think of off the top of my head that I’ve been wanting forever, and it’s not life-changing or anything, but it would just be fun, and it would be new, and it would solve the problem that it solves better than the way I currently do it, and that’s the pipeline operator.

Oh, yeah.

Oh, yes, please.

I like pipelines. I live in Elixir land on the server side, and we use pipelines all the time, and I would love to use them in the browser as well.

Absolutely.

Yeah. I was curious why is ESToolkit so much more tree-shakeable or bundling down smaller… And it turns out that they are essentially flattening the logic out for a lot of their things. So like if you look at Lodash implementation of once as a thing, it uses once, it imports before, and then uses the special case - because once is a special case of before - and it has that all over the place, where it’s like, they’re basically composing their functions out of their own functions, which is like the functionally pure way to do it; it makes sense. But ESToolkit is implementing each one just flat, so it doesn’t have any dependencies, so that if you import once, you don’t import once and then before, and then anything before is doing; you’re just importing once, which is this ( looks like) 18-line function.

Yeah, that’s actually pretty smart. I like that. Thanks for looking that up. That’s interesting. They’ve basically done what Nick did with groupby, only with all of them, and… There you go.

[30:04] Well, and that kind of makes sense if you’re a utilities library author. You can take the time to do that extra work, and it makes your library so much more independently usable in that way. I do wonder, if you start using a larger amount of the functions in your code, if you – this is, once again, the classic “Do you have a runtime-ish thing that is shared, or is everything flattened and independent?” At what point is the crossover where it’s actually more expensive because you’re shipping a lot of duplicated logic? But I would bet most codebases, especially as we move into this - we split things, we only load what’s necessary for each particular things… They’re going to benefit from that flattened approach.

And there’s plenty of environments that I’ve been in where it’s just – you have to play politics to get new dependencies in, or we just don’t want to ship new third party code in. And if it’s like that, where it’s just like “There’s this standalone thing”, I mean, at that point you can just copy and paste from it, which is fantastic. And it’s also just way, way easier to learn from that. Like “How is groupby actually created? How would you do that?” If you’re like “Oh, it’s calling this utility, that’s calling this utility”, and you have to go up this stack, then you lose the thread on that a little bit. So…

I literally remember doing that with Lodash years ago, because I used it all the time, I appreciated it, and I just wanted to see – I think at one point I wanted just one function, and I was like “I’m just gonna copy-paste that function into my codebase”, because I’m not above that. I will definitely do that when it seems like it’s smarter. And I went and I’m like “Oh, I can’t actually do that, because I’m also going to need this other one.” And then I followed that one, and I’m like “Oh, there’s a call stack here, and they’re calling all their own functions.” And it’s kind of hard – as an outsider, it’s kind of hard for me to reason about. it also ruined my plan of just copy-pasting the single function… But it did look really nice and thought through, and so I was impressed by the engineering… But ultimately, I think probably simple would have served me better in that particular case.

ESToolkit. There you go. Still written in TypeScript, as is Lodash, as I discovered when I started digging into this… Because I think as Nick highlighted, TypeScript may have won.

It’s won! It’s won!

What did it win? Tell us what it won, Nick,

Our hearts, and our minds… [laughter]

Creepy… Okay –

You say that now.

When am I gonna stop saying it?

Apparently, when type annotations ship.

Yeah, probably. Well, then we can stop talking about TypeScript, right? We’re like “Hey, it’s just – now, it’s won.” I’ll probably give up at that point, and say “You know what? It won.”

You’ll probably be retired. We probably all will be by the time that ships.

Probably. Probably before Temporal comes out, it sounds like… We might even be hanging them up, too. Okay, no dissing on the Temporal folks. We love the effort being put in. We’re ready for it. We’re here for it. Kball, state of React.

Yeah.

2023.

So 2023 survey, which was published five days ago as of when we’re recording it…

Oh, so last year’s survey is out now.

Last year’s survey is out as of July 20th, 2024.

Gotcha. Okay. What’s interesting here?

Interesting to me looking through was like looking at stuff like what are the pain points people are feeling… So there was sections on like main API pain points, where some of the biggest pain points I see are the forward ref memos, and the context API… Memoization - apparently, if you follow the rules, you can use React compiler now. You don’t need to worry about it. So that’s hopefully one pain point they’re actually getting rid of, but we’ll see. They also have some new API pain points. Lots of people complaining about React Server Components… Interestingly, number three on the “new APIs pain points” around React is Next.js issues. So it’s more indication of the extent to which Next.js and React are becoming sort of entangled with one another.

[34:02] There is a place where you can sort of see what frameworks people are using, and there I think it was – the one that’s still the most known was Create React App. It’s not gone away, but lots of people don’t like it anymore. They’re pretty unhappy with it. After that was Next. It is sort of the most – most people have tried it, and it actually has reasonably positive sentiment. 46% of people said they liked it, 44% felt neutral about it, and just under 10% ish were unhappy, if I’m reading that… Which is confusing to me, because they have multiple numbers on the same – I’m having trouble with their graphs, but… A relatively large percent of people like it, a lot of people felt neutral, and then just a few people didn’t like it. Gatsby’s still on there, nobody likes it… Astro and Remix are moving. And then Redwood is also in there, but also nobody likes it.

Let’s see, other things of interest… I mean, I noticed that Syntax is still more popular than we are, but we’re coming in number two again, so it’s all good… Syntax, man…!

We need to have a Syntax flipping party. Like, how are we gonna flip in those guys, you know?

At least we’re beating the Changelog. [laughter]

That would be embarrassing, wouldn’t it? If we couldn’t beat them… We’re not even close, though. We’re at 7%, and Syntax is at 16%. They’ve more than doubled our respondents. But this was last year. I mean, maybe we already flipped them and we don’t even know yet.

They’re pretty good, gotta say.

I know.

Credit where credit’s due. They’re awesome.

I’ve got no problem with those guys. I just like to complain. But I think they’ve deserved all their success, and I’m happy for them. I just want to deserve equal amounts, and then maybe more than they have. [laughs]

Gotta recruit them. Didn’t they get bought out or something, too?

Yes, they are wholly owned by Sentry now.

What’s amazing to me in just that podcast section is this is only 28% of respondents. There’s 72% that listed None for their podcast consumption. We’ve got a big market to tap.

I was gonna say, that could be how we catch up, is we go after the 70-something percent. All we’ve gotta do is ask Sascha for the email addresses. Bam. Just kidding, guys… We would never do that. Unless, you’ve got the email address, let me know. Still kidding. Anything else, Kball?

Those were the things that stood out to me. Let’s see… I don’t know, Nick or Jerod, did either of you get a chance to look through anything else that stood out to you?

I was just happy to see some of my picks actually show up on the list of things. For example, XState has about 10% usage, with most of it being favorable, it looks like… But it made it on the list. That’s pretty cool. And then I do think it’s interesting, just the whole – I don’t know if controversy is the right word, but the world around React and Next, and how – I don’t know, it doesn’t seem like there’s positive news out of that relationship.

I would tend to agree. Negative sentiment would be what my analysis is. If you fed me all of the public talk, and asked me to have my neural network determine if it’s positive or negative sentiment, I would say negative sentiment. This is interesting… So at the end, Josh Comeau, who I think’s been on the show before, definitely has been on the Changelog - the third best React podcast out there - has a conclusion that he wrote at the end of this… So I think probably Sascha asked him to write this, and this is interesting… He says that he thinks that this year has been the most interesting year, the biggest year for React since 2018, when React hooks were first introduced. He goes on and at the end he’s talking about React Server Components, and he says “If I had to guess, I’d say that in 2028 there will be two Reacts in wide circulation, with roughly equivalent usage. The ‘full stack’ version with server components and server actions, and the client-only single page app version.” I wonder your guys’s reaction to that particular prediction from Josh Comeau.

[38:21] So it’s interesting that he would say that… And it makes me wonder, would those both be called React? Or is what happens - React continues down this full stack direction which they’ve very much been going, and some other competitor says… I mean, this is the dynamics we were talking about before; they’re incorporating more and more into React core, and at some point it’s enough that the complexity starts to really bother people, which if you look at the pain points, excessive complexity was like the top React pain point in the question at the end that’s “Are there any other React pain points you’d like to mention?” They say “Excessive complexity.” That’s the incorporation of all of these different pieces coming in. And at some point there’s room for a simple take of a competitor to actually rise up and eat up a bunch of those. And I think that might become that second “React”, except maybe it’s not called React. Maybe it’s called Vue, or Qwik, or Astro. Astro is weird, because they actually do something different. But maybe it’s one of these competitive frameworks that says “You know what? We don’t need all that complexity. We’ll handle one use case, which is client-side applications, and we will do it really well.”

Yeah. Maybe one would be from the before times, before they started going into this. So it’d be the pre-times. They could call it something like Preact, or something… I don’t know, I think that –

Dojo revival!

I was gonna say, Backbone 3.0.

Do you think that server-side rendering is fad, and we’ll just eventually revert back to SPAs?

So I remember when I was first looking at the tech industry back in early 2000s, and I did an internship at Sun Microsystems, and they had this thing where they were experimenting with thin clients, because they had all their stuff on the server… And that was a new – and maybe they were going back because before they’d had these fat clients. We’ve been in this server, client, server, client, server, client, what happens in the server, what happens in the client - that cycle has happened four times now, across the industry, going back pre web, back to… All these different things. So will we have that cycle again? I mean, if past performance is the best predictor of future performance, I would say yes, we’ll see that again.

Have we gotten to the other side of the pendulum yet? I think we’re still swinging away. I think we have to get to a point, and then we swing back. I feel like we’re swinging away at this point from, from SPAs.

I think that’s true. I think right now we are swinging towards doing a lot more on the server again.

Yeah.

But there’s a lot of friction in that path right now. It’s slowing that, or reversing that. I was heavily looking into –

With React in particular, I guess, maybe.

Yeah, for sure. I was looking heavily into Next, and all of the friction that I ran into, I was just like “You know what? I know I can ship a SPA, so let’s do that.”

How’d it go?

Then I woke up and had to go to real work.

[laughs] You didn’t actually ship anything. Sounds about right. Checks out. But you should see the types in that sucker. He’s got beautiful types.

Oh, just beautiful. [laughter] I want to jump into a different tangent…

Sure.

What’s one word that comes to mind with React? If you think of what type of library or framework React is, what’s the first word that comes to mind?

When you say “What type of framework?” I go back to it’s a Vue library.

Okay, yeah.

[42:00] That’s two words.

Vue…

I would say client.

With an IE. Not the UE.

Yeah, I think you’re in the same ballpark. I was gonna say a component library.

Okay. Component. Yeah, sure.

It’s components views. You’re creating UIs for it. And there is a component pain points section of this. So that’s effectively what the whole thing is. And if you take the top four things that are listed there, which accounts for 51% of the problems, the top pain points, it’s all about CSS. And so CSS is definitely a big problem, not just in React, but in all component frameworks, I think, at this point. And I wonder what the solution for that is. If you asked me, and I hadn’t seen this, I would say Tailwind… But Tailwind is listed as number two, with Tailwind issues, and I don’t see how Tailwind’s an issue. But…

Do note that only 3% of the survey respondents replied to this question.

Oh, I didn’t click on –

It may be over-indexing on that. But interesting point… I just feel like we’ve found either our [unintelligible 00:43:07.04] or our title for the episode. “CSS is a big problem. Nick Nisi.” That’s just – that’s the quote. [laughs] And then in parentheses, “And I hate it.” You know, something like that.

I’m fine with this.

[laughs] Yeah, that’s an interesting thought…

There’s another angle into all of this, like what does the application system of the future look like, is maybe we’re going to have all of our UIs be generated. Have you all played with websim.ai at all?

No.

Oh, so much fun. Go to websim.ai. It gives you this little fake browser. You put in a URL that you think should exist in the world, and it will generate it for you on the fly. You can pass in parameters, query params, URL params, and it will tune it. You can actually use that to point it to external resources. I saw a guy who set up a little WebSocket server, and then created a websim page that referenced that in a param that was a chat, and you could actually get multiplayer on this, through his external resource he set up. It’s banana pants, and it’s literally just a big prompt sent over to Claude Opus that says “Dream with me. Create a website based on this.” And it will. And that’s an extreme version, but I do think there’s a world in which you have stuff like – you’ve got a component library, maybe it’s a movie, maybe it’s something like this, and your backend is an LLM of some sort, that references some coded tool calls, but that’s weaving it all together and it says “Pick which elements are useful to display this, and throw them on the screen.” And is that a thin client? I think it’s a thin client. I think that’s like stuff’s happening on the server. But maybe it’s streaming out that HTML and CSS from the server. That’s what websim is doing. It’s streaming that stuff straight from the LLM. And it seems to pretty much work. It’s not reliable, it’s a toy… But is that the way we’re going? I don’t know.

Well, I think unreliable and toys are definitely the way that we’re going right now. [laughs]

An appropriate conclusion to a TypeScript episode…

Yeah, I wasn’t sold until it did generate a TypeScript fan page by Jerod Santo from the Changelog about why he loves TypeScript… So yeah, I can see the appeal of this.

Send me a link.

Can I?

Yeah, you can. You can share the outer link, and it’ll get –

Sent a link. We’ll put it in the show notes…

Oh, nice.

So this is like a JS Party equivalent of a deep fake, Nick. I mean, you are trying to fool people into thinking not well of me. Okay, I was just stalling so I could get the link.

That is amazing.

[45:57] Let’s see it. TypeScript fan page. “Why I love TypeScript. As a developer and podcaster, I’ve come to appreciate the power and flexibility of TypeScript.” This is actually super-boring. I think it should be way fancier. They don’t know my style, man. I’ve got way more style than this.

You’ve got to pass in some params. Style = epic poem, or something like that.

Yeah. Tell them it has to rhyme to the beat of Snoop Dogg’s Lottie Dottie. Now, that’s my style.

Yeah. Put that in as an inspiration parameter. See what it does.

[laughs] Okay, now we’re just live-prompting on the air. We should call it a show. I think we’ve devolved far enough for this episode. We hit our obligatory AI chapter, we got it in… So that means we can officially stop. All the links to all the things will be in your show notes, assuming Nick can get this prompt written in time…

I’ve destroyed Nick’s productivity for the rest of the day.

The TypeScript [unintelligible 00:46:51.29]

[laughs]

“Brought to you by Jay to the Rod from the Changelog.”

Okay, we’re getting a little better. See, it needs more humanity. You inject some more humanity into it, things start to get more interesting, that’s what I’ve found.

Put that in as a parameter. Humanity level 500.

[unintelligible 00:47:09.21] Tune in to Da Changelog. Now it’s just talking jive, you know? This is just like stereotypes on stereotypes on stereotypes. Alright, let’s call it a show. Anything else, anything we didn’t talk about, anything you guys want to say before we call it a day? And yes, that did rhyme on purpose… Silence from the peanut gallery. Go ahead, Nick.

No, that’s it.

Why do I put up with you sometimes…? He leans in, he opens his mouth, and then he says “No, that’s it.”

I had come up with my own list of things, of topics, of newsworthy things, and…

Oh, you did?

…I don’t want to jump into another tangent, because we have to go. But…

We’ve got four minutes before Kball has to hop off. Is there anything good, or is it just gonna be like Nick-level good?

Nick-level good.

I mean, this was an emergency podcast, right?

This was a Nick-level emergency. [laughter] So, I mean, what can we expect…?

There’s a title for you…

Yes, that’s a good title. Alright, Nick, I’ll let you read one headline that you want to discuss, and then Kball and I will decide whether or not we’re gonna let you talk about it.

I can’t remember the name of it, but there’s a new feature in Astro that lets you more natively support Tailwind by effectively baking in the clsx utility right into it.

I fell asleep mid-sentence. Kball, did you follow that?

So it’s another example of pulling in a third party dependency into a core of something as [unintelligible 00:48:41.26]

Yes. Yes.

That’s a pattern that we’re seeing here. So there’s got to be more of these.

Hashtag no build step…

And Astro just – it didn’t seem to get a lot of love in that survey either. Not that it got like hate, but it just didn’t seem to register very high.

On behalf of Nick Nisi… [laughs] And Kball. I’m Jerod. This is JS Party. We’ve officially run out of things, as Nick talks to the air. We’ll talk to y’all on the next one.