Remix Live Loader with Alex Anderson
A conversation on using Remix for real-time web apps with insights on server-sent events, React Query, and next-gen frameworks like Next.js
Episode Description
JavaScript Jam discusses real-time web apps with Alex Anderson, covering Remix Live Loader, Server Sent Events, and the React Server Components debate.
Episode Summary
In this JavaScript Jam Live episode, the hosts welcome Alex Anderson from EchoBind to discuss his upcoming Remix Conf talk on Remix Live Loader, a approach for bringing real-time capabilities to Remix applications. After introductions and promotion of the upcoming Remix conference where the podcast will serve as the official live show, Alex breaks down the three essential components of any real-time system: a pub/sub mechanism, a transport layer (comparing WebSockets, HTTP long polling, and Server Sent Events), and client-side handling of incoming messages. He explains how his Live Loader implementation uses Server Sent Events with Remix's resource routes to signal clients when data is stale, triggering revalidation through Remix's built-in hooks. The conversation broadens as Ellery shares his experience building a live voting platform using PubNub, and Jason raises the complexity of data synchronization and conflict resolution in multiplayer apps. The group explores tools like PartyKit, Hocus Pocus, and LiveBlocks for managing real-time infrastructure. The discussion then shifts to comparing Remix and Next.js's App Router, particularly around React Server Components, per-component data loading, streaming, and the anticipated mutations API, with Alex offering a balanced perspective as someone who uses Next.js professionally but admires Remix's developer experience.
Chapters
00:00:00 - Introductions and Remix Conference Preview
The episode opens with the JavaScript Jam hosts — Scott, Anthony, and Ishan from Edgio — welcoming listeners and working through some technical difficulties getting guest Alex Anderson connected via Twitter Spaces. The team introduces themselves and their roles, with Anthony promoting the Lunch Dev Discord server where he and Alex became friends.
The hosts spend time previewing their collaboration with the upcoming Remix Conf, explaining that they'll serve as the official podcast at the event and will be recording live during the after party. They mention last week's episode with Kent C. Dodds and encourage listeners to grab tickets, noting a group discount code. Alex shares his excitement about speaking at the conference, praising the Remix community's focus on progressive enhancement and performance for all users, and speculating about possible V2 beta or V3 announcements.
00:10:44 - Alex's Background and the Shopify Acquisition
Ishan asks Alex about his reaction to Remix being acquired by Shopify. Alex reveals he predicted the acquisition about a week before it was announced and expresses optimism about Shopify's track record as stewards of open source, pointing to their contributions to the Ruby ecosystem. He notes that the acquisition freed Michael Jackson from CEO responsibilities so he and Ryan could focus on the framework's technical direction.
The conversation shifts to Alex's professional background, including his time at UI.dev where he authored courses on TypeScript, TypeScript with React, and React Query. Now at EchoBind, he discusses their internal RFC process and highlights his popular blog post about migrating their Bison boilerplate from GraphQL to tRPC. He also shares enthusiasm for shadcn/ui as an ideal approach to building configurable Tailwind component libraries, explaining how it solved a problem he'd been wrestling with months before its release.
00:17:15 - The Three Pillars of Real-Time Web Development
Alex lays out the foundational architecture for real-time applications, identifying three essential components. First is the pub/sub system — whether a simple Node.js event emitter for single-server demos, or Redis and Postgres for distributed environments. Second is the transport mechanism, where he compares WebSockets, HTTP long polling, and Server Sent Events, recommending SSE for Remix apps due to their simplicity and unidirectional nature.
Third, he explains the client-side response strategies: simple notifications, invalidation tokens that trigger data refetching, or full data payloads that surgically update a client-side cache. He notes that Remix and Next.js App Router don't expose their caches for direct manipulation, but React Query's setQueryData method enables precise cache updates. Alex emphasizes that while third-party services like PubNub handle the first two pillars for you, understanding the underlying infrastructure remains valuable for developers who need more control.
00:25:15 - Real-World Real-Time: PubNub, PartyKit, and Trade-Offs
Ellery joins the conversation to share his experience building a live union voting platform during COVID using PubNub, which required live chat, polling, voting with audit trails, and even the ability to forcibly reload users' browsers. He highlights the practical benefits of using managed real-time services, noting that pricing came out to roughly twenty dollars per multi-hour event with thousands of concurrent users.
Alex acknowledges these services are excellent but points out that compliance requirements like HIPAA might force teams to self-host. The discussion then turns to PartyKit, Sunil Pai's new startup built on Cloudflare Durable Objects, which Alex describes as serverless real-time that's fast and easy to deploy. Jason adds context about data synchronization challenges in multiplayer apps, mentioning CRDTs, Yjs, and Hocus Pocus as tools for conflict-free collaborative editing, raising the question of whether the server or client should own the data.
00:39:40 - How Remix Live Loader Actually Works
Alex walks through the technical implementation of his Live Loader hook in detail. His approach maps events directly to Remix routes — so updating an issue fires events for both the issue detail route and the index route. These events flow through Server Sent Events using splat resource routes, and when a client receives an event, it gets a simple timestamp signaling that its data is stale.
On the client side, his custom useLiveLoader hook wraps Remix's built-in useLoaderData, subscribing to the appropriate SSE endpoint and calling the revalidate function when messages arrive. He walks through a practical scenario of two users viewing different pages that share data, showing how both browsers stay in sync through this invalidation approach. He notes that Remix's built-in request cancellation prevents race conditions, but cautions developers to implement server-side caching to handle the burst of simultaneous revalidation requests from many connected clients.
00:46:50 - React Query's Role Alongside Remix
A listener from Tesla joins to ask whether React Query still has a place alongside Remix's built-in data management. Alex affirms that while Remix provides enough tooling for many apps, React Query remains powerful for cases that need more granular cache control. He recommends feeding Remix loader data into React Query as initial data, then using real-time messages to surgically update the query cache rather than revalidating entire loaders.
The conversation explores the tension between Remix's simpler invalidation model and React Query's direct cache access, with Alex noting trade-offs in both directions — React Query gives power but requires manual optimistic updates, while Remix handles more automatically but with less granular control. He mentions using React Query with Next.js App Router for infinite scrolling, a use case where React Server Components don't yet have a clean built-in solution.
00:50:39 - Next.js App Router, RSC, and the Mutations Debate
Alex pivots to discussing the state of Next.js's App Router, noting it was still missing a mutations API and predicting an announcement during Vercel's ship week. He shares that he's been waiting to write an internal RFC at EchoBind recommending either App Router or Remix for future projects, but couldn't fairly evaluate until Next.js shipped its mutation story, since Remix's actions API is so compelling.
The group then tackles the value proposition of React Server Components versus Remix's loader pattern. Alex explains that RSC enables per-component data loading without network waterfalls, compared to Remix where all data must flow from route-level loaders. A listener suggests using pathless routes in Remix as a workaround, which Alex finds intriguing. The chapter closes with discussion of streaming becoming table stakes across frameworks, with Jason noting that these techniques have existed for over a decade but are finally being made accessible to everyday developers.
01:03:25 - Wrap-Up and Conference Details
The hosts begin closing out the episode as Anthony experiences recurring Twitter Spaces connectivity issues. Jason remembers the name LiveBlocks, the real-time collaboration tool he'd been trying to recall throughout the conversation, recommending it for anyone working on data synchronization challenges.
Scott delivers the closing remarks, reminding listeners that Alex will be speaking at Remix Conf on May 10th at 11:50 AM Mountain Time. He encourages the audience to grab conference tickets and follow the speakers, subscribe to the JavaScript Jam newsletter, and join the live podcast recording at the Remix Conf after party. The episode ends with the hosts expressing appreciation for the community participation that made the discussion particularly rich, including contributions from audience members who came up to ask questions and share experiences.
Transcript
00:00:04 - Anthony Campolo
Hello, everyone. Welcome to JavaScript Jam Live. We're bringing up the people to speak about the things and the stuff right now, so hang tight.
00:00:16 - Ishan Anand
Where stuff is. Anything JavaScript or web development related?
00:00:21 - Anthony Campolo
That's right, it is.
00:00:24 - Scott Steinlage
Whoa. Yo. Welcome to JavaScript Jam Live. We do this every Wednesday at 12:00 PM Pacific Standard Time. So glad y'all could be here. Alex, I sent you an invite there. I don't know if it worked for you or not, but here we go. Try it again. Yeah, today we're gonna be talking Remix Live Loader with Alex. So excited for that. We actually met Alex at Remix last year.
00:01:08 - Anthony Campolo
Yeah, he's an SLC native, I believe.
00:01:11 - Scott Steinlage
Yeah.
00:01:12 - Ishan Anand
So is Alex maybe on the web experience? Did we coordinate to make sure he's not? He's definitely using the mobile device, because then he can respond to speaker requests.
00:01:24 - Anthony Campolo
Yeah, I think Alex would be aware of such restrictions. He tends to be on the up and up. But if that is the case, Alex, you need to be on mobile. Ah, no, he is on the web. He just sent me some Discord messages. Yeah, well, okay, we'll get him up in a second.
00:01:42 - Ishan Anand
Okay, this has been us before. I thought, for example, that they'd naturally have web support by now. And even if you primarily listen, you're like, "Oh, well, this time I want to be good," right? So I'm gonna get on a wired connection with my laptop, and yeah, it kind of really inverts your expectations. But this is what it is. So we'll get him up here soon.
00:02:09 - Scott Steinlage
Very true.
00:02:11 - Anthony Campolo
He just hopped off, so I think he's gonna be getting on the phone. So yeah, let's just kill a little time while we're doing that. We can introduce ourselves and whatnot. Nicky T. in the audience, what up, bruh?
00:02:22 - Scott Steinlage
Nicky T., bro. Yo. Can't wait to see Nick here soon. I think he's actually at Reactathon right now, if I'm not mistaken.
00:02:34 - Alex Anderson
Hi, gang.
00:02:36 - Scott Steinlage
There you go.
00:02:37 - Anthony Campolo
What's up?
00:02:38 - Ishan Anand
Hey.
00:02:39 - Alex Anderson
Yeah, apologies. I've never done a space before, so.
00:02:43 - Anthony Campolo
No, that's great. Well, I'm happy to have you for your first Space. And this is a good reminder for us to include this in a writer-type message.
00:02:51 - Scott Steinlage
Yep.
00:02:54 - Alex Anderson
Okay. What'd I miss? Nothing?
00:03:00 - Anthony Campolo
Scott, why don't you go ahead and kick us off?
00:03:03 - Scott Steinlage
Yeah, sure. All right. So 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 web technologies, we want to hear from everybody. So feel free to understand that this is like an open-mic kind of atmosphere. We love that, actually. It 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 or myself, and also maybe state an opinion or a fact or two. Whatever you want. It's up to you. So we'd love to hear from you. With that being said, my name is Scott Steinlage, and I am a technical community manager at Edgio and one of the co-hosts here, MC Dilly Doo of JavaScript Jam. Yeah.
00:03:56 - Anthony Campolo
Go ahead, Ishan.
00:03:57 - Ishan Anand
Yeah, I'm Ishan. I'm the VP of Product for the applications platform here at Edgio, which offers CDN security and, you know, Jamstack-like hosting for some of the largest sites on the planet. And then, Anthony, I'll let you go.
00:04:16 - Anthony Campolo
My name is Anthony Campolo. I am a developer advocate at Edgio, where we serve 4% of the internet. Is that right, Ishan?
00:04:25 - Ishan Anand
That is correct. You probably use it and don't even realize it.
00:04:31 - Anthony Campolo
So yeah, I'm super excited to have my good friend Alex here with us from EchoBind and the Lunch Dev server, and general contributor to awesome open source stuff. So go ahead and introduce yourself for our audience.
00:04:46 - Alex Anderson
Howdy. Yeah, I'm Alex. I actually live in Boston right now on the East Coast of the US, and I work for EchoBind, 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.
00:05:13 - Anthony Campolo
Very cool.
00:05:15 - Ishan Anand
Yes. You're going to be speaking at Remix. We should maybe pause and talk about what we're doing with Remix because last week we had Kent. Next week you guys are going to 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 going to happen at the conference next week.
00:05:36 - Scott Steinlage
Awesome. Yeah, no, 100%. So last week, yeah, we had Kent on here and we were talking Remix and all the exciting things there, why you don't want to 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 this year. And so that's what we're doing, just basically bringing on some of the speakers. Kent is actually going to be speaking there too, not just organizing. And also Alex here is going to be speaking there as well, which is exciting. He'll kind of get into maybe a little bit of a sneak peek into what's going on there with him when he's at the event. And yeah, we're just very excited for all that. And we're actually going to be the formal, I guess, official podcast at the event there. We're going to 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. It's going to be a good time.
00:06:43 - Scott Steinlage
They're giving out free milkshakes and 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 chance?
00:07:04 - Anthony Campolo
Negative.
00:07:05 - Scott Steinlage
Negative. Okay, we'll throw it in the comments.
00:07:06 - Alex Anderson
Pretty sure it's just team.
00:07:08 - Scott Steinlage
Team. That was it. Yeah, I think you're right. Either way, I'll double-check it and we can throw it in the comments later. But yes.
00:07:16 - Ishan Anand
So make it to Remix if you can. And if you can't, tune in next week and hear from it live from the floor because...
00:07:23 - Scott Steinlage
Right, exactly. We will be live there during 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, 100%. 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 going to be conducting a couple podcast recordings as well for future stuff. And yeah, just love to hang out with y'all and see you. So feel free to come and say hi to us. All right. Oh, by the way, one last thing. Sorry.
00:08:04 - Ellery
I would.
00:08:04 - Scott Steinlage
It would probably behoove you to go onto our newsletter and sign up. So go to JavaScript...
00:08:14 - Anthony Campolo
I'll go ahead and drop the link for that. I'm also going to drop a link for the Lunch Dev server. I already see we got good buddy Roman here in the crowd. What's up, Roman? This is my favorite Discord server. This is one of the ways that Alex and I got to know each other. It's run by Michael Chan from React Podcast. So for anyone who wants a really cool developer Discord, I highly recommend this one. And Nicky T. is also in there as well.
00:08:42 - Scott Steinlage
Yes.
00:08:42 - Anthony Campolo
Yeah, yeah.
00:08:44 - Scott Steinlage
It is a pretty cool Discord. Awesome. Shall we get started?
00:08:52 - Anthony Campolo
Let's do it.
00:08:54 - Scott Steinlage
Let's do it. Alex, first of all, I do have one question for you. What are you most excited for at Remix coming up here?
00:09:04 - Alex Anderson
For Remix itself or for Remix Conf.
00:09:08 - Scott Steinlage
Remix Conf? Yeah, I'm sure Remix too. Yeah, absolutely.
00:09:13 - Alex Anderson
Okay. The conf itself, I'm excited to speak. I love speaking. It's like I 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 and hear 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 Conf about those things. Absolutely would not surprise me if a V2 beta dropped at Remix Conf, and then they've hinted at V3 having some really cool new changes that are going to make everything better.
00:10:34 - Alex Anderson
And I'm just like, awesome. It's already pretty good, so if they can make it better, great. Yeah.
00:10:44 - Ishan Anand
So one of the changes compared to last year, you know, Remix is now under the Shopify umbrella. When you heard about that, I'm curious, as somebody who participated last year and somebody who observes the Remix ecosystem, just what your thoughts were in reaction when you saw that. And how do you think that's played out?
00:11:03 - Alex Anderson
Oh, I've got friends that work at Shopify. Before Remix was acquired, I actually guessed that that was what was going to happen about a week ahead of time. I messaged one of my buddies, who was like, "How'd you know that? 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 they have not disappointed with their stewardship of Remix so far. I had 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 CEO 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 CEO, 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.
00:12:22 - Alex Anderson
So yeah, I was optimistic beforehand, and I think my optimism has paid off in the ensuing months.
00:12:33 - Ishan Anand
Yeah, we introduced you as being at EchoBind. You were previously at UI.dev, which I think a lot of our audience may already be subscribers to or familiar with. They put out the Bytes newsletter. And you did some courses that you authored. Do you want to tell people a little bit about that?
00:12:58 - Alex Anderson
No, I think you said everything that needs to be said about that.
00:13:02 - Ishan Anand
Why don't you tell people the courses that you authored?
00:13:06 - Alex Anderson
I made the TypeScript course and the TypeScript with React course.
00:13:10 - Scott Steinlage
Okay.
00:13:11 - Alex Anderson
And the React Query course.
00:13:14 - Ishan Anand
Very cool. And if people want to see those, where do they go?
00:13:18 - Alex Anderson
UI.dev.
00:13:19 - Ishan Anand
Okay, you heard it here first. Yes.
00:13:21 - Anthony Campolo
This is Tyler McGinnis's company. You were working there before EchoBind and did quite a lot of work there.
00:13:29 - Alex Anderson
Yes.
00:13:31 - Ishan Anand
And when you create, like, how much time do you have? That's a very content-heavy role. At EchoBind it sounds like you're doing more day-to-day engineering. Do you still have time to create content and...
00:13:46 - Alex Anderson
Yeah, that's a good question.
00:13:50 - Anthony Campolo
You write a lot of blog posts?
00:13:53 - Alex Anderson
I do write some blog posts, yes. And a lot of the content that I write is staying internally. So we have an internal RFC process for making decisions about pretty much anything at the company. Actually, anybody could submit an RFC 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 EchoBind. One of my blog posts, which has probably done the best, was titled "Why We Dropped GraphQL for tRPC," and in it I basically just outline what GraphQL is good for and why that's not what we need for our clients, and why tRPC 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 tRPC is also great and highly recommended.
00:14:56 - Anthony Campolo
It's also worth mentioning that within this blog post you're talking about how Bison migrated from GraphQL to tRPC, and I think this is a super, super interesting topic area to get into, but it would be quite a huge diversion, so we might want to put a pin in that before we get into your Remix talk.
00:15:13 - Alex Anderson
Yeah, for context, Bison is basically a boilerplate that we use at EchoBind for starting up our projects, so it includes Next.js, Prisma, tRPC. Now, in 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 shadcn/ui components, which is just fabulous work. I was doing research into how to build a reusable, themeable, 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 Tailwind's just-in-time compiler. And I had that thought around September of last year, and then in January shadcn comes out and he's like, "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 shadcn/ui.
00:16:44 - Alex Anderson
I know we're talking about Remix. I use Next.js mostly in my work at EchoBind, but shadcn/ui works great with Remix as well.
00:16:54 - Anthony Campolo
So are you saying shadcn...
00:16:58 - Alex Anderson
CN. Shadcn/ui. I can reply to this, right? I'll just...
00:17:05 - Anthony Campolo
Yeah, yeah, you can tweet at the Space that we can put on the Jumbotron, as we say.
00:17:15 - Alex Anderson
Cool.
00:17:15 - Anthony Campolo
But while you're doing that, I know that you're going to be speaking about Remix Live Loader. This is bringing real time to Remix. So this is something that I don't know a ton about. I have not done a lot of real-time programming, but I know that you're pretty experienced, and I've seen you do streams and whatnot around these types of things. So what was it about this topic in particular that made you want to give a talk about it?
00:17:44 - Alex Anderson
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 Node's EventEmitter, 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 real-time event that just fired, or some serverless providers... I think Lambda now supports real time in some way.
00:18:27 - Anthony Campolo
Yeah, Lambda had a type of streaming, which I can only imagine is an extremely hacky way of getting it to work, because Lambda's not meant for that. But it sounds like AWS was like, well, enough people are asking for it. We're gonna clutch it in there.
00:18:43 - Alex Anderson
Exactly. And I don't know if Edgio has anything like that, but that 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, 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 going to shove into my talk that I can't because I don't have enough time. I'm only giving a five-minute talk.
00:19:29 - Anthony Campolo
You got as much time as you need right now, so luxuriate in it.
00:19:34 - Alex Anderson
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/sub system, some way for you to tell your server some real-time event happened and you need to notify clients about it. So that's the EventEmitter in Node.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 WebSockets. HTTP long-polling is another option, I suppose, and those are the two methods that Socket.IO wraps together, where it falls back on long-polling if your browser doesn't support WebSockets. But every modern browser supports WebSockets these days, so cool. But then another technique, which I didn't know about until the Remix team started making it more popular and started talking about it, is server-sent events, which is basically a way for a server to keep an HTTP connection open with the client and just send messages down whenever it wants.
00:21:07 - Alex Anderson
It's kind of like WebSockets, except it's unidirectional, where the server is sending messages to the client, whereas WebSockets 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 a 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/1, you're limited to the number of HTTP connections that you can maintain in your browser. Pretty much all modern browsers cap it at six, but if you're using HTTP/2 or HTTP/3, then you can have as many as you want. You don't have that limitation. And server-sent events work for everything. So if you're using Remix, I recommend that you use server-sent 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 Auth and Remix Utils, and is just a great helper all around. Anyway, Remix Utils has utilities for client and server handling of server-sent events.
00:22:34 - Alex Anderson
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/sub system, an EventEmitter or Redis or Postgres or some other pub/sub system. You've got your transport, WebSockets, HTTP long-polling, 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 message from the server, shows it to the user, and then forgets about it. Or you could make it so it's kind of an invalidation token, where the server just tells the client, "Hey, you need some fresh data. I'm not going to give you that data, but you can get it yourself." And then if you're using Remix, you use the revalidator 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 refetched.
00:23:55 - Alex Anderson
If you're using Next App Router, you can use the router refresh method, which refetches all of your React Server Components. So that's one option. And then the final option, and 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 setQueryData method to update the data however you see fit based on the message.
00:24:46 - Anthony Campolo
Okay, 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 you had mentioned that there's not a lot of good tools to do this. It looks like Ellery is kind of pushing back and pointing out some things like PubNub and Azure SignalR. So yeah, let's bring him in here.
00:25:15 - Ellery
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 Ellery. I also work at Edgio with Anthony, Ishan, and Scott. I actually have some experience in this space because back in 2020 I worked on a project where a client of mine had a need to support live events. 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, you know, hear speakers and so on. And there's ADA and other stuff that goes into it. But because of COVID, no one could get together and meet. And so the requirement was like, we have to have a live-streaming platform that has live chat, live voting, live polls, all these things with full audit trails, et cetera. So we started looking at this problem. We were using React JS at the time. It's like, oh crap, how do we go build this? Because I need to be able to persist all these messages. I need to be able to have waiting rooms.
00:26:20 - Ellery
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 track everyone who voted, blah, blah, blah. And we looked at a lot of different tools, including building our own. Azure SignalR was 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 it as a general-purpose Socket.IO project, where they give you a client-side library. They have one for React, which is what we use. Basically you can create streams of data and people can subscribe to those and get messages, and they can publish, and there's full RBAC and everything else built in there. So we used that to build all the voting and poll information as well as live chat in the app, and even built some sneaky things because many of the users were not very competent, like they had IT issues. And so we built some fun stuff where we could forcibly reload their pages without them giving consent, which is kind of cool.
00:27:21 - Ellery
But I just want to 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, like, oh, am I going to do long-polling, open a WebSocket server, server-sent events? Just install their SDK and let that do 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 we could get by just doing volume-based pricing, and it was like 20 bucks per event that we had to support. These events had thousands of users and they ran for like four or five hours.
00:28:00 - Alex Anderson
Yeah, absolutely. PubNub is great. I've never used them before, but there are a lot of these real-time SaaS products 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/sub system that you can notify to let them know that some real-time event needs to be sent to clients. And they have a transport mechanism for the client and server to connect and 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 I mean, 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 LiveView. I don't know if they encourage you, but you can use their LiveView setup, which basically moves all of your app's reactivity to the server, and it sends any updates to the app to the client using WebSockets with real time.
00:29:19 - Alex Anderson
And that's just baked right into the framework, which is fascinating. Then Sunil Pai is working on PartyKit right now, a new startup which is supposed to make all of this really easy for you. You're able to, with just a few lines of code, set up these real-time rooms for sending these messages. And I'm pretty sure he's 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 want to do it yourself, if you want to set up the infrastructure, I think it's helpful 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.
00:30:08 - Anthony Campolo
Yeah, so I guess kind of like, what are the trade-offs that come along with that? Do you feel like it's preferable to own it yourself? Or what would you feel comfortable kind of offloading to a service?
00:30:20 - Alex Anderson
Oh, Anthony, you can't ask a senior developer a question that obviously is answered with it depends.
00:30:26 - Anthony Campolo
Well, that's fine. You can give me what it depends on and then give me whether you do this when it depends on that.
00:30:32 - Alex Anderson
Yeah, I mean, I don't know what regulations or what degree of privacy you need to have for union voting or whatever you might be doing. 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 systems. 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 PubNub is HIPAA compliant. I don't know what effort it would take in order to get set up on a HIPAA-compliant enterprise plan with PubNub. 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.
00:31:35 - Anthony Campolo
We got Jason up here with us, long-time listener/caller on JavaScript Jam. What's up, Jason?
00:31:42 - Jason
Hey, everyone. Yeah, been busy. Haven't always been able to make the meetings, make the Spaces, whatever we call these places.
00:31:52 - Anthony Campolo
But yeah, feel free to let us know. What's on your mind? What do you want to...
00:31:57 - Jason
Oh, real-time data communication syncing stuff is something I've worked on and off for a long time. I was just thinking about... I love...
00:32:09 - Anthony Campolo
How this topic elicits certain devs to be like, "Ugh, I've been there, I've seen some stuff. I gotta give my thoughts."
00:32:18 - Jason
Yeah, I think there's a number of challenges you guys have already talked about, and the next one, or what kind of got brushed on, was data synchronization. So if you're storing any amount of data in the browser, how do you resolve conflicts? So if it's a simple use case like chat, where you don't have collaborative editing of shared objects, then there isn't any synchronization. It's immutable objects. And then it gets really interesting if you start doing these multiplayer apps, as I think people are calling them now, where you have multiple people editing the same objects. And there's a number of different camps.
00:33:06 - Scott Steinlage
What's.
00:33:06 - Jason
Or what's the one that Vercel is really into these days? Is it data...? I'm just having a brain fart.
00:33:15 - Alex Anderson
Yeah, I'm forgetting too. Databricks.
00:33:19 - Jason
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, a shared document model where you can build things like Google Docs, where you've got multiple people editing a highly concurrent object. But that is probably going to be overkill. And then there's, like, does the server own the data or do the clients own the data? So there's all these kinds of other things that pop up as you start to think about, on top of all the overhead and complexity of maintaining and scaling WebSocket servers. It gets pretty gnarly pretty quickly, which is why hopefully one of these other solutions will have a nice edge-function equivalent ease of deploy, like Edgio or Vercel, to deploy your React app with WebSockets. It really hasn't happened yet.
00:34:22 - Alex Anderson
Yeah, I would keep your eyes peeled on what Sunil's doing with PartyKit. Yeah, PartyKit.
00:34:27 - Jason
That definitely looks really interesting.
00:34:29 - Alex Anderson
Very. And he's already got support for Yjs. I'm not sure if he has Automerge.
00:34:33 - Anthony Campolo
Can we give like a TLDR? Like, what is PartyKit?
00:34:38 - Alex Anderson
Yeah, PartyKit is described as an open source platform for collaboration. So you basically just use a very small amount of code to set up some WebSockets on your server. 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 fully managed and deployed to the edge, so you don't have to worry about your own servers. And it's fast and batteries-included. The idea is it's serverless real time that's really fast and easy to use.
00:35:32 - Anthony Campolo
Yeah. And I think it's interesting how you're saying he's built it on some Cloudflare stuff. He was working at Cloudflare for a bit, and I feel like that's when 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 too much bureaucracy, and then jumps to build a startup to fix it instead. I feel like I've seen this pattern a couple times, and it's usually a good sign that they're onto something.
00:36:02 - Alex Anderson
Yeah. And Sunil's very, very thoughtful and humble and definitely going about building this, in my opinion, the right way. Another interesting thing about it is it is open source, so it's GitHub.com/partykit. PartyKit. Find all the code right there.
00:36:30 - Jason
For sponsors?
00:36:32 - Alex Anderson
No, it's open to everybody.
00:36:34 - Jason
Is it open, though? Oh, I thought it was sponsored.
00:36:36 - Alex Anderson
Okay. It was sponsors-only. He opened it at React Miami.
00:36:41 - Jason
Oh, cool.
00:36:43 - Alex Anderson
Yep.
00:36:45 - Jason
The other one I've used, I think it's by the creators of the Yjs project, is called Hocus Pocus. It's another MIT-licensed... It was a sponsored-only project for about a year, and I think they open sourced it, or took away the sponsor barrier, probably six months ago. It's a WebSocket endpoint server for Yjs documents that plugs nicely into the Yjs 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 Yjs, 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.
00:37:30 - Alex Anderson
Yeah, slick. It looks like they've got support for auth and persistence and, yeah, fun stuff.
00:37:38 - Jason
It's relatively... I should probably just flip this. I've got a little repository that's an example of it that I should probably just flip the switch to open source.
00:37:46 - Anthony Campolo
It is?
00:37:49 - Jason
You can plug in your own database. So whatever database you use, it's got some callbacks that you implement for data, and then an auth hook that lets you... It's like if anybody used Socket.IO way back in the day, where you just implement your own little middleware for auth and that kind of stuff. It's very similar. But then it has the downside of you get to host it yourself, which may or may not be a hard thing for people.
00:38:18 - Alex Anderson
Yeah.
00:38:22 - Jason
But it's literally like I've got maybe 10 lines of a Node.js script on top of their library, and I've now got a functional authenticated backend for a fairly decent-sized shared data store app.
00:38:40 - Anthony Campolo
Scott, do you want to do a station break? Sure.
00:38:44 - Scott Steinlage
All this talk about rolling your own stuff, oh man, you're...
00:38:55 - Anthony Campolo
You got some distortion on your mic.
00:38:56 - Scott Steinlage
Right now, do I? Is it?
00:38:59 - Anthony Campolo
Yeah. Am I better now? I'm not the only one hearing that, right? People hear that?
00:39:04 - Jason
Yep. He's a little garbly.
00:39:07 - Anthony Campolo
Yeah.
00:39:07 - Scott Steinlage
Shame. I don't know where it's coming from.
00:39:13 - Anthony Campolo
Okay. You sound like you're in a blender right now.
00:39:16 - Scott Steinlage
Oh, that's awesome.
00:39:19 - Anthony Campolo
All right, well, I could do a station break. So if you've gotten value from anyone here on stage, go ahead and follow them. We are talking about Remix Live Loader right now with Alex Anderson. And while we bring it back to your talk, is there more you want to speak about, Remix Live Loader specifically, that we've not hit on?
00:39:40 - Alex Anderson
Yeah, the hook itself.
00:39:44 - Anthony Campolo
Do it.
00:39:46 - Alex Anderson
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 kind of 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 real-time template, which is a Linear clone, so an issue tracker. And so I have another event that I can fire for issues and then an issue number, which is going to be fired anytime an individual issue has been updated. So I call updateIssue, 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.
00:41:13 - Alex Anderson
I'm using server-sent events in this case. And the way that server-sent events work in Remix is you subscribe to them. They're resource routes. They're basically loaders that your app can request, that they can connect to using the browser-based server-sent event APIs. Again, I'm using Sergio's Remix Utils for this, so it's all abstracted away in a very simple API. And when I'm subscribing to these, I'm actually using a splat route on my server-sent events loader on that particular route. So I can do events/issues/ 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 second method of just letting the client know that its data is out of date, and the client can handle updating its data however it wants.
00:42:36 - Alex Anderson
And then on the client I have a special custom hook called useLiveLoader, which wraps Remix's built-in useLoaderData 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 you have your friend sitting beside you looking at the issues index page, and you're on 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 recognize that you're connected, 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.
00:44:11 - Alex Anderson
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 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, please, please set up some kind of LRU cache, some kind of server-side cache, to make sure that you're not going to be completely hammering your server with all these requests. But for as inelegant a solution as it is, 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...
00:45:22 - Alex Anderson
I think it's 11:30 Mountain Time next Wednesday. Let me double-check the schedule.
00:45:37 - Anthony Campolo
Awesome. We got someone who has a question. Let's add this person up here. Hopefully they're not a bot.
00:45:50 - Alex Anderson
Hey.
00:45:51 - Ishan Anand
Hello.
00:45:52 - Speaker 7
Hi.
00:45:53 - Anthony Campolo
What's up?
00:45:55 - Speaker 7
So, I had a question. Of course we have to be careful on how we design loaders with Remix, especially because it's going to fetch everything. So if you have like 15 loaders on one page, that's probably not 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 Query? Is there still space for it? Or would this be something that we can handle with just Remix cache invalidation, with sort of designing our loaders in a much simpler way?
00:46:50 - Alex Anderson
Great question. React Query is fabulous. I mean, 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 doesn't have any additional reasons why you'd want to 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, 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 to be really fancy, you can serialize the cache in your loader. But I don't know that 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.
00:47:55 - Speaker 7
No. Okay, that makes sense. Okay. Feed the output of your loader as the initial data for your React Query. Okay, that makes sense.
00:48:03 - Alex Anderson
Yep. And then with the real time, instead of revalidating 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 setQueryData in order to update whatever needs to be updated based on that real-time response. And then the cache updates, and that updates all of the queries that are using that cache data, and your app updates. And it's wonderful.
00:48:39 - Speaker 7
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 like 10 loaders 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 an additional defense on your UI side to sort of have some sort of control rather than Remix just doing like, okay, we're going to just get everything for you.
00:49:18 - Alex Anderson
Yep, Remix's solution is great, and it is going to solve those race conditions. Using React Query, 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 cache. 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 there are trade-offs. But React Query... 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?
00:50:24 - Speaker 7
Nope, that's all. That was the question. Thanks.
00:50:27 - Alex Anderson
Yeah, that's actually all that I have to say about my talk. So if there are any other questions about the talk, I'd be happy to talk about them. Or if we want to talk about anything else, I'd be curious to talk about...
00:50:39 - Anthony Campolo
You mentioned App Router a little bit. What are your thoughts on the current Next.js world?
00:50:45 - Alex Anderson
Yeah, it's a shame we're not having this conversation tomorrow because I'm pretty sure there's going to be the mutations RFC that's going to drop tomorrow as part of Vercel's Ship Week. Which, cool, it's Vercel week. Awesome.
00:51:05 - Anthony Campolo
You should let our listeners know what that is and why they should have their eyes peeled for it tomorrow.
00:51:10 - Alex Anderson
No, Vercel is doing a good enough job of that. Basically, App Router was first announced as a beta for Next.js 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 App Router is not there yet. You can use it. You're going to 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 RFC 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 kind of like a magic RPC that's being built into React Server Components. And I think as part of this Vercel Ship Week, they're going to announce that tomorrow for the keynote.
00:52:44 - Alex Anderson
So I've actually really wanted to do an RFC at my job to recommend that we either switch to... because 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 want to 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 going to win. Because actions are just such a nice API 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?
00:54:01 - Anthony Campolo
No, that was great. I thought that was all good context for people who are not super-duper deep into this world. We got Bro Nifty coming up here. You got some thoughts you want to throw in here?
00:54:16 - Bro Nifty
Oh yeah, you just queued me up with the people who are not super deep, Bro Nifty, which is me. Yeah, I'm not super deep in it. No, but just kidding. Yes, thank you, Anthony. Yes, I did.
00:54:27 - Anthony Campolo
New questions are always welcome, mister.
00:54:29 - Bro Nifty
Thank you. I did have a question actually to... Alex. Yeah. So do you know exactly what the value prop is? I had some back-and-forth with Dan and some other people from React and the general ecosystem. And 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... So like, we have loader and action. It's hard-coded to the router in Remix, right, where you have, like, 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 somewhere nested, not at the root of the route, but somewhere nested in there or something.
00:55:29 - Speaker 7
Is that.
00:55:29 - Bro Nifty
Is that your kind of general takeaway of what the value prop of RSC over something like Remix's standard loader-and-action type of thing is?
00:55:39 - Alex Anderson
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. Kent recently said, in fact, I think it was on this Remix 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.
00:57:02 - Alex Anderson
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's 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.
00:57:50 - Bro Nifty
Yeah, just to actually 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 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 [unclear].
00:58:23 - Alex Anderson
GraphQL fragment.
00:58:23 - Ellery
Fragment.
00:58:24 - Bro Nifty
Fragment, yes. That is the... I guess all of this that we're implementing in Next, the App Router, and Waku, Adam [unclear], Daishi Kato's thing, which was used by... I can't remember his name because there's too many things to remember at once. But yeah, what you brought up, Whiteboard of the Web, all of that. I believe the genesis of it is what we just talked about, the GraphQL implementation. So if we really did 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.
00:59:17 - Alex Anderson
Absolutely. I want to highlight one other benefit, which 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 going to 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. It's first going to load the whole page with the Suspense boundary showing the fallback, and then as soon as that inner component loads its data, it's going to stream in that data and show up just fine.
01:00:19 - Speaker 7
But I thought in Remix, if you have a nested small component, you can have a loader inside of it and ensure that that is like a pathless route so that a user cannot directly access that particular component on the page. But it's sort of hydrated on the page.
01:00:41 - Alex Anderson
Yeah. You know, I've never tried that before, but that sounds... that's actually something I'm...
01:00:45 - Speaker 7
Going to try out with my teammates, like, within the next week.
01:00:51 - Alex Anderson
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 going to 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. So yeah, very, very good idea, though. I might have to try that sometime.
01:01:46 - Jason
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 inside of their framework, and that Remix has had it for a while now, I think.
01:02:14 - Alex Anderson
Yeah, I mean, relatively a while. I can't remember who got it first, but it's become table stakes these days.
01:02:25 - Jason
Well, I think, like with everything with Remix, that's everything that's old is new again.
01:02:30 - Alex Anderson
Exactly.
01:02:31 - Anthony Campolo
Taking advantage of the old stuff that Remix invented and no one else did... [unclear].
01:02:37 - Alex Anderson
Yeah, yeah, well, yeah,
01:02:42 - Jason
Yeah, I'll try to stay off that third rail. But yeah, I mean, the ability to do streaming, like server-sent events and just straight-up long HTTP requests to kind of stream back even HTML, has been around for almost decades, you know, at least a decade now. But having that be part of normal things, that everyone has a usable user interface, as opposed to being some crazy hack that you had to know some mystic voodoo to know existed, I think bringing those techniques back and making them easy and kind of normalized is always a good thing.
01:03:25 - Alex Anderson
Absolutely. Just put more tools in our toolbox. Give us the power. Power... what? That was one of the big themes of last Remix Conf, is Remix gives you levers. You can choose how much you want to pull.
01:03:37 - Anthony Campolo
All right, sweet. Well, this has been a super great discussion. Are there other things, Anthony?
01:03:44 - Ishan Anand
What?
01:03:44 - Scott Steinlage
What? Maybe you might not be able to hear Alex, because I think he was mid-sentence when you said...
01:03:51 - Anthony Campolo
Twitter Spaces is just going totally nuts right now. I'm just...
01:03:54 - Scott Steinlage
Please continue.
01:03:55 - Anthony Campolo
Continue on.
01:03:57 - Alex Anderson
That was basically the end of the thought. Thanks for sticking up for me, Scott.
01:04:02 - Scott Steinlage
Yeah, okay. He said that was basically the end of the thought. It's all good. All right. Well, Anthony has jumped in and out at least probably four or five times and he was having issues, and obviously still having issues. Thank you, Twitter Spaces. Never a dull moment here, folks. Absolutely never a dull moment. Well, with it being the hour here, I don't know, we could probably just kind of call it here and just want to thank everybody so much for showing up. Does anybody have anything else they want to say before we... Maybe a question or opinion or fact or whatever it might be about anything that was just discussed? Maybe any last-second questions for Alex or anything like that?
01:04:49 - Jason
I did have one thing. I finally got rid of my brain block. It's Liveblocks. They've been around for a while now. Looks like they've increased their product footprint quite a bit since the early days. So yeah, might be worth checking out if you got to do real-time data sync stuff.
01:05:09 - Alex Anderson
Lots of great tools out there.
01:05:12 - Speaker 7
I just wanted to say thank you for giving me the space to ask a couple of questions.
01:05:18 - Alex Anderson
Yeah, absolutely fabulous questions.
01:05:21 - Scott Steinlage
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 request to come up, whether you're a beginner, whether you're an advanced user, it doesn't matter. Developer, you know, we want to hear from you. Ask questions, opinions, facts, whatever, because it just really creates some authentic conversations and creates value for those in the audience as well as the speakers up here who are trying to give their time today to have a great conversation. So thank you so much 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. Because if you're getting value from them here, well, guess what, you're probably going to get value from them in other places as well. And JavaScript Jam wouldn't mind a follow as well too. And don't forget to subscribe to our newsletter so that you can find out when we're going to be having awesome people like Alex on here and all the wonderful things that we are collaborating with and doing.
01:06:22 - Scott Steinlage
You don't want to miss out, folks. So with that being said, you can see Alex live next week at 11:56...
01:06:34 - Alex Anderson
Mountain Time.
01:06:36 - Scott Steinlage
Okay. 11:50 PM Mountain Time. AM, PM, what?
01:06:44 - Alex Anderson
Oh, AM. Sorry.
01:06:46 - Scott Steinlage
Okay. We could go that late, probably, but...
01:06:49 - Alex Anderson
Yeah, it's late in my day.
01:06:52 - Scott Steinlage
No worries. No worries. 11:50 AM Mountain Time. He will be speaking, I guess. Is that on the 10th or the 11th?
01:07:00 - Alex Anderson
It'll be the 10th.
01:07:02 - Scott Steinlage
The first day. Cool. Awesome. So go check him out. And if you don't have your tickets yet, go to Remix Conf. Go to Remix Conf and get your tickets. Don't want to miss it. There's gonna be some fun people there. You know how it is when you miss a conference and then you're not able to attend whatever it is and you see all the stuff on Twitter and you're like, "Oh my gosh, I wish I could be there right now." You don't want to be that person, so just go get your ticket.
01:07:35 - Alex Anderson
It is that time of the year. Reactathon is happening as we speak. And I'm like, I know my friends...
01:07:42 - Scott Steinlage
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. Give him some claps, some hearts, some love, some one-hundreds, and everybody else that showed up here as well. So yes, thank you, thank you, thank you so much. All right, y'all. Appreciate you guys. We love y'all, and we'll see you in the next one, which will be live at Remix Conference. Thank you all. Love you all. See you in the next one. Peace.