Remix!

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS web development treats coming in hot. Here is Wes, Barracuda,

Boss, and Scott

key. Hey, everybody. This is Scott. I misspoke on some things in this episode that I wanted to get ahead of really quick before the episode started. What I said in the episode is that the loader makes the data available to your components via props.

Honestly, I'm not sure why I said that. The loader makes the data available via the use loader data hook.

And, I I just wanna make that very clear because you will hear me say the data is available via props several times in this episode. Again, it is available via the use loader data hook, not props. Okay? Just to get ahead of that and enjoy the show.

Woah. Welcome to Syntax.

In this episode of syntax, we're gonna be talking about remix.

Yep.

Yep. Breaking freaking Remax. Yeah. We're gonna be talking about Remix, this awesome new platform, from the creators of React Router. It's Very cool. I'm very into it. My name is Scott Talinski. I'm the developer from Denver, Colorado. And with me as always is Wes Bos. What's up, Wes?

I am stoked to try to finally talk about Remix. We've had the people have been asking us about, what What do we think about Remix? Probably for like a year and a half. We've been trying to get Ryan and Michael on the podcast.

It's gonna happen one day.

But now, now that it's it's out, it's available, it's publicly available to everyone, it's not a paid thing anymore. For some reason, I thought it would be it was always like a always going to be a paid framework, but that Seemed to be only for early access and now it is, no longer early access. It's available to everybody and we've got to play around with it. I think Scott's given it a bit more of a run than myself, but I definitely, was taking a look at it and built a few things myself. So,

I'm a big fan. I'm excited to talk about it. Yeah. I I found it to be very cool. I really focused some time on it recently by doing a tutorial course on it. So I got to spend some serious time with it, and I really really enjoyed it. It it you know, very rarely does things that get hyped up so much, you know, deliver on the hype, and I think Remix delivers on the hype. I think it's it's it's excellent. So, this episode is sponsored by 2 awesome sponsors that also deliver on the hype, Sentry Insanity.

Now Sentry is the perfect place to see all of your errors and exceptions, and it's one of those tools that I've been using for so long. It's just a part of my workflow. This is the place where you can log all the errors and exceptions in your website or application or anything that you're working on, and you can even track performance metrics snow in it, but you can do so much more. You can tag specific bugs to different releases automatically.

For instance, we have our site. Anytime we have a new version of our site comes out, it gets an auto version bump, and then that version's tracked onto each error so that we can see if this error is present in any individual version of our site, and that's, like, awesome. That's so awesome. Then we also have the ability to, You can create a GitHub issue directly from Sentry's dashboard.

You can auto see which user is having this issue, how many users are having this issue.

Is this a widespread issue? Is this thing caused by maybe a browser extension? We recently had a bug that was definitely caused by a browser extension, and that was really nice Be able to figure out to know that if this is something we needed to work on or not. You can also have, you know, I haven't used these tools myself yet, but there's some interesting user feedback tools. What do users think? And and those are types of things you see on a lot of websites. So if you're asking for users feedback on the impact of different things on your site, user feedback, You can get that as well as everything else, including the performance metric tools and the issue tracking and all that and more. So Check it out. Century.i0.

There's always something new. There's always cool new tools, and all those stuff is just going to make your user experience better. Century.i0.

Use the coupon code tasty treat, all lowercase, all one word, and you'll get 2 months for free. Thank you so much for Century for sponsoring.

Let's talk about Sanity.

First of all, Scott, did you see that Sanity put my I did. Ad on the so awesome. Yeah. I was just talking to a friend of mine, and I was like, Yeah. We we mostly just make up our ad reads on the spot, and he works in, like, ad tech, and he was like, what? And he's like, yeah. We we we did that's how we've always Dunham. Like, actually, one of the companies ended up using one of the slogans that he had said in these on his website. They thought that was hilarious.

So in one of our last episodes, I said Sanity is super nifty. It's structured content plow platform that power digital experience.

