NodeJS Evolves

Welcome to syntax. Today, we've got an awesome show for you today on how Node. Js has been kicking ass lately. Lots of new features hitting Node. JS, a lot of stuff we've been asking for for years, and it kinda splits up into, like, a, aligning with web standards, and, b, not web standards at all, but things that we all use anyways. It's sort of just like industry norms, and they're being implemented. And a Scott of these things are, we think, because Deno and Bun have have sort of come along and said, hey. Let's make a better Node. JS, and now Node is adding them. So we're gonna go through this massive list of new features that you can use natively in Node. Js, and I'm pretty excited about them. My name is Wes Bos. I'm a web developer from Canada. With me JS always is Scott Tolinski. How Yarn you doing, Scott? Oh, I'm doing great. You know, I'm I'm stoked for all this stuff. And in fact, some of these things make me wanna update my Node version to a nightly version, which,

that that's not out of the realm of something I would do, but not not quite what I'm going to be doing. And let's say if you are updating your version of node to a nightly version, you're definitely gonna want to have error and exception handling tracking in your application because who knows what's going on those nightlies. So you'll wanna check it out at century.io, the perfect place to track all of your errors and exceptions, but also track your performance, track metrics, track all kinds of stuff. You wanna understand what's going on in your application, why it's slow, this is the place to do it. Why it's slow, why it's buggy. We both know it's slow and buggy. So let's fix that, by having that visibility from Sentry. So head over to century.ioforward/syntax ESLint up and get 2 months for free, and let's get into it. So first and foremost, you you had mentioned, like, is this because Deno or and Bun? And I think one thing you'll that you'll notice through the course of this Node, that a lot of these features did arrive first in Deno or BUN. So it's it's not necessarily GitHub question to say the competitive nature of these run times probably has influenced Node continued improvement. Because, honestly, I don't know if it's a very recent thing because Node has always been kind of steadily improving.

It does feel like in the past 6 months or 5 months, there's been a huge jump of some of these wild features that I don't think I would have ever predicted would have landed in in Node. Js.

Yeah. And we should also say that, like, Node is not a company. Right? Like, it's just an organization, and it's run by Volunteers. Team. Yeah. Volunteers. And anyone can bring suggestions to Node and say, hey. Maybe we should. So, like, there's been a lot of people that have been sort of fighting for it or Scott necessarily fighting for it, but making a good case for adding these types of things to the runtime, and it's it's really exciting to see it take this direction.

Yeah. Super exciting. And in fact, man, I I don't know where we wanna get up to the start, but I think the most exciting one to me is this first one that we have on the list, which is Node, in their nightlies, has added support for TypeScript files.

And this is awesome. It I should say, the support is is that it is able to run TypeScript files as JavaScript files Wes the runtime itself is going to just ignore the TypeScript types ESLint, and it's going to just run it as JavaScript. Meaning that your editor, your your, you know, text editor will now be able to get all of those classic TypeScript insights that you get from TypeScript.

You can use TypeScript itself to run against your whole application to type check, but you don't need to build your TypeScript code into JavaScript code to get it to run-in Node, which is a massive, massive productivity boost.

We won't have to reach for a whole bundler or anything set up just to load up a stinking TypeScript file, which that's the those are the times I I reach for BUN because it's like, I got a TypeScript file. I just wanna run this dang file. I'm gonna maybe write a singular script. I don't wanna compile TypeScript and then have to run the script. I just wanna run the script that I'm writing. And this is where this, new TypeScript support will really come in handy for me personally.

I'm really excited about this because, like like, I use TSX right Node. And anytime I have to use something that's, like, sort of outside node, you have to add another, like, tooling to it. And when it's not native, then you have to realize, okay. Well, I'm not using the native node to run this, like the like, literally node command.

Now how do I do this, like like, when the dotenv support came out in node, which we'll talk about in just a sec? And I was like, okay. Well, like, how do I pass these arguments to the thing I'm using so that they can then pass it to node? And putting something else in between is kind of annoying. So we should also explain that how TypeScript works with a lot of these things, and it works this way in in Deno. It works this way in BUN. Now it works this way in Node JS that there's there's kind of, like, 2 parts to TypeScript. There is type checking, which is, you take your TypeScript and you actually check that all of the types are satisfied and there is no errors. And the only thing that can do that right now is the TSC node package, the official TypeScript node package. There are no other tools. There are some being worked on, but they're sort of just pipe dreams that will be able to do that. But right now, it's just TSC. And then there are lots of other tools or several other tools that will simply take your TypeScript and take out the types. They will strip them from the runtime and give you JavaScript out the other end. And then sorta in between that, there are several features of TypeScript that are compiled too because I often like to explain TypeScript as JavaScript with sprinkles on top, meaning that you sort of sprinkle on typings so that you can add a type system to JavaScript. But there are things like enums, the older TypeScript decorators, several I think namespaces is another one Yeah. Namespaces. Wes they literally do compile to JavaScript, which is a bit of a an odd one. And those things can be done in these these build toolings, but they are not part of the Node. Js support. And quite honestly, I I think I like that because it's a pain if you use enums, but all of those, like, weird stepchild parts of TypeScript, I don't I don't mess with. So, I'm pretty excited about that. Plus, like, we're getting types as comments or that is now a spec that's being proposed, meaning that JavaScript is being proposed that we we give some syntax. We allocate parts of the language for typing, and the browser will not and the the JavaScript runtime is not going to parse them. It's not gonna type check them. It's simply going to do what we just said, which is the browser will simply ignore them. That's why it's called types as comments, not because we write them in the comments, but because the browser ignores them as if they were

