Standard Server JavaScript - Deno, Workers, Bun and More

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talinski and Wes Bos.

Hey, everybody. Welcome to Syntax. Today, we've got a show for you on rid. Server side run times and the APIs that we need to use in order to target them all. So there's sort of this, like, new Suite of different runtimes. We have nodeno, Cloudflare, Bun, Fastly, Alibaba Cloud. There's always like there's more rid server side JavaScript runtimes than there are client side, which is wild to think about.

So in order to make them rid. Make your code work across all of them. We're starting to see people shift from, oh, I'll just write this thing entirely in node APIs to, if rid. Possible. I'll write this thing in JavaScript APIs.

And that's kind of what the show is about today. I'm pretty excited to dive into it. So Welcome, Scott. How you doing today? Oh, hey. I'm doing good, man.

We didn't talk about this, but I destroyed my glasses. The glasses that I've had for the past, like, 2 years. Oh, I was wondering why you weren't wearing them. Oh, yeah. I dude, you want to talk about, like, classic Kind of like clumsy things that I do. I was in the gym and I was doing like a rotational chop thing where you got some resistance and you're doing like chop movement. Yeah. And, I did a movement and my glasses have always been kind of loose and they just fell off my head. And then as a part of the movement, I took a step and just Godzilla stepped right onto them and just actually broke them into like 5 pieces. Oh. It was just 1 step, and I felt it instantly. I was like, ah, shoot. I mean, but they were they were old. They were kinda nasty. Like, what are you wearing Now, are you do you have backups? No. I'm just squinting right now. You don't you don't have any backup glasses? So I ordered like an emergency Couple of pairs from some like Ibuy direct and like cheap sites. I got some like emergency prescription pairs for like $40 or something. And they're decent, but I I was wearing contacts. I have contacts, but my eyes have been rid. Wigging out just like, I'm not used to wearing contacts every day, so my eyes have just been crazy. So What I'm doing right now is I'm just giving my eyes a bit of a break. I'm just letting them relax and then, shoving my face into my computer so I can see.

I don't know how if I could have glasses. My wife has them and she loses them all the time. And I was like, when are we gonna get find my In your glass. Glass. Yeah. Because, like, it's it's gotta be somewhat soon, you know? Like, I guess getting a battery in there is gonna rid Kinda tricky, but I can't lose mine because I always have them on. But Oh, yeah. Yeah. My wife just puts them on sometimes. And I the whole glasses industry is such a scam.

Rid. Like it's we're starting to see a lot of like online companies pop up, and you realize, oh, like this if you know your prescription, you don't Have to pay 6 times the price if you at the optometrist.

Seems like that's a bit of a conflict of interest. I get my Typically get my glasses from a rather fancy place that I've always been to though. So, they do all, like, custom glasses see eyewear. And, rid. Yeah. It it's actually one of the funny little, coincidences between Denver and Ann Arbor, where I I lived before, was that they both have a seat. There's not like a there's 1 in Chicago or in Ann Arbor or whatever. But it is is that I've always just gotten in there. Either way, I like fancy glasses. These cheap ones, that are, you know, I buy direct are definitely garbage, but

I'll take them. Awesome. Alright. So rid I did a talk at Reactathon a couple months ago about these new server side runtimes and How if you write server side JavaScript now, it might make sense for you to start especially if you're a package author, It might make sense for you to start to think about deploy writing it so that you can deploy it literally anywhere. So we have Node.

Rid You can deploy that to serverless node or long running node. We have Deno.

There's Deno deploy. Netlify Edge Functions run on Deno. Rid. Supabase, Edge Functions run. And, you know, we have Cloudflare.

Vercel Edge Functions run on Cloudflare.

You have BUN. I don't know if anyone's running BUN in production as like a service just yet. At least I haven't heard of any. There's Fastify. We had Jake on a couple of days ago and the Alibaba has their own edge, which is Crazy that there are so many JavaScript runtimes where you can run server side JavaScript, and a lot of them are kind of focused on Edge, which is essentially just JavaScript that runs.

