Potluck × Bun Thoughts × Guesting on Syntax × Why Rust?

Hey. What's up? This is Scott. Just a couple of things before we get started here. We are trying to make syntax better, so we made a survey. Head on over to syntax.fmforward/survey or use the survey link in the show notes to fill it out and let us know what you like, love, want some more of we have various questions in there, like, what are your favorite episode formats? We want to hear from you.

Also, October 10th, We have a Syntax meetup in Toronto. It is free. It it is at the Mascot Brewery.

Spots are limited, so grab your spot at Syntax It's .fmforward/meetup.

Again, October 10th in Toronto. Come hang out with Wes and I Along with the entire syntax team, we'll be there kicking it. So sign up at syntax.fmforward/meetup if you'd love to come and join us. And now on to the show.

Hey, everybody. Welcome to syntax, the podcast with the tastiest web development trees out there. Today, we have a potluck for you. This is where you bring the Questions. We bring the answers. Please keep submitting your questions. We love getting them. Go to syntax.fm.

Top right hand corner, there's a link where you can Submit your own question, and we'll try to answer it on the next episode.

My name is Wes Boss. With me as always, mister Scott Talinski. How are you doing, Scott? Hey. Doing super good.

Yeah. Not too much to report here.

Just, I solved a really interesting bug in my Tori app that I'm working on.

And Yeah.

By solving the bug, I mean, I haven't figured out exactly how to fix it yet, but I have figured out what it's not. I've been dealing with a an issue with Git display media, and it would never show up. The little prompt would never show up on my computer. And and sure enough, Get display media with the permissions thing, everything would supposed to be working on the latest version of Mac. Turns out It's not working on my computer. Worked just fine on last year's macOS update on my wife's computer.

So it's definitively something wrong with my setup and not with my app, making me feel a little bit better. But that's that's it. Hey. Yeah. Weight off my shoulders there. And you know what, Les? It's a good thing I I didn't ship this app because I I my errors wouldn't have been logged in Century because there wouldn't have been any errors because it would've worked Fine for everybody. But if you got an app that you're pushing out to production, need to make sure that, you know, you you have visibility into what's going on. Check out century at century.io.

This podcast is presented by Century. Thank you. Alright. 1st question we have here today is From everyone, literally everybody is asking me this question.

What are your thoughts on bun? It's it was kinda interesting because we had, the founder or original author of BUN on the podcast probably, like, 8 months ago, and I've done talks on all the different JavaScript run times and and what that means for the future and whatnot.

But Bun launched 1.0 the other day, and we'll we'll talk about what it is in just a second. But it seems like everybody just sort of put their head up and goes, what? Woah.

And it it it kinda blew up. Everybody got kinda, heated about it. So what Bun is Is a JavaScript runtime that is built on what what is it built on again? Zig.

Zig. So Zig is kinda like Rust or or one of these other languages.

And whereas Node. Js is built in, c plus plus. Deno is built in Rust. Bun is built in in Zig. So, the whole idea behind this is you just have another A runtime that you can run your JavaScript in, and they also rolled out support for just working with all They say all, but it's it's not all working with node modules. You can use NPM. Your package JSON replaces a lot of the NPX commands. It does TypeScript JSX kinda like Deno does. So it's kind of exciting.

And they say, of course, they say it's 5,000,000 times faster, the node and everybody like, I was I I just looking at my TikTok comments of I posted a note tip a couple days ago, and, Like, half the comments are BUN? BUN? Yeah. BUN. Node is gone. What's going on? So thoughts on this.

I really like that we have in other JavaScript runtime.

JavaScript is a standard.

We will be able to run this in many Different places, not just Node. Js. And we've talked about this on the podcast many times where you shouldn't be coding For Node, you should be coding for JavaScript standards as much as possible, and I think that's becoming more and more a thing As we go on, I I don't know that it's like, you I don't know that you're gonna be able to a 100% move your app over and just It works in node, and it will work in BUN. There's still quite a bit of stuff that needs to sort of be polyfilled, but that is the the end game. And then the other thing that they Bun really nailed is they got rid of all the common JS, ESM Oh, my goodness. Yeah. Interop Pain, which is funny because fun started off being this, like, faster node.

But a lot of people were saying, wouldn't it be funny if they, like, Won the won the war just because they got rid of the pain that is trying to get ESM and CommonJS to work. I know. And it's so funny how many times I feel like I've said, hey. Why

why can't something just be happening behind the scenes to make it just work, you know, to have them whatever it needs to do, and it seems like I I I have no idea what the actual solution to that was because it's, you know, an entirely new project. But they They managed to get CommonJS and ESM working side by side without any issues, and I just feel like that's The I I I don't know if that's necessarily you know, I've seen arguments for being the right thing or the wrong thing because maybe now it's going to encourage people not to update their code because They can just use CJS and DSM. But in the same regard, I think things are way easier to upgrade over time given the ability to not have to do it all in one fell swoop. I mean, that's, like, a big reason why people Are being stuck in an ESM based Yeah. Context or a CHIS based context is because they don't wanna refactor 10,000,000,000 files to make it all work, and then all of the bumps you're gonna hit along the way, which there will inevitably be lots of bumps, Then all of a sudden, your your testing setup doesn't work correctly or your bundler doesn't work correctly or the way you thought it was all going to work, and then you're tossing your computer out the window. So I don't know. I I love a lot of these things.

