From React To SvelteKit

to Syntax. This is the podcast with the tastiest web development treats out there. Today, we've got a really good show. We're gonna talk about moving from React to SvelteKit.

Scott Did the craziest thing ever, and we wrote the entire front end of his level up tutorials website, which was in React, And he moved it entirely to SvelteKit surprisingly fast, and he's here to talk to us today about it's his podcast. He's not just here for that, but he's gonna talk to us today about rid. Why he did it, how he did it, benefits, what he used, where he hosted, all that good stuff.

Excited to to hear all about that. Today, we are rid by 3 awesome companies.

1st one is Prismic.

It's the headless CMS where you just sign up and get an API out the other end, rid. Sentry, the error exception in performance, logging, and a cloud in ARIA, which does image hosting transformations. Talk about all of them partway through the episode.

Are you doing today, mister Svelte Talinsky?

Hey.

Doing good. And that's really Svelte Talinsky, I like it. It's a great little nickname there. Oh, I'm doing great, man. You know, feeling a little bit more moved into the office. I still need sound treatment in this place. I know you're you're, like, in a you have hardwood in your office. Right? Yeah. Yeah. Yeah. But you got a lot of stuff. Lots of crap.

I got a huge rug in here as well, which I I added. Yeah. So you you've got deflections, and this This room is just, like, kind of a box right now, and and there's a bookshelf, and there's a little small frog and stuff. It's fine, but it is echoey and it's making me very upset. So I'm gonna I'm gonna get some sound treatment in here. I'm gonna go into some of these like. Their sound panels, which are, like, very, very good high absorption rate materials. I'm gonna do a couple to do, like, Not like a like an office space floating ceiling, but, like, a couple of, sound panels floating, like sound clouds. Yeah. And then I'm gonna do some over here. You won't see that, like, rid What they do, they use that, like, foam. I'm not gonna use that, like The YouTuber

grid of, like, black and, like, that horrible blue. That's only for aesthetics and, like, doesn't actually

block the area, reduce your frequency.

Yeah. I'm gonna get some really nice sound panels made. I can probably get some, like, ones in here or something like that. So I'm I'm I'm gonna be excited to get get moving in that direction, but I'm not here to talk about sound panels. I'm here to talk about re Svelte panels. Yes. Yeah. So the question everybody wants to know is,

do you hate React?

Oh, rid Yes. I hate React. No. I you know what? It is funny. I don't hate React, but in the same sentence, in the same breath, I can't see myself going back this style of site, this style of website, web application to react for any purpose. You know, I don't see myself using React in this way unless I'm I'm being forced to. So just the the dev experience is that much better. That doesn't mean I hate React by any means. I think React rid Still can probably do a lot of things better, of which I'm not quite sure what those are at this moment, but I would say Sean Swicks has a really good blog post about You know, React definitely has I would say doesn't necessarily give you more control, but I think it's easier to take more control over the renderer because of the virtual DOM existing. But, No. I I don't hate React in any way. I do very much love Svelte, though, and I'm not the kind of guy that lets hate drive my rid Decisions. I'm more of a kinda guy who loves love drive my decisions, and my love for Svelte is really what drove this decision.

It was really kind of the culmination of a bunch of things. I was having a lot of trouble, and I don't wanna say hate of React and SSR or whatever. I I was having a lot of trouble with It was an opportunity for me to say, alright. I've had this. I didn't react since, like, 2016, maybe. Let's take a look at this and say, is this still really rid where we wanted to be in 2021, especially when all I was doing at the time was a lot of self tutorials and just really enjoying them. So For me, it was like a decision of if we're gonna be doing a pretty substantial rewrite of the JavaScript aspect of the UI, maybe perhaps we should take a look at, You know, actually moving off of React and that exploration, which was about a couple hours, I was like, okay. I'm gonna give myself a few hours just to spin up. Gonna connect to the API. I'm gonna, you know, get things working a little bit and just see see how it goes. And in 3 hours, I had made so much progress, And it was feeling so awesome. I was just like, dang. Can we do this? I think we can do this. And then after really getting into it, the whole whole process took about, like, 2 months or so, Which really isn't that much time when you think about it. I'll go into much greater depth about, like, the process of converting React components over and how we were able to do it so fast Because by no means is this a small site. This is a large site. And so at the end of the day, it really wasn't that hard, and that's a great thing for people who are probably listening to someone, hey. Rid. Maybe not even convert a site, but can I learn Svelte in any sort of meaningful way to make a a changeover because I I do like its simplicity or whatever? I like its developer experience.

So if you aren't familiar with the source material here Yeah. Head on over to level re Up tutorials.com. And while you're there, you can go test out this subscription flow and maybe purchase yourself a subscription. Button.

Just rid Just give it a try, baby. Just, you know, enter enter your credit card in there and see what happens. That's great. One thing I wanna say that you just touched on briefly is that How quickly you're able to get up and running with it. And that's that is partly Svelte, but that is also because rid And then we hear this a lot. People are probably stressed out right now because they've just spent the last year trying to learn React, and now Scott's doing something different. And what the heck? Rid. The thing to know here is that because Scott is a JavaScript developer and that he understands how events rid. And inputs work and how components are built and how data is, actually, maybe data is a bit of a different story. But He was able to pick up another framework pretty quickly. And I think that's a really important thing to drive home to people who are new to JavaScript listening to this that rid. It doesn't necessarily matter which framework you're doubling down on right now and what framework will come and change in the future

