955: SvelteKit has solved data loading

Scott and Wes break down SvelteKit’s new remote functions and why they finally solve the long-standing pain of page-level data in Svelte. They cover queries, forms, batching, caching, and all the clever RPC ergonomics that make Svelte’s approach feel surprisingly powerful and refreshingly simple. Show Notes 00:00 Welcome to Syntax! 00:45 Lots of RPC library options. 01:22 Svelte’s Page-Level Data Always Felt Off 02:12 Progress on the new Syntax site. 03:47 Remote functions explained. Svelte Remote Functions Docs. 04:15 Make a .remote.ts file. 05:07 Querying data. 07:52 Brought to you by Sentry.io. 08:17 Svelte’s leg up on React. 10:13 Query Arguments. 11:39 The benefits of Standard Schema. 13:13 Refreshing Queries. 13:29 query.batch 15:18 Form function. 21:13 Enhance. 22:31 Refresh. 23:16 Command query. 24:25 Prerender. 25:22 Caching. 27:44 My Local Cache Service Worker. 31:23 Sick Picks + Shameless Plugs. Sick Picks Scott: CoffeeSock ColdBrew Filter, Chemex Filter. Wes: Bosch Dishwasher. Shameless Plugs Scott: Syntax on YouTube Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we're talking about remote functions in RPC in Svelte. I'm going to say off the bat, this is the solution for RPC, for data loading, for anything. I don't want to use anything else on any other platform, and we're going to show you why. If I'm using React, it better look like this. So, we're going to be breaking down what these things are, just the general approach for data loading, how it kind of takes the server-client side of it all, and makes it really nice and palatable while keeping a nice separation still. My name is Scott Tolinski. I'm a developer from Denver. And with me, as always, is Wes Boss. What's up, Wes?

• 0:43Wes Bos?

  Hey, excited to talk about this because I dove into several of these RPC libraries in the last couple of weeks. You know, and it turns out Better Auth has one called Better Call, Hono has one, Eliza has one, Cloudflare has one that's called Cap'n Web or something like that, like it's Cap'n Crunch. And like, there are a lot of the, like, this idea of, like, obviously, we talked about TRPC. We had them on the podcast as well in the past, but there's so many different implementations of this RPC, and I'm excited to see what Svelte's take on it is.

• 1:22Scott Tolinski?

  Yeah, this is something that I think we've both personally felt. The Syntax site is built with SvelteKit. It uses the load functions for data. And I think one of the things that always felt odd about that was like, all of your data, all of your, you're refreshing, you're invalidation, even your form actions, they all kind of live at that root of the route level, like on any given route. It exists on a page level. And like, in a componentized world, that just felt weird, right? Sometimes you were defining actions on a route, and then having to call them, or refresh more data than you'd want, or re-invalidate a load function.

• 2:02Scott Tolinski?

  So, I was really excited when they announced this at Svelte Summit, and I've been doing quite a bit with this, like, really quite a bit. In fact, Wes, you might be interested to know, I've been going nuts on the new Syntax website. So, we've been working on a new Syntax website.

• 2:20Wes Bos?

  I've been getting emails, brother. Man, you're motoring.

• 2:22Scott Tolinski?

  I'm motoring, and it is like...

• 2:26Scott Tolinski?

  I ripped out our ORM, so we're using Drizzle now. I changed from MySQL to Postgres. I rewrote all of the data loading and Svelte remote functions. I have done a shocking amount of things and Courtney was like, is this, does this stress you out? Like, do you regret making these big choices? And I said, no, I, I love this. This is what I love. I love taking everything.

• 2:54Wes Bos?

  Scott's middle name is Rewrite Tolinski. Did you know that?

• 2:56Scott Tolinski?

  I love taking everything out of the cabinet and putting it all on the countertop and then like meticulously putting it back in and maybe 3D prints in boxes or something. And that's what I'm doing right now.

• 3:07Wes Bos?

  I just like pushing the stuff to the back of that. Like, we've lived in our house for like three years now and I like got on up on a stool. We have this really deep cabinet and I was finding like hot sauce from like three or four years ago. I was like, I should probably do a Tolinski on this right now.