a comment. And I like that because the the enum stuff and whatever is is not going to be part of that as well. And if we're looking forward to what comes after TypeScript, I think that this is it. Yeah. And and what's so great about this and to be clear for those of you who who might not be entirely up on the differences and what exactly all this stuff is, again, this is not the JavaScript types JS comments.

This is not a language feature. This is a Node. Js feature. So this this code will not be ignored. The types will not be ignored in browser until it's added to browsers themselves. So this is just

for Node. The language. Yes. Correct. Yarn of, like, the JavaScript runtime, like, V eight must implement it. And what's interesting about this is that, you know, technically,

is that this uses SWC Wes TypeScript under the hood to do that stripping of the types.

And I think that's really wild to see. I I I are things like SWC WASM being added to Node, is that a new style of improving Node? Like, bringing in a third party WASM type stripper? It feels pretty crazy to me. But I actually I don't know the history to know if there there haven't been or has been things like this that have happened more often. But you can now be kind of assured that if you used SWC or bet on SWC for any particular reason

Yeah. It's probably not going anywhere. And the kinda cool thing about if you read the proposal for this and Wes should say, this is all still experimental.

But the idea here is that don't bake this into Node core. But I I think the idea is eventually it will be a Node. Meaning that in Node. Js, loaders are a way to tell it, hey. When somebody requires this type of file, you can use this code to first parse it and process it. Right? Like, somebody loads CSS. Node doesn't know about CSS, but you can put a Node you can put a loader in there so we'll understand what to do with the CSS when somebody imports it or or requires it. So the idea is, like, it's not going to be, like, baked in to Node. Js very similar to how NPM is not baked in to Node JS, and they can be operated separately.

And that's going to be ideal because then you're not going to be locked in TypeScript versions to to Node versions.

So I was surprised to see that this is not a loader. This is just some Scott other experimental implementation, but the end game is that this will be a loader.

Interesting. Yeah. Cool. So this is not available to necessarily use unless you're grabbing a nightly right now if you just wanna go experiment with it. But for now, I think it's just something to be aware of. This thing is gonna be coming down the line really soon, and we will update you when it is available to use in Node.

The next Node is something that I also did not expect. This is something that I would have expected to have gotten a lot of pushback, and this is adding SQLite to Node. And this is one of my favorite BUN features. And one of the reasons why I would pick BUN for various little things is because SQLite is just available as an import in BUN, and it has been added to Node.

Wes, can you tell us more?

Yeah. So you might be asking, like like, why would we add a database driver to the language? You know? That seems a bit odd.

But because Squeelite is so popular just joking.

Wes honestly, though, we should just mispronounce things like that for the sake of a TikTok clip. Be because SQLite is so uniform, it's on literally every device.

There's chances are that there's a toaster out there. There's probably it's running on your phone. Imessage uses it. It's so commonplace that it's it's everywhere.

It makes sense to sort of bake this in straight to the language so you can save it. And by default, it it works with memory. You can also use it with Vercel file. I don't know that it would probably works with, like like, externally hosted SQLite. I haven't used it myself just yet, but I'm I think this is great to have it right baked in because, again, if we now have a standardized way to share data to a file that is not I I know we have local storage and IndexedDB, but I I we don't really have those in Node, do we? Now we have a a standardized way that we can store and share data. What does that mean for different modules that wanna Scott talk to each other?

Yeah. So this is it's super interesting. You can import it, import SQLite from Node colon SQLite.

It was added in version 22.5.

And, Wes, I'm looking at that connection string. And it says that the location Wes you're doing a, essentially, a connection here, must either be stored in a file or in the memory. So you could just have the value as being colon memory colon if you want it to be stored in memory. But for a file backed database, the location must be a path to a file. So it doesn't say anything about if that path to a file is external or internal or whatever.

Probably uses the, like, file system APIs.

I think for most serverless, neither of these are gonna be okay if you want it to persist past running. And I I think well, maybe that is okay because a lot of times, you might be using this with a serverless function where the function starts. You'll create a quick SQLite database.

You'll store a bunch of stuff, and then you'll send it along the way. But with these, like, ephemeral hosts, serverless, edge compute, even box based stuff that spins up multiple boxes, you're not gonna be able to to do that because they spin down and and delete the files. It's the same reason why you can't store JPEGs that people have uploaded to your website on the actual box that you're running because

they will be deleted and cleaned up before you run away. Be super handy if you're building, like, even desktop applications. You can think, like, Electron or or Tori that have, like or I don't know if Tori has a node available. But, like, let's say something like Electron that you have available Node. You could have your data living in a a database that's shipped with the application itself. Nice and easy. Or even, like, another thing I was thinking is the Raycast

extensions.

Mhmm. One of the Raycast extension that I use is it takes a a onetime passwords that get SMS to you and will autofill them into your into the browser, which is a thing on Safari. It's such a great feature, but it's not a thing on all the other browsers. So what that extension does is it reads the SQLite database from your computer, which is your Imessage JS a whole bunch of SQLite databases on your computer.