Everybody's insanity is going to love it. Why? Because you, the developer, get the right plain old JavaScript or TypeScript to define your schemas or your data. The marketing people on this other side, once you build the thing, they are going to love using it because of the amazing UI to edit the data, to, relate it, and to make custom workflows. Marketing people They're going to need it to get approved by lawyers, and the lawyers are gonna love logging in and approving this thing. It's just awesome. Everybody is happy with Insanity. I think they should put that on their website.

Just took my, like, rambly ad read and put it on the website, like the home page. I thought that was really the so props to them for doing that. Sanity is, is where your content for your application goes and it is both a development platforms so you can build on top of Sanity because you can they have you can they have APIs where you can pull the data out as well as this entire content management platform where you can log in. You can see who's editing what, who edited what, when they edited it.

You can have work flow. So like marketing makes a change, it gets approved by legal, then it's published to the website.

It's awesome. It's it's more than a CMS. It's It's it's makes you happy. So check it out. Sanity.i0forward/syntax.

That's gonna get you double the free use of share. Check out for your next project where you need a I'm gonna say a CMS. They don't they don't call it CMS, but, just to sort sorta give you an idea of where it fits into your application. It does your photos and everything else as well. Okay. Well, let's get into it.

Remix.

What is it? Remix is a it's a web platform that's focused on web fundamentals and modern UX, so you're simply going to build better websites.

It's built on the fetch API, the web fetch API. So you can use fetch anywhere and everywhere. You don't have to worry about whether it's node or or or front end code or whatever. You you just use that fetch. Right? You write your code primarily, at least right now. This isn't going to necessarily be evergreen, but let's to say right now, you write your code in React.

And that code is is rendered on the server and, sent to the front end, and and it's really pretty neat actually.

And there's also a folder based routing setup, so it feels a lot like many of these other modern platforms. You have Next. Js or SvelteKit or, any of the the Vue alternatives that where you have the whole folder based routing system. You have that same kind of deal in, in Remix here where the folder structure for your application is just about the exact same as the routing structure, but then you can also have as many folders outside of that as you want for your components To be living for your non route based components.

So it's a you can think of it as really like a server first platform, But you don't even have to think about server versus not server, where something like we talked about Astro, you kinda have to explicitly tell the client side that okay. Now we're have client side JavaScript. But with with Remix, you don't have to even think. Is this client side? Is the server side? Whatever. You're just writing your code as is in these, these files. They're they're component based files or route based files. You just write your code, And it really feels nice.

It it feels nice because, again, what this allows you to do is it allows you to co locate so much code, Whether that is your get requests or your post requests on the server, allows you to colo locate that inside of your routes rather than having to worry too much about Having all this separate separated code concerns.

Yeah. Like, maybe we should explain that a little bit more is that, collocating means that you can literally write A function that runs server side in the same file as, the actual, like, UI gets gets rendered on out. And it's really smart about I I think the like like Scott said, that it's It's based on fetch. The I think that the the killer feature of this thing and sort of the whole ethos of that it's built behind is that it's It understands where your data is being fetched, and your data can be fetched in any component, but it is always aware of that. So it can, sort of like skitter scatter through all of your components, figure out where all your, fetches are happening and run them in parallel and that's really really good because it, what can happen in a lot of React applications is you You fetch some data.

You get that data back, and then that renders a component, and then that component loads, and then that component component. Fetch yeah. Then it rerenders, and That one needs to fetch more data, and you can get these waterfalls or you get lots of spinner. We've all been on websites where you visit it, and there's several different spinners.

And I we in my, advanced react course, we use something similar to this with Apollo where, it will Sort of walk the the file structure tree and look for any Apollo queries. But it's always it's it's a bit of a pain to get set up, and every time Next. Js updates, it's a bit of a pain to to get working again. And it's really nice to just, like, Oh, it just fetched data and it knows and it can render them all out and you don't have all these spinners out all over your website because it will render it all server side for you and then just send that,