• 3:22Scott Tolinski?

  I love taking it all out. And then, uh, in the web dev is absolutely the same. But you know, at this point, we, I needed to like rework the entire data structure of the website anyway. So it was like, if I'm already reworking the entire schema and how the data is connected and like, I might as well do it in technologies I actually like. If it's easy enough to just migrate it. Yeah. Which it has been. Yeah. So, uh, it's been, it's been a trip, but let's talk about remote functions. Cause I've been using these things like crazy. Basically as of today, when we're recording this, this may change soonish.

• 3:57Scott Tolinski?

  To get these things going, you do need to tick two different experimental options in a Svelte config, remote functions true and async true. So these APIs are used in combination, the async Svelte where you can just throw a wait tags in your Svelte components and just do that. And it just all works. Remote functions though. Remote functions exist where you have a special file name. It's something dot remote dot TS or JS. These can live straight up anywhere. And a dot remote file name is great because that lets you know off the jump, this is taking place on the server. You don't have to worry about client server, where's this code running? Am I importing something?

• 4:43Scott Tolinski?

  Like a database or something insecure in this? You know that it's a dot remote. It's a server based file. So that's really great, right? And then from within a normal Svelte component, you can just straight up import that query mutation, whatever. We'll talk about those in a second. But you can just straight up import those as a function and call that function in your code. So if you want to, let's talk about the like the first one of these, which is like querying data. In a .remote function, you have a query. It's essentially like a query function that takes in another function as a parameter or like a schema that you can then use to validate your data.

• 5:27Scott Tolinski?

  Either way, you have a function, that function can do database calls, returns data. In the client side, you're just calling that function. Bingo, your data is there. You don't have to worry about routes. You don't have to worry about paths. You don't have to worry about anything. It's like, I'm calling this function and it's going to go grabbing my data. And it's very most simple. You could have a query function that just returns Scott. And then the client, you could say, get Scott. And then it just gives you Scott.

• 5:57Wes Bos?

  So like, let me maybe explain to the listener, if they're like, what's, what's the benefit of that? So typically, when you have like a website, right? You have like a backend, you have a frontend, and then you need some way to communicate between those two, right? And you might make like a, like an API where you can like fetch endpoints. You might make like an open A, open API schema so that you can, you can share types from the backend to the frontend. But with a lot of these, like RPC, React Server Components, Svelte Remote Functions, the way that it works is you simply just import the function from your server JavaScript and run it in your client JavaScript.

• 6:41Wes Bos?

  And then there is a little bit of magic that happens between those two where you're not actually importing the client side code into your, sorry, the, the server code into your client. You're, you're simply just importing something that will interface over the network if you're calling that from client to the Server or if it's server rendered, it's just going to run it all on the server. Is that a fair description of it?

• 7:05Scott Tolinski?

  A perfectly fair description of it. Now, when this gets really powerful is combining with the fact that you can just await anywhere inside of Svelte components. So you could just even inside of a loop, you could do like an each await get Scott and then as the whatever. And the next thing you know, your data is just there. Or at the top level of a component, you can await in the top level of component and get that data there as well. And utilize it just like you typically would. And you don't even have to await it either. You can just run the query and then you could also have a query dot error, query dot loading or query dot current, which then gets you access to the data when it's available.

• 7:47Scott Tolinski?

  But if you want like server side rendering and stuff, await it and it just works. And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io forward slash syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 8:17Wes Bos?

  This is, I wouldn't say one place, but this is another spot that Svelte has an up on React. Because asynchronous components do not exist in the client side React. They do exist on server side React and they have said that they're coming to client side React. But if you want to simply await some data and then return the component, you can't do that on the client side, right? You have to have a use effect or you have to use tense that query, something like that. And you have to show a loading state and that's a pain in the butt. Cause in many cases, you simply want to just return nothing while it is loading. And, and I think also this goes in hand in hand with the asynchronous component stuff where I think the reason why Svelte and a lot of these places

• 9:02Wes Bos?

  did not initially offer the ability to do fetching at a component level was because.