Because the ideas and concepts will transfer really, really smoothly from one framework to another. Yeah. I 100% agree with you, and and part of this is My nature to want to do quick mean things like this. You know? And level up tutorials.com is my playground. It's, for the most part, A site that I I've used to try out a lot of things because it's a real world site. People are using it, and the users aren't guinea pigs or anything like that because, you know, the rid. Paramount importance is of making the site 100% better and more usable, faster, all that stuff all the time. But, rid You know, for me, it is nice to be able to experiment in these real world apps and actually take advantage of some of these things that I'm I'm learning as I'm learning them. Rid So general thoughts on the rewrite. You know what? I think some people, they wanna hear hard numbers. What was the size of the site you were shipping beforehand versus the size The site that you're shipping after, what's the speed like? What what are those hard numbers? And I'm gonna tell you right now, those hard numbers are not going to be useful at all in this instance. And that's an unfortunate thing, but we're really comparing apples to oranges here for a couple of, like, really key important reasons. One, we're not We're switching from a custom React server side rendered front end, as in we were using just Vite dotdev to do the UI building. And before that, we were using Meteor, but that didn't really even change how we were building the front end of the site. The site was only being client side rendered. We were doing code splitting, but we weren't doing server side rendering. Right? So that's one big aspect. We're moving from a a platform that is just client side rendering, shipping it all via JavaScript to a platform that is a server side rendered. And even some of the pages, we've been able to tell some of those pages, like, don't hydrate the JavaScript here. Don't ship JavaScript on this page Because it is just HTML that we need. This is the about us page. Right? We don't need you to to ship JavaScript for this page. So it's not analogous. It's not going to be the rid. But also, we made some substantial changes in some of our dependencies too, and those dependency sizes are also changed. So We're shipping inherently way less JavaScript than we were before because we're server side rendering it, and we pulled some of the libraries from our site like Apollo. We pulled Apollo from the site in favor of a custom JavaScript fetcher because if you don't know, GraphQL rid. Fetches are really just being done by an HTTP fetch. It's being done by a post request,

and it's sending the GraphQL as a rid String in the body, essentially. So we do that by hand now, essentially. So you were not necessarily, you maybe were using them, but you were not getting any benefit rid Out of any of the other parts of Apollo, which is caching the data, local states. You weren't you really using any of that Part of a poll. So it was okay for you to just get rid of it, and then you stored the data in

the SvelteKit data? Yeah. We're storing them in in SvelteKit writable stores. So it's a writable stores, but that data is initially being called on the server side And then being hydrated into a store client side, and then when the data updates from, like, a mutation or something, all we're doing is saying rid. That store is now equal to the data that's returned from the mutation,

and that will update the store everywhere in the site. So we don't need this normalized cache. Rid not doing anything for us there. Another thing that Apollo did really well in it does really well in React is, like, data injection. If you just need your data rid. Anywhere in your application, you can just query it, and Apollo will have a provider somewhere higher up in the tree, and it'll be able to access it. That's huge benefit to using Apollo.

Rid In Svelte land, I've been doing a little Svelte myself, you just use data stores, and you just import the object from the data store. And you could just have the data there.

Rid So imagine that. Right? You don't have to have a provider somewhere up the tree. Yeah. You just import the data and use it update it. And that's one of the one of the things that I really like about working in Svelte is that there isn't that, like there isn't the amount of places for foot guns like that or Specialized knowledge. Things just kind of work how you'd expect them to. So that's one of them. I also changed the video player. We were using Plyr, re e l y r or player, however you say it. And now we're using Vime, v I m e, Vime j s, which is actually a web component based Video player, which is is actually kind of neat because we are using the web components version of it. So since this is just something that doesn't need to be server side, it's a video player. Right? It it doesn't need to be server rid rendered or whatever. We just have these web components, and then we're utilizing just a straight up import of a JavaScript file rid. To load that web component when we need it, which is our video player, and it works really well. So what's neat about that is that you feel like you could take that video player with you from rid thing to thing if you ever need to use it in something else that's not, you know, Svelte. I'm just looking at it. They have bindings for React, Views, Svelte, Stencil, and Angular. Yeah. And we don't even use the Svelte bindings because rid fine to just use the web component one. Right? Why bother? So those aspects were quite significantly changed. It's hard to get, like, true metrics on some of this stuff when you have video on just about every page of the site, and those video players start pulling these chunks immediately. So rid My, like, full page load times and stuff like that are are never super accurate. Our amount of total day data downloaded, it's never super accurate because it's starting to download video right away, like, the moment the rid page loads and starting to do so in in chunks preloading it. So I don't know. The numbers aren't particularly helpful in this case. Anecdotally, the site's way faster. I mean, it's server side rendered, but, also, the site's just faster in general.

So even though some things in regard because it is server side rendered and we we're doing an ready. Only cookie for authentication. The user data is available on the server for the initial render. We're not having to do any sort of double renders Or when the user's available or whatever, everything just feels faster. Not to mention, besides code split unroutes automatically because of the automatic routing stuff, So I didn't have to manually do any of that code splitting like we were before choosing those code split points. But let's see what else. Honestly, the hard hardest part about this entire thing was some of the things that took the longest were making UI re Changes. I mean, we're rewriting the UI here. We're rewriting the HTML and JavaScript. It was a good opportunity to take a look at rid some pages and say, like, what sucks about these pages and what could be better? Mhmm. So that was kind of the hardest part was having those Conversations because, let's face it, like, straight up conversion of our React component to a Svelte component was not that hard. If we were just straight up converting things to one thing to another, it would have rid Taking a lot less time, I think. But something that's not going to take time is to have your data ready ready and available for your headless CMS with one of our sponsors today, which is Prismic. It's also not gonna take a lot of time for you to head on over to their landing page, which is at prismic doti0forward/ syntax and give it a look because that's really neat.

I have the perfect ad read for them today because rid.

I have been trying out SvelteKit because Scott won't stop me hammering on about how awesome it is. I can't stop. And, I've been really enjoying it. Rid. So my wife just started another little project, and I needed to build tiny little website for her. She's like, hey. Can you make me a little site for this? Rid. I said, yeah. Absolutely.

What happened at first was I built the whole thing in HTML, CSS, and hard coded all the data.