And if it does just end up working as a drop in replacement for Node eventually, whatever, hey.

It's all win win for us. But in the same regard, Node. Js is super stable, been around for a a long time.

There's it it it is not dead or anything like that. It is not we're not we're not bearing it yet, so, I I'm happy to use whatever. We're we're currently building the new syntax site on Node. Js. Right? But there is a BUN adapter for SvelteKit, and there's a Deno adapter for SvelteKit as well. I think it would be interesting to try those and to see how much of a Struggle it is to get either of them working with BUN and or Dino. And I think that's, like, really the the awesome thing about the modern way in which we're working sometimes, especially with Either these runtimes or adapters or whatever, we're able to just write JavaScript, hopefully, and be able to deploy it

wherever it is the fastest and most appropriate for our application. I I can't think of a single thing in the new syntax website site that was specifically built on node, like, not even Right? When I initially built all the transcript stuff, I built it all on, like, file systems reading and writing just files to to disk, but that Is no longer the case. Even even downloading the episode and before I send it off as a buffer to the transcription service, That's all done in fetch. Right? Like previously, that might be like a node stream or FS dot read file or something like that, but It's it's all built on on Fetch now. So, like, I think it would be able to go. Like, other things to think about, like like, BUN is a for profit company. So, like, Certainly, at some point, we might see some sorta, like, you know, Dockers had their issues, in the past. Terraform has had their issues.

You just have to think about that as well. Dina's also for profit. Right? And their model is Dina hosting Yeah. Which Feels like that's kind of the inevitability here. And, you know, I don't know who who who's who's to say right now if you'll get burned by that or not. Yeah. I at the very least, I'm glad that this stuff is happening because,

like, look at the stuff that we're getting in in Node. Node the other day just shipped dotenv support.

Which is like, finally. I like, I hate having to, like you starting a new project, you got a npm install dotEMV, and you gotta require it in. And, like, Alright. Now I have TypeScript and and things like that. So Node has dotenv support, has test Running support. It has Yeah. I was about to say test running. Yeah. They are experimenting with the, like, permissions model, which is kinda similar to how Deno does it, Where like, it's like, do you want to allow access to this file? Should this script be able to go to the Internet? And, like, I think the folks that build Node and run Node, which is like Node is not a company. Right? Like, it's It's an open source project. They don't have a mass massive budget, so shout out to everybody working on it.

I think they're realizing, like, yeah, probably shouldn't have, like, TypeScript and all this stuff in the core, but that's that's kinda what we want. You know? That's what most of us want. And, like, there's this, like, purity aspect of it, and then there's just, like, us devs trying to get stuff done. And if you can make that stuff better, faster, easier on us, then we're gonna like it. You know? We'll see in, like, 8 years when there's all this, like, bun is 8 years old and we have to support bun 1 through 27.

It'll be a little bit of a different story. But Yeah. Right now. Yeah. We did see I mean, there has been a lot of things, like you mentioned, the test runner, and that we can now watch or process a note without using Notebon. Yeah. Watching too. Yeah. Yeah. There there's been a lot of A lot of great additions to Node. Even just getting fetch, yeah, has been a a big big bump to Node. So, yeah, shout about to Node. Shout out to everybody working on these great things so that people like Wes and I just get to, drop them in our application and not get to think too much about it, but, yeah, shout out to everybody working on that stuff. Yeah. Everything's getting better, faster, awesomer Yeah. For us. Totally. Okay. Next question is from Juan. Juan says, How can I add a custom auth header for image requests done by the browser for HTML content that's pulled from an API and inserted into the DOM directly? The images, SRC URL and image tag, are protected on the server and require the auth header to retrieve.

Currently, can intercept requests with a service worker to add the header, but I would like to find out if there is a more solid approach without using a cookie.

So this person has essentially protected images that they would like to be loading into the DOM directly.

I'm interested in hearing your answer here because I have never considered this as being, a thing. Right? Because I there There is some little bit of it. Like, the image goes to the client side, and how are you gonna prevent somebody from downloading that if it goes to the client side. Yeah. Yeah. So

this is kind of a interesting question. That's why I put it on there because It's kinda done at a, like, a at a network level. Right? Like, you need to like you said, if you want to be able to do it in the browser, The way the best way to do it is with with a service worker. So I'll explain for everybody that's listening how that works. So a service worker Allows you to intercept requests that the browser makes and sort of jump in the middle, and You can you can stop it from going to the server. So, like, if I'm running some JavaScript on syntax.fm and, I sent I put an image on syntax.fm, and it it goes to scott.com.

I can step in there and say, Before you go to scott.com, let me jump in. Let me add a header. Let me say, I cache this. Let me send it back so you don't actually go to the thing. You can, like, intercept stuff at a network level in a service worker, which is awesome. The downside to that is that a service worker has to first be installed, which it sounds like probably is not an issue in your case since you're you're dynamically generating the DOM in JavaScript.

But if it was just an HTML page, that image tag is gonna fire the request off before your JavaScript is even done loading.