• 9:09Wes Bos?

  You get this like waterfall problem where like you can, if you can fetch anywhere down the tree, then you can cause these waterfalls that can cause your render to be very, very slow. So React Suspense, Svelte, the sync components, it solves that by allowing you to find how long and what you should actually wait for if you're server rendering and then what you should simply just send to the client and then let it load at a later point.

• 9:33Scott Tolinski?

  Yeah, there's a cool query dot batch in here too, which I'll show you. So you can basically just await that data and get it. You know, this is really great because I found this to be super clean. I found it to be way nicer than having data in the load function that load function then passes to props. You're kind of hot potatoing this. This is more like you have your function call already. You call that, you get your data, you output it, you can await it. You can also, with a async fault, you can await inside of derived too. So if you want to have something reactive coming in from the server, you can just toss in and await get Scott inside a derived. That's super nice. So that's great.

• 10:14Scott Tolinski?

  You can also pass an argument. So these things are functions. You can pass in arguments. One really neat thing that they've done with all of the remote function stuff is that they've really leaned on standard schema. If you want to learn more about standard schema, we did a whole video on it. But basically, because it uses standard schema, that means that you can use any validation library out there to validate your inputs. So whether that's ZOD, Valibot, archetype, like whatever you want to use that uses standard schema, you can do so. And inside of your query, if you want the, if you want to accept arguments here, the first parameter is just that validation. So in all of their docs, they use Valibot, which is really great. Actually, I've been using Valibot. It's

• 10:58Scott Tolinski?

  really nice. But if you could say like the query, the first parameter is a v dot string, then you know that that requires a string. And then of course, you get all of your TypeScript type checking. You get everything like really nice. I think that's one of the things that as you'll see throughout this episode, is that the type checking story for all of this is so effortlessly good. And I think a large part of that comes down to their usage of standard schema where you're not having to import types or whatever and everything just kind of, whether it is client or server side. You have that type checking story the entire way.

• 11:36Wes Bos?

  Just flows right through.

• 11:38Scott Tolinski?

  Yeah.

• 11:38Wes Bos?

  Man, the, the standard schema guys, like the ZOD and archetype and valid bot, they like all worked on that. And like, since we did the episode on that, I've seen it implemented in so many places. And it's become so much more important from like an AI perspective, because you can get a, quickly get a schema of what your data actually looks like. But then like, when I run into stuff that doesn't use standard schema, like the Chrome, Chrome has like a beta right now for AI in the browser. And they use JSON schema. And it sucks because like I have to now, I'm like, I just want to write it in, I want to write it in ZOD or whatever.

• 12:19Scott Tolinski?

  Like, or whatever.

• 12:20Wes Bos?

  For those who don't know, standard schema is this way that you can write your schema in ZOD, valid bot, archetype, effect, whatever. And then it will, there's a method on that will just convert it to a standard schema. And then you can also, many tools will also just consume a standard schema and convert it to, to whatever they need internally. And when a tool doesn't support standard schema, it's a pain in the butt now.

• 12:46Scott Tolinski?

  Yeah, because now you got to just use that tool. We're here, it's like, I can pick my own from all, I, I just pulled up a list of all of the different ones. And there's so many effect schema, type map, form data, I haven't even heard of most of these. Joy, have heard of that. Yup, have heard of that. So there's a whole bunch and, and it's great that they are all kind of landing on standard schema. And even better that something like this would be like, you know what? Let's embrace that. And because of that, you can use whatever you want, which I love. There's also the ability to refresh your queries like manually. If you want to refresh your queries at any given point, you just take the query and then you call a dot refresh method on it. And it will re-trigger that as a function.

• 13:29Scott Tolinski?

  So that's nice. There's also query dot batch, which allows you to batch queries that happen within the same micro task. This is like in their example, they basically had a list of cities and then they had a. Query that was like get weather from that city. And the query was taking place inside of an each loop in the component. So inside of an each loop, the city had a wait get weather passing the city that's being passed in from the loop. And so if you were to do this without the batching, you could imagine each loop is going to be a call, right? A remote call. And that's not great. So if you use query dot batch, it's going to batch all of them from the same task.