Rid. And what happened was she says, okay. How do I edit the data? I was like, wow. Or she kept sending me changes, and I was like, you know the how the pain of rid People sending you changes 5 times. So, finally, I was like, alright.

I'm done editing HTML straight. I'm gonna give you a CMS. Yeah. Good. I want something to log in to. So I was like, let's do Prismic this time. So I logged on to Prismic, rid. And I said, I'm gonna approach it in the slices approach. I've talked about this in the past where with Prismic, instead of thinking of your data as, like, a page, rid. You think of your data in terms of components. So I made a info component that had, like, a title and a box. Rid. I made a person component or a person slice, they're called, and then that could have the person's name and their Instagram, rid. And they could have photo uploaded of them and all that information.

Then once I had all the data in Prismic, rid. I said, alright. I'm gonna build it in Svelte. So I went to Svelte, and then I modeled components after each of those slices that I had then built in Prismic. Oh. So you've got a slice in Prismic, rid which means you got a component. In my case, it was in Svelte. They had a really good little tutorial on how to pull data from Prismic into Svelte, rid. And I I followed that. And probably in about 3 hours, I had a full blown website up and running, and my wife was able to rid. Log in and edit it and everything like that. So it's really cool because they didn't have to host anything for that. And there is a webhook that Every time the data changes, it pings Vercel and and rebuilds it on Vercel for me, so I was pretty happy with it. So check it out. If you have a a little website you need to build or a big website or an app or anything, Prismic, p r I s m I c dot I o forward slash syntax. Rid Thank you, Prismic, for sponsoring. Sick. Let's get into the actual process of converting a React component to a Svelte component because rid The hardest ones to convert were the ones that we were lazy enough on where we would have multiple components in 1 page. And, actually, something I really like about

Felt fine at the time, but going back and looking at it, it never was super great. But most of the time when we were doing that, it was almost always to get, like, some sort of, like, a data wrap or to get by rid Some weird React thing anyways. So that wasn't necessarily too bad because you just normally nuke out the wrapper and have that wrapper just straight up JavaScript or something. But what are the things that you're doing the most in React? You need to think about, like, use state. Right? To do a use state, you have Your setter and your variable and then the use state function. So, basically, you can take that use state and just convert it to a straight up variable.

Use name and set name now just becomes variable. Let name is equal to string. Anytime you wanna update it, you don't need to call a setter function. You just say Name is equal to whatever the new value is. What about immutability, Scott? I don't care. I mean, I I I like immutability, but, like, It just doesn't matter in this context. To me, like, when you're in a file and in a component, you're changing it. It's funny ridged. We still use even, like, reducer style updates to do some of our our store our state updates for, like, more involved State. Right? We have more involved state. We still want to do maybe that update where you have a function, you have access, you can create a new ridged and do all the same stuff you did in React. You can still do all that if you want to, but we just found it to be especially in forms, you bind a value to a form input. It just works. Rid Right? And that just ends up being so much more simple than having to create a thing that calls a thing that calls another thing. And I'm not talking about Redux. I'm talking about just straight up React. Right? So that was one of the things that felt really nice was converting all of those use states into just a variable. Right? I mean, we write JavaScript outside of the React context, and you expect re You update a variable, and that variable is now the new value. And it's just the same with Salt except for the UI updates as well without you having to rid. Worry about that flow. React aside,

when I taught JavaScript in person, we would often get people take rid. A variable in JavaScript and put it into, like, a span tag, and then they would update that variable. And then the span tag wouldn't update. Rid. And they're like, well, like, what's going on? And, like, that's how brand new people to programming expect it to work or assume rid Zoom it to work. You put a variable in a thing and then you update the variable, it should update. Right? And React kinda made it work that way, but then you had this, like, Set state a way to approach it. But now, Svelte is just kind of like how people expect it to work, which I'm a big fan of that approach. I'm a big fan of it too because it feels like you said, it works the way that you would have expected it to work without having to learn. Mhmm. That was actually, like, a hard part too was re Unlearning all of the

overly engineered complexities of a React app. Right? When you start to look at a React app and you're wondering, like, Okay. Or you're looking at the Svelte component saying, okay. In the past, we we did this thing that needed to do this other thing that like, wait. I have access to the DOM here. I can access the DOM element, and I can just do this thing. Oh, I just have access to this variable. I just update this variable, And it all just feels so much more less like you're learning its this own thing, and you're learning just you're you're using just straight up JavaScript in the platform. Rid. I had that. I was building some small little form element on the side I just talked about in the ad read for my wife, and I built, like, an event handler callback function.

And then I was just kinda sitting there being like, oh, I don't need this. Yeah. I don't need this. I didn't need the intermediate handler that would then rid. Take the data from the thing and put it set state and and all that. It just happens on yeah. It was just bind colon value equals Quantity. In my case, it was a drop down, and the number selected from the drop down needed to be into a quantity variable. Rid. So I just said let quantity equals 1, and then I just said bind colon value equals quantity. And whenever the drop down changes, rid. It just automatically updated that variable.

And I know that we've had this for, like, 10 years in Angular world, but it's I was sitting there writing a event handler, And then I realized, oh, I don't need this event handler at all. It's very simple. I was really happy to hear that. Me talking to a React developer rid. Now is me being bad Santa and saying, do you really need all this stuff?

Do you really need it all? So, yeah, what are some other neat things? A GraphQL calls in the past, they were rid generated for us before, and they're still code generated for us. But instead of now generating a React hook that just re Creates a function. You just import the function. Oh my gosh.

Like, just oh, you don't have to create the function. You just import the function. Oh my god. We also removed extraneous things like fragments that we had on our React code because, believe it or not, you can put 2 components next to each other Without having to make them an array or fragment, whatever, a lot of these things seem like small little simplicities. I have a couple of videos on YouTube now that are, like, 5 things I like more are in Svelte than React, And people are like, these are just the small little niceties. I'm like, yeah. But if you get a small enough small little niceties, your whole experience is nicer, And there's less room for foot guns because you have less platform specific knowledge that you really have to consider. So we removed extraneous things like fragments. We converted our rid Conditionals,