It's like a CDN. Right? It's distributed throughout the world. And when somebody hits a request for a specific function, then it's going to run As close as possible to you. We have other shows about what the edge is. And and I I also do wanna point out to the listeners

who, You know, if you're newer to JavaScript, some of this stuff can feel a little confusing in in terms of, like, what it means for browser JavaScript.

And it ultimately doesn't mean very much for client client side JavaScript in this context.

And so In the web world, we're so used to having to support different things. But here, you know, with these different server side run times, Yeah. You only have to support what you're running on. So you don't have to worry about any of these if you're writing a node app or node. Right? That's that's, like, I think just a thing because sometimes you you see all of these different things, the bun, the Dino, the the and people might worry, rid. Do I have to support these things? And the answer is ultimately no. You wherever your server side code is running, that's where Yeah. You need to support it.

But I think the the point in which we're gonna get to is, like, what is the common thread here to support the most of these? Yeah. And

rid Even I think even further, you said, like, if you are just doing client side JavaScript, you don't have to worry about these. And the answer To all of these different platforms is not that there is either a, a whole bunch of specific APIs for each of them. Rid There there are, but the the whole idea is that we're gonna standardize. And the thing that they're standardizing on is browser APIs.

Rid And that's the whole that's the amazing part about this is that they're taking because we've standardized browser APIs because we've had so many browsers and we needed rid. Do that. And now that we have a lot of server side APIs, it doesn't really make sense to reimplement an a whole new Standard of server side APIs because we have a set of APIs. So at the end of the day, it's all just rid JavaScript. And a lot of these all of these APIs, I I was gonna say a lot of them, every single API we're talking about today rid is a browser API that is now being used on the server. And it's pretty awesome because

eventually, I think we'll get to a point where You don't have to think about, okay, I did this this way in the browser and this way in the server. It's just JavaScript. And I think that's really the beauty of a lot of this. And that's definitely been, Like, I think some of the initial appeal of when Deno was first announced, them going hard on browser APIs was a big thing. And, you know, it's funny because it does feel like I mean, fetch has only been in I know we'll we'll get to the actual APIs in a minute here. But I I you know, Fetch has been a node now for what feels like a decent amount of time, but ultimately in the timeline of things like a couple of Years ago when we were doing the show talking about Deno, we were saying, is Node ever going to get native fetch? And now Node has native fetch and rid It's just interesting. And I I I love the fact that it isn't it is like a a one language For the same things in all of these different contexts. And that's really the beauty of being able to write JavaScript rid. On the server side, on the client side, on the I mean, JavaScript can run anywhere.

So now that if we standardize on the APIs, You'll be able to essentially transport your code in different places. Exactly. So there's

a new rid community group called the Winter CG, which is the web interoperable runtime community group. And they're ready. Trying to figure out a set of standard APIs so that our our code will run across them all. You might be thinking, Wes, isn't there already rid Like a bunch of like we have t c 39, you have w three c, and you have the what w g, The What working group. And so now we have another standards API. You might be thinking like why why do we need those? Well, The thing about the web standards group and the reason why we never had fetch in Node is because fetch was a browser API. Rid. So that fetch was developed in the what working group, the what w g, and same thing with service workers and resize observer. All of those things were developed in terms of the browser and that everyone kind of was like, well, why don't we have this in node? Rid. Right? Like because Node conforms to TC 39. And TC 39 is, async await, ESM, import export, arrow functions, all of that stuff. That's JavaScript. Right? And then you the w three c has things like WebRTC, rid. See the streams API, web components.

So you're thinking like, oh, why doesn't Node have or why didn't we have fetch for the longest time? It's because they didn't really conform of that. But now we're starting to see Node implement a lot of these browser APIs and Giving us really good like converter tools so that if you have older code that isn't based in In browser APIs, then you can easily convert them. Like a good example is like streams.