So if you're writing Node scripts that need to Scott necessarily just save data, but sometimes you just simply need to parse data that is is on a device.

Yeah. And what about, like, embedded

devices as well? Yeah. Is that where we're going with this? Like like, we are certain we've talked a lot about, like, JavaScript running on embedded devices or or JavaScript running on low power devices.

Is that eventually where we're going with this type of thing? Yeah. Node a database? Scott a Node? Yeah.

Cool. Next Node we have here is dotenv support. So, again, like, the frustrating thing about developing a Node application a year or 2 years ago is I would start a brand new node application, and I would say, okay. Well, I need TSX to run. I want I'm gonna do it in TypeScript.

I need the dotenv because I put my environmental variables in a dotenv file, and I need to be able to parse that and to put it into whatever. And there was, like, 3 or 4 of these, like, you need these in every project, and it's it's kind of annoying when you just wanna write a quick script.

Now Node has the ability to simply just when you run Node, you can pass a dash dash env file, and it will pick up the path to it. And then it will populate and put all those environmental variables in so you can access them via process .env.whatever.

Again, major major update. And, also, one of the cool things that people maybe don't recognize, like, Wes, you can put tokens in there. You can put API keys, and you can put passwords and and database connection strings and all that stuff that you're used to. But the other thing that you can put in dotenv files is node flags. So if you have features that you wanna turn on in your node environment, like, for example, we're gonna be talking about the, experimental require module or the experimental WebSocket support. If you wanna turn those features on, you used to have to, like, put them in your, like, NPM script package, and you'd have this huge ass long connection thing that you'd have to run. Now you can put those environmental variables in the node underscore options environmental variable, and they will get picked up because it's reading the dotenv file, which is really cool.

Yeah. Another like you said, it's just one of those things we add to every single project. And getting away from that stuff is great. Another one of these is a Wes runner. You know, the the whole let me tell you. I had my fair share of issues with just in the past with, you know, having to compile my tests and things like that. Having a a test runner baked into Node is one of those things that it feels like it flew way under the radar for most people.

And I don't I don't know why that is, but there's so much good stuff in here. It's just the, package namespace is just node colon test. And it works exactly like what you're used to, Test, the name of your test. Inside of there, you can do assertions, like assert, strict equal.

You can do all kinds of things. And to the point where, like, I I don't know what are the particular use cases for reaching for other testing individual libraries like v Wes. I don't know why you would reach for v test over just using nodes baked in ESLint, unless, of course, you were testing UI things. I don't I don't know. I don't I I'm thinking off the top of my head here. I don't honestly know because I haven't used the node testing. I don't write that many unit tests. I tend to Yeah. Go more towards end to end testing myself. But I think, like, maybe, like, if you're using

TSX, like you said, some some of the client side stuff.

But, like, it's crazy. Like, you're telling me now that I can write my tests in TypeScript and have features turned on in a dotenv file Yeah. And none of that requires some bizarre bundle compile to step. That was always the pain that everybody had with Jest is that you had to literally compile your code first. Yes. With this, it's testing it as it's running on your actual server, and we're taking all of the middle ground out of the picture, and it's just straight running with a node, which is I'm again, I I keep saying I can't believe it. I'm so happy about this. But, like, as you get into larger and larger applications, it's either and you wanna add something, it's just such a pain in the butt and things go wrong pnpm ESM doesn't work in this specific use case and there's gotchas here and, oh, you actually are compiling to CJS and then you're running the test. None of that. We're all done with that. It only feel it feels like a very short time ago that we were like, why can't we have tests baked in like Rust, or why can't we have,

this or that? And it's like, so many of these things are here, and we hardly even notice, which is just incredible. It's so funny. We just recorded an episode about CSS new stuff, and the same thing. It's like, somehow, relative color syntax.

The fact that it landed in July slipped under the radar for me, and I'm staying up on this stuff. So it's incredible that all this stuff is just kind of moving along here. I think a lot of the reason behind this is because this these are decisions that you need to make

early on in a project. And most people's projects are already running, and it's just not a lot of the stuff is if it's working, I'm not messing with it. Nobody wants to mess with build tools or testing or or anything like that. But if you're starting a fresh from scratch project, it's worth taking a look at the list that we're talking today and saying, which of these things can I go full native on?

Yeah. Next Node here is, watch mode, which, hey. I used to be called the Node, and now I get to use watch mode baked into node. It's crazy because, like, what else like, that's another thing. One more thing you install on every single project is something to watch your files for when you make a change. So we now have watch mode, which is as simple as just a hyphen hyphen watch flag. It's just a watch flag in your standard Node command. You even have a watch path, if you want to watch a specific path. Folder? Watch a folder. Yeah. So, man, that's incredible. You can even with watch path, you can you can have multiple paths too. You can use that flag multiple times. So you can say watch path. Here's a path, and then watch another path. Here's a path. Man, what what Node is dead. What are you what are you gonna use nodemon for? When this came out, I posted that, and, like, Rami Sharper's like, Scott, it's it's not totally dead. But with these tools, there's always, like, Node is so full featured, and there's lots of little edge case use cases that people use it for. But for