• 14:13Scott Tolinski?

  And therefore it's going to not make a bunch of trips. Basically it calls them all instead of having multiple.

• 14:21Wes Bos?

  Okay.

• 14:21Scott Tolinski?

  Calls.

• 14:22Wes Bos?

  Yeah. So the benefit here is that like, instead of sending off 10 requests for 10 cities, it sends an array of 10 requests once. And then those 10 things are executed on the server. And I guess you could have logic on your server to do them all at once, or you can just fire them all off at once. And then it sends all the responses back at once. So that helps both with network, but also I'm assuming it helps with rendering as well. Because then you're not getting 10 render updates as they they come in. You simply just get one, one render at once it's all done.

• 14:53Scott Tolinski?

  Yes, and in this particular example, they're able, because it's in that loop, they're doing query dot batch. Like you said, they're getting all of the cities as an array and it's one database call even instead of not just one.

• 15:04Wes Bos?

  That's exactly what I was hoping for.

• 15:05Scott Tolinski?

  Database call, yes. Uh, which is great.

• 15:08Wes Bos?

  That's nice. And there's no fussing with like promise dot all or anything like that. It simply just sticks them all in.

• 15:15Scott Tolinski?

  Yes, for this, for this use case, this, this rocks. Now let's talk about the, I think this to me is the killer feature of this all. Because a lot of RPC systems have like a query system, you call the function, you get the data, right? There's another type of remote function called a form function. And the form function is the GOAT. This thing is awesome. So what's so cool about this is it's used for doing mutations, but not just general mutations. It's useful for doing mutations that take place on an HTML form. What this gets you is you're basically. Defining a form function using your standard schema stuff. You're passing in the inputs as the first parameter.

• 16:00Scott Tolinski?

  The second parameter is an async function that does the work. But what's so awesome about this is not the server side stuff. Cause the server side thing functions exactly like you expect. Data comes in, you do the work, you return your stuff. But on the client side, the form function has a ton of stuff. So you spread the remote function onto a form. And then you get a progressively enhanced HTML form that works with or without JavaScript. You can spread out individual fields and then you get individual field validation. So you write your standard schema on the server side.

• 16:41Scott Tolinski?

  That is then used to validate both the input into the function as well as the HTML input itself.

• 16:50Wes Bos?

  So it does like it will render out the client side HTML and the JavaScript that is necessary for it to client side validate.

• 17:00Scott Tolinski?

  Yes.

• 17:02Wes Bos?

  Oh, that this is almost getting like, like, like rails.

• 17:06Scott Tolinski?

  It's sick. It, this is sick because not only do you get that, right? So like the, the, the way you're spreading it out, you're spreading like, let's say it's a create post. You're spreading create post dot fields, dot title as text on a normal input tag. That then sets the input tag to type of text. It sets the ID, it sets all of the stuff that you would need to have a valid working form input. And that rules, man. I, I'll tell you what, I, I, I was working on a blog. And I use this in like, I'm doing a tutorial course on which is, it's going to be out by the time you are watching this.

• 17:48Scott Tolinski?

  So, uh, check it out on syntaxed if you want to learn how to do this, but like. Man, um, to be able to build this wrapping a label around an input and just saying here, use that, um, oh, it's read only, uh, like, man, this kicked ass. And I really, really liked working in this, this way, but it gets even better than that because not only do you get those things, man, you get, so you get the validation component and stuff like that, but you can also get error messages. You can get, sorry.

• 18:21Wes Bos?

  Scott, can I just stop you here? A couple of episodes ago, you were fighting me and saying, I was, I was showing you some form library that like, that did this.

• 18:33Scott Tolinski?

  Yes.

• 18:34Wes Bos?

  And you're like, I don't need that. I could just do that with this felt store and a couple lines of code.

• 18:39Scott Tolinski?

  Yeah.

• 18:40Wes Bos?

  And now you're here, you're, you're gushing over the exactly this.

• 18:44Scott Tolinski?

  No, this is, this is the platform. Mind you, this existed.

• 18:48Wes Bos?

  It's built in, it's fine.