Rid We have web streams now, but like Node had streams for forever before that. So you can now convert them to to web streams. So that's kind of the whole idea with this, show is that when you need to implement something, even if you're just writing Node, rid Just tell yourself, okay, let me pause for a second and figure out is there a web standards way? Because rid. Even if you're just writing note at the end of day, you're never gonna deploy it to anything else. You're just running a render server.

You probably still wanna be using these standard APIs because they are the sort of the way forward. Yeah, I think that's a great message, yeah. All right, so we'll start with the first one which is fetch.

Rid. That's no fetch, right? It is so fetch.

How many times have we said that joke on this podcast? We need the AI thing to count it for us. Yeah.

So fetch is obviously used for submitting requests. However, fetch is also the basis for rid. Two things, incoming and outgoing requests and responses.

So if you build a Cloudflare Worker or rid. Adeno edge function or or Vercel edge function or something like that.

What you essentially are listening for is you're using event listener, you're listening for a fetch event.

And when a fetch event comes in, that is essentially a request.

So you're saying whenever somebody hits this URL, it's a fetch event and it gives you 2 things. It gives you a request, the thing coming in, and it gives you a response, The thing going out, and you also get the event. The event has a bunch of information about headers and IP addresses and all the stuff you probably used to for that coming in. And then on the event, there's event. Respondwith so you can return data. That's that's the whole response thing. So The whole idea of fetch, standard, web request, and web response are sort of the building blocks For a lot of the stuff that we build and send over to the server and especially something called web streams. We'll talk about it just a second. Yeah.

Rid. I mean, those of you out there, it's a good API because it's so used in front end dev stuff.

It's a good API to standardize on because it's one that everybody's familiar with. It it largely feels like it doesn't necessarily feel like there are things missing from it. Now granted, you know, there's there's definitely like little wrappers and things you could put around it that make it nicer than anybody coming from something like you used to use. Rid. Do you still use Axios?

I have it in a couple of my projects still, specifically, because I use the, like, interceptor and default stuff, which is funny because we did a whole show on Why do people still use Axios? And you were like, nah, I don't get it. Why do you never use it? Yeah. I've never used it. And then you sent me a package the other day That was like something built on top of Fetch.

And I was like, this is what Axios is.

I know. But it rid. It was new. Okay? It was new. It interesting. Yeah.

But we should probably mention what that is because it was Significantly smaller than Axios. It probably doesn't have feature parity, but it does most of the things that I want. Sometimes I get that with With packages is like, I'm using this massive package, but I only used it for 1 or 2 things. What was it called again? Yeah.

Rid. I'll go back and look in the chat.

KY from Sundreis Sorehouse. Yep. And so it does a simple API, has method shortcuts, Which is like you can do .post, which is really nice because if you want to like post or put or delete something, by default fetches get, You don't have to like set the setting, you could just use a nice little method.

Treats non 200 status codes as redirects. Retries failed request, that's a big one why people use Axios.

JSON by default. You can do URL prefixing. So if you just want to likeif you have like a base URL and you want to like say API. Syntax. Fm, You don't want to prefix that every single time you just want to say like forward slash shows.

You can just you can set that default

in there, which is really nice. Yeah, I thought it was rid neat little thing. But, yeah, I that is it is funny because I never used Axios, and I was always like, I don't know why. And then, sure, I send you this.

Rid.

URL is a API that is in the browser and this is for parsing out URLs. So you It's a new URL, you pass it a URL. And this is how you can get parameters and Route information when you're inside of a request. So you getyou have like request.url or something like that Or request that path name.

Mhmm. And you can pass that whole URL to a URL constructor, And outside of that, you get the you get every little piece of the URL that you could want, the protocol, the path name, search params, host, etcetera, except the search. URL.

Search will give you the entire question mark after it on the URL. And if you wanna parse those out, how do you do that? Using