So you wouldn't be able to sort of, like, step in at that point. So, honestly, I think service worker is probably your best bet, but there's other other approaches we could do here. Cloudflare Worker, is one that you could do. So if I don't know if you have access over the the server that's serving the images Or not.

If you don't, a really good solution that server side is using a CloudFlare worker or like an edge worker. And what that allows you to do is sort of, Again, you can intercept the request. You'd have to change the domain name or set up, like, a intermediary if you're using Cloudflare as your your DNS.

But what that allow you to do is to intercept the request for that image, then you can add in your auth And then send it along, along the way.

A cookie honestly, a cookie is is the way to do it. He probably saying Without using a cookie for he probably has some sort of limitations and whatnot. But honestly, cookies is better than service worker. It's better than a CloudFlare worker, edge worker.

And the reason behind that is because cookies will be sent automatically with every request to the server, so you don't necessarily have to Worry about that. And when you initially load the page, if you have any images that are in there that need to be sent, The cookie goes along for the ride. You don't need to load the JavaScript and then intercept it and all that type of stuff. So, honestly, cookies are the best way to go ahead and do that. And you don't you don't need a cookie banner for those as well. Maybe that's why you're thinking about it because you can use cookies on your website That are for actual reasons of cookies and not tracking people.

The last 1 is you could put a query because you said you are Templating out the DOM and injecting it probably with Reactors fault or something like that, you could put, like, query prem tokens on that, and this is what Amazon S3 does. If you're trying to protect assets from being loaded, You might try to load west dot JPEG, but the server will reject that unless you have, like, a query param question, token equals ATV x y z 123 on the end.

And, generally, you can create, like, a single use token, And that token will be valid for 1 minute, 10 minutes, 3 days for you to actually load that image, and that will tell you. So in general, you're gonna need access to the server that's serving up the images to do a good job at this. But if you don't, I think you gotta stick with the service worker. Nice.

This was that was really interesting. You know? Honestly, it's it's one of those problems that I would look at and be like, well, Time to time to get the old Google machine

going. Yeah. Even, like, even Facebook doesn't do that, though. Like, protecting image assets is this tricky thing. Like, if you Right click copy source on an image on Facebook, and you open up an incognito tab and paste it in.

That image will still load. However, it's likely that that URL path, somewhere in there, there's some unique identifier that's tied to Me being able to access that image. But for for a long time, Facebook images were they were not protected because the URLs of the images were so random that if someone were someone can't guess them by just typing in random URLs.

And If somebody has authorized access to view that image, then they could just screenshot it at that point. Right? So if someone's sharing a URL with you, Then it's the same thing as if someone were to screenshot it or save the image locally and sending it to you. Yeah. Interesting.

Next question from Joe.

What are the differences between tRPC, REST, and GraphQL? Why might you reach for 1 over the other? Oh, that's you hit this one, Scott. Yeah. Yeah. So, you know,

basically, at a high level here, you have REST APIs. REST APIs, you're hitting any URL with a request. That request is just going to send back your data. You can use that data.

GraphQL, You're sending a request via, you know, standard HTTP request, but within the body of that request is essentially a string of a GraphQL query string, and that GraphQL string is going to be the shape and the data that you're expecting.

So in in REST, I would I would hit a specific endpoint, which would say, like, podcasts, and it would give me a list of all the podcasts.

With GraphQL, that query string would look like podcasts with brackets and then the individual fields that I would like and maybe perhaps even nested or related fields, which could be related in the graph, so to say. So GraphQL, You're sending a big string asking for a specific thing with rest APIs. You're hitting a URL, and perhaps There's some additional information there, but, essentially, you're hitting URL and getting that information back. TRPC is a library, so it's less of a spec and more of a library.

Like, GraphQL is a spec on how to do this thing, where tRPC itself is a library that serves your your code and then also receives it, allowing you to essentially have a function that you call instead of writing a fetch request or a a GraphQL query or something. You're essentially just calling a function, and behind the scenes, That function is doing the call and returning what you're asking it to. Well okay. Let's talk about, like, the benefits and why you would use each of these. Right? So REST Does not require a library. You know? Granted, you're you'll need an HTTP server on your back end. But on the the client side of things, You could just use straight up fetch, get the data, do whatever you want with the data. Right? So there's not an ecosystem or a library associated with REST. It's just like the standard way of doing things. GraphQL, it being a spec, you would need a library on both ends of the the process to both serve the GraphQL endpoint as well as on the client side. But the benefits are with GraphQL is that you can request specific things that you're asking for. I only want the following information.

And, the relational side of Things can be done within the graph, which is in how the data's connected at the API layer rather than at, like, the database layer.

And so, therefore, I could say, give me the podcast with the hosts and maybe what the host's Twitter account is, and that information will have to be produced by the server somehow, but it gives the UI developer more abilities to just request what they want instead of having the endpoint essentially give them what the endpoint is giving them. GraphQL has a lot of strengths in that it is, easy to make type safe because your API itself is typed. And because your API is typed, you always know exactly what you're getting from the API when you do a call. Right? And that's really nice, but it sometimes it A lot makes you have to write types in multiple places, yada yada yada. There's also some great tooling around GraphQL where you can document your APIs extremely easily, and there's nice visual editors for that type of thing.

TRPC, on the other hand, because it is a library to do this stuff.