• 18:49Scott Tolinski?

  This existed when we recorded that episode. This is less code than that was too. I'll tell you that. My point was is that if I want, not that I don't want a form library, it's that if I have a form library, I want it to do more for me. I don't want it to write all of the inputs. I don't want to have to write the update stuff. I don't want to have to write any of that stuff because at some point it's like, what is the library doing for me? I want the library, or in this case, the platform to do more for the forms.

• 19:18Wes Bos?

  Yeah. I want it to go all the way from schema to

• 19:22Scott Tolinski?

  Exactly.

• 19:22Wes Bos?

  inputs, validation, all of that stuff. And

• 19:25Scott Tolinski?

  Yes.

• 19:25Wes Bos?

  I think that's, that's what that library did. I can't recall the name of it right now, but I agree with you because I am done writing crud forms where we simply

• 19:35Scott Tolinski?

  Done.

• 19:36Wes Bos?

  Done.

• 19:38Scott Tolinski?

  Yeah. And like, I do want to push back on that because I, I, I agree, like, I do think form libraries are really nice. I've built my own so many times, but I want the form library to do more. If I'm having to write out every little bit.

• 19:50Wes Bos?

  Tip to tail, yeah.

• 19:51Scott Tolinski?

  Yes, then then at that point, like what that library did, I didn't see a benefit of it. Like, yes, it handled validation in those types of states, but you still had to write most of that code yourself. And a lot of that was because of how you work in forms and React in general. So that that's my point. Also, this gives you client server, gives you the whole bingo bango. Gives you everything here. There's also, you can do programmatic validation with it easily enough. If something becomes invalid, you can get the error message directly from here without having to write any of that. You don't have to have controlled inputs or anything like that. The state just kind of lives as a part of this remote function.

• 20:33Scott Tolinski?

  So you don't have a controlled form, you don't have to deal with form data on yourself. You're you're just writing an HTML form that works in JavaScript or without JavaScript. And you get access to things like the individual error messages if something becomes invalidated. It's pretty sick.

• 20:53Wes Bos?

  That's great. I could see myself building even like a even higher level wrapper on this.

• 20:58Scott Tolinski?

  I'm already doing that, yes.

• 20:59Wes Bos?

  At a very high level, just took all my inputs, figured out what kind of input they needed to be, you know, is it text area? Is it a number? Is it a date, etc.?

• 21:08Scott Tolinski?

  I love doing that. I'm already doing that, yes. Huge, huge fan of that. Yeah, it's really neat. And like, obviously, if you want to step in and there's this whole progressive enhancement story. If you want to step in and do more with JavaScript in here, you can do a dot enhance on here and get access to the entire process. So let's say you want to throw toast message after you submit it, or you want to handle errors your own way. Or you just want to step in there.

• 21:36Wes Bos?

  Yeah.

• 21:37Scott Tolinski?

  You can hook in, you can call await submit, you can call a form dot reset if you want to.

• 21:43Wes Bos?

  And I assume that's the same as if you need to do something custom on like key up or something.

• 21:47Scott Tolinski?

  Yes.

• 21:48Wes Bos?

  You could you can overwrite the default one.

• 21:50Scott Tolinski?

  Totally. You can also get in here and do, you can update the state programmatically of the form. Keep in mind, again, these aren't like controlled forms in that way, but you can get on here in an individual field by referencing mutation dot fields dot the field name, so dot title dot set, and you can programmatically update that. And you can grab the value at any point with fields dot value and get access to that value live. So it ends up becoming a controlled input, but you didn't write one line of state. You didn't write a state updater. That state just lives with the form and it all, it's just so cool. Um, love all of that. When you're done with these, you can update your data.

• 22:34Scott Tolinski?

  So there is the dot refresh uh method that we called before. If you run dot refresh, it is just running that query again. But there's also a dot set method too on that. So let's say your mutation returns the new data, right? Like you didn't update and that mutation actually returned the new data. You wouldn't have to then call a refresh and have it do another database query. You could use this dot set to take that new data and just insert it as the result into that query and pass that along, uh, avoiding an extra database call. They really thought of like everything here. Um, there's even optimistic UI you can do with this. So it's pretty sick. Form is goaded. It's, it's awesome. There's so much here.