send that part back to the To the client. Yeah. So, I mean, some of the key benefits from all this is, 1, that it's fast. 2, it doesn't feel like a React app. Like you said, so many of those React apps Do you feel like you have the initial pass and then on the useEffect then chooses to then go fetch the data and then has to rerender that? It doesn't feel like that. Right? So it's it's fast. It feels really modern and smooth, but then you also get all this server side, SEO benefit that you get. All the information is there available, in the HTML. So Google's gonna see it and everyone's gonna see it. It's it's gonna be awesome. So I I've actually I've been, Just really enjoying working in the platform and it has this really neat module API where if you want to have, different things available to your component. Whether that is like a prop. Right? You wanna have a prop available to your component at at the initial render.

You export a function that's a loader, and there's this really common pattern in Remix where you're just exporting functions to do different things out of your route, click the module API in Remix. And it will talk about more things that you can do with this, but, like, for the most part, like, Think about it like this. Typically, you you think of, like, a common way that you're working in any of these modern front end frameworks is that you're having to hit an API to get your data And then you're passing that data along via props into your component.

And with Remix, you don't necessarily have to do that. You can still do that. In fact, that's the way we do it in our course. We an API. We get that data back. The data is available as props. But you can also even, like, query your database directly in that code because that's code that's only run on the server side in the loader. So that's server side only code And you don't have to worry about the security concerns there because it's stripped out of your client side bundles.

And you you can utilize it in a way that you haven't been able to do with these front end frameworks for so long and that you can load your data up right there on the component if you want. And that's really refreshing to me. It's really nice. Yeah.

It's funny. Like, I I went into it looking at it, and I had been watching what what they're all saying on Twitter about what what this is gonna be. Is it gonna be another the act framework and stuff like that. And after using it for a little bit, I'm like, no. This is just a like a node framework or like a a website framework. Right? Yeah. It's a web framework.

And and I myself, I've been sitting there being like, I wonder if they'll ever allow other rendering engines in in instead of just React. And that seems to be there was a tweet the other day that Ideally, they would like other like Svelte or Vue, things like that to be able to use that inside of it. I think they said pre act support is Coming soon. So, yeah, it's it's just like another I think we talked about this a couple episodes ago, but, like, frameworks, man, are getting They're getting so good, you know? It just takes care of all the hard stuff for you and but then you also have the benefit of Like, we're all sort of swinging back to the server side and doing a lot of the server side but then you also get the benefit of you you can run it on the the client as well, if you need parts of that to be

done in the client. Right? Yeah. Anyway, it takes a lot of that the complexity out of it because the complexity is where I think a lot of the mistakes, a lot of the performance concerns come from a lot of the issues with double, triple renders, whatever, where you're trying to fetch data, get all your data available, And even, like, SEO concerns. Right? It takes away a lot of that complexity and just says, here is, your your view code. Here is your your your post put request to whatever, all of those things. Here's your metadata. They're all existing in this one particular file, and then everything else just becomes easy.

So let's talk data loading. We we mentioned this briefly. There's this whole module API where you export a module, and if you export something that has a default the export the default export, that's your component. But if you export a, I it's funny because when I was doing my course on this because, SvelteKit also has the concept of loaders. And so I was like, load versus loader versus loading. Like, I I wanted to make picture. I said the right thing here. So in in Remix, you have the function is loader. So if you do export to let loader, Then you have this function. And now this function can be used for a lot of things, but the the key thing about this folder is really that the or this this folder. The key thing about this function Is that it is a git request on this route. So if you're doing a server git request on this route, it calls this loader. So you can do things like firing off a redirect, throwing an error state, but also querying a database, hitting an API, And then just returning that data as props and those will be available in the component.

Nice and easy. Right? And then we also have the analogous to that where you have that's your get request. We also have the post put delete whatever request. It's it's so funny because we say all of those things, right? Oh, it's the the post put.

I forget all of them all of the time.