What makes tRPC so compelling is that When I call this function on the front end, it kind of obfuscates the fact that you're even doing an API call. It's almost like working directly against the server because the client and the server are well connected. And that way, you also get full TypeScript capabilities.

The type like, with REST, the down one of the big downsides is is that you don't often have that type connectivity because you're just doing a fetch call. Right? When you make that call and the data comes back, there's not an assurance it's automatically going to fit those types that you're saying. But with tRPC, you're going to know if the data coming in, in fact, matches those types. So you get automatic type safety.

The developer experience side of tRPC is really nice because it does feel like you're just calling a function.

And in general, Even though it is a library, it it is a batteries included full of, like, sort of an ecosystem for calling and getting back data in a way that makes it feel nice and easy, but it, in my opinion, has much less buy in than GraphQL.

Because with GraphQL, you have to worry about a couple of things. You have to worry about typing your APIs itself. You have to worry about making sure your graph calls are actually performant.

Because if if you aren't Experience with GraphQL, you could end up writing queries that could be very heavy, load time and hard on your server.

There's obviously ways around that, but even those ways around that are kind of like they're not obvious at a glance.

So using a pattern called the data loader, which is a whole thing in itself, and many people just They get to that point. They're like, oh, no. I have to write all this additional code to do data loader.

So at a glance, REST is, a really nice choice because it's probably the least effort involved here. It's the least effort, but you also sometimes get the least amount of type safety. And I'm saying sometimes here because a lot of modern JavaScript frameworks, Things like SvelteKit do give you that type safety across REST calls.

GraphQL, maybe has the most buy in, Is has the most flexibility, but is also probably the most difficult of these. And TRPC sits in the middle there where it's Less buy in, but there's still quite a bit of buy in because you have to have a server that's a tRPC server and library on the client to do tRPC calls. But it does give you a really nice developer experience.

So, you know, 3 different options here. If you are up in the air about which one to use.

You know, REST is the most bulletproof tried and true option here where, You know, you're not going to get fired for picking REST. That said, I have run GraphQL APIs for a long time myself and really enjoyed working in GraphQL, QL, but occasionally would feel the pain of having to update a thing to update a thing to update a thing to update a thing. Next thing you know, You know, you're hitting 8 files to make one little change.

So just some just some thoughts there. Yeah. I'll I'll answer it from, like like, what kind of Teams and companies would use the one. So, like, a REST or GraphQL API, while you might be building one for your application, that's Extremely common thing to do. They come in very handy when you have multiple types of clients that need to be able to access The same server. So you've got a mobile app built in, built in Swift. You got an Android app built in Twigs or whatever they use to to build Android apps. And Yes. You got web app built built in JavaScript, and, you have, like, a A BlackBerry running on some 10 year old car system. You know? Rest in GraphQL API is really nice because Literally anything that can send a request to a server can interface with REST or GraphQL. Right? It doesn't have To be a JavaScript application that is your front end is communicating with your back end. It might just be like like FreshBooks, for example. I was using their API the other day, and I needed to be able to pull in a list of all of my expenses. So FreshBooks offers up a REST API that you can literally use anything. And then they also have, like, a, like, a node thing that you can install, and it's just something, like, nice has the types that come along with it. And you can It put your API key, and it will do the the sort of the fetches under the hood for you. GraphQL is also really popular in larger companies. We've had this on, the show several times. This is kinda where Gatsby's going with their Valhalla product. Or what's it called now?

Gatsby Connect? What's it the Gatsby Connect. Yes. Or Netlify Connect. Basically,

it's a great way to take a bunch of Rest APIs, services, XML APIs, SOAP, HTML, literally anything. It's a great way to unify all of those Different data sources into a single endpoint and allow other teams to be able to, work and interop with them. So that's What we're seeing GraphQL become extremely popular for these days is a sort of unified data layer that underneath Might come straight from a SQL statement, might come a rest might come from a rest API. Yeah. Yeah. GraphQL does seem to have its benefits

at larger scale than than necessarily at a smaller scale. Oh, yeah. Alright. Next question from Shelley is, are there podcast guest opportunities? Yes. Shelley, if You or anybody is interested in coming onto the podcast, always feel free to reach out to us. Now That doesn't mean you will even hear back because my DMs are a nightmare. Wes' DMs are probably a nightmare. But if you have something interesting to share, You know, we at least wanna we at least wanna, you know, have that opportunity to say yes or no to you. Because, occasionally, we have people come on the show that aren't building something incredible, working at some sort of major project, but are are just, you know, everyday developers improving their life through code and perhaps have an interesting story that other people could benefit from. So I think one of our strengths as a podcast is we're not just here to, you know, promote the big company's next big project. You know? So, certainly, if there's something interesting out there that you feel like you need to share with us.

We would love to hear from you. And, again, don't don't spam our inboxes if it's not worth our time. But at at the same regard, you know, I I almost always would would love to hear from somebody who has an interesting story about their career or advice than,