for the high level, very simple watching a file and rerunning it when it changes, that's what most people need, and and now that is totally baked in. And, again, watching was always one of those pain in the butt things that was annoying with TypeScript because you had to write it in TypeScript, compile it, put it in some other folder, then the watcher had to see, oh, something in your compile folder changed. Let me now restart myself, and it's not not a thing in anymore. You can simply just watch a TypeScript file, which is is good news. Yes. It's great news. Yeah.

Next 1 we have here is Bos support. So globs in programming in general are the ability to sort of do, like, wild Yarn file matching.

Meaning that, like, yeah, give me everything with an extension of dotjs or give me all the files that start with puppy and end in JPEG or jpeg e g, and being able to sort of people always think they're regexes. They're Scott, but use this syntax to match files on your file system. For example, in the syntax website, we have a glob that will simply just look for all Scott MD files that are in the markdown folder, and it pulls them all in and we process each of the shows individually.

Glob support is something that was in Node for many, many years, and it was never actually exposed as a public API Wow. Until No. Until recently.

And now we have full Bos support in with the the file system to to read files off disk.

This one's so under my radar because when we had a section in this episode at the end called wish ESLint.

And on my wish list was glob support or glob imports.

We have them already. I just did not know. That's, like, one of my favorite features in Vite. I use it all the time to do, like, many of the same things you just mentioned. So, yeah, glob imports are super duper handy, and I find myself reaching for them all the time. Another one that I, new landed, but I didn't know to the extent of the support JS top level await. Now top level await means that, you know, you're typically working in a TypeScript file. And let's say you have a function that's at the exact, like, as a the root of the file, would you call that? The root Yeah. Yeah. Yeah. The the root scope of or module scope, I guess. The module scope. Okay. So at the module, like, the like, let's say you have a file. It's calling 1 function, and that file returns a promise. In the past, you would always have to do a dot then on that to get the result. But now with top level await, you can simply just await that function. Now top level await, there's a whole post on it from about how it could be a foot gun, and I tend to agree with that because you don't always want to wait on the execution of 1 specific thing. You don't wanna hold up things within a wait. But I think if you know what you're doing with it and you have a specific situation in which it comes in handy, top level await, I think, to me, makes things a lot more simple. Let's say, you wanna just import a specific file to initiate a connection or something like that. You could just await that connection in that file instead of having to create a function,

then run that function for that that to happen. So The database connection Node is the most common one that I hit all the time. It's like, I want to import DB from a file called Scott DB. And the 1st time that I require that Yeah. I need you to make the connection Wes then return it. And it was always really annoying because instead of just importing DB from DB dotTS, you would have to import get DB from whatever, and then you would have to go inside of some sort of function and await that value. And the 1st time, it would return it would take a second to connect and return it, and then the rest of the time, it would resolve immediately.

Being able to put this instantiating things, databases, if you have a class that needs to be instantiated the 1st time a module is required, that, though, is always a huge bit of a pain. And you get into this, like, really weird where everything has to, like, import a go function or a start function, and Node of that is is needed anymore. And this was Scott, like, a pain point in Node. Js for a long time because you could do it in you could do this type of stuff in common JS. But then when ESM came around, you couldn't do it, but now you finally can do it, which I'm pretty excited about.

Yeah. I'm stoked.

But this, this is not actually Scott that new at all. It came out in 2021. Yeah. I didn't know that. One of those things that the the whole, like, LTS, a lot of times, the people don't adopt new Node features until it's in LTS, and Node. Js has this feature where the even numbers of Node. Js are going to go into LTS.

So right now, Node version 20.16 is the LTS version, meaning that they will support it for, I believe it is, like, a year and a half.

And if you are in a large company, you say, okay. We're gonna we're gonna use that because it's gonna get security updates. It's gonna get updates for whatever we need, and then we'll have enough of a runway. We know that it's going to expire by this date, so then we can we can plan ahead. And then the the odd numbers, which is, like, 21, that's sort of where they do all the development and whatnot.

And then the the odd numbers are will never be promoted to long term support, so you have to wait until a feature hits. That's often when you see a new feature, it'll be pushed out in both an odd and an even version, and that's because they they want it to hit LTS as well.

Word.

What do we got next here? Experimental require module. This is another one of those ESM paper cuts. The whole getting ECMAScript modules in Node. Js was a bit of a a painful go through, and there is now if you wanna use Wes modules, which everybody should be using, it should be the default for absolutely everything. However, Node. JS has this, like, old baggage where it's common JS by default. So if you write import whatever from Node JS and you run that file, it will break because Node JS expects Common JS require syntax by default. So you have to create a package JSON. You have to go into the package JSON, and you have to set type of module. I have a little shortcut on my computer that does it immediately.

You cannot even put type of module in your, like, NPM Sanity files so that it goes in by default.

Very bizarre to me.

So Node is experimenting with being able to detect if something is an Wes, progress. So it'll take a look at your file and parse it out, maybe look if there's a import in there instead of a require, and then it will programmatically change it. They say that this does take a little bit of time on startup, so you should probably still put this in your package JSON type of module, but it's one of those paper Scott that BUN and Deno do not have where you you shouldn't have to know it works like this, especially somebody coming brand new to Node. Js. I have this with Python all the time. I'm always complaining.

There's all these gotchas in Python that, yo, you have to use this. Oh, didn't you use this? Make sure you have this. It's just like, no.

Make it work.

No. Make it work. Yeah.