• 23:16Scott Tolinski?

  There's also a command query. So this lives in a remote function. This is basically just a mutation uh function that you would exist where you're not using an HTML form. But the form one makes it so easy. It's like, we should really be using forms for so much more, right?

• 23:33Wes Bos?

  Everything needs to be form data.

• 23:35Scott Tolinski?

  Yeah. So.

• 23:36Wes Bos?

  Everything should be like, there's the best way to transport data from the client to the server is with form data, right? Like form data is the best. You can have multiples of the same type. Um, you can have images in there. You can have multi-part. It's just like, all the remix stuff is all built on form data as well. It's just one of those standards where everything going forward should be built on form data and an added benefit is that you can simply use HTML forms if you want.

• 24:04Scott Tolinski?

  Yes, and also like in addition to that, something we do a lot on the syntax site, URL as the state using query parameters. State in query parameters on the URL. Yes, it's shareable. It's very nice. I think those two things are totally underrated. Forms, query parameters. The last one here is pre-render. Pre-render is basically query, but it's something that only runs on build time. So if you're doing static sites, you only wanted this to ever run on build, you have the option to have the pre-render. So that's it. You have query, query batch, form, command, and pre-render. Those are the different remote functions. They all kind of have a specific use case.

• 24:49Scott Tolinski?

  And man, I've been ripping on this stuff, especially on the new syntax site. Just like whether or not it is just throwing a database query in here or there or whatever, or changing our remote functions. I've just been really, really, as I get through with this, I'm writing less code. I'm getting better validation. The TypeScript stuff is so nice. I'm not having to import types and anything like that. All typesafe across the board. It rules. Very big fan of this. So that's pretty much it. Do you have anything there?

• 25:22Wes Bos?

  I got a question about, is there anything related to caching?

• 25:26Scott Tolinski?

  Yes.

• 25:27Wes Bos?

  In all of this?

• 25:28Scott Tolinski?

  Yeah, so caching, especially like you would, it would still happen at like if you're, especially if you're doing server-side rendering, right? That's still happening at the like the page boundary, right? If you're caching that, it's still happening at the page boundary. I think there's going to be more with the caching of the data. There's some caching stuff with the pre-render queries using the cache API. But in general, on these functions, you're not setting cache headers.

• 25:55Wes Bos?

  So this is something that. Only NextJS, I think, has nailed.

• 26:00Scott Tolinski?

  Yeah.

• 26:00Wes Bos?

  And it's the ability to do a component level cache. And a lot of people don't understand. So let me give you an example. On my website, westboss.com, I have the syntax, latest syntax podcast in the footer. And that is a syntax component in the footer of my website. And that does a fetch to the syntax API and then brings it back. And there's a problem where, and I have a couple of other things in the footer of every page. Right? And I can, I cache the data there. Right? But I kind of want to just cache the entire component.

• 26:37Scott Tolinski?

  Yeah.

• 26:37Wes Bos?

  As it's been rendered. And there's nobody, except for NextJS, that has the ability to, to cache a component level. Everybody's caching entire pages, which is sometimes okay. But like, but what I end up with sometimes is that like, if I cache an entire page, then the footer data is sometimes different from page to page because they've been cached at different points.

• 27:01Scott Tolinski?

  Yeah.

• 27:02Wes Bos?

  So the other, the other option is you can simply just cache the expensive stuff, which is the data fetching and then just re-render every single time or set like a really short re-render on it. But I'm, I'm curious to see, and I bet Svelte will roll out something like this as well, where you'll be able to just like cache this entire component for however long. And then do the whole stale wall re-validate headers on it. And that would be sick. Because then you can reuse that component anywhere else on your dynamic site, but you don't have to spend the overhead of re-rendering that sucker and doing data fetching.

• 27:36Scott Tolinski?

  Well, let me tell you, Wes, I also felt this pain. I felt this pain and that's why I took it upon myself to make something. Which, so I wrote and I'll, I'll share this with everybody. And this is, I'll say this, it's naive. It's a quick implementation, but it works really well. What this is, is a service worker, because service workers are built into SvelteKit. It's a service worker that basically does stale wall re-validate using index DB. So it takes any, right now it's just queries. It takes any. Remote function query, because I can identify those. It takes any remote function query and saves it to index DB.