you know, a a product release or something. I think the the the best thing I like is when people who listen to the podcast say, hey. I want You to get x, y, or z on simply just because you wanna hear from them? Yes. Totally. It's it's like a tricky thing. Right? Because, like, we have a lot of, like, PR companies try to contact us and get their people on and and, like, do a book tour, essentially. You know? They go on every single podcast out there, and I'm not really interested in that. I'm Interested in guests that have cool stuff to share that I can learn a thing or two about and and I think will be valuable to the listener at the end of the day. So I don't we don't really have any rules for how we suss that out, but it's mostly just a A feel. And and also, like, one nice thing about having this podcast and and such a large audience in it is that we don't have to, like, get Massive guess every single time. We can just bring on people that are interesting. Like, the last one we did where we talked to the guy who just got a job, Like, we didn't have him on because he was gonna pull numbers for us. We had him on because I think that's literally helpful to our audience, and

Kind of that's what we we aim for. Yeah. That is certainly a big trap where you have podcasts that are set up essentially as a book tour, and then you have people Their whole thing is just to hit all of as many of them as they can, then they'll bounce around from podcast to podcast doing the same spiel, and the podcast needs it because they know that this person will bring in an audience for them.

And what you end up having is Eight different podcasts that are just, like, the same version of the same story of the same questions. Yeah. And then it turns out to be that person was a snake. Like, That happened with Liver King on all the, like, mainstream podcasts.

Like, every single podcast had this Liver King guy on, And he's talking about eating liver and everything like that. And then it turns out the guy's juicing like like crazy, and Yeah. The guy's just, like, a total snake. And that kinda sucks because, like like, literally, everybody had them on because it was pulling numbers, I guess. But, Okay. I kinda wanna

make sure we don't hit that as well. Baby Gronk thing. Did you hear about the baby Gronk thing? Was it did that reach your radar? I

Slightly. What's what's baby Gronk?

He was just like a, he's like a kid who who's he plays he's like a an actor. He's like a 10 year old, and his dad was just, like, spamming everybody, like, but I'm, you know, baby Gronk's dad and they like and it's just so Disgusting.

That dad was just, you know, shelling out his son to a 1000000000 different podcasts so that dad could get famous, and it's like, gosh. Yeah. That that stuff is rough. But baby Gronk, if you wanna come on this show, we got you. We we we I would totally have baby Gronk on.

You know who I was thinking about the other day? Remember the the Black Eyed Peas singer was all about coding, Like like like, 5, 6 years ago? Which black eyed peace guy they,

Will. I. Am? Will. I. Am? Really? Oh, yeah. He kinda always says these are really bad startups.

He'll be like, oh, here's the cell phone case with a cup holder on it. I mean, that's not literally one, but he his startups are all like that. Like, really bad app ideas. Still,

Is he still coding? Because I we'll have him on. Will. I am is a hard thing to Google because it's just the name William. Yeah. It just autocorrects it to William.

Yeah. I saw him at a breakdancing battle one time. I was at a, freestyle session 11, and he was standing there in the, just in the general audience with all of the, plebs at the breakdancing battle. It was pretty cool.

Say hi. That's that guy. Let's see. I'm looking for Will. I. Am's GitHub.

Will. I. Am's GitHub. This is not the right Will. I. Am, but his GitHub's looking a little dusty anyway, so Well, we'll say that.

Next question from Edwin. I'm at an ecommerce start up with just 2 developers. Over the years, our app has grown to be incorporating Capacitor, Hasura, servers, and some SaaS integrations like Algolia and Stripe. So let's go over those real quick. Capacitor is an open source native runtime for building web native apps. It's like I think we've talked about this before. It's kind of, like a PhoneGap, Cordova, React Native competitor? Yep.

Asura, which is, like a data API that sits on top of your database. They're pretty cool. They sponsored us in the past. Big fan of Hasura.

And then Algolia is search. Stripe is obviously credit card payments. With no initial documentation, how do you suggest we document our intricate code, business logic, and integrations? Most of the logic is in my head or in a few random read me files, any tool or habit.

Good question.

I think

Some of this can be generated if you are on TypeScript. Right? Like, you can generate all the docs for your APIs.

That's maybe ideal.

Honestly, just going through it and scaffolding it out, what the different parts are and then just putting to dos And then just kinda bang through them, wireframing how these things work together Or not wireframe. Like, draw a diagram. Be like, basically, here's our servers. Here's capacitor.

Our data is coming from here and going into the website, and, Algolia is in here. I find that really helpful to look at those diagrams when you're trying to understand how does this tech Work together? Other than that, it's it's just a lot lot of work. I guess for your your front end, Scott has some comments here. I'll let him say that. Yeah. Oh, yeah. Well, there's there's a lot of different options here. You know? We I I've had this issue in the past

where like, what do you what do you put where? How do you document things? I think, you know, the getting up and running stuff, you know, how how do you get it from 0 to running It's perfect for just to read me. In general, I think you could lean on comments in your code if the primary consumers of this Stuff our other developers in your in your, you know, your team. If this isn't like a open Project, if other people aren't reading and consuming your application to use it for something else, you probably don't need, Like developer docs, like a DocuSaurus type of deal. Right? What you're more looking for is, like, explanation as to what things are, where things exist. I like even, like, file based comments. Right? Here, why does this file exist? What's going on here? Yeah. You know, comments, I think you can lean really hard on comments. And in that regard too, you could always invest time into actually using a JS doc style flow. If you use JS doc, Then you could generate documentation if you so needed it. But, JSDoc just gives you a little bit of structure for writing those comments. But in general, I do think this is a place where commenting comes in handy, especially if you can do things like lead the developer through it. Like, for instance, in the level of tutorials payment flow.