that's a nice thing too. It's small, but your conditionals are no longer a thing, ampersand, ampersand. It's now if rid thing inside of curly brackets is so those are fairly easy to swap out. Oh, that's one thing I kinda missed. There's no shorthand if in Svelte. Rid. You have to do a full Pound if. Yeah. Pound if, then you do your condition, then you render out the component, and then you close your if statement.

Whereas in React land, it's much easier to do, like, a nice little shorthand.

But it's way more explicit to say pound if thing.

In fact, the only thing that you're actually gaining you're gaining, like, verbosity wise is the closing if tag is really it rid Or in else instead of using a question mark or something. And that is the devil's advocate here. React intentionally doesn't have a lot of these niceties that Scott was just saying

because they prefer to be more on the extremely explicit. And there's a lot of developers who will look at Svelte and say, rid Too much magic for me. You know? Like, I don't know what's happening. React is just JavaScript even though it's it's not. It's JSX, but that's rid. The sort of the flip side. If you're, like, listening to this being like, well, like, then why do people still use React? Because there's a lot of people who much prefer The flip side of it, which is I don't mind writing a little bit more code or it being a little weirder, it's much more explicit, and there's not as much magic under the hood, which is Svelte gives you. Yeah. Totally. And the nice things about it is that you get this magic without having to sacrifice bundle size because

rid Svelte doesn't have a library that it ships, so to say. So another thing is that we can convert anytime. This is a pattern you see a ton of time in React rid You have a component. You have a prop name hello, and you're passing in a value named hello. So you do component hello is equal to hello inside of curly brackets. That just becomes component hello inside of curly brackets, which, believe it or not, is something that the editor can actually do for you Because component or hello is equal to hello is valid Svelte code, but so is just the shorthand of it. So when you save the file, it auto rid It's those, and it's really nice. It saves a lot of space. It's something that JSX shoulda had from day 1. Yeah. And to me, it's small. These are all small little things. Is that a part of Prettier that does that? It takes out the Yeah. I think it's Prettier that does that. Yeah. I like that a lot. Okay. So what are some things that really rid Sparked a joy for me in this transition. You know, state overall, we've talked about this a bunch. State is one of those huge things in Svelte because You don't need a a state library. In fact, I don't know who's using state libraries in Svelte because you have a lot of options for state baked in the Svelte. You have the straight up local values being set via just Variables, then you have writable and readable stores with custom update functions if you want, and it all works super well. It's really nice. It's Transparent, and everybody does it the same way. And if you need the complex state updates, then they're there too. You can do all of that just rid Same way, but you don't have to pick a tool. You don't have to pick a library to do that. And it's shocking how that lack of choice rid around all of these things is a huge plus in my favor. And the choice of having 800 different state libraries to pick from is definitely a rid Pro of React. But, honestly, it's not something that I really want in this stage of my life, Wes. I'm in the just pick it for me stage. Yeah. And just pick ready. For me as long as it's good. And let me tell you, it's good, so pick it for me. I don't wanna care. And that's really what I like about it. It takes a lot of that decision fatigue out of it for me, and it just presents it as here's how it rid and it's good. Another thing, here it is and it's good, is one of our sponsors, and that's Sentry at Sentry dot io. Now Sentry is the perfect place to see all of your errors and exceptions happen in In your application, it's actually really, really neat because they keep on adding additional new features to Sentry and with some really, really neat stuff around performance metrics and rid Greatly dropping because that's right. They give you a user misery score, which is how slow a specific page route is on your site significantly faster across all of our user routes, And everybody's less miserable than they were before on the old site. So things like that are one of the reasons why I love and use Sentry just about every single day. Rid. Head on over to century.io.

Use the coupon code tasty treat, all lowercase, all one word, and you will get 2 months for free. So check it out. Thank you so much for Century for sponsoring.

Some other neat things that spark joy for me were, like, the render flow. You know, I never had to think about rid Accidentally causing an infinite loop by goofing up a dependency or something in a useEffect. Yeah. I'd never had to worry about memoizing or use I don't care. I don't even think about it. Yeah. And the fact that I don't have to think about it is a huge plus for productivity.

I've never had an experience where I've only caused a crazy amount of rerenders from something like that. It just never had to happen. It was never installing a plug in to count how many times the component render rid because it didn't become important in this context.

Just overall developer experience has been a joy for me, writing and creating new components, creating new things, working with All of these things, these choices are made for you. They're easy. It's just a joy to work in. Another one, this is kind of low key that I don't know if a lot of people know, but making a library is really easy in rid because SvelteKit has a SvelteKit package command.

So if you make a new SvelteKit package or you make a new SvelteKit project and it's like a a component library, something like that. And then you run Sveltekit package. It packages this all out for you. Easy. We have a package directory that we import some Some of these things from and I I made a few packages. I'll have links in the show notes. One of which is called Svelte toy, which is based off of a meteor toy package. And this thing is basically, you just plug in all of your different stores into it, and it makes a little pop open window where you can Edit those. It just gives you text boxes to edit any of your store. So let's say, like, I have the user data popped in and I wanna just quickly change a role. I have a checkbox box in there. I click that checkbox, and it quickly changes the role, and the UI updates automatically because everything's using the exact same store. The cool thing here is that, again, there doesn't need to be any providers or parent child relationship here. You just need to import the state, add it to the array, and it works.

Oh, that's cool. It's like kind of a quick and dirty The dev tools. Admin UI