Oh, man. I I'm curious about some of these other ones you have on here because I I don't know much about any of these you have on here. So do you wanna just run through some of these? Yeah. So another thing that landed maybe about a year and a half ago is all of the web

request standards.

So streams, form data, headers, Wes, response, and fetch. These APIs are web standards for creating requests and sending data from client to server or server to server.

And having full support for all of these things means that we can write code that works in the browser. We can write code that works in Node. Js, And a lot of these new frameworks, Node JS probably being one of my favorites, they're all built on these primitives that I just rattled off.

And now that Node. Js supports all of these things natively means that you can write a lot more cross platform code rather than having to do the Node. Js equivalent of it. It's a web standard, a web Wes, and web response standard.

Along with that is experimental WebSocket support, mean that it will if you want to use WebSockets from the the client to the browser and vice versa, there used to be, like, a a Node. Js WebSocket version, and now there's now there's a standard, which is in Node. Js. But then there's an experimental client support as well so that you can very easily talk between the browser and the actual client. So I'm hoping that lands in stable as Wes, but I I love seeing that they're willing to at least experiment with a lot of these things. Last 2 we have here, we did a whole show on this async local storage. The async context API is the standard version of this, and the async local storage was the one that hit Node before any of this was standardized, so we do not see it being added to node just yet, but I bet we will see it soon. But what this API allows you to do is to sort of stick stuff in the call stack. So if you have 1 function that calls another function or if you have middleware where 1 function runs and the next one and the next one, you can stick stuff into context or into a sync local storage, bad name, has nothing to do with local storage, and then you can access it anywhere down the call stack, meaning that anywhere within the request or anywhere within a function calling another one. And that's really nice because it doesn't it means you don't have to pass your data into every single function that you write. It's sort of just available to you, and it's scoped to the the call stack or it's it's scoped to the request in in a lot of use cases.

So It's like context for your server. Yeah. It's it's like context, and it's standard context. Meaning that if a package wants to use context and your own code wants to use context, you're not, like, coming up with your own version of context and having to pass the Svelte context into some other weird function that you're running. Single file executables, I asked on Twitter like, hey. What do you want in Node? And and someone's like, well, I want single file executables.

And we've had this for maybe about a year now. And what this allows you to do is you can take the entire Node JS runtime, and you can take your entire Node. Js application.

And you take all of your Node modules and bundle it up into a single package that is a single file, and then you can bring that to different computers. And that's really nice because you don't have to have people install Node. Js on their computer in order to run it, and that is often a case with if you write some tooling and you need it to run on somebody's computer locally rather than on a server remotely, you can just give them this file, and it will it will run. It's it contained. The it is fairly large. It it's up to, like, 90 megs, but that's not even touching, like, Electron,

which is sort of a lot of the alternative to this type of thing. Yeah. Word. Cool. Well, let's get into our wish list here. Yeah. What are things that we wanna see? My first one was glob imports, which we already have. So, yeah. No. You you had one that Wes, Scott Reload.

And how could Hot Reload work in this context?

I don't know.

The problem that I've had in the past with with long running node node applications is that if you make a change to the node application, what happens is that the entire application stops and has to restart itself again. It has to do the database connection and that type of thing. And with hot reload, if you make a change to a function, like, let's say, you're dealing with a event handler. Somebody visits this URL, they fire an event, and you wanna reply with some JSON. If you change just that code, the whole thing shouldn't have to restart itself. And a lot of frameworks are getting better at this so that they will simply just require they'll dynamically require that function that needs to happen on a handler, so that you don't have to do that restart. So that's that was a big version. And then, also, like, my computer JS getting really fast, so it's not much of an issue.

But my, like, my Express app before I got the MacBook M1 would take 2 seconds to, like, restart the TypeScript server and Yeah. Wait for the file watcher to change. So now that a lot of the stuff is built in, we don't have to worry about that time. And my computer is much faster at restarting, so it's not really that much of an an issue anymore.

Yeah. It is funny how things things change here. Yeah. Well, another one might have been, like, a a window shim. You know? Yeah. I think ESLint interesting because a lot of libraries, they do still use window dot things, which will fail if you try to use it on Node even if the code will work on desktop. Or even, like, let's say you're in a server side rendering context and you want to set something, you wanna just use Window. You always have to check to make sure you're in the browser. A way that you can get around this today is by using global this, but, you know, global this is essentially putting something onto the global namespace, which would include, what's on Window. Correct?

Yes. So global this is the pnpm for doing things isomorphically, meaning that you write codes on the server and on the thing, but, like, nobody's typing global this. People are often just typing window Scott something.

And, again, that's another paper cut that we hit in Node. Js land. That's not an issue. Do you know if they get even further where, like, they've shimmed prompt and confirm to show you CLI, approvals, which is kinda nifty? Yeah. Wow. Another thing I would love is, like, a better server.

So if I'm using BUN or Deno, their, like, default server HTTP server is is good enough just for a quick server. And I I don't feel that way about the the built in HTTP Vercel, and I'll usually go and grab some sort of lightweight server or or even like a Deno JS to throw that in there. So it'd be nice to have that built in. And then my last Node here is, like, better console log or better terminal integration because the console log in the browser is so good.