The payment flow was somewhat intense. Right? You have subscriptions. You have individual purchases.

You have referral codes. You have emails that need to get sent out. And so what I did in the code base for that was I, not necessarily like a table of contents, but the very start of that process payment function was a, here are the following steps this code takes, and I wrote it out in the comments. Step 1, it does this. Step 2, it does this in plain English. And then in the actual code, I annotated those with the exact same number, sort of like figures. Right? Like figure 1, but it just said, like, 1. This is where it processes the payment. This is where it checks the nonce. This is where it sends the email. This is where it, adds a referral code to the order if somebody does a referral. And it just allows the users to step through it and, at a glance, see exactly what's going on so you can lean on comments. Another thing there is in the UI side of things, Storybook is a great option. There's another one called History that I'll I'll post as well that is really nice depending on which front end language you're using. But Storybook is a is a great place for documenting your UI components, especially internally.

But, again, if you then do adopt Storybooker history. Now you're essentially supporting a 2nd code base of documentation for your code. So Yeah. At the laziest version of this, I think comments are the most lazy and effective.

And then the more intense you wanna get, you can then go to JSDoc for a little bit more intense and then Storybook for your

component documentation if you need to go there. Yeah. I think also just having a set of quick little guides or even videos of how you do common things. So How do I add a new data type? How do I figure out which template is generating this page? Because sometimes that's half the battle is, like, Where is this thing even happening? You know? Like and, of course, you can step through it and, use the Debugger command, but sometimes it's really helpful just to have, like, alright. You wanna add a new data type? Here are the steps that we need to go through, in order to do this type of thing, how do I run it locally? That's that's a a big one is what databases do you need? Do you need A whole bunch of dotenv values that are not documented literally anywhere.

Keeping a dotenv dot sample file, it's probably a good idea. Oh, that's nice. How do you publish a new version? How do you deploy this thing? Just go through. Every time you do something, Just take an extra 10 minutes and write out some documentation and notes for it. It certainly has helped myself.

Even the like, my Versus code theme, I don't publish a new version very often, maybe once every 6 months. And every single time, I'm like, what's the crazy process To build this thing and bump the version and then deploy it and tag it on git. And It's always such a thing. So I just wrote it all in the read me, which is just for me. Like, I'm the only one that publishes it, but I I go back to the read me every single time now and Follow my own steps. I love it. Yeah. Just document documenting what you do. That that helps. How do you document? You document it. Yeah. You just do it.

Alright. Next question is from Dave k. Dave Dave k says, not so much a question as a comment. I listened to both of your Rust podcasts, and they're excellent. I'm a huge fan.

But double colon, sign integers, fixed sized arrays, Rust didn't invent this. There are common paradigms in languages like Java, c, and c plus plus.

Many maybe y'all know this and maybe you're just using a witty and urbane dialectic style that I'm too thick to decode. Yes. I don't think the intention was to say that. Right? I don't Is I didn't get that either. Invented any of that. We're more or less talking very blankly about, like, This is how you write Rust, and this is what is in Rust, not what makes Rust unique or special. Yeah. And,

like, if if I can I'll back you up there.

Most people listening to those podcasts have not done another language past PHP, JavaScript, Ruby, or Python.

And then when you get into these lower level languages, You start to say, oh, wow. There's there's a lot more data types here, and I, as a JavaScript developer, have never run into those types of things. That's what I think Scott was trying to get across there. Yeah. And, also, I I did get a, a comment too that was really nice, but the comment was like, oh, this one thing you had mentioned about

using as As a, a means of changing a string type. You know? It's not like the the way that everybody does it. And I think I think another thing that I wanted to get across in those episodes that maybe wasn't super clear was that, like, sometimes when you're learning the basics or, like, the very bare bones of things. What you don't get into is the more nuanced conversation around stuff, because Once you start to get into too much nuance and too much in-depth knowledge on anything when you're first learning it, it's it's gonna be a wash. You're not gonna remember that anyways.

You wanna keep it very entry level, very surface level. So if you're interested at a surface level of understanding, like, what Is working in Rust like? That's what those episodes are for. So Dave also says, I'd also be interested If you would answer the question, why Rust? Should I throw all of my JS skills away and use and learn Rust instead? Should I become ride or die with JavaScript and skip your shows on Rust? Use both or something else? Huge fan. Keep it up. You've kept me company on a lot of dog walks. Well, thanks, Dave.

Yeah. You know what? The question of why Rust is one of those ones that it's it's not necessarily a thing you need to learn.

Okay? I'm learning Rust essentially for fun.

And by fun, what it is for me is it's experience with a different level and different type of programming where I'm getting to experience what it's like to not program with the bumper rails of JavaScript, so to say. JavaScript is is really permissive. It lets you do a lot of stuff, and Rust is not that way.

And it's a different paradigm. It's a different way of of of typing and writing code in applications.