URL search params, which is funny because URL Search params. I would imagine. I I I don't know, everybody's story, obviously, but I would imagine a lot of people re encountered URL search params for the very first time when using React router. And they were like, how do I get query params? And React routers official stance was always, We're not gonna build this into the library because it's a browser API. Just use URL search brands.

And whether or not that was a, you know, a controversial decision or, You know, something people love. But I I would imagine that a lot of people in the React world, who had never used this API came to this, API and decided, Oh, shoot. Now I gotta learn how to actually work with browser APIs to pull out my URL search params.

But, basically you pass on a param string to a new URL search params and it just, gives you your, params. So you can

rid Loop over them. You can pull individual ones out. You can append. You can get. I mean, you if you're working with params, this API should be very comfortable to you. And especially because it's not just like an array or an object of data. It is, and you can get an object if you really want to.

But it's it's an iterable that has a whole bunch of nice methods on it. Yeah. It's very closer to Yeah.

Like the map, Like a JavaScript map. So it has append, delete, entries, get, get all, has, keys, set. And it's it's so nice. Like if this was a library, You'd be like, oh, man. You definitely gotta check out URL search params. It's got everything. It's makes it makes working with params so much easier. So, like, if you ever In the same on the flip side, if you ever have to construct a URL I do this all the time. I'm like, rid I'll just have an array and join it with an ampersand, you know? Yeah.

Pain. No. Pain. Pain. Pain. It's because there's a special encoding, URL rid.

You got to look up the difference between encode URI and encode URI component.

I've it's funny how I think a lot of people would go that route, just because it does feel like, oh, it it would be easy enough to do. You know what I have been doing recently, Weston, what I'm doing on The syntax site, which you might find to be interesting Yeah. To work with URL params, I found this to be, there's a Svelte rid. URL params store, and it essentially just works as a Svelte store called params or something. I forget what it is. Rid To add or remove params, you just do dollar sign params dot whatever param you want, and then you can just update it. And it automatically updates it In the URL bar, and keeps it in sync. And likewise, you can read them really

observably because it's a Svelte store. You can, Yeah. Oh, that's nice. It's it's funny, like, you talk about data stores. The OG data store is the URL. Right? Oh, I love it. Right. Rid Put stuff in the URL. That's really nice that it like because the other API that kind of goes along with URL search brands and URL is the history API, which is ready. Yep.

Changing the page, you know, and that's what a lot of all these routers, Felt router, React router, all these things use the history API in the browser.

Rid And keeping those in sync can kind of be tricky, so it's nice that they just do it for you. Yeah. I'll I'll I'll post a little Code snippet in the show notes or at least a link to a code from the actual repo. So anybody out there can see it's pretty neat. But you know what? Rid out there if you're out there and you want to put state into your params, that's such a good place Have state because you can share it. You can share a URL with query params and have it encompass state.

So a lot of times you'll see websites using query params to do state for things like that. And I think that's largely, especially for interface stuff. Right? You have Content that needs to be filtered. Put those filters into the dang URL as either query params or you can also do it as, like, actual slashes in URLs. But Having your application state in a way for things like filtering or sorting or those types of things in the URL is

lovely. Rid Next one we have here is, at event listener. You're probably used to using at event listener for clicks and other events in the browser. Well, surprise surprise, the exact API works also in on the server. There is not a whole lot of built in events.

Rid. There is I talked about the fetch event, which most platforms implement. That's kind of how you build a Cloudflare Worker. The entry point is rid. Literally listening for a fetch event.

And then there's like error load and unload are when your script starts and stops.

It's kind of like, on before close or whatever the that browser API is before you close the tab.

But the the real benefit Here is not that you can listen for Mhmm. Your script starting and stopping because, like, honestly, that's probably not all that useful.

Rid. The real benefit is that you can make your own events.

So you can Yeah. When a database is saved, you could fire an event, oh, user has been updated. And then you can dispatch custom events. Like custom events in the browser, I think are kind of under underutilized because rid Dude, they bubble they bubble up and you can listen and you can you can put data in custom events. So you if you want to, like, say, alright, anybody who cares That I just updated user 123.

