📧 ⬇️ Don't Miss When We Go Live! Sign Up Below Now! ⬇️ 📧
Transcript:
Scott, why don't you go ahead and kick us off. Yeah, sure. All. Like I said, welcome to JavaScript Jam. We do this every Wednesday, 12:00 PM Pacific Standard Time. And it doesn't matter whether you're a beginner or you're an advanced user of the web technologies, you're a developer here.
You know what we wanna hear from everybody, so feel free to, Understand this is like an open mic kind of atmosphere. We love. That actually just creates some really awesome conversation. Things are very authentic. But yeah, feel free to request to come up. We'll be more than happy to have you up, ask questions of Alex or Anthony or Ishan myself.
And also maybe state an opinion or a factor two, whatever you want. It's up to you. So we'd love to hear from you. With that being said my name is, Scot Steinloge, and I'm a technical community manager at Edgio mc of JavaScript Jam.
Go ahead Ishan, I'm Ishan I'm the VP of product for the applications platform here at Ed g o which offers cdn security and JAMstack like hosting for, the largest sites on the planet. And then Anthony, I'll let you go. And my name is Anthony Campolo. I'm a developer advocate at Edgio, where we serve 4% of the internet, is that right you, Sean?
That is correct. Yeah, you probably use it and don't even realize it. So yeah, I'm super excited to have my good friend Alex here with us from the dev server and general contributor to awesome open source stuff. Howdy. Yeah. I'm Alex. I actually live in Boston right now on the east coast of the US and I work for Echo Bind, which is a full service software development agency. So we do design strategy and development and I am working on building apps for clients. So yeah. That's fun. Very cool. We should, sorry. Yes, you're gonna be speaking at Remix.
We should maybe pause and talk about what we're doing with Remix. Totally. Because like last week we had Kent next week you guys are gonna be doing something exciting over there. Maybe we should just pause, let people know about that and then we'll talk to Alex about his talk that's gonna.
Awesome. Yeah, no, a hundred percent. So last week, yeah, we had Kent on here and we were talking remix and all the exciting things there, why you don't wanna miss out on remix. So we're doing this little collaboration with them because we love them and had a great time there last year, so we wanted to be a part of it even more so this year.
And so that's what we're doing. And just basically bringing on some of the speakers Kent is actually gonna be speaking there too, not just organizing. And also Alex here is gonna be speaking there as well, which is exciting. He'll get into maybe a little bit of a sneak peek into what's going on there with him when he is at the event.
And we're just very excited for all that. And we're actually gonna be the the formal, official. Podcast at the event there. We're gonna be doing a live podcast at least at the after party, which is actually the first night. Which if you heard last week, Kent was talking about how it's gonna be the after party.
You can actually remember it's gonna be a good time. They're giving out free milkshakes and like board games and all kinds of stuff. So lots of fun networking opportunities there. So if you haven't gotten your tickets yet to remix, please go check it out and get your tickets and you can actually get a discount if it's three or more folks by using, do you remember the code, Anthony or Ishan by any chance?
Negative. Negative. We'll throw it in. Sure. It just Team, team. That was it. Yeah, I think you're right. Either double check and.
So if you can't make, so make it remix if you can. And if you can't tune in next week and hear from it. Live on the floor cause exactly. We'll be live they're in the after party speaking with some of the speakers and you can take the opportunity then to ask questions of them if you did partake and you're there.
So we're gonna have a live audience there. It's gonna be fun. Hundred percent. It's gonna be really good. And then also yeah, hit us up, come find us. Anthony and I will be there and we're gonna be conducting podcast recordings as well for future stuff. And yeah, just love to hang out with you and see you.
So feel free to come and say hi to us. Alright. Oh, by the way, one last thing. Sorry. I would, it would probably behoove of you. To go onto our newsletter and sign up. So go to JavaScript javascriptjam.com d I'll go ahead and drop the link for that. I'm also gonna drop a link for the lunch dev server already.
See we got good Buddy Roman here in the, with Roman. My favorite Discord servers is one of the ways that Alex and I gotta know each other, run by the Michael Chan from React Podcast. So for anyone who wants a really cool developer discord, I highly recommend this one. And t is also in there as well. Yes, it is a pretty cool discord.
Awesome. Shall we get started? Let's do it. Let's do it.
Alex, first of all, I do have one question for you. What are most excited for remix? For remix itself or for remix comp remix Conference. Yeah. Yeah. I'm sure I'd say both remix too. Yeah. Yeah, absolutely. Ok. The comp itself I'm excited to speak. I love speaking. It's just love hearing the sound of my own voice.
But I love to share things. I love to talk with people, get inspiration, that kind of thing. And I don't use remix professionally only for side projects, so being able to see it here, what other people are doing with it is pretty great. So it's like that classic. What's the best thing about working at such and such place?
Oh, it's definitely the people, but it really is, I think Remix has a good community that's focused on good things, good performance for everybody. Progressive enhancement across the board, making it so that you don't have to have a beefy smartphone or computer to run websites. To have websites that work well.
As for remix itself, your guess is as good as mine. I have no idea what's happening with V2 or the hinted at V3 that's coming up at some point. So I imagine we'll get some juicy details from the keynotes at Remix Comp about those things. Absolutely would not surprise me if a V2 beta dropped at remix Comp and then they've hinted at V3 having some really cool new changes that are gonna make everything better, and I'm just like, awesome.
It's already pretty good, so if they can make it better, great.
Yeah, so one of the changes compared to last year, remix is under. Now the Shopify umbrella. When you heard about that, I'm curious, as somebody who participated last year and somebody observed the three makes ecosystem, just what your thoughts were and reaction when you saw that, and how do you think that's played out?
Oh, I've got friends that work at Shopify before remix was acquired. I actually, I guessed that was what was going to happen about a week ahead of time. Messaged one of my buddies who was like, how'd you know that? I'm like just heard it on the wind or something. And I'm jazzed about it.
I think Shopify has shown they're very good stewards of open source with how much they contribute back to the Ruby ecosystem. And that has, they have not disappointed with their stewardship of remix so far. I had a chance at a chance to talk with Chance Strickland when he was still at remix before the acquisition, and he was talking about how Michael Jackson was just so overwhelmed with c e o responsibilities, he couldn't focus on the technical and strategic parts of remix, the framework itself. So the fact that Michael is now no longer c e o, he doesn't have to worry about those things, means that he and Ryan can focus together on guiding the framework forward.
And we've seen that with their focus on opening up everything having their open roadmap sessions that they've been doing on YouTube, which has been really great. Yeah I was optimistic beforehand and I think my optimism has paid off the that's really months.
Yeah. We introduce as being at Echobind previously bit more background, which.
May already be subscribers to or familiar with. You put out the Bytes newsletter and you did some courses that you authored. Do you wanna tell people a little bit about that? No, I think you said everything that needs to be said about that. Why don't you tell people the courses that you authored?
I made the Type Script course and the type script with React course. Okay. And the React Query course. Very cool. And if people wanna see those, where do they go? Ui.dev. Okay. You heard it here first? Yes. This is Tyler McGinness company. You were working there before Echo and did quite a lot of work there.
Yes. And when you create, like, how much time do you have? That's a very content-heavy, role at Echo Bind. It sounds like you're doing more day to day engineering. Do you still have time to, to create content and. Yeah that's a good question. You write a lot of blog posts. I do write some blog posts.
Yes. And a lot of the content that I write is staying internally. So we have an internal R f C process for making decisions about pretty much anything at the company. Actually, anybody could submit a an R FFC and try and enact some change with the way the company runs, which is nice. We're only about 30 people, 40 people somewhere there, so pretty small.
So yeah, I've been shaking things up since I've been at Echo Bind. One of my blog posts, which has probably done the best, is it was titled Why We Dropped GraphQL for T R P C. And in it, I basically just outlined what GraphQL is good for and why that's not what we need for our clients and why T R P C works better for us.
Not that GraphQL isn't good, it's great. If I was in a situation that I'd need it, I'd absolutely reach for it. But T R P C is also great. And it's also recommended worth mentioning that within this blog post you're talking about how bison migrated from graph huel to rpc. And I think this is like a super, super interesting topic area to get into, but we'll be quite a huge diversion.
So we might wanna put a pin that before we get into your remix talk. Yeah. For context bison is the, it's basically a boiler plate that we use at echo bind first, starting up our projects. So it includes Njs, Prisma T rrp C now, and my most recent, I haven't written the blog post for this yet, but we recently migrated from chakra UI to Tailwind with.
An encouragement to use the shadn UI components which is just fabulous work. I was doing research into how to build a reusable teamable configurable component library with Tailwind, and I just kept getting stumped. And I thought to myself, the only way you can do this is just by copying and pasting each individual component into your project so that you can edit them individually for projects as you need them.
Having it from a package just doesn't work. It's very difficult to override and configure things while still making things work with tailwinds just in time compiler, and I've had that thought around September of last year, and then January shadcn/ui comes out and he's check this out, and I'm like, it's everything that I ever wanted and I didn't have to build it myself. Perfect. I'm such a lazy cuss. So if you haven't checked it out yet, if you're a fan of Tailwind and great UI libraries that you can configure yourself, check out shadn/ui. I know we're talking about Remix. I use njs mostly in my work at Echo Bind, but shacn/ui works great with Remix as well.
So that, are you saying shadn/ui? I can reply to this, right? I just in the can tweet that we can put on jumbotron as we say.
Cool. But we should while you're doing that I know that you speaking about remix live loader, this is bringing real time to remix. So this is something that I know a ton about. I have not done a lot of real time programming, but I know something that you're pretty experienced and not you do streams and whatnot around these types of things.
so what was it about this topic in particular that made you wanna give a talk about it? Yeah, I just think that more apps should have real-time capabilities. And it is complicated. It's not an easy thing to add, especially as your app scales. Most of the demos that you see use nodes event emitter which works in memory and is really great if you have a single node.
But if you're doing anything with distributed servers that need to talk between one another to let one know that, hey, there was this realtime event that just fired or some serverless providers, I think Lambda now supports realtime some way. Yeah. Lambda a type of streaming, which I can only imagine is an extremely hacky way of getting it to work.
Cause Lambdas not meant for that, but it sounds like AWS was like people asking for we're gonna it in there. Exactly. And I don't know if Edgio has anything like that. But that's, it basically adds constraints to your app. You either have to add an expensive third party service to handle all of that for you, which is a perfectly fine solution.
And my live loader thing that I, and actually you actually can do that with it if you wanted to. Or you have to set up your own infrastructure with some kind of pub sub system in Postgres or Redis or whatever, and then make sure that everything's taken care of. Let me just start at the very beginning.
All of the stuff that I was gonna shove into my talk that I can't because I don't have enough time. I'm only giving a five. Yeah, you got as much time as you need right now. So luxuriate in it. Yeah.
So the way I see it, there are three things that you need to do any kind of real time. The first is some kind of pub subsystem.
Some way for you to tell your server some realtime event happen and you need to notify clients about it. So that's the event emitter in no js, if you're doing just a simple demo with a single server you just fire off an event to the event emitter, and then it triggers all of the listeners and those listeners are able to Respond to that.
And usually that responding means sending a message to a client via the second part of any real time, which is the transport mechanism. How is it that the client finds out that the server wants to send them a message in the first place? Typically, you think of like web sockets http long polling is another option, and those are the two methods that socket.io wraps together. Where it falls back on long polling if your browser doesn't support web sockets. But every modern browser supports web sockets these days, so Cool. But then another technique, which I didn't know about until the remix team started making it more popular, started talking about it, is server sent events.
Which is basically A way for a server to keep a, an HTTP connection open with the client and just send messages down whenever it wants. It's like web sockets, except it's unidirectional where the server is sending messages to the client. Whereas web sockets are bidirectional, the client can send messages back to the server.
In most cases though, server sent events work great because the client can still send a post request or get request to the server to let the server know what's up, and then the server just trickles down messages with server sent events. And let's see. The one big limitation of server sent events is if you're on http one, you're limited to the number of connections.
That you can maintain http connections. You can maintain your browser. Pretty much all modern browsers cap it at six. But if you're using http two or http three, then you can have as many as you want. You don't have that limitation and service and events work for everything. So if you're using Remix, I recommend that you use server Scent events because with the Remix Utils package by Sergio, I actually don't know Sergio's last name, but he's very prominent in the remix community.
He built Remix off and remix Utils and just his great helper all around. Anyway, remix Utilities has utilities for client and server handling of server scent events, and that's what I'm going to demonstrate in my talk.
And then the third thing that you need, you've got your pub subsystem an event emitter or Redis or Postgres or some other pub subsystem. You got your transport web sockets, HTTP long pulling or server sent events. And then the final thing is, what does the client do when it gets the message from the server?
What kinds of messages are you sending and how do you want the client to respond? So your options include just popping up a notification. It's just a one and done. The client gets the notifica tion the message from the server shows it to the user and then forgets about it. Or you could make it. So it's a, an invalidation token where the server just tells the client, Hey, you need some fresh data.
I'm not gonna give you that data, but you can get it yourself. And then if you're using remix, you call You use the Revalidated Hook in order to invalidate your data and fetch from your loaders. Again, if you're using React Query, you can use it to invalidate whichever queries you think need to be invalidated so that they can be re fetched.
If you're using Next App Router, you can use the router re fetch method which re fetch is all of your React server components. So that's one option. And then the final option, and most most elaborate is actually getting into your data. Having the server send data, like a whole chunk of data down with the message and using that data to update some kind of client side cache.
I'm not sure how you could do that with Remix or Next JS app router because they don't expose their cache to you. But with React Query, you just use the set query data method to update the data however you see fit based on the message.
Okay. That was that was a lot of stuff. We also brought up Ellery here.
He's someone who works at Edgio. He was slacking me about some stuff about this. And so what I would kinda log into is like you had mentioned that there's not a lot of good tools to do this, it looks is kinda pushing back and pointing at some things like pub nub. Yeah. Yeah. Signal are. So yeah, let's let's bring him in here.
I'll go ahead and speak for myself so you don't have to do that on my behalf. So as Anthony mentioned, I'm El I also work at Ed with Anthony Ishan and Scott. I actually had some experience in this space cause back in 2020 I worked on a project where a client of mine had a need to support live events.
Like they had a legal contractual need to do that for some of their customers. It was a really weird industry. It was voting for unions, right? These unions have an obligation to let people vote and, hear speakers and so on and there's into it, but get together and so was we have to have live streaming platform that has live chat, live voting, live polls, all these things with like full audit trails, et cetera.
So we started looking at this problem. We were using React. It's oh crap, how do we go build this? Cause I need to be able to persist all these messages. I need to be able to like, have waiting rooms. I need to be able to, start a poll or start a vote on an issue or on a motion, and have that end in a certain period of time.
And we learned a lot of different tools including building our own Azure Signal R with the second place winner. It had a little bit more setup than we wanted it to, but we ended up going with PubNub, which is this general purpose. You can think of a general purpose stock IO project where they give you a client side library, they have one for React, is what we use.
And basically you can create streams of data and people can subscribe to those and get messages and they can publish and there's full rback and everything else built in there. So we use that to build like all the voting and poll information as well as live chat in the app and even build some sneaky things cause many of the users were not very competent, like they had it issues.
And so we built some fun stuff where we could like forcibly reload their pages with, without them giving consent, which is kinda cool, but I just wanna call out that there are some tools that do a lot of this for you to the point where you don't need to worry about oh, polling open AE servers, like you install their SDK and let all the work for you.
And the pricing was fairly reasonable. There were two different options. One was based on volume of messages submitted and messages have a size limitation or the number of concurrent users. And for us, it turned out that like we could get by just doing volume based pricing and it was like, 20 bucks per event that we had to support these events at thousands of users and they ran for four or five hours.
Yeah, absolutely. PubNub is great. I've never used them before, but there are a lot of these real-time sass that are out there that take care of this kind of stuff for you. Under the hood, they're still doing those three things. They're still having some kind of pub subsystem that you can notify to let them know that some realtime event needs to be sent to clients and they have a transport mechanism for the client and server to connect them for the server to send messages down to the client.
In PubNub's case, they handle those first two things, and it's up to you to decide what the client is going to do with the message that they get. But if you were sorry to take this out of the realm of JavaScript, but apparently web development is still on topic. If you're in Elixir Land and you're building with the Phoenix framework, all of this stuff is just built right in.
They encourage you to use their live view. I don't know if they encourage you, but you can use their live view setup, which basically moves all of your apps reactivity to the server. And it sends any updates to the app to the client using web sockets with realtime. And that's just baked right into the framework, which is fascinating.
Then Sunil Pie is working on Party Kit right now. New Startup, which is supposed to make all of this really easy for you. You're able to, with just a few lines of codes set up these real-time rooms for sending these messages and I'm pretty sure he is building it on top of CloudFlare durable objects.
So it's really fast, it's low latency across the globe and is just really cool. But if you wanna do it yourself, if you wanna set up the infrastructure, I think it's helpful to, to have the context for how specifically you do that. These places, they've done that hard part for you, so you don't have to worry.
Yeah. So I guess kinda what are the trade offs that kind of come along with that? Do you feel like it's preferable to own it yourself? Or like what would you feel comfortable kinda offloading to a service? Oh, Anthony, you can't ask a senior developer a question that obviously is answered with it depends.
That's fine. You can give me what it depends on and then give me the, whether you do this when it depends on that. Yeah. I don't know what regulations or what degree of privacy you need to have for for union voting or whatever you might be doing for like a, I don't know, on PubNub's website they show this sports demo where you're watching Football and you've got live chat and reactions that are powered by their their systems for that.
Sure. PubNub sounds great. You could roll it yourself, but it's probably easier to do it their way. But if you're in healthcare and you're dealing with HIPAA or other government compliance issues, I don't know if pub nub is HIPAA compliant, I don't know what effort it would take in order to get set up on an HIPAA compliant enterprise plan with pub nub at some point, you just gotta say it's not worth it.
I'm doing it myself on my own infrastructure that I know is HIPAA compliant.
We got we got Jason up here with us. Long time listener caller on JavaScript. What's up Jason? Hey everyone.
Call these.
Yeah. Feel free to let us know what's your what do you got on your mind? What do you wanna, oh, I was just the realtime data communications syncing stuff is something I've worked on and off for a long time. I was just thinking about this topic elicit, like certain devs be like, Ugh, I've been there, I've seen some stuff.
I get my thoughts. Yeah, I think the, really, there's a number of challenges guys have already talked about. Next one being brushed on data synchronization. So if you're storing any amount of data in on the browser, how do you resolve conflicts? So if it's a simple use case like chat where you're not, You don't have collaborative editing of shared objects, then it's, there isn't any synchronization.
It's immutable objects. And then the, then it gets really interesting if you start doing, these multiplayer apps as they're, I think people are calling 'em now where you're editing you have multiple people editing the same objects and there's a number of different camps.
Who's the data blocks? What's or what's the one that Vercell's really into these days? Is it data? I'm just having a brain fart. Yeah. I'm forgetting too. Databricks. No that's the AI one. Yeah, it'll come to me in a minute. But then you get into, things like, do you use YJS?
Which is a crdt. I think we've talked about this on previous spaces, so shared document model where you can build things like Google Docs where you've got multiple people editing a highly concurrent object. But that's, that might, there's probably gonna be overkill. And then there's does the server own the data or do the clients own the data?
So there's all these kinda other things that pop up as you start to think about on top of the, oh, the overhead and complexity of maintaining and scaling socket servers. It gets pretty gnarly pretty quickly, which is why hopefully one of these other solutions will have a nice edge function equivalent easiness and deploy of a Edo or a Vercel to deploy your React app.
With web sockets, it really hasn't, really, hasn't happened yet. Yeah, I would keep your eyes peeled on what Sunil is doing with Party Kit. Yeah. Party Kit. That definitely looks really interesting. Very. And he's already got support for Y J S I. I'm not sure if he has Auto Merge. Could we give like a tldr, like what is Party Kit?
Yeah. Party Kit is, it's described as an open source platform for collaboration. So you basically just apply, you, you just use a very small amount of code to set up some web sockets on your server and then all of a sudden your clients can send messages to the server and the server can send messages to the client and you add all of the necessary logic for how you want all of that to behave.
It's is fully managed and deployed to the edge so you don't have to worry about your own servers and.
It's fast and battery's included. It just, the idea is it's serverless real time that's really fast and easy to use. Yeah, and I think it's interesting how you're saying he's built on some CloudFlare stuff. He was working at CloudFlare for a bit and I feel like that's why I usually trust that a service is really useful.
When someone worked for a giant deployment company, saw an issue with it, tried to fix it, realized that there's bureaucracy and then jumps to startup fix, that's patterns a sign, they're onto something. Yeah. And Sunil is very thoughtful and and humble and definitely going about building this in my opinion, the right way.
Another interesting thing about it is open source it's github.com/party kit slash party kit. Find all the code right there for sponsors. No it's open to everybody. Is it open though? Oh, I thought it was sponsor. Okay. It was sponsors op only he opened it at react Miami. Oh, cool.
Yep. The the other one I've used I think it's by the creators of the Y js project. It's called Hocus Pocus. It's another MIT license. It was a sponsored only project for about a year. And I think they, they open sourced it or took away the sponsor barrier probably six months ago. It's another, it's a web socket endpoint.
Server for Y js documents that plugs nicely into their kinda the y js ecosystem. So if you have an application that needs to go all the way to a fully conflict free replicated data type that you need something like y js then a good off the shelf backend that you can run yourself is hocus-pocus.
I've got a couple of projects using it right now. Yeah, slick. It looks like they've got support for path and persistence and Yeah. All kinds of fun stuff. It's relatively, I should probably just flip the, I've got a little open source or I got a little repository that's an example of it that I should probably just flip the switch to open source.
It is it, you can plug in your own database, so whatever database you use, it's got some callbacks that you implement. Okay. Here's, stuff data here, and then an off hook that lets you, it's if anybody used Socket io back, way back in the day where you just implement your own little middleware for off and that kind of stuff.
It's very similar. And, but then it has the downside of you get to host it yourself. Which may or may not be a hard thing for people. Yeah.
But it's literally I've got a, maybe 10 lines of a node js script on top of their library. And I've now, I've got a functional authenticated backend for, fairly decent sized shared data app. Scott, you wanna do a, all this talk about rolling your own stuff?
Oh man, you're, you got some distortion on your mic right now. Do I? Is it? Yeah. My better now. I'm
Sound like you're in a AER right now. Oh, that's awesome. Alright, I can do a station break, so if you've gotten value, anyone here on stage, go ahead and follow. We are about remixer right now, Anderson, and while we bring it back to your talk, is there more you wanna speak about remix live loader specifically that we've not hit on?
Yeah the hook itself do it, it's.
The way that I've implemented it, I wanted it to be as trivial a developer experience as possible. I don't want to have to mess around with anything complicated in order to get this to work. And so the API that I've landed on is a little weird, but it works.
And I don't think I'm ever going to use it in production necessarily, but maybe it will be inspiration for other people. That's the whole point of the conference, right? So my event emitter itself, the events are actually routes. So I have an event called slash which is going to be triggered anytime data needs to be updated for the index route.
And my example is the remix realtime template, which is a linear clone. So an issue tracker. So I have another event that I can fire for slash issues slash and then an issue number, which is going to be fired anytime an individual issue has been updated. So I call update issue and it's going to trigger those events because the issue appears on both the index page and on its individual issue page.
And that's going to trigger my server sent events. I'm using server ent events in this case. And the way that Server sent Events work in remix is you subscribe to them at they're resource routes. They're basically loaders that your app can request, that they can connect to using the browser-based server scent event APIs.
Again, I'm using Sergio's remix utils for this, so it, it's all abstracted away in very simple api. And when I'm subscribing to these, I'm actually using a splat route on my server sent events loader, and on that particular route. So I can do slash events slash issues slash and then the issue number.
And that's going to subscribe to any events that happen for that particular route, for that issue that I'm on. So if you follow where I'm going with this, whenever any of those events happen, I'm going to just send a timestamp. It could be anything, it could be a random number. I'm sending a timestamp down to the client as an indication that it should revalidate its data.
And that's all that I'm sending, I'm using that, that second method of just let the client notes that it, that its data is out of date and the client can handle updating its data however it wants. And then on the client, I have a special custom hook called Used live Loader, which wraps remixes built-in used loader data so that I can use it to get the data from the loader itself.
But it also is going to subscribe to the server sent events endpoint for that particular route. And when it gets the message from that server sent event, it's going to call the revalidate function, which is going to update all of its loaders. So in practice, the way that it works is I, you have your friend sitting beside you looking at the issues index page and you're on issue an in an issue details page, and you rename that issue that triggers the action to the server, which is going to fire off your event emitter.
It's going to fire two events, actually one for the issue page that you're currently on and one for the index page that shows that issue. That's going to go over to the server sent events loader where both your friend on the index page and yourself on the detail page are connected. Currently receiving server sent events.
It's going to send it's going to recognize that you're connected and get that event message and send each of your clients the current timestamp, which is going to signal to your clients that data has gone out of date. And you need to update, and then you'll call the revalidate function, which is going to have both of those browsers request the loader data from the server.
And now both of them are in sync. And a cool thing about remix is the fact that if you're running a loader and then you call the revalidate function. It's just going to cancel that original request and send a new request. So you're never going to run into race conditions with this. It's always going to give you the correct data because of the way that they've engineered it.
Now, one thing you might notice is this is if you have a lot of clients all connected at the same time, they're all going to be requesting from your server at the same time. So please set up some kind of LRU cache, some kind of server side cache to make sure that you're not gonna be completely hammering your server with all these requests.
But for as inelegant as solution as it is quite simple and gets the job done, hopefully without being able to actually see the code. All of that made sense. If you want to see the code, watch my talk at I think it's 1130 Mountain Time next Wednesday. Let me double check the schedule.
Awesome. We got someone who has a question. Let's add this person up here. Hopefully they're not a bot.
Hey hello. Hi. What's up? I had a question on of course we have to be careful on how we design loaders with three, especially because it's gonna fe everything. So you have loaders on one page. That's probably not like the most ideal way to design the application. But ever since Remix came out and at Tesla, I'm actually trying it out on one of our internal applications right now.
I'm wondering what is the future of a library like React? Is there still space for it? Or, would this be something that we can handle with just remix cash invalidation with designing our loaders in a much more simpler way? Great question. React Query is fabulous. If you were here at the beginning, I wrote a course about React Query.
I love it. And Tanner is a good friend of mine. There's absolutely a place for React Query, even in remix apps. I think that Remix provides a lot of tools that give you reasons not to use React Query. And if your app. It doesn't have any additional reasons why you'd wanna use React Query, then just use Remix.
It's great. But React Query absolutely is a powerful tool that you can use with remix. In this case, you probably want it to, in order to support server side rendering, you would want to have your loader data be passed into React Query as initial data. Or if you want it to be really fancy, you can serialize the cache in your loader.
But I, I don't know that would work super well with Remix. I haven't thought of a good way to do that yet. So you've got your, oh, go ahead. No. Okay. That makes sense. Okay. Feed the output of your loader as the initial data for your React quality. Ok, that makes sense. Yep. And then with the real time, Instead of re-validating your loaders, when you get that message, make it so that the message includes any data that needs to update in your React Query cache so that gets sent from the server to the client and then the client is able to go in and surgically update the React query cache with use query data in order to update whatever needs to be updated based on that real-time response, and then the cash updates, and that updates all of the queries that are using that ache data and your app updates and it's wonderful.
Okay. So that's one extra layer of defense, because typically when you start building applications, it's all very simple and nice. But then with enterprise applications, before you know it, now you have 10 lowers on your page. And it's not because any engineer is intending to do or design things that way, it's just when you're moving fast, it just ends up happening like that.
So I guess React Query can be thought of as like an additional defense on your UI side to have some sort of control rather than remix just doing okay, we're gonna just get everything for you. Yep. Remix a solution is great and it is going to solve those race conditions using React Query.
Might your data might get out of sync or might get munged in a weird way just because it does give you direct access to the cash. But that direct access to the cache gives you so much power. But you also lose out on some of the benefits of remix, like the way that they handle caching or you have to roll optimistic updates yourself.
So they're trade-offs, but React Query, like I'm using React Query in a next JS app, router app right now with React server components. And it's a little weird, but in my case it works great because there isn't a great way to do infinite scrolling with react server components with App Router yet.
So this takes care of that for me really nicely. Yeah. Thank you. Anything else? Nope, that's all. That was the question. Thanks. Yeah. That's actually all that I have to talk about my talk. So if there are any other questions about the talk, I'd be happy to talk about them or if we wanna talk about anything else I'd be curious to talk about, you mentioned app router a little bit.
What are your thoughts on current Next JS world? Yeah. I, it's a shame we're not having this conversation tomorrow cause I'm pretty sure there's gonna be the mutations RFC that's gonna drop tomorrow as part of Vercel's ship week, which, cool. It's Vercel week. Awesome. You should you should.
Let's, what is that and why they should have their eyes peeled for tomorrow Now Vercel's doing a good enough job of that. Basically, app Router was first announced, its beta for Njs 13. It was announced in October. And it's the first real serious implementation of React server components. And it's still very much, I would say it's an alpha by my definition I say alpha is anytime you're missing features, whereas beta is when you have all the features you intend to have, but it's probably still buggy.
So a App Router is not there yet. You can use it, you're gonna be on the bleeding edge and everybody knows when you're on the bleeding edge, it's you that's bleeding. So the big thing that they're missing right now is some kind of mutation api, some way for you to tell the server to change some data. And they have alluded to an upcoming mutation, R F C, in their app, router docs.
And it was mentioned in the most recent react.dev blog post about how they're working on making it so that you can do form actions and have server actions that are like a magic R P C. That's being built into React server components. And I think as part of this Versace Ship Week, they're going to announce that tomorrow for the keynote.
So I've actually really wanted to do an RFC at my job to recommend that we either switch to, cuz all of our apps currently are using the old pages router in next js, which is fine. It is the recommended way of doing it if you don't wanna be on the bleeding edge still. I wanted to recommend should we go with the new app router in Next.js or should we switch over to remix for future client projects?
But I can't do that until Next.Js announces their mutations api because otherwise remix is gonna win because actions are just such a nice API for. For taking care of so many things all at once. It takes care of updating your data, reloading your loaders, optimistic updates error handling, all kinds of great stuff, just all built into a very nice api.
I'm hoping that we get a similar experience with App Router and that it gives remix a run for its money. As much as I love remix I work with Next.Js at my job, so I want Next.Js to be good too. Is that a hot enough take for you, or is that too tepid? No, that was great. That was all good. Contact people who are not super duper deep into this world.
We got Bronifty coming up here. You got some thoughts you wanna throw in here? Oh yeah, you just queued me up with the people who are not super deep. Bronifty, which is me. Yeah. I'm not super deep in it. No, but just kidding. Yes. Thank you, Anthony. Yes, I did. Newb questions are always welcome. Thank you.
As, as well. I did have a question actually to our dot r Alex yeah. So do you know exactly what is the value prop? Had some back and forth with Dan and some other people from React and the general ecosystem. And do you ca, do you have a nice takeaway of what the value prop is of the next app router with rsc you can just drop in?
It's something about hard coding, the routing to in with, so like we have loader in action, it's like hard coded. To the router and remix, right? Where you have at the base of the router where you're making your server calls. Whereas I think the value prop of RSC is you can just drop the server calls into a nested somewhere nested not at the root of the route, but somewhere nested in there or something.
Is that your kinda general takeaway of what the value prop of RSC over something like remix standard, loader and action type of thing is, yeah. I don't have as good an idea as many of our peers. I would say Ben Holmes did a lot of work with this whiteboard of the web.
That guy definitely check out his stuff on React server components and we need to make a distinction here. React server components and the app router. Are a little different. App Router is an implementation that uses React Server components. So if we're talking about just benefits of App router itself, you get nested layouts, you get interception routes, you get parallel routing, all kinds of stuff, which really wasn't possible with the pages stuff.
That's all awesome. React server components are a major part of that but they aren't tied to the app router itself. Remix Kent recently said, in fact, I think it was on this very podcast, that he is very confident Remix is going to support React server components someday. So the benefit of React server components as compared to remix loaders is that remix loaders only load at the route level.
But if you have nested components inside that route, all of those nested components, data has to come from the parent route. And you can do nested routes. So you get those parallel loaders all happening at the same time. But you can't load data inside of an individual component without either passing it from the loader or doing network waterfalls by loading on the client.
With react server components, each individual component can load its own data. And all of that data loading is done in parallel. You have no network waterfalls. In fact, if you go back through Dan Abramov tweets a little bit, you'll come to a poll where he basically does some quizzing on how you expect React server components to behave and highlights some of the surprising benefits that come from React server components.
Yeah, just to just actually fit, put a button on this, I think the most unambiguous implementation of it, although it's a lot of work to do it. I believe the relay GraphQL meta, formerly Facebook implementation of it is, has been using this for a while through the use of I forgot what it's called.
It's like a template or it's a partial fragment. Scrap QL fragment. Fragment. Fragment, yes, that is, yep. That is the, I guess all of this that we're implementing in next, the app router and waku work Adam Kato thing and which was used by. I can't remember his name cuz there's too many things to remember at once.
But yeah, what you brought up, whiteboard, the web, all of that. I believe the genesis of it is the is the, is what we just talked about, the GraphQL implementation. So if we went, if we really did all sit down, do the work and went from beginning to end through that, we'd probably have a really good idea of what we're trying to re-implement in a framework, like a meta framework like next or whatever is happening there.
So anyway, thank you for your input there and you answered my question. Absolutely. I wanna highlight one other benefit is streaming remix has streaming through Defer and the Await or awaited, I can't remember the exact terminology, but they've got streaming responses again tied to the router itself.
App router lets you do streaming per component. So I had a situation where below the fold I had some data. That I knew was gonna be a little more expensive than the rest of the data for that particular component. So I ripped that section out into its own server component that loaded its own data, separate from its parent component.
And then I wrapped that component in a suspense boundary. And now it's going to show the suspense boundary until the it's first gonna load the whole page with a suspense boundary showing the fallback. And then as soon as that inner component loads its data, it's gonna stream in that data and show up just fine.
But I thought in remix, if you have a nested small component, you can have a loader inside of it and ensure that is like a pathless route so that a user cannot directly access that particular component on the page, but it's hydrated on the page. Yeah. I've never tried that before, but that sounds, that's actually something I'm gonna try out with my teammates.
This, like within the next week. Yeah. Yeah. So a pathless route. So it's still a route, but it doesn't add to your URL and it gets its own loaders. It still isn't as convenient as just breaking it out into its own component. But then again, react server components are really annoying because you can't use any client side JavaScript in them.
You have to break out any client side JavaScript into their own components, into their own files that have the use client directive at the top of the file. Otherwise, next is gonna complain at you. But it's something that you get used to. It's just a convention that you become familiar with and then you get used to it, and that's just the way that you do things.
Yeah. Very good idea though. I might have to try that sometime.
I like your point. You're talking about, the normalization of streaming into the frameworks now. So instead of waiting for all of your data to get loaded, you can incrementally update your client as the data is streaming back from the server. I'm glad to see that become more normalized now that it sounds like next is starting to try to figure out how to make that easy instead of the, instead of their framework.
And that remix has had it for a while now. I think yeah. Very relatively a while. I can't remember who got it first, but it's become table stakes these days. I think like with everything with Remix, it's everything that's old is new again. Exactly. Taking advantage rem.
Yeah. Yeah, that's one. Try community. Yeah, I'll try to stay off that third rail. But yeah, the ability to do streaming, like server events and just straight up long HDP requests to stream back. Even HTML has been around for decades or almost, since at least a decade now.
But having that be part of normal things that everyone has used, usable user interface as opposed to being some crazy hack that you had to know some mystic voodoo amped or to no existed. I think having, bringing those kind techniques back to the, and making them easy and kinda normalized is always a good thing.
So ab. Absolutely. Just put more tools in our toolbox. Give us the power. That was one of the big themes of last remix comp is remix gives you levers and you can choose how much you wanna pull. Sweet
Anthony, what maybe you might not be able to hear Alex, cause I think he was mid-sentence when you, oh man. My freaking Twitter spaces is just going totally nuts right now. I'll just please continue. Continue on. That was basically the end of the thought. Thanks for sticking up for me, Scott. Yeah.
Okay. He said that was basically the end of the thought. It's all good. All right. Anthony has jumped in and out at least probably four or five times, and he was having issues and obviously he's still having issues. Thank you. Twitter spaces. Never a dull moment here, folks. Absolutely. Never a dull moment.
With it being the hour here I don't know we could probably just kinda call it here and just wanna thank everybody so much for showing up. Does anybody have anything else they want to say before we, maybe a question or opinion or a fact or whatever it might be? About anything that was just discussed, maybe any last second questions for Alex or I did have anything like that.
I did have one thing. I finally got rid of my brain block. It's.
They've been around for a while now. It looks like they've increased their product footprint quite a bit since the early days. So yeah, it might be worth checking out if you gotta do realtime data sync stuff. Great. Lots of great tools out there. I just wanted to see, thank you for giving me the space to ask couple of questions.
Yeah, absolutely. Fabulous. These questions. Thanks for coming up, man. Appreciate it. You created some awesome conversation. In fact, that's what we tell everybody every time we come here. This is an open mic atmosphere. We love it when people come and request to come up. Whether you're a beginner, whether you're an advanced user, it doesn't matter.
Developer, we want to hear from you, ask questions, opinions, facts, whatever. Cause it just really creates some authentic conversations and creates value for those in the audience and as well as those speakers up here who are trying to give their time today to have a great conversation. So thank you so much for you for coming up and asking those things.
So awesome. By the way, if you got value from anybody up here on the stage, please feel free to click on their face there, follow them. Cause if you're getting value from them here, guess what you're probably gonna from in other places as well. And JavaScript Jam wouldn't mind follow as well. Two.
And don't forget to subscribe to our newsletters so that you can find out when we're gonna be having awesome people like Alex on here. And all the wonderful things that we are collaborating with and doing. You don't wanna miss out. So with that being said, you can see Alex live next week at 11 50 11 Mountain Time.
Okay. 11:50 PM time PM Oh am I'm sorry
it's late in my day. No worries. 11:50 AM Mountain time. He will be speaking, is that on the 10th or the 11th? That'd be the 10th Wednesday. So what's that? The first day? Cool. Awesome. So go check him out. And if you don't have your tickets yet, go to Remix Comp. Go to Remix Comp and get ya.
Copy your ticket. Don't wanna miss it. There's gonna be some fun people there. You know how it is when you you miss a conference and then you're not able to attend whatever it is. And you like see all the stuff on Twitter and you're like, oh my gosh, I wish I could be there right now.
You don't wanna be that person, so just go get your ticket. Its that time of the year reactathon is happening as we speak. And I'm like, I know my friends. Yes. You know what I'm talking about. Absolutely. All right, everybody, thank you so much for your time today. Greatly appreciate every single one of you up here on stage and in the audience.
Let's give a big round of applause for Alex. Woo. Give some clap, some heart, some love, some 100 and everybody else that showed up here is so yes. Thank you. Thank you. Thank you so much. Appreciate you guys. We love y'all, and we'll see you in the next one. The next one, which will be live at. Remix Conf