• 28:18Scott Tolinski?

  On the next page load, if it's being done on the client side, it's going to check index DB and just load that data. So it's basically like a local index DB cache that

• 28:30Wes Bos?

  Yeah.

• 28:30Scott Tolinski?

  I don't even have to do anything in my code because it's a service worker. It's just there. It it worked really well. I like wrote this and like, I'm not good with service workers. And I, I, it's a pretty small implementation, 150 lines. I do need version numbering needed. I I chatted with CJ about this yesterday. But man, it works really stinking good, man. You're doing like massive amounts of data loading within,

• 29:01Wes Bos?

  Yeah.

• 29:01Scott Tolinski?

  10 milliseconds because it's just there. It is like, it's like the not local first, but it's the local data cache lessons I learned from using something like zero just tossed into an automatic service worker.

• 29:14Wes Bos?

  That's great.

• 29:14Scott Tolinski?

  Yeah, I was pretty stoked about this working.

• 29:17Wes Bos?

  That's similar to what I did on my side as well, but I did this on the server. So I stuck everything in like a key value store. And then I, as part of my data fetching strategy, I just first checked if it was there. But that doesn't help the fact that the the actual component itself has to re-render in.

• 29:35Scott Tolinski?

  Well, sure. Yeah, yeah.

• 29:37Wes Bos?

  If you, like, if you want to like server render in cache an entire page and then go from page to page, then you're you're in trouble. That's a hard problem. I don't envy anyone that has to work on this caching stuff because it's it's a can of worms and it's edge cases all the way down. It kind of sucks to have to.

• 29:54Scott Tolinski?

  Cache and DNS and what are all the things? Yeah, those are.

• 29:58Wes Bos?

  Cache ruins everything around. We gotta make that shirt. I have a rule, no funny shirts, but man, that would be a good funny shirt.

• 30:06Scott Tolinski?

  Yes, I mean, Wu Tang is for the children, so I think I think it's.

• 30:11Wes Bos?

  Beautiful. Well, I'm excited to see all of this implemented in the new syntax site because this was one of the biggest qualms I had with Svelte and they have done a fantastic job at solving that.

• 30:23Scott Tolinski?

  Yeah. Yeah. I, I, it was one of those ones that afterwards announced, I, I had so much on my plate that I didn't dive into it. And since diving into it, just a big, big fan of this implementation. I'm not, I'll say this, I'm not saying no other RPC systems have, have done it as good as this, but it better be as good as this if, if you want me to use it. Cause now I've, I've been the edge and back and I, I very, very, uh, yeah.

• 30:49Wes Bos?

  Yeah. I don't, I don't think you would get better than this. Um, because it's like, it's tip to tail, right? Svelte kit has control over absolutely everything. Um, for something where you just need to add RPC into an existing solution, that's where you probably would reach for one of these, yeah, individual one. But man, is it nice having a meta framework where it just is, is tip to tail.

• 31:11Scott Tolinski?

  Yes. Snout to.

• 31:15Wes Bos?

  Snout to hoof?

• 31:17Scott Tolinski?

  Snout to hoof. That's not that far of a distance, if you think about it.

• 31:20Wes Bos?

  No.

• 31:21Scott Tolinski?

  No. Um, cool. Do you want to get into sick picks and shameless plugs?

• 31:27Wes Bos?

  Yes. All right. I'm gonna sick pick my dishwasher. I talked about it in the last couple of episodes. I'm very happy with it, but I, we've had it for like, almost a month now. And we got the Bosch 800 series dishwasher. And this thing is amazing. It's got the third row for, I don't understand how they, they have more room in a dishwasher when it fits into the same physical one. Uh, like the 24 inch thing in your, in your kitchen, but this thing is awesome. So if you're looking for a new dishwasher and you're tired of fussing with them, you know, like we have, we have a house, we have a cottage, we had our, our old house. Like I have fixed enough dishwashers in my day that I know do not buy the $500