Yeah.

You just they're just firing guns in the air. That's how I think of events. They're just firing guns in the air, and then literally anybody who cares says, oh, I actually want to know that that user was updated, And they just dispatched it. So I'll grab that event and and get the data of the updated person.

I love making my own events, first off. And I do use them on the front end quite a bit. And then every time I use 1 on the front end, I'm just like, man, I really don't See enough people talking or using these that much. But having them to have your own custom events is so useful. I wonder why, libraries like you think about like database connections or Redis or stuff like that, they're oftentimes just using their own like on method Or like on connect method. Yeah. I wonder why they they don't use custom events. Like, what's the downside there? Yeah.

So like in Node land, there was, event emitter, which was, kind of their own version of this, and now Node has implemented add event listener.

I'm curious. May like maybe I think a lot of the legacy stuff was just wrapping it, or they need to do yeah, you're right. Like, I don't rid. Don't necessarily know. Maybe because they only ever want you to do 1. You know, like, you could add multiple event listeners by accident.

You know, maybe that would be an issue that you usually want it in internally.

Web streams. We have an entire episode. You go back and listen to Episode number 587.

We talk about what web streams are and and how they work.

So again, Node. Js had its own streams implementation and a lot of libraries still use those. But Web streams itself is is massive. You can stream stuff from the browser to the client, and what it allows you to do is rid. The client or the browser client is my example, you could go server to server if you really wanted to. But like a good example is If you have a React application as you are rendering it you're literally throwing it out the door to the client before the entire thing has been rendered. And Chat GPT is is a good example like that. You know like Chat GPT does that like typing thing Where like you have to sit there and wait for it to to figure it out. At first I was like this is like don't fool me. Yeah. Just think you're doing it twice.

Yeah. Like, oh, yeah. You're a I get it. You're a person.

And I was like, this is so silly that I have to sit here and wait for this thing to Fake type it out to me. Just reading a stream.

Exactly. And Yeah. And the the actual answer to that is it's act it's literally Yeah, it's streaming. It's streaming the data. As it's figuring it out, it's streaming it to you, which is Crazy to think that when you have the first part of a response, it doesn't know what the the other responses. And if you use the OpenAI API, their own their own node package doesn't even support web streams.

So you do have to sit there and wait for the entire thing. That's sometimes why it takes so long to get a response.

So, Vercel's AI library, which uses which is sort of like an interface for multiple, AI providers, They support streaming 1st class, which is really cool. It is really cool. I I oh, I've I've said this before, but like There's so much to web streams, but one of the coolest thing to me is you get a you can create a web stream on the server, and then you you use fetch To accept the stream on the client.

And you can literally call stream. Cancel And it will signal to the server that you have canceled it without any special APIs or rid Controllers or anything like that. I just thought like, wow, that is literally amazing that there's a method that works rid. On the client and we'll just communicate directly to the server that, hey, you know what? I no longer need to keep going with this thing.

Is that considered an RPC?

Rid I don't I don't know. That's a good that's I was just thinking that as as you're, like, oh, this sounds like RPC. Right? Yeah. Totally. Kind of. I I guess so. It might be more of like a networking level thing, but it kind of the same idea of you call something client side and it executes the cancel method. Like if you have a custom cancel method on your server, it will run that. Structured clone. This is one of those things where I feel like I've been doing Coding for a while, and I had no idea this was a thing. Have you ever heard of structured clone? Have I heard of it? Yes. I'm I I feel like it's one of those ones that,

comes up when I'm looking for things sometimes, but I don't know if I've ever implemented this, rid. Explicitly.

I I'm trying to look right now in my code base to see if there's anything with structured clone in my code base, but I don't see anything.

But it it looks familiar enough that I know that it existed, you know. The

thing that It does is it creates a deep clone of your object.