Post put, get, delete options and post put yet to the.

What are all the. Let's look it up. Yeah. Let's look it up. These are called HTTP verbs. It's funny because I only ever use post and get.

Patch is a is a big one. Is there other ones? Post, get, put, patch patches what we were missing. Patch is used to update or replace.

Or no update or modify.

Oh, and pull is used to update or replace.

So I never never do that. Yeah. I never I only use post and get right.

But you have also if you export a function named action or export let action or export function action, that is essentially the post, put, patch, delete requests on this component.

So let's say you have a form that's submitting. You can write that form handler directly in the component itself. And that's something we actually did in my course is that we even imported node mailer directly in my React component.

We used it in the action, and we submitted a form. And we're able to handle that routing function or that that that form handler directly in the action, which is honestly, not something you've been able to do in any of these platforms, and it was fantastic. It was a great experience to not have to say, okay. Now let me send this request over to a server somewhere or a server route or even another file and have to handle it there. It's like I have the form. I have the data. It's a simple thing to send off this data somewhere. Let me just handle it right here. So you you end up having both your action based requests or also your git based requests. All that happened in your remix file, and there's more than that inside of their whole module API. The the module API again is, like I said, it is It's based on what you're exporting, which might feel weird to some people. I know if you've used Svelte, you export a prop to use it, And so that might feel comfortable people to export something to use it. And in Remix, it's very much like that. They have very specific things that you can export to use.

Let me get the list of the rest of them here.

While you're doing that, I think that I really like this because, this is convention based, meaning that, this is the way that you do it. You export a specific thing, and here's how you handled data and like it's you still can do your data however you want. You still can build a GraphQL API or whatever, but you don't have to pick and choose pieces in order to build it up. And and that's what I really, really like. And that's one thing I dislike about, specifically Next. Js myself is that, like, I don't wanna have to choose all of these things. I wish that you just told me totally which one to to go ahead and use.

Yeah. Totally. And so okay. So here it is. The default exports the component.

The loader export is your git request. The action export is going to be your put patch delete request. Okay. So you have your action. You also have headers, which you can return any HTTP headers. You're caching a route or anything like that, you can straight up your return your headers by export let headers. And it's a function. Whatever you return from there is going to be your headers.

Meta. So let's say you want to, have a page title. Export let meta. And then again, you can modify any of your metadata so that way you can quickly and easily not have to worry about things like React Helmet, which let me tell you, React Helman has never been my favorite thing in the world.

Moving to SSR, you had to completely change what package you were using, if you were using suspense. There there there's it's never been like the smoothest experience. So, again, having this Confenogen based in baked in where you can just do export let meta and deal with your meta right there. Super handy.

Export let links for any link tags. Again, any HTML based thing is going to be here, and that's super good. You can also do a catch boundary, which is, really pretty nice because it's capitalized so it kinda distinguishes it because a catch boundary allows you to return JSX, and an error boundary allows you to return JSX. And that again is another export that you can have if there's an error or if you need to catch anything.

What's what's the difference between a error boundary and a catch boundary? Like, what are the use cases for those? An error boundary is for uncaught exceptions, right? If there's a bug in your application, something in your reacting renders weird or breaks. Correct. We have those in React. But what what's a catch boundary? Is that when,

like, a fetch request goes wrong. A catch boundary is, like, if you want to, like, throw something. So here's a good example. In our tutorial course, we We checked we we'd built like a syntax website.

And so I checked I hit the API with the slug for the episode or the, the episode number for the API. So episode 401, I hit the API.

If that episode does not exist in the API, I threw a 404 saying the episode does not exist, And then that's going to hit the catch boundary. So you think you throw an error, a specific type, whether that is a 404 or whatever, you throw an error, You catch a boundary. You throw an error, you catch an error. Right? Oh, yeah. That that makes sense.