for editing your data. Yeah. It's a quick and dirty it's an admin UI rid. For state, where you can quickly and changely easily change anything like dev tools. I also made a Svelte element query, which this package is, like, Ten lines of code, and this gives you element queries for any individual component. You know me. I love element queries, which allows you to change a component CSS Based on the component size rather than the window size, and that was really easy as well using something called Svelte actions, which are underutilized Part of Svelte that gives you access to the DOM node and life cycle methods on that DOM node. And I also forked a Svelte simple data table library that wasn't working with kit because there's some, you know, server side rendering issues. I forked it, and I just removed a bunch of stuff. And, it's not good for a PR because I hacked rid depart, so to say. Yeah. But I have to depart now, it works with SSR, and it works really well. So Can I ask what you had to do in order to make The SSR stuff work because I was running into some of the same issues that I hit in Next? Js, which is cannot rid Read window or something of window because window still doesn't exist on it. So I still had some of those SSR panes in SvelteKit. Yeah. I mean, we can get to that in the rid Challenges section where I think I have SSR stuff as being one of the things that's still a challenge. It's definitely a challenge still. There's nothing that's gonna save you there rid in Celcate specifically other than just not utilizing things that are calling the window or or whatever. So Yeah. I ended up using the same approach that I use in Next. Js land, Which was I use the on mount. I like to find the function, but then I waited for the on mount hook. Mhmm. And then when the on mount hook ran, I checked If the window was there and then ran the function if it was because it it's something I only wanted to run client side. Yep. And there is a browser in SvelteKit. You can see if there is Browser that's available to you. We use that anytime we needed to run code like that. You'd say if is browser, then do this thing. Rid You know what? I really wish there was, like, a turn this component into a client side only component and then only

even access this component rid If it's pointed out only. On a page by page level, you can opt out of SSR Yeah. But there is not a component by component

rid Opt out, which I think would be really nice. Just export SSR false from a component, and it just skips that entire component. That's what I would like too. Yeah. Other things that really spark joy would be, like, we created a site map really easily because of server side routes. You basically create a route that is the route path rid dot whatever it's returning, dottsorjs.

So for instance, we will have a site map. It's an XML file. That file is located rid added in our routes as sitenap.xml.ts.

There's just a get or a post function in there that returns whatever you want, So we can just access anything that we need. We call our GraphQL stuff, get all the data, generate that site map, and return it as XML. It works really well. Oh, that's cool. We didn't need any sort of CSS and JS library because scoping is on by default out of the box in SvelteKit, and scoping is per file per component. And then if we ever needed to do live updating props like you do, it's actually way, way, way, way, way more elegant to just use CSS variables Rather than having a prop being passed in and then having to call a function inside of a string backticks or whatever inside of a string Like, we did in style components, way easier. And there's even a shorthand for it in Svelte, which is style props, or you can pass A CSS variable as a prop onto a component just by using hyphen hyphen, the prop name as a prop. Okay. So If I'm understanding that right, if you wanna pass data from JavaScript land to

CSS

Mhmm. You pass that with style props? Rid Yeah. Pass it with style props, and the style prop again is just hyphen hyphen. The prop name is equal to the value, and that can be modified with JavaScript. And that sets that as a CSS custom property or a CSS variable. And since all of our stuff's in CSS variables anyways rid. That live updates because CSS variables are reactive in that way. It's just semantic sugar, meaning it's a nice way to write. It literally just converts it to a style property on your div Yep. And then it passes it in like a inline style. It's funny because this is a new feature, and before this This was available. That's literally what we were doing. We're just saying style is equal to and then had our variables in there to control it. Another thing, animations are all done with rid Svelte and turtle animation library, very nice and easy. The animation stuff, you don't have to think about it. It just works. That's great. Didn't have to pick an animation library. Didn't have to blow the bundle with it. Just works. Hosting.

So we used the SvelteKit adapter node, which, you know, SvelteKit has the ability to basically output it as anything you want, whether that is You're generating a package library. You're generating a build for a static site, a SPA only site, a node app. Whatever you want to export this thing as, whether it's For Vercel or for Cloudflare Workers, you can do that. You know, for me, it's easy to just have a node app that you can move from place to place. So we use the SvelteKit adapter node.

And earlier on, like, when we first started this 2 months ago, I would've said this adapter node was a little green. There were some little compatibility, weird little things here and there, but It's been rock solid for the past month and a half or so and had no issues. So we, basically, we hosted on render.com, which allows you to basically get a node rid Process is up and running for about $7 a month. It is basically Heroku, Heroku for cheaper. So for Heroku and Netlify had a baby, And you didn't pay anything. It's very good. So for $7 a month, we're, like, hitting 10% of our allotted CPU and memory usage on this thing, which is, like, very good. I will take that. We were paying quite a bit more for our Meteor hosting at the back in the day when we were on Meteor, so it's wild the amount of rid Bandwidth and CPU and everything, and how little this ends up taking up. And is that your back end? You're not publishing them all at the same time. You're basically just pointing your front end towards whatever Endpoint your back end is hosted on? Yeah. We have a node API, which is also a $7 service on a render, which is a Fastify API with Mercurius to host our GraphQL. We kept those separate just to have them separate just so you could iterate on 1 or the other.

You could very easily host your API in the SvelteKit site itself. Does SvelteKit have anything

like rid. Serverless functions are if you wanna I guess you can run

SvelteKit entirely server side. So if you wanted SvelteKit to also handle all your back end logic, Does it do that as well? Yeah. It can handle all your back end logic, any of that stuff. You know, you have server side routes. You can have a route that is just an API endpoint Or any API end point, it it just goes in your routing folder, and it can whatever resource it returns the exact same way we're doing our site map file. Yep. But you could have a Graph route inside of there that, you know, sucks up all your stuff and outputs a GraphQL endpoint or rest endpoints or any of that of stuff. Oh, yeah. Because your endpoints can both be front end rendered, but or it could also be Server side only rid Resources. Site map is just a server side rendered. Yep. Oh, yeah. That makes sense. And it is serverless depending on where you deploy it to. You have Yeah. Rid. Sort of think about the caveats of going entirely serverless. But Yeah. You have options there. I deployed my site that I was talking about earlier both to Vercel and Cloudflare,