So if you have rid. We can do a real quick primer on references versus copies.

In JavaScript, if you have a variable Const name equals Wes, and then you say const name to equals name.

Rid You're copying the the string less to the into the 2nd variable.

However, if you rid. You if you have an object or an array or any other type of specialized object, rid. Then you by doing that same song and dance, it's not copying the data inside of it, it's just creating a pointer, And saying, all right, well now you have 2 variables that point to the same piece of data, and if you updated either one of them then The other one will update, right? It kinda like you have a live variable to the other one. And then you can do like a spread rid Or array. From or anything like that, and that will take a copy of the top level values. But if you have like a nested object That's like 2 levels deep.

The only the top level will be copied and the other ones will just reference it, which is often rid What you want. Right? Like you you generally don't always want to make a whole entire copy, but sometimes you do. Sometimes you wanna create an entire deep clone all the way down, nested as many levels deep as you can possibly want. So structure clone Who does that for you? And quite honestly, that's one of the reasons why I was still reaching for Lodash in some cases is Yeah. If I needed to Pick a copy of something, then I I could. So structured clone is it's it's in all the browsers, Chrome 98. What are we on right now with Chrome? Rid

A 100 and 114.

Oh, so it's not that when did Chrome 98 come out? February 1, 2022. So it's It's only a year and a couple months old at the time of recording. So that's probably why I haven't heard of it is it's really, pretty new. Safari 15.4. So it's only been around for about a year, in all the browsers right now. But it is in Deno, it is in Node, which is cool. So you can take a copy of it.

So that's one of that's one of the standard APIs that every single Implementation needs. And then I saw this thing on there's this website called Worker Tools.

And Worker Dot Tools is a set of rid.

Different packages used to go across all of these. And we're going to list off a bunch of packages that work literally everywhere.

A workers

tools just so people know. Oh, workers. Tools. Oh, thank you. Yeah. Yeah. Because worker tools does not lead you to that. It's a cannot be reached. And that people Although that's funny, it's workers.

Tools. Or workers.

Tools is the URL, But it says worker tools as the main header. Oh, yeah. Update that.

So I I actually reached out to the guy and asked if he wanted to come on the podcast because, rid I've been referencing this website quite a bit.

He's like, I'm not really comfortable coming on podcast. Sometimes people are so smart, but they don't love Coming on and talking about it, they'd rather just kind of put their head down and keep working on awesome stuff.

But this is a whole set of different tools that That you can use to create applications for streaming and for promises and whatnot. And the guy said, he's like He's like, this project is not kind of ongoing right now because a lot of people have gone over to Hano JS, but it's still an awesome resource to sort of look Look at Anyways, so he has this package called structured JSON, which allows you to stringify And parse objects, but keep all of the types that are not JSON able.

Rid so dates, maps, sets, array buffers.

There's a bunch of JavaScript that cannot. And when you JSON stringify something with a set or a map in it, it won't work. And you have to have a custom parser, to do that. So this is kind of cool is that it takes The structured clone algorithm, and it allows you to stringify it and then put it back into All of the types that you had.

So, like, maybe this is this is not a browser API. So the structured clone is a standard API, But the structured JSON, this is just a package that he created. But like wouldn't it be cool if one day We moved to this new type of JSON parsing without breaking the existing JSON. Oh man,

So that's that's like really interesting because I mean, for those of you who don't know when you're sending, let's say data from server to client, you can't like you said, there's some things you can't send as is. Right? And they lose their type. So you have to Serialize and deserialize stuff on the to and from.

Dates are like often a problem as well. Right? So this could be used to do that, right? Yeah. That's that's yeah.

I oh, it also supports file, blob, and file list.

Man, that's cool.

If you had a file, it would encode it, and then you could decode it back into a file.

Rid. That's sending more JS types across the network. I love it.

This obviously requires buy in on both ends.