What else do we have here? I was gonna we're gonna have, like, a part here where we talk about differences between Next. Js and Gatsby and Svelte and and all that stuff. And I think that can probably be its own show, Just because they are they're different beasts.

Mhmm. The they do do a lot of the same things, obviously, but they are different approaches.

I think the one thing I will say here is that, it doesn't do static site generation Because you can Scott just said, you can return headers from each request. And one of the headers can be how long to cache it. And if you want to, Cash a page per client, meaning per person that visited visits that, you can or you could, you could put a CDN in front of that CloudFlare or whatever, and then Cloudflare would cache that thing for however long. And that's beautiful because that's that's the web API, right? That's a standard of the web API. And if you just use what is it? Use the platform,

it works. Yeah. And that and that same thing goes with, like, a lot of stuff in Remix. Like, how does Remix handle CSS? Well, it it just does it via the links just like you do with the web browser. Yeah. Right. You have a CSS file. You can link it via the module export using links.

What about hot reloading? I I saw that that was not a thing, in it. And I'm not sure if it will be added or if that's an issue.

What did you find there? In my experience, You're updating the file by the time you tab back over to the file that's been updated. Okay. So whether or not that is hot module reloading or any of these, like, fancy terms for the technique that they're using do it. I found the auto reloading. Whatever is baked into the platform, which to be honest, I don't know what that is, worked very good. So, yeah, I never had any concern. And what I found needed about this was, like, the HTML would be there too. It wouldn't just be the, so I don't know if it's just causing, like, a fast refresh and the platform's faster what? But, the HTML would be inserted into the DOM. So yeah. Cool. Yeah. But Remix tries to handle, like, less things for you. Like, it's not trying to handle Too Many Things For You. And I think that's, like, kind of a a kind of a part of their methodology.

Right? They're they're kind of keeping it open ended, At the same time, there's these conventions that this is how you do it. Right? Yeah. Remix isn't they don't have their own CSS system. You're writing CSS, and you're linking it. You handle scoped CSS by linking a specific file to a specific route. You know, nothing crazy there. Right? It's not doing anything into the CSS itself. Oh, okay. I see. I see.

And you could do one of your favorite things is it does nested routes as well. Right? Yeah. You can do nested layouts and nested routes, which I do do love.

And it does kind of like, the same kind of, like, view slash Svelte version.

You know, there's slots.

So there's, like, the same type of concept in Remix, And that's actually from React Router 6. This whole whole thing is is built with React Router 6 in mind so that many of the features and tools and whatever that you get with React Router 6 or just remix features. So one of those features is that each of your slots, they call them, I believe, outlets. So each of the outlets can have its own context, and it does have its own context. So if you pass some props, You're actually passing props into that context, and then you're using that via a hook that use, like, context.

And actually, I I I totally misspoke here earlier when I said that the loader makes the data available via props. It doesn't make it available via props. It makes it available via a hook. My apologies on that one. I know that. That's like a a bit of a caveat. Oh, yeah. And then you use the use loader hook? Yeah. You use the use loader hook. So, Hooks hooks are a big deal in in Remix, and you end up using hooks for just about everything.

It's that's really cool because I was looking at it. I was like, but how does it know What I want. Yeah. And I was like, oh, because it's called loader. You know? Like, it because there's a convention that it's called loader and you export it. Gatsby does this as well, as you just export the query from the page and then it's just available to you because there's a convention. You don't need to specify, what it is. Yep.

Yep. Yep. Yep. It's all pretty cool. What else we got here? TypeScript support. Very good. Baked in. Baked in works out. To do anything. Yeah. Any other gotchas?

All of the types where they're available to us, you use the whole import type syntax, so that's really nice.