So for me, it gives me a different level of knowledge, and I'm acquiring that level of knowledge without having to move to something like Java c or c plus plus because, frankly, Rust feels a bit more like TypeScript than those do. And to me, that's a plus. Right? But in the same regard, you don't have to learn it. There's no reason to learn it, especially if you're a web developer, other than maybe giving yourself a new perspective, and perhaps you might like it. For me, I came from, First, a visual programming background, then into CSS and HTML, and then into JavaScript, where each time I picked up something, I learned, oh, this thing isn't actually as scary as I might expect it. This JavaScript stuff, not as scary as I expected. And you know what? I Truly, really like it because I feel productive in it, and I'm accomplishing things with it that I couldn't accomplish without JavaScript.

And, likewise, It's important to try some stuff like that because you might open up something into yourself to say, hey. Hey. Actually, I kinda like this lower level programming language, and I like the stuff that I'm doing in it more.

As to why you might pick it up, hey. Maybe you just wanna build applications.

Maybe you wanna get into non web stuff. Maybe you just want to, have fun and explore. Maybe you wanna build really, really perform at lower level utilities, and and that's, like, the stuff where Rust shines, and and perhaps, those things become fascinating and interesting to you. But if you're just purely looking at it from a web dev standpoint.

Man, there's not a a huge amount of reasons to pick up Rust,

as a practical means of doing anything. Next question we have here from Michael c.

A while ago, you sick decked Piece of home gym equipment. I think it was the tonal. Are you still using it, or is it a coat rack? Yeah. So this is just a quick

I did. So I just wanted to throw this in here to brag a little bit.

I, have a 102 week streak of tonal.

I have lifted £4,100,000 with it, and I've done 396 workouts on it. So it is not a coat rack. I have used this thing just about 3 times a week ever since I got it. So, not a fancy coat y'all. If you get these get these things that improve your life, you you stick to it, you make a a schedule, and you just show up every week,

you will really see big things out of it. Aaron with an e says, hey, guys. Insert obligatory compliment to the show here.

I've recently ran into an issue I've never seen before and wondering if you have any insight on to what's going on. I'm building a node process that interfaces with Some endpoints in the WooCommerce REST API. So hitting a URL to get some data.

I've worked with this type of flow many times before. I've always used Axios to handle my request. Whoever's my 1st project of this sort, since the fetch standardization, thanks to WhatWG.

So I decided to use Fetch instead. Okay. So fetching data from an API, always use Axios in the past. Now using Fetch Because fetch is built into Node. Js and all that good stuff. The issue is that on my post request to a specific endpoint, my returned My request returned a four zero four error.

The handler actually executed within WordPress, and the data was created successfully.

I triple checked my headers, authorization, bearer, content type, etcetera, but I keep getting the 404. When I tried running the same request in Postman, I got a two zero one response, which is created. That's the successful created.

So I isolated the fetch request In a new dot ts file, added all the parameters as plain strings, and ran the file directly, but I keep getting a 404.

Finally, I caved, installed Axios, and it worked.

What could it be? As my first Inkling with this type of stuff is that Axios has a lot of handy and assumed features.

Fetch doesn't assume anything. Fetch doesn't assume JSON.

Fetch doesn't assume it doesn't even assume that you're getting A request back. It might be a finished response. It might be a stream that's coming back.

So probably what I'm thinking here is is a couple things. I bet and this is this is what always gets me, is it's possible that you forgot to JSON stringify your body.

It's weird saying that it's it's already created it, but a lot of the times, it's when I forget to JSON stringify the body and I send an object instead.

And then the object object gets sent over. So there's That possibility. There's also a possibility that the WordPress, WooCommerce REST API is a little bit flexible.

So it's trying to account for people sending different types of data, and it's checking, what's coming here. But I would first check that your JSON stringifying it. It could be redirects. She mentioned later in the question that I thought it might be a weird redirect issue, That can be the case. Sometimes a fetch request will drop, authorization headers if you go cross domain.

So if you're redirecting from 1 domain to another, Fetch will follow those, but it will drop The auth header. So maybe check that. Honestly, you need to get into the the WooCommerce REST API And log out the request on that side and just see what's actually being sent.

Another thing you could do is Figure out how to debug the request. So go back to the show we did just this past Monday. By the When you submitted this, this is wasn't out, but we just did a show on hacking the tonal, proxying, intercepting, and debugging traffic. So what I would do Is codep 1 in fetch, 1 in Axios.

Submit them both and then open up Your proxy man application and look at the requests that were sent. Mhmm. And you can, side By side, look at exactly each of them, and there's gonna be something weird that's not being sent. So look at all the headers. Look at the body. Look at the method that's being sent, and make sure that you're not goofing something up by accident and maybe just assuming that Axios Does something, whereas Fetch doesn't assume very much. That's often why we'll write wrappers around Fetch to do some of those basics.

Sick. Yeah. That's interesting.

Those those are I'm gonna say those are straight up not a ton of fun problems to have. When When when you're calling something and you swear it's going to work and it's returning an unexpected result despite having everything that you'd expect to have in it, That is it it feels like hopeless a little bit. Not that it is, but it feels like it's out of your hands. Right? Oh, I just got another idea. Alright. Let's hear it. 404.

Nah. Maybe not. So sometimes this happens. Sometimes you successfully error.

So fetch does fetch throw on a 404?

Does fetch Throw on a 404. No. It it shouldn't. Right? It's just the response code. Yes.