Rid. So in order for this to overtake the JSON implementation that we have right now it would need to be implemented by literally every language In the world, right? Because JSON is not just JavaScript. JavaScript JSON is is universal. It's every programming language. So Will we get that? Probably not.

I've I've been part of so many, rid. Discussions of can we move to at least move to JSON5? JSON5 allows you to trailing commas and you can do Comments and Comments,

yeah. Comments, come on. Can we get comments? Come on. Please.

And like I proposed it to NPM And they're like, it's it's not ever gonna happen because the tooling, the entire ecosystem is all based on JSON. Parse.

And they would all need to install this third party package called JSON5 in order to parse it.

So it's probably never gonna happen, which is a bit of a bummer.

Rid Yeah. Yeah. But we'll we'll see. Maybe maybe one day we'll move away. Versus Code uses JSON five. That's why if you go into your any of your Versus Code settings files, You can comment stuff out and you can have duplicates and you can do all kinds of rid. What else does JSON5 do? Let's let's explain it real quick. You can do unquoted keys. That's really nice. So you know when you have a key in JSON, you have to put double quotes around it. You don't need to do that in JSON five. Well, you can also do single quotes too in JSON five. Oh. Oh. That's the one thing that always has to be. And line breaks? You can't do line breaks in JSON? Multi line strings. Yeah. That's a decimal.

Trailing comma is the big one for me. Rid. Such a pain in the butt to not be able to do a trailing comma because if you whenever you tell somebody to add something to your Versus Code, You have to you used to have to tell them, Hey, make sure you put a comma on the line before that you had not touched. And then that screws up your git diffs and rid Thankfully, Versus Code's all in.

Yeah, that's the kind of weird thing about standards. Same thing happened with Markdown, although Markdown has moved on, Is that like markdown was put out by John Gerber, and he never updated it for any of the features that people wanted, right? So now we have many flavors of markdown, we have GitHub flavored markdown, MDX, I guess, is its own Flavor of markdown there is.

Multi markdown, markdown extra, pan doc, cramdown.

Cramdown sounds sick.

Markdown 2, Marcu What name like cram? Ghost, Showdown.

There's probably 15 different flavors of markdown, which is a bummer because markdown is no longer a standard. If you take some GitHub flavored markdown and try to render it in something that is not GitHub flavored, then it stops working. That's why sometimes you see like people will post a tip, Here's how you do this in markdown and it works great. Like my favorite was if you have a hyperlink, hyperlink, who says hyperlink anymore? Is do do you say hyperlink? I don't, but I love it. Let's bring it let's bring it back. Hyperlink is where we wanna be. Rid. Anyways, you could just put like angle brackets around it and it'll just automatically turn into a link.

But not only GitHub supports that, not every other flavor supports it. And when I moved from MDX 1 to MDX 2, they dropped that Because trying to parse angle bracket links and trying to parse MDX, like JSX tags, I think was like impossible.

So they just like dropped support for that. So I had to go through like a 130 blog posts and find every instance of me using those that type, which is a pain in the butt. But that's Markdown for you, I guess. It's Markdown. Alright. A little detour there. Where were we?

File? I wan Yeah. I don't know the file, MDN file API. I don't I don't know if I use this for is it this it's not FS.

No. The that's kind of the the interesting thing is that there is no file system rid support in any of these yet. So if you do want to do things like write files, then you have to use the specific version. So rid Deno has its own file system. Node has its own file system APIs.

The reason why there's not there's none yet is because rid. Cloudflare Workers, you know, deploy all these other ones don't have the concept of a file system.

So they're kind of on the fence of rid Whether they should standardize on the browser file system API or just do nothing at all because rid. Half the people in the group are like, well, we don't have a file system. Why would we? And if you can't use it, then implementing it

is a bad idea.

Yeah. Yeah. But

but then, like like, I guess, like like, how often do you write Files to your server in production. Probably almost never, right, because you're doing these immutable builds. Like if you'rethe one thing is you're uploading a file, You're probably not putting it like in WordPress, this is different.