And both of them worked

right away on the 1st try on both of them. So I was like, oh, this is kinda nice. Yeah. It's kinda nice. It's not really it works right away. You know, and the only reason I went notice because I only wanna make so many changes at once. And it's like I'm been very used to running a node app for the front end of the site, so Very used to doing that kind of thing. Easy to do. Things that we still need to do, all of our admin tools have not been moved over because, let's face it, can do those on our own time. We can just use the React ones. I just have them in their own folder on its own service being done as a client side only Static site, and that all just works the same way it was, just pointed to a different URL than it was. Yeah. So our admin tools are all in React Still, but I'm taking this time to, like, rethink and rewrite them again. And and it'll be fun because the cool thing about admin tools is that just like, you know, building dev tools for yourself, rid You can do really customized solutions to whatever you want them to be, whatever helps you the most. It's your admin tools. Rid. Your company's admin tools, they can do exactly what you need them to, and it doesn't need to be just some generic thing. Right? And it can be very hypervascularized.

Rid I've been taking some time doing this, and I've been using a library from Rich Harris called Pancake to do the charts and graphs. Yeah. There's not a lot of docs on it. You kinda just read the source to figure it out, And I don't know if he recommends even buddy anybody using this, but it's for our admin tools. It's a lot of fun. I'll have to talk a little bit more about it later, but it it's pretty cool. I'll show off some stuff that we're working on when it's done further, but the charts are really nice and works really well.

So challenges challenges, like, Wes mentioned server side rendering stuff. You know, if you're not used to writing server side rendered code in general, you might definitely hit a bunch of, like, what is this? Why is Window not to find kind of issues that you're not used to? But server side rendering code, the site has to be able to run on a node process like ours is or in the browser and or both, whatever. That's definitely a concern. ESM is not a lot of fun. It's like a lot of little weird things when you're running ESM modules for ECMAScript modules, which is the import syntax. Reason being is that some libraries just flat out don't play nice with everything. For instance, we had, like, a situation with Lodash.

And Lodash, rid Typically, you wanna access just the function, and that way, you can code split better. So if you were saying, like, import has from lodash forward slash has, Gives you just the has function rather than all of Lodash and then using the has method. Right? I don't wanna say this exactly, but we had an issue where that Import was not working in either dev or prod, and it was asking you to import has dotjs from lodashforward/has.js.

They they wanted the dotjs on there, so then we did that. Oh, yeah. And it would work in in dev, but not in prod. And then so it's like a constant PR battle Between 1 getting fixed and 1 like, oh, I fixed prod. Oh, but I broke dev. Oh, I I fixed dev, but I broke prod. So the solution actually the thing that worked rid Right. If this is you here listening to this, and you say, this is me. What's the name Leonardo DiCaprio meme where he's, like, pointing at the TV? The solution that we had is that you can also Install each Lodash function as its own thing with a dot.

I don't know if you knew this. If you do npm install Lodash .has Instead of Lodash and then grabbing has, lodash.has, then it just installs just that 1 function that worked.

So if you were having issues there, that's the answer. Another thing, we were on Apollo for a little bit before I realized that we just flat out didn't need it. Apollo has, like, a bunch of weird dependencies for React and stuff. And if you wanna access the stuff without React, you have to import it from core in a nested All that in addition to the fact that we just weren't using it.

T s, typescript in SvelteKit is great. It works very, very well, but there was one specific instance where I had, like, a read. Prop. You know, like, if you wanna spread props to have, like, kind of like a catch all for props, you're doing, like, a form input. You wanna catch All of the various things that would be on a form input and then spread them onto the input. Yeah. There's no way to define In Sveltekit currently, I know they're working on it. There's no way to currently define all of the props on a specific component Without explicitly listing each of the components and defining their type, there's no way to have, like, a props type Where you list all of the prop, you have to type each thing as their input, as their prop individually. So that was a little annoying, but they're working on it. Yeah. Last thing here before we get into final sponsor, and then Wes has some questions or anything. Drag animations were also a bit of a pain because with dragging specifically, you know, if you wanna have some really slick drag animations, there's a lot of solutions out there in React land. We always use Framer Motion on the last site. There isn't as many solutions in Svelte land, And it's one of those things where, like, you could just write it yourself, but there's a lot of edge cases there, and I I don't wanna encounter those edge cases. I don't wanna have to, like, spend too much time on it. We ended up using A library that implements pop motion as its own thing. Pop motion is the library behind framer motion. Somebody did a Svelte motion package which utilizes pop motion, but it's a big, big package. That's a big package. Me looking at it across the street, that's a big package.

Oh, that's going on the soundboard for sure.

You see that package?

So, you know, in the future, it would be nice to To refactor that into something that's not so large, especially when we have all the animation goodness coming from somewhere else. Yeah. Again, that's pretty much it.

You know, what else Is the small package be any photo that you ask for from, one of our sponsors today, which is Cloudinary because they're gonna give you rid The correct size for whatever photo you are requesting.

And when I say correct size, I mean a fully optimized size. It's gonna give you Just optimize for performance, speed, quality, whatever you want. You could say give me this quality auto size auto whatever, and you're gonna say this is the right sized package for me. This is the right sized rid. Image for me here. So, Wes, do you wanna talk a little bit more about Cloudinary?

Yeah. Cloudinary is the solution for hosting media on your website. So We all know Cloudinary probably for their images. They do video and all kinds of stuff for that as well. You can use Cloudinary as your main point of upload for all of your images rid. So you could hook it up to your application. When a user uploads a image, you could go straight to Cloudinary.