And then a console log in your terminal sucks, and it doesn't show you where it's being logged from. The setup to get either to get Versus Code working with it, there's auto detect in Versus Code, but, again, it's it's still still kind of tricky to get up and running. And then or if you want, like, the Chrome dev tools, you have to, like, set up the dash dash inspect or dash dash debug flag.

And then when that restarts, the Chrome DevTools has to, like, reconnect to it. So there's this other Chrome extension called Npm Node inspector monitor that has to, like, watch for those, and it will auto reconnect to it. And it's just like I just wanna see what line something was console logged on. I just want my, like, console dot table works. You know? I want, like, a couple more things, and I think it's a bit of a limitation of terminals as well as Node. JS, but I would love if, like, a warp just took, like, some of the I don't even know how this would work, but, like, warp the terminal, take the Chrome DevTools or something, and just make it work so that when I do something in whatever, I can fold a stack trace or something.

Yeah. Folding If I have an object, I shouldn't have to use console dot dir depth Or or JSON stringify. Yeah. Yeah. I shouldn't have to use that to, like, see an object more than 4 levels deep.

And, again, I realize there are lots of debugging tools out there, but they all require too much setup. And in larger projects, it's worth it for me. But as somebody who is slinging brand new projects several times a day so that I can talk talk to you guys about it, it's it's too tricky.

Yeah. Yeah. I agree. You Node? Specifically, that object thing that always bugs the life out of me when I'm counseling. Like, I'll just, like, quickly log something out, and it's just like object. I'm like, okay. Great. Thank you, for logging and telling me it's an object. You know, one thing that I I I really appreciate about the new Svelte five is that they have a better console log, which is called inspect, and it's like a rune that you just do inspect.

I I don't like that I have to memorize or not memorize, type something new that's not console log and have my muscle memory. But what's cool about inspect is that it watches values. Anytime that value changes, it'll say, alright. This is the value in it. And then if that value changes, it'll say update it and have that like, it's just a more full featured logging system for what's going on. Not that I want that at Node specifically, but I do think there is Node maybe out of the box thinking that could happen to make the Node console experience better to, give us better debugging.

On that same point, I forgot this one, is Node rolled out utils, colon, style text. Everybody uses Node colors to, like, style text. Chalk? Yeah. Or chalk.

So now you can use the Node style text API to change the colors, but I think it's a bit of a miss because it's not it's so much more verbose.

Like, Chalk is a better way better API. Like, why don't you just copy the Chalk API? And then also, like, why don't you just copy the browser API, which is you can pass it CSS Yeah. And it will console log it with CSS. And Deno does that. You can pass it percent c fetching data. And then in the 2nd argument of console log, you can you can say background color red, text white or sorry. Color white. I don't know how to do CSS, and it will match it as close as it possibly can to what's called ANSI colors. Those are those are the colors available to you in the terminal, and it will log it out for you. So, like, just give us that. You know? If we're we're trying to web standards this whole thing, just let me use CSS to to do it. And, like, couldn't Warp pick up a custom CSS color and display that to me? We should go past ANSI.

Yeah. Yeah. I I agree with that now. I know I don't know if Warp will ever get it today. So if what's funny is that, like, Warp is I don't wanna say controversial, but maybe, you know, anytime you bring up Warp in general, people get, like, not not real terminal, Even though it's like because you have to log in. You gotta log in to your terminal widget. I don't care. I log in to everything.

Yeah. And I understand why that they're doing that. It's because they wanna sell you Teams features.

You wanna charge 5 bucks a month per user, and that's every single startup right now wants to do that. So by aggressively putting you into an account, even though I use 0 of the account features but for me,

I don't care because it's worth it to me. Warp is so good. So Yeah. Number 1 warp feature to me, being able to select text and delete it or click and, you know, use it use my text set or use my, prompt as, like, an actual text input rather than just this archaic command a, command k, all this. Like, yes.

Let me dank a click on things for sure. I I don't know, you know, if that's something that normal people care about, but there's there's a handful of times where, like, you know, you mess up a script ever so slightly, and it's a long ass, thing that you've just typed in. And now I could just select where I want my mouse cursor to go and fix or, you know, group select or whatever. So, yeah, worked for me. Pretty dope.

Alright. Let's move into some oh, hold on, actually.

I asked on Twitter what people wanted. Let's rattle through Oh, yeah. Node to meet you. Ones.

Alright. I asked on Twitter, what's your Node. Js wish list right now? And it's kinda interesting to see what people say. Someone Sanity, cheap cPanel hosting, Coolify, definitely saving us from that. I should tell you, my, like, Bluehost hosting, which I hate, but I've had it for probably 15 Yarn, and there's like, I've got my wife's website on it. My dad hosts a couple website on it. I've always, like, been like, you're allowed to host as many WordPress websites on there as possible. And I the other day, I got an email from them being like, you're over your hosting limit for gigabytes.

And I was, like, over 15 gigs of of space, and they're like, you'll be automatically upgraded to our next tier. I was like, oh, no. Like, they're squeezing us. They're the last one to squeeze us, realizing that selling somebody a server that you can run unlimited websites on is probably not getting as much money as you could if you charge $5 a user per website per user per month per week per dog. So Google Fi, save us, is saving us from that type of thing. Bundle to ship executables. You can do it. This is a tweet that I did over a year ago, and this might be, besides my sock tweet, my most viral tweet ever because Crazy.