• 32:09Wes Bos?

  LG. LG does make good ones. Um, they're, they're a higher up there, but man, it's, it's a nice life improvement if you can get a nice dishwasher. So our old one lasted for 21 years.

• 32:22Scott Tolinski?

  Yeah.

• 32:22Wes Bos?

  Pulled it out. We're like, yeah, we'll just buy another one of those. So sick pick.

• 32:27Scott Tolinski?

  Nice. I'm gonna sick pick my new cold brew setup. Man, I've been, I've been making my own cold brew for a while. And when you make cold brew, like, there's a number of things that can go wrong. It can get really bitter really quick. And it can get really like burnt tasting. And I like went deep on like, what am I doing wrong? Because I was just kind of suffering through mediocre coffee when I like, it's like I, I drink good cold brew other places. I know it's possible. Like, why can't I dial this in? So I dialed it in. I am now measuring my beans. I'm doing seven ounces of, of beans per coffee sock. So the sick pick, one part is going to be a coffee sock.

• 33:08Scott Tolinski?

  Uh, it's basically just like a, a cotton sock that you put the beans in. And I do that in a, this is a 64 ounce, um, mason jar. You can buy a kit that comes, I'll have a link to this.

• 33:23Wes Bos?

  Yeah.

• 33:24Scott Tolinski?

  You can buy a kit that comes with the mason jar and the coffee sock. Now, the key to this all is you brew it either in the fridge or on the counter for like 24 hours, right? You do this, this six to eight ounces, you, you put it in the coffee sock, you fill it with water. But the key ends up being a double filter. So after you're done with that, I then have another glass thing. And then I, I pour through one of those Chemex filters. I don't have like a fancy setup, but the, the Chemex filters are these paper filters. And you double filter it through the paper filter. And then I do that into like a giant glass pitcher. And man, it tastes like Starbucks cold brew. It tastes like the stuff that I buy in the store. It is perfect.

• 34:06Scott Tolinski?

  It solves every issue that I've ever had with cold brew. The, the two things that are important is like, the double filtering is a massive one. And then the amount of time that I'm brewing, plus the amount of beans. But let me tell you, it's been really great. And now it's so much more economic. We, we have like, uh, Economic, economical, I don't know what the, either way, we buy a big old thing of beans from Costco, you ground them up, you put them in the thing overnight, and then a big thing that was important to me was that it had to be all glass on glass, the whole process, because so many of the options out there are like, plastic filters, or plastic brewing systems. There's one cold brew, like, system, that's like a countertop machine, that is really

• 34:50Scott Tolinski?

  just concentrated cold brew pods, that it's mixing with water. It's like, what's the point of that?

• 34:56Wes Bos?

  Who's buying that?

• 34:57Scott Tolinski?

  They're expensive, too, it's like, what's the point? Uh, so, yeah.

• 35:02Wes Bos?

  Man, I, for the longest time, I wanted an espresso, and I finally, I finally got one.

• 35:09Scott Tolinski?

  Yes.

• 35:10Wes Bos?

  Those things suck.

• 35:11Scott Tolinski?

  It's not for me.

• 35:12Wes Bos?

  Well, like, it's, yeah, like, it brews okay coffee, but like, it's like, like, four bucks a pod, and you gotta buy the special ones, and there's DRM in it, and like, no thanks.

• 35:23Scott Tolinski?

  Yes.

• 35:24Wes Bos?

  You know, like, beans are not that expensive, and if you can just figure out how not to be an idiot, and do a little bit of research, like Scott just did, you can make some wicked coffee at home, without being like, an obnoxious coffee person.

• 35:36Scott Tolinski?

  Big ol' bag of beans, doesn't matter what, because cold brew especially doesn't matter, uh, normal beans, it, like, but yeah, I'll get whatever is on sale at Costco, that's decent, crunch it up, uh, and then I do two 64-ounce ones, uh, because we consume a lot, um, and then I put it into a big glass thing, and it's glass on glass on glass, the entire way down, glass, cotton, paper, that's it, so.

• 36:00Wes Bos?

  Beautiful. All right, thanks everyone for tuning in, we'll catch you later.