You can also just literally sometimes, rid When I'm building the website, I'll just log in to Cloudinary and drag and drop that sucker up in the the UI. And then you can also the kind of the third way there's probably even more ways. The rid way is it via the slurp function where you can host the images on your own server, but then you put the Cloudinary magic URL in front of it, And it will then download the image and then whatever parameters you pass it. So you can say quality, size, width, height, rid. Sepia effect, old timey cowboy effect on top of it. You can do all that kind of stuff. You can put a text on top of it. Rid. It's just the best way to manage all of the images in your your application. So check it out. So check it out. Rid. Cloudinary.com. They've got APIs. They integrate with all kinds of different languages and frameworks. You name it, they got it. Thank you, Cloudinary, for sponsoring.

Sick. Cool. Okay. So last little bit, West, you probably got some questions for me. I did a lot of talking here. Hopefully, I covered most of the stuff that people would wanna hear about this kind of thing, so let me know what you got. Yeah. So questions I had is, like, one of them was, like, what about the ecosystem? But I think that one is kinda answered. So, like, with React, Like, literally, you could be like,

I wanna build a dog shelter website or, like, oh, just use react dash dog shelter. You know? Like, there's always something. Rid. The React is so dominant and so popular that whatever you need for React, there's always a package or a approach that somebody has done. So rid. I think the answer to what about the ecosystem, because it's still pretty early in SvelteKit days, is that you don't always have to use the specific rid. SvelteKit version of something because it doesn't need to be converted to useEffect

and hooks and all this stuff. You just use the JavaScript version of whatever it is. Right? Yeah. That's a huge plus too. Right? You have access to the real DOM, not like the virtual DOM. You don't have to worry about the rendering cycle or any of that stuff. So you can use the DOM. Know, like I said, we we don't even use the Svelte version of our video player library even though it exists. We use the web components one because, hey, why not? It's just The DOM in the browser. So I found myself using a ton less libraries overall, but even, like, the ones that I do can be pretty small. One really nice thing about Svelte is the REPL. I don't know if you've seen too much of this, but the REPL is is basically a good code playground for Svelte. But because it exists and it's really easy to create a REPL and share it, like, ripped. Super easy. What you end up getting is, like, people doing a ton of examples of, like, what you wanna do, what you wanna see, whatever as just REPLs, and then you have the code Just available to you in a couple of files to go ahead and try out or something like that. So I find myself implementing a lot of things even like a Toast library, whatever, just from popping open the rid REPL and just kinda packing away on it or or taking somebody else's and forking it and and just experimenting there. Another one I question I had was to do with rid. In React, then you generally don't reach into

DOM element and modify. You don't set the value of an input box. You don't select rid. The a drop down box. You don't with the video, maybe you do set the current time directly. But generally, with React is that you just set the rid. Data. And then when that data changes, you update the thing.

If you're working with forms and inputs and maybe media elements, you still bind all that important data to a piece of state, or is it okay just to directly reach into the DOM and and pull that value out of there? Oh, I bind it because

one thing that you can do like, let's say you create a writable.

So if you would create a writable object that is, like, this form's data, Like, if you say, like, form I'm just doing this, like, kinda cowboy coding in the Notion is equal to a writable with a empty object, and these are your default rid form values. So you would say, like, writable as an object, default value, title is equal to yo and a string.

You can bind that in the HTML really easily by saying input bind value.

Oh, Oh, yeah. This is what I was talking about earlier with how easy it was to bind. But you can do so inside of the full object. So if you were to say form data dot title, then that binds That's nested property of the writable Oh, that's nice. Into a form. So this is typically how I'm doing it, rid Is I'm typically creating a ratable object and then just binding the values into that object in the same data structure that I would want it to be. I think the other benefit rid. You're still binding it to a variable

is that let's say I have a variable with, like, a video progress, and I have another variable with video length. Rid. What I could do is I could divide those 2 and then round them to come up with 52% through the video, and that would be a A reactive is that what that's called in in Svelte? A reactive variable? Yeah. It's a reactive variable or, like, a store value. It's like a reactive subscription. You put, like, a You put, like, a dollar sign in front of it to show that you care about the updates?

Yes. Yeah. That's correct. Basically, the dollar sign is saying, hey. I'm gonna rid The latest version of this thing, and it's gonna be reactive and update for me. The dollar sign is kind of like a magical reactive indicator anyways. Like, The equivalent of useEffect in Svelte land is basically dollar sign, colon. That's it. No no dependency array or anything like that. This is typically how I'm doing it. You can access the form values directly. I think there are probably instances for that when you have, like, a really dumb form, but it it takes So little effort to create that writable and to create those values and update and bind them that controlled inputs in Svelte are a heck of a ton easier. So it's like, rid. I almost never feel the need to have an uncontrolled input.

Awesome. Is it stable? So SvelteKit. Svelte's been around for a while, but SvelteKit is rid. Somewhat new? Do you feel safe running your entire child's Mhmm. Food on the table on something that is not

is not released? Is it 1 point o yet? Where is it at? To me, it feels very stable. The only issues that I've encountered that have been, you know, issues of it being not ready were, like, 2 months ago, and it was with the adapter node. It wasn't even with SvelteKit itself. You know, it's funny. Rich Harris posted, I think, like, 2 weeks ago. It was, like, some, I believe it was French site, and he was like, this is what I'm gonna use anytime anyone asks me if Sveltekit is stable yet because the site was just so rock solid and great And just such a good experience. It's like this is the answer. You know, me personally, like I said, I'm not running into too many situations or any situations really where I'm like, I wish I wouldn't have picked some unripe fruit here. No. This fruit feels very tasty to me, Wes. This feels like I was gonna say yellow banana, but now I'm regretting that choice because rid because I don't really like bananas that much. Like, what what's a good ripe fruit? Peach? Yeah. Yeah. Raspberries? What are, like, plums? Yeah. Any of that stuff. Literally, any fruit is good when