But in most modern deployment, it's immutable, meaning that if you want to write to file of them. They'll let you. But if you redeploy that thing, boom, it's gone.

So you have to use, like, an external s 3 or something like Cloudinary to hold your photos or or user uploads. But where they browse their file system API

Is your local file system because it's running on the client. It's running on your Yeah. Your your computer.

If you use the file system API, which actually rules in the browser, by the way Yeah.

It is using your local file rid. Yeah, I have no idea how that all correlates to server side in systems where there is no file system for you to really, truly work with. I think that they should implement it, and I'll tell you why. Because

in the browser, if the person does not have access if if the browser does not have access to your file system because you've denied it It will just deny it. Yeah. So then Yeah. Why not implement the file system? Because like I can imagine something like Vite.

If you wanna run Vite on Deno, you wanna run Vite on Node, Vite is a build tool. It does lots of file system stuff, you know? Mhmm. So So wouldn't it be nice to have a single library? I even tweeted asking, like, is there a standard library that, like, consolidates it? And It's not a big thing. It's it's not a lot of people write to file systems, so it's not a really high priority, I don't think.

Rid. But there is file.

The file is an interface in JavaScript that allows you to hold Files, and probably the most popular implementation of file is you have input type of file. When somebody selects a file from an input, you ready. Can say input dot value, you get either an array or a single actual file. And on that, you'll have a name of the file, and then you'll have what's called a blob. And a blob is the binary data representation of that actual file.

And you can move files around in blob format. They're just in memory.

And then you can you can send blobs to services to download them. You can Save them to disk. You can just send them back to the user, whatever it is that you want. So again, file is a standard API.

And if you are doing anything with files, don't use the Node API, use the standardized file system

or file API. Now you also have abort controller and abort signal here. I've never used either of these APIs.

Yeah. These are the rid. Interfaces for aborting fetch requests.

So if you have a fetch request that's that's going on. I talked earlier about how nice it is rid. To cancel a stream, it it is using abort signal and abort controller under the hood.

But like a standard fetch request does not have like a cancel method on it. What you have to do is you create an abort controller and pass it to your fetch request.

Rid And then you have, like, sort of this little, like, button that you can press at any time that says, you know what? Rid. Somebody canceled that upload and they're gonna they're gonna redo it. Oh, they they they uploaded the wrong file or rid. I gotta I gotta do this at different times. Hit cancel and and the way that you're able to cancel a fetch request is with a abort controller and abort signal. Rid Yeah. That makes sense. I I don't know why I've never ever implemented these things. I guess I don't work with that many long running user initiated processes. Right? Like, if it's a if it's a fetch request and you're just fetching, like, an API, you're likely just like, I think the one time I've used it is When I'm doing like a autocomplete search and, like, you type let's say I'm searching on the syntax website and I type Java, And then I wait for a second, and I go, Java. And it at that point, it'll send a request to the server and say, give me search results for Java. But then I keep typing in TypeScript.

There's now 2 requests in flight, and there's a possibility that the The first one. Yeah. Yeah. Because if you don't, there's a possibility that the first one comes back second, and then it will overwrite the actual results. Right? So you gotta abort Anything that is currently in flight. And then again, probably why you've never done that is because most Mhmm. Packages

do this for you. Yeah. Rid. Right, yeah, you don't really have to think about it too much. If you're using like

some sort of GraphQL library or whatever and you make a second request, rid A lot of them will just say, alright, well, just I'm gonna abort it, or a lot of these autocomplete packages will do it for you as well.

Let's talk about packages that you can use rid when building stuff. So again, the APIs in a lot of these Do not support Node. That is changing because people just want to use a lot of people don't care about any of the stuff we're talking about today. They just want to npm install something in it. They want it to work. Right? Jip it. So if something uses node APIs, Deno fully supports all node APIs now. So that's great. Rid. Cloudflare has been rolling out support for a lot of them, and they're very close, I think, to doing all of Node.

Which is funny because