Client side HTTP errors. So Axios, I believe, will throw an error if the response code so maybe I know you told us what the response codes are, but maybe you are successfully erring or erring successfully where maybe the the response code are the same, but Axios is saying, alright. I see that there's a body data here.

So maybe Maybe take a look at that. That's honestly why you need to get into to Proximan or something like that to be able to peer or or if you try to do a client side.

I I don't know if you can do a client side because of Chorus. If if Chorus is an issue, you can't. But if it's not, just run on both client side, open up Chrome DevTools, And just look at both of those 2 requests, and I guarantee you're gonna see the difference between the 2. Even just paste them in a chat g p t and say, hey.

These this is this is the 2 requests that I have. How are they different? Yeah.

Alright. Well, that is a sick I think that is it for Paula questions today.

So now is part of the show where we get into sick picks, things that we think are sick, things that we enjoy. It could be anything, whether it is a podcast, YouTube channel, stuff from Amazon, or anything that we'd like.

I have a sick pick. It's a show that we watch every time it comes around on Netflix. I I don't know what season it is now, maybe 4 or 5.

It's on Netflix.

It is called the Glow Up, and it is a competition reality show. Obviously, my one of my favorite genres of TV.

And, what glow up is is it's like a makeup competition reality star, show. And if it and I gotta say, Out of all the reality show competition and the reality shows, I think I'm the furthest removed from understanding makeup competition.

It it to me, I I have no clue about who's gonna win at any point, but I still Have fun watching this show because it's a little outrageous. The hosts are completely outrageous.

One of my favorite things about this show Is that one of the main judges on the show she has did you you watch Bake Off. Right, Wes? I have in the past.

Yeah. British Bake Off. Sam. Okay. Well, Paul Paul Hollywood on Bake Off, he does his his famous handshake when somebody does, like, the best job. Right? And the handshake is reserved for only the the finest bakes.

With Glow Up, the the host has decided that, like, She has her signature, like, handshake item. I I really feel like she sat down and was like, alright. I gotta have something like the Paul Hollywood handshake. What could I be? And her her her signature is is saying ding dong, so she'll say ding dong.

And and every single time, my wife and I are watching the show and suddenly somebody does something really well, we're like, oh, this is gonna be a ding dong. I just I just know it. The show is goofy beyond belief, and, I really enjoy it. So if you like competition reality shows, Globe is just totally goofy and a lot of fun, so check it out. That's great. I'm going to sick pick a

Website or service called SendCutSend.

That's SendCutSend .com.

I initially had heard about the service from a, Like a YouTuber who was I think he's, like, working on a car or something like that, and he wanted to build something.

So what this Website does is you can design a part and have it laser cut out of Metal or PVC or ABS or wood or, like, there's so many different materials that it can do it. And If you have an idea of something that you want to build that is physical and it's not like a 3 d printed kind of thing, Then this website allows you to just, like, make stuff. So I had this idea.

I wanted to build a barbell hanger for my rack in the gym, and I talked about this. I was like, I kinda feel like doing that. So what I did is I just you can upload an SVG to them, so you don't have to know three d modeling. Oh.

You can simply just I designed it in Figma. Wow. I figured out, like, what the pixel to inch ratio was, And I designed this whole part up in Figma export to, I think, to SVG or to EPS to EPS, I think.

And and I uploaded it.

And then they cut it out of out of PVC and out of, like, quarter inch steel.

They sent it to me, and I just I did. I tapped holes. They'll tap holes and bend it, but I did all that all myself to save a bit of money. And It's I got made this amazing little barbell hanger, and I was, like, amazed that for it's relatively cheap. I think you can go even cheaper if you go to a local place, but It's it's just like they've made this whole world of custom metal parts accessible to just regular Web developers that know how to use the pen tool and Figma. So if you need to build something Are you you just need, like, a little part? My lawn tractor at the cottage needs a little piece of steel with 2 holes in it. And now I'm just like, oh, I I could just make that with some calipers, send it off, they'll cut it, and they ship it right to you. They ship it in Canada and the US. So really cool

They do HDPE as well, which means that when I was talking about getting, like, a head headspin trainer Yeah. Just like a a flatter block. I wonder if I could get something

made to attach to my helmet. You could. And you could get your Ridiculous.

The kinda Cool thing was, like, I could I could buy this barbell hanger from a company. It's called Dark Hole Lifting.

But I was like, I wanna put my logo in it. You know? And I just I just took my logo, put it in, and they They cut it out with lasers. They were really helpful. Like, I had I had some parts that were too thin, and wouldn't cut well or would overheat.

So they're like, oh, make this a little bit bigger, and and it will be okay. So all kind they have cork, copper, stainless,

Acrylic? Sick. Well, that is a sick pick. Yeah. It's like 3 d or, it's like a T shirt printing, but for Yeah. Hardware.

And you can just get 1. You know? Yeah. Right. Because you don't need mass produce of this stuff. Interesting. No. Well, that's sick.

Shameless shameless plugs?

West boss.comforward/courses.

Check it on out. I'm gonna say shamelessly plug the syntax TikTok. If you, want to check out clips from the show or even little video quick tips, we have a TikTok at syntaxfm

on TikTok. Wicked. Alright. Thanks, everybody. Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows, And don't forget to subscribe in your podcast player or drop a review if you like this show.