The the only gotchas that I really had of this is like a minor gripe. I've I've I've talked about it on Twitter a little bit. But if you're if you are choosing to deploy some way. You kinda have to have that worked out ahead of time. When you first start your project, it asks you where you want to deploy Because there's, like, several config files needed for each deploy target, and those are all community based. So it's the the remix Team isn't building in all these deployed targets. It's like there's a Vercel deployed target and a Netlify one, but those are all sort of like community solutions in terms of, like, There's all these config files, and it's not necessarily easy. And there's config differences in the the Remix config file. It's not easy If you've chosen, I wanted to play with Vercel at the very start to then say, oh, no. Wait. I wanna deploy with Netlify.

The easiest way right now to change Is to literally create a new re remix project and drag and drop the files over.

That's the easiest way. You can't just, like, copy paste from,

Like an example? You can, but there's nothing special about the remix code that you write that's Nothing special about the remix code itself. There is differences in the config file, And then there's the platform specific ones. Yeah. But there are some interesting caveats to that where, you specify the build directory, you specify how that build directory is deployed. And so, like, Netlify itself has kind of like a, a little bit more complex of a platform to deploy to. So because of that, you have some more complex deployment code for that. Yeah. And you can copy and paste it, But they don't make that available to you anywhere right now. Yeah. So, like, you could create a new empty project, pause through that project to see what files are there, And then copy and paste and move those over. But, I mean, there isn't, like, an easy way. There's not turnkey necessarily.

Cool. I bet I bet that'll be something that That gets changed in the future because of,

how much of a pain it would be. Yeah. I I know they they kinda said they don't wanna get too involved there because it's like, I mean, it's not their their thing to to play on these different platforms.

That's one, like, huge benefit 2 remix over something like Next. Js, in that, like, Next. Js works awesome, and it's serverless and beautiful.

Au deploy it to Vercel.

And then, like, I've taken a Next. Js app to other hosts and been like, okay, like, how do I make this thing serverless but also host it on your platform? And it's always just been like, Well, like like, finally, what was it? Netlify got it working, but they had to do a whole bunch of work on their end just to make it Yeah. It works like that. Right? And because Remix is just

I guess they're all open source, but Remix is just like, alright, anyone can host it, but write your own way to Put this on your platform. I think that's pretty neat. Yeah. I mean, you can build a straight up node app, and it's like, if you wanna just deploy a straight up node app, That's, like, way easier than working with some of these serverless platforms that have their own functions and config platforms that are, like, a little bit more complex to deal with.

And so, you know, that that's where any of the complexity comes into play. I found it exceedingly easy to deploy to Vercel. It was super just nice and nice and easy to get it up and running. That's really I I did it to Netlify and Vercel. I had some issues with Netlify, but I would imagine that was because I didn't choose it from the start, and I was kinda trying to copy and paste here and there. And it wasn't like that that turnkey, but,

Vercel was super easy, and just building a straight up node app was easy too. So Beautiful. Wow. I'm really glad that this is here. I'm really glad that we have another option now to to work with stuff seems like some pretty interesting like, I know that it was in the works for so long, and I bet that a lot of that time was not just building it, But just, like, sitting around scratching your chin, being like, how should we approach these type of things? Because this it feels like it's not like a It's not a hard thing to learn how to code this thing. If you're learning Remix, you have to sort of understand the ideas and the fundamentals behind building a Remix application because it's it's pretty neat. Yeah. Once you get the handle of here's where

I get my data, here's where I handle, post requests, here's where I write my components, those types of things, that's like the majority of it. Everything else feels very much like any of these modern platforms we're working in, and I'm very, Very, very confident that we've missed a ton of stuff. We didn't talk about MDX. We didn't talk about, oh, optimistic UI or resource routes or a whole ton of stuff. So if you're the type of person who's like, well, what about this or that or whatever? We'll probably be talking more about Remix. Yeah. It'd be great to have Michael or Ryan on either of them. So We'll do that. We'll be talking much more about remix, and I'm sure we'll be diving into more of that as we evolve here. Because this platform's some truly great, and I I would imagine it is here for good based on how cool it is. So Alright. That's it. That was a tasty hay, Steve, thank you so much for tuning in. We'll catch you on Wednesday. Peace. Peace.

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