People lost their minds because it was 85 megs as a hello world. But even like a go hello world it by the way, it's smaller now. You can get it down quite a bit, especially if you take out all the ESLint stuff. So if you're not doing international translation for Arabic, you can take out that stuff, and it will get much smaller. But the reason it's so big is because you need the JavaScript runtime to run JavaScript. It's not being compiled into machine code.

So you still need that. Anyways, TS support incoming is good. People are happy. Affordable housing market.

Native ES decorators, that is something coming to the import. We talked about this a while ago, a couple episodes ago on import something as text or import something as CSS, so that's kinda cool. I don't think that that is inspect out yet, though. Is that finished? So, like, it's not gonna land in Node until it hits the JavaScript language.

Mature defacto web framework that fills the rails void. Alright. So, like, this is not Node itself, but, like, this kind of the community.

Right? Somebody wants a Laravel or Rails of JavaScript. What else do we got in here? Pipes.

This would be amazing. So pipes are being added or being talked about being added to JavaScript for many, many years, and that would allow it's not part of the JavaScript yet, so it will not be part of Node. But it's kind of cool because you'll be able to do things like, you know, when you chain a map filter reduce and then you wanna pass that output to something, you have to wrap the whole thing in, like, a console log or in a display text, piping, and I need to just continue to pipe.

Sorry. I'm wondering if Dex is talking about, like, Golang style pipes or if he's talking about What's Golang style? Golang

pipes.

It's basically your your streaming data from Node spot to another. You're you're you're passing something into a pipe, and it goes in that pipe.

We have stream. That's isn't that streams, though?

Like I that was part of there's I I'm not going to speak on that because there's subtleties here that I'm not aware of. But I know people who use Go really like pnpm in Go. Oh. But I don't know if that's what he's even talking about, so I don't wanna put words in Node his mouth. But when I first read pipes, I that's what I thought he was talking about. NVM out of the Bos, so that's

versioning your node Vercel.

I don't think they'll ever do that because that's so specific.

Yeah. They even on the, official node install

page, they suggest using NVM directly. So Yeah. I still use n.

I don't use anything. I just install 1 version globally from my whole machine and Really?

Abandon old projects because they might not work. I I use n a lot because like, for example, the TypeScript support dropped the other day, and I quickly just did n nightly and installed the nightly Vercel. I was able to show the TypeScript code running in Node in in the video right away without having to, like, override my global node version. Remove it from existence. ESM only. Honestly, I think we should do this. Just Yeah. Me too. Yeah. Although I don't know. I know. That's a that's a controversial opinion of mine. Yeah. Just don't I mean, people people say this, but then they don't realize that, like, their Next. JS is still running in in Common JS. You know? Like, yeah, you you author your ESM, but it's you got a lot of bundling under the hood. And, like Yeah. Everything is supported on this 1 node package that hasn't been updated in 12 years and JS it would totally crumble.

Realistically, that's tougher than theoretically.

Totally. Yeah. It's it's an ideal.

But that's it. Node is doing super well right now. Couldn't be more excited for the sort of JavaScript server side space in general, but let's get into some sick picks.

Yeah. I got a sick pick. So we had a guest on Anna Pavlitz from 1 Password, and she sick picked a board game, which was Cascadia.

Now I'm our family isn't like you know, there's, like, board game people who are, like, really into niche board games. Yeah. That's my wife. She loves games, and I I couldn't Okay. I I hate it so much, games. When we went to the Century office, Century made, like, a card game. And I was like I was like, just so you know, I hate games, but I'll still win. And I won.

Yeah. And that made me really mad because the whole time, you're like, I don't like this, and then you Yarn winning it. You're just like, okay. Let's cram in here. I I like games. I'm a I'm a game guy, but I'm not like a a niche game guy. But I took a chance on the Cascadia, which is a game that Anna recommended Yeah. Because it sounded like something my kids might like. And at first, it was like, alright. I think the intended age might might have been, like, 8 and up or something like that. So it you know, our kids being 57 didn't really fit. But I went for it anyways, and our kids really picked it up. It's about, like, you're building kind of, like, wildlife habitats where you get combinations of squares for maybe this is a specific environment and the eagle can live in here, and you're building all these patterns. So, like, an eagle can't be next to another eagle. And if you have 2 eagles, you get 8 points or whatever. At the end of the thing, you you tally up your points. So you each have your own little environment that you're building.

And our kids have picked it up really, really well to the point where they're having a chance at actually beating Courtney and I at this game even though it it's rules wise, it wasn't that simple. They just like the idea of, like, it's animals. Oh, I wanna build a a a a row of salmon here because they're pink. Okay? And that, you know, got my daughter a lot of points, or I want I want this eagle so bad. Alright. Where do I put the eagle? I put it here. And, gosh, it was just a really great kind of calming, relaxing game that still involves, like, personal competition. So when we're all, like, trying our own strategies and trying to win, it it it was just a lot of fun. So if you're into board games and haven't checked out Cascadia, give it a try. I thought it was really great. Or if you're just looking for something that is fun for the whole family, yeah, I found this to be really great.

Oh, that that seems like something I would fake an injury to try and get out of.

We we ended up buying it for our sister-in-law, my sister-in-law.

And their family really liked it too. So