rid

Right. Oh, okay. Okay, Wes. Whatever.

You you got you got me here. Fruit is good.

Rid Fruit is good. Awesome. Last one I had here. I was just very curious about this because the issues we have with Window and SSR versus client side, A lot of those will be alleviated with Deno instead of using Node. So I was curious, like, you probably don't even know this, but I just googled it and found this thing called rid. Snell Yeah. Which is a Dutch word for fast, and it converts your Svelte to JavaScript so you can run it in Deno. Rid. I don't know if that works with SvelteKit yet. And also, you would have to assume all of your other dependencies also work with Deno. But I just thought I would mention that because it seems cool that this might be able to work with Deno in the future as well. Yeah. I've never heard of this, But I do wanna say, like, how many languages are we gonna get through before we've run out of words for fast in every other way? Isn't that v to v to fast?

It's like Yeah. Okay. Well, this one is gonna be fast, but it's gonna be in, Japanese here.

Is this this one is in Catalon? Catalonia? Yeah. Catalonia. I think Catalon is the link. I don't know. Yeah. Catalon. Yeah. Rapide.

Rid No. That's not that good. Let's see what other Serbian is. Oh, I don't know how to say that. Hungarian.

Gyors, rid g y o r s. That's funny. Yep. Tell us. Yeah. What is fast in your native language? And Scott and I will try to pronounce it on the

And then we will promptly make a library with that name. That's the trend right now. Oh, Filipino is Mabilis.

No. That one was good. Rid I think that's it. Thank you so much for sharing all that. Honestly, this gets me so excited for SvelteKit. I am onboard with all of this, so I'm it's really cool that you have Decided to rewrite your entire platform, which is a little bit crazy to me still, but I did it and crazy to me. But you know what? Like, it was a great learning opportunity, and now I can, like, safely rid that any Svelte content that I'm going to produce,

I'm gonna have a good handle on No kidding. Yeah. The things that you could run into. Rid I probably run into any of the quirks or features or anything like that, but it's also like a very real world app. And if I'm gonna be, like, you know, this is so good. I wanna teach it. I gotta you'd feel like I've encountered everything you could possibly encounter with it, and it definitely does help that I've really dove into the platform just completely, and, I'm very, very, very, very happy to have this process now not because it was a pain, but because I have a SvelteKit site now. And that SvelteKit that I'm looking at, like, you. I like you.

Let's move into some

sick picks. Do you have a sick pick for me today? Sick. Pick. My sick pick today is going to be a podcast that I discovered 2 days ago, and this is SGU or the Skeptic's rid guide to the universe, and typically, like, kinda some of these podcasts get a little bit, I don't know, like, I'm too smart for you kind of stuff. Yeah. But I found this one to be extremely approachable, the episode that I listened to is the most recent one at the time of recording this. It was an hour and 40 minutes, but a brisk one. Rid Episode 844, for those of you who may wanna check out the same episode, in that hour and a 44 minutes, they did, like, a non scare but very, like, scary update on on COVID, but, like, talking about, okay, what are the variants out there? What do we actually ready. Need to worry about. What are what are the things that we don't need to worry about, and, like, what's the data about it? They also talked about interesting information about current status of nuclear fusion electric cars, like, at what point how many miles do you have to drive an electric car, and, like, what's The data behind that before it becomes better for the environment. Oh, interesting. And then even, like, accounted for all the sorts of different data and, like, different seasons that you might live in. It was so fascinating, and every single one of these little things that they touched on was just endlessly informative and endlessly just really interesting to listen to, talking ready. About rocks on Mars.

They talked about cryptocurrency in a way that was like you know, it's, like, so hard when you're talking about cryptocurrency because so many people have such a a stake in it. You know, they're just You might too if, like, science information is interesting to you. Cool. I'll have to check that out.

I am going to sick pick a nozzle rid For your pressure washer we've had a pressure washer for a long time, but we never had one of these rotating turbo nozzles, which ready. It's really cool. It's a much bigger nozzle than the rest of the nozzles, and it spins in a circle. And there's something to do with the fact that how it bins while you're doing it, that it makes it even more pressure full than the regular pressure nozzles. And rid I think because it is just like a pinpoint nozzle, but it spins and moves, you you still get more surface covered at the same time. Cool. And we just We're repainting our porch right now and are cleaning a bunch of algae off of our pavers in the back. And this thing, you could rid your hand off. I bet. So don't put your fingers in front of it, but these things are awesome. So they sell them everywhere at your local hardware store or whatever, so you can check out One of those. If you're having if you're doing any sort of pressure wash work, I recommend grabbing one of these. Cool. I need to get a a pressure washer. Definitely need to get one at some point here. They are key for if you have water. People always get mad at me for rid Doing anything with water. If I post myself watering our lawn from the lake, people get mad at me on Instagram because I'm wasting water, but It's okay in our area. I understand there's parts of the world that don't have a lot of water. So Yeah. I know.

There's a lot to navigate there. But yeah. Okay. Cool. Well, shameless plugs. I'm gonna shamelessly plug the latest course at the time of recording this on level up tutorials.com, And that course is on web components. 101. Hey. If you wanna dive into web components, we build, like, an accessible tab component where you get keyboard navigation, all that stuff. You can build a tab component. We build models. We build all sorts of neat stuff in this course. So if you're confused about what web components are, why they might use them, or even, like, How to write them without the use case of using a library or something like that? Check it out. This course is really neat. We don't use any libraries, any build tools, anything just straight up Script on the page and browser APIs. It's very, very cool.

So level up tutorials.comforward/pro.

Sign up today and become a pro. Sign up for the year you can save 25%.

Alright. That's it. Thank you so much for tuning in. We will catch you on Monday. 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 rid Drop a review if you like this show.