Kill me. Kill me. That sounds awful. Anyways, I'm sure it's fun. Maybe I should give it another try. I'm going to sick pick a Roborock vacuum again.

So we probably about a year ago, I sick pick the Roborock S 8 Pro Ultra, which is the, like, Cadillac of vacuums, and it has improved our life so much because the amount of time saved like, I I I think we have, like, 400 hours on it. And if you think if you were to even spend, like, a tenth of those hours yourself vacuuming, that's quite a bit of time that that you save, and it it's been such a game changer in our house. It's expensive, but it's been such a game changer in our house for just always having super clean floors and also not getting stressed out. When the kids drop something on the ground or they spill something, it's not a big deal because the little beep beepot will come and suck it on up. So we've had that one for maybe a year, year and a half, and we've been loving it. And I was doing the, like, YouTube thing because we wanted to get one for the cottage, but I was like, there's no chance we're spending I think it's, like, $1800 Canadian.

There is another one called the Roborock Q Revo, and this one does all the things that the Pro Ultra does. Meaning it mops, it vacuums, it has a freshwater tank, and a a like, a dirty tank in it, and it has bags. Meaning that, like, you you have to just change the bag once a month. You gotta change the the water maybe once a week or so depending on how much you use it.

And this one's, like, $1,000 Wes. And I was like, okay. And a lot of people Yarn saying it's just as good as a mopping and vacuuming.

It just doesn't have some of the LIDAR in it that does the sensing. And I'll tell you right now, the the expensive one sensing is not very good. It still sucks up our cords. You still gotta run around and make sure there's not a Yeah. Not a cord on the ground because it will suck it right up. So we got the Q Revo, and it's just as good. It's 94% as good. I feel like it sucks up the cords a little bit more than the other one. The other one every now and then, 1 in 10 times, it will, like, be like, oh, I shouldn't suck up a cord, and it will it'll turn away. This Node, 100% of the time, it will suck up a cord. But if you keep the cords off the ground, this thing is amazing. And for $1,000 less, I would probably recommend you don't upgrade to to the the other one. It's even the the tank is bigger. The freshwater tank is bigger. So why not? Had a water tank. I have the Roborock

6, maybe. I got a Costco special Yeah. A few years ago, and I love it. The only downside of it is that it does not have a water tank. So I'm, like, constantly You gotta fill it up. The water, like, almost every day. Yeah.

You just like, maybe once a week, once every depends on how often. We run ours at probably 2 or 3 times a day.

Run it after breakfast, and we run it just because after dinner, and then often, we'll do it. I'll bring it down to my office. So what you need to do, Scott, is bring it to your office. Yes. I've My my my my my my my gym.

The we've got these, like, like, rubber mats in the gym. Yeah. And it it just does such a perfect job at scrubbing the mats and making everything feel good. So I still need

to get some mats from my gym because we're just rocking on carpet right now. If if I felt like throwing away money, I would get a second Node. But mine is, like, too functional and too good to justify it. But, yeah, you know, I I do the thing I love the most about the roborock system or even having that little mop dragging arm or whatever. Like, for me, it's just like a little mop pad that you have a little water tank and whatever drags behind it. The thing that it does the best for me is, like, kitchen sticky spots or whatever. You know? Yep. With kids, stuff is ending up on the floor all the time. And if the robot is not running for, like, a week because maybe it sucked up something and I haven't done maintenance on it, then I Node very clearly the kitchen floor is getting worse and worse all the time. But then when it runs, it's like you don't even notice it. It's like, wow. These these floors are actually feel clean. You wouldn't think that a little tiny mop dragger would work that well, but it works really, really pretty well. Yeah. Yeah. The the Pro Ultra has

it vibrates.

It goes.

And Wes the Pro Ultra also has 2 vacuum head spinners, and the Q Revo has 1. Again, I haven't noticed the difference, and our kids are very messy.

But the the Q Revo has spinning mop pads. Like, it spins in circles, 2 of them. And I I feel like that's better because it's it's constantly actually moving over it. And, like, it also has, like, a pin feature. So, like, if the kids drip, like, a or if I drip coffee, I've done it too. You can just open the app and pin it on the map, and then it will just run over there. It'll do, like, a meter square and then go back and clean itself. Oh, that's cool. We just have room. I don't have, like, ability to pin. I can just say, hey. Go do this thing real quick. But that's easy.

Tech. The problem with tech is that I don't want my vacuum to go out of date.

You know? My vacuum is gone. I don't want my car 2 years old. Depreciate. I don't wanna know about any new cars anymore. I have my new one. I don't wanna hear about any features on new ones. I don't care. I don't wanna have to have the iPhone effect on everything in my life.

Yeah. I Node. That is it. Right? Alright. Well, shameless plugs, check us out on YouTube syntax at Sanity f m on youtube, youtube.comforward/atsyntaxfm.

We post all these episodes on YouTube, and sometimes we show code. And, we do a lot of fun stuff over there. Not only that, but we are cooking up a ton of additional stuff over there. CJ just released a video at the day of recording this on tree shaking. So it's been really, really pretty awesome. I've been doing some videos on Local First, and we have just a ton of stuff coming down the line. So follow us on YouTube. If you like, our voices and you like the way we describe things, we'll give you that much more of it. So check it out. Awesome. Alright. Thanks, everybody, tuning in. Peace.