00:00:00 Speaker 0: What is up everybody I'm super excited to be joined by my friend Ryan Florence say hi Ryan

00:00:08 Speaker 1: Every time you say that to me I almost say hi Ryan like it's some funny joke

00:00:12 Speaker 0: I mean like it kind of is you can

00:00:14 Speaker 1: I know but I've done it every single time we've done 1 of these things? Yeah. Like, wait, I'm having deja vu. So anyway, hello, I'm Ryan.

00:00:23 Speaker 0: Yeah, actually, I had Ryan on the Chats with Kent podcast, I think season 4, and that season I had that as a running joke where like I'd say say hi so-and-so and if they Most of them would just say hi and I said no I asked you to say hi

00:00:44 Actually on that season, I think you did say, hi, Ryan, I'm like, you're the only 1 who did it right.

00:00:52 Speaker 1: Oh, man.

00:00:53 Speaker 0: Yeah, so actually in that episode, we talked about Remix as well. We're gonna talk about Remix in this episode too, and it's gonna be awesome. But Ryan and I, we met, let's see, I remember, I think my earliest memory of us was at a meetup at AtTask, which is now Workfront here in Utah. It was an, I think it was an

00:01:13 Angular meetup. Were you, No, no, no, this must have been a Utah JS thing.

00:01:19 Speaker 1: It might have been my lunch JS things that I started.

00:01:23 Speaker 0: You know, I never went to those. I did hear about those, but it was in a meetup. We were in a parking lot afterward just chatting as 1 does after you're kicked out of the meetup. And yeah, and then eventually I took your week-long React training.

00:01:39 Speaker 1: Yeah, with Tyler McGinnis, he organized that. And then I taught it.

00:01:44 Speaker 0: Yeah, That was good. I didn't really pay too much attention. I'm sorry. But yeah, and then we've just been friends ever since. You moved away from Utah and then you came back and then we hang out sometimes. And looking forward to all the snow that's hitting the mountains, because we're gonna be up there a lot.

00:02:04 Speaker 1: I know, I've got a, I actually have a view of the mountains from right here in my office.

00:02:08 Speaker 0: Oh yeah.

00:02:10 Speaker 1: And it's snow capped, and I'm super excited.

00:02:15 Speaker 0: Yeah, yeah, I'm liking that, Awesome. Okay, anyway, so that is a little bit of our history. We go back, I think, that's like 2014, maybe, is as far back as we go. So it's been almost a decade.

00:02:29 Speaker 1: It's been years.

00:02:30 Speaker 0: Yeah, it's wild. So Ryan, Why don't you tell us a little bit about yourself like your own? Place in the Community and and whatever

00:02:39 Speaker 1: oh geez I don't know where my place in the community is but I love the web I think JavaScript super fun And yeah, I guess I have some opinions about how to build things on the web. And when your opinions are too strong, sometimes you just have to stop talking and start building.

00:03:00 And maybe that's where Remix came from.

00:03:04 Speaker 0: Yeah, I actually can relate to that a little bit. Although, I don't think either 1 of us stopped talking, even though we built some stuff.

00:03:13 Speaker 1: Yeah, that's true. Yeah, so most recently, I helped build Remix with Michael Jackson and you. You joined us there in the beginning. Before that, did React Router with Michael and before that did stuff in MooTools and Ember and a lot of Rails development, a lot

00:03:33 of jQuery, lots of Backbone, stint with CoffeeScript, that was fun. But yeah, that's where I'm at, web developer. It's people mostly associate me with React, but I've never really felt, like I love React, but I've always felt

00:03:54 funny when people are like, oh, Ryan Florence, the React developer. I'm like, well, I've written a lot of other code that's not React.

00:04:03 Speaker 0: Yeah, for real. Yeah, actually speaking of code you've written that wasn't React, I always like it when you say that you've been doing web development since before CSS was invented.

00:04:15 Speaker 1: Yeah, exactly.

00:04:16 Speaker 0: So for a long time, how did you get into web development at the very start like that?

00:04:21 Speaker 1: So I was 15 or 16 years old and the internet was just kind of showing up. This was like, I don't know, I was in like 8th grade or 9th grade.

00:04:31 Speaker 0: Yeah, late 90s sort of.

00:04:33 Speaker 1: 94, 95-ish, early 90s, mid 90s. And just me and 1 other friend had email addresses, and all the rest of our friends made fun of us for having an email address, like we were super computer nerds or something. And I was just like, you're all like your whole world is gonna be on the internet. Like don't make fun of me.

00:04:53 Here we are. Now they're the ones on Facebook all day. But no, my dad invested in an ISP, an internet service provider. And so we had our little username. My dad's name is Casey, so it was Casey F. That was our username. And back then, when you signed up for an internet

00:05:14 provider, you'd dial in with a modem and you hear all the crackling noises and stuff. And then your older sister would pick up the phone to call her boyfriend. And then your picture of Kurt Cobain that you were downloading would get ruined. And then you're like, no! So then your parents buy 2 phone lines, 1 for the internet. Anyway, my dad invested

00:05:34 in this ISP and with the username KCF. Back then they would give you like, you'd get an email address and then you'd have like an FTP, file transfer protocol, like HTTP, but FTP. That's funny, nobody...

00:05:49 Speaker 0: Yeah.

00:05:52 Speaker 1: But you could just FTP a bunch of files and up to the internet. Like everyone just kind of had their own little homepage if they wanted. And you just throw some HTML up there. And so yeah, this was back when HTML was really rudimentary. It was like to change the, all style was inline, which is funny, because we're back to that. Styles

00:06:12 were inline. There was no such thing as CSS. So it was like body, BG, color equals. Or to change the font, you had to put a font tag in. I think it was font family as an attribute. And then everything below that would be that font. So if you had to put it inside of a paragraph, So every paragraph

00:06:32 tag pretty much had, like you repeated font tags everywhere because as soon as you change it to another 1, then you want to like change it back. It was pretty funny. So yeah, before CSS, before JavaScript. And so I kind of grew up with the web, which I think is pretty cool.

00:06:53 And then I built websites for my punk rock band and I'd bribe other bands to let us play shows with them. Like I'd go online, find their websites, or I don't even know how, that's how I found out about shows. Go to skate shops? Yeah, it was skate shops, and you had like little flyers. And I'd find those bands, and I'd say, hey,

00:07:14 you need a website, I can build it for you. Let me take some pictures at your show and yada, yada, yada, and then let my band play with you. And then I'll build you a website. And so that's how we got our first shows.

00:07:27 Speaker 0: That's actually very industrious of you.

00:07:31 Speaker 1: Yeah. Cool. So That's how I got into it.

00:07:36 Speaker 0: That is awesome. But you did not graduate with a CS degree though, right?

00:07:42 Speaker 1: Right. So I did all that stuff and then After I graduated high school, I went on a mission for my church, the Church of Jesus Christ of Latter-day Saints. And that's like a two-year thing where you kind of unplug from the whole world. And got back. And when I got

00:08:02 back is when DHTML, dynamic HTML had kind of like taken over, like pre-AJAX, it was like HTML, and then CSS and JavaScript showed up, and then there was DHTML, and then if that was AJAX. So I got back from that missionary service, And the whole web had changed. Before I could like view source

00:08:22 and it all made perfect sense to me. And now I would view source and there was like, I don't know, It was so different. There was just so much scripting. And I think some tools were even introduced. I think Visual Basic would actually kick out Jscript.

00:08:43 And then that would go into, so they'd like author it. And I don't know, I never did it that way, but I just remember looking at the code and it was just a mess and I was like, ah, forget this. And so I went to, when I went to college, I studied economics and didn't really touch web dev for 4 years or so after that. So I kind of had a 6 year break

00:09:05 just right after CSS was created and then right before, and then I got back into it right when like jQuery and MooTools and everything else started blowing up, like the Ajax phase of web development.

00:09:19 Speaker 0: Yeah, around like 2006 and 7.

00:09:23 Speaker 1: Yeah, 2005, yeah. My wife needed, she was graduating with a photography degree. And back then we were super poor and she needed a portfolio.

00:09:37 Speaker 0: Right.

00:09:37 Speaker 1: 200 bucks to get a portfolio printed and like a nice like bound in the book and everything like that. But her teacher, her professor is also like, or if you know how you can build a website for your portfolio, cause that's probably the direction we're all going. And so she's like, you used to know how to build websites, right? And I was like, oh crap.

00:09:55 Speaker 0: You can save some money here.

00:09:57 Speaker 1: Yeah, it's like, well for 200 bucks, yeah, I'll try to remember how to do this and yeah, grab MooTools and jQuery, put them both on the same page and everything broke. And then I learned that they were both messing with globals. And anyway, Yeah, I just got hooked after that. I started

00:10:17 really digging into JavaScript because she kept giving me these requirements. Like, when they click on this picture, I want the background image, the background color to change. I'm like, I don't know how to do that crap. And then the next morning, I was a typical software engineer. Product team says, hey, make the app do this. And engineering says, no.

00:10:38 Yeah. Yeah. Then the next morning I'd have it working and I was all proud, impressing my new wife. And then, yeah. Yeah.

00:10:46 Speaker 0: And then

00:10:46 Speaker 1: it was just history. I got involved with open source with MooTools from there. Got some contract gigs from developers in that circle. Who we still interact with today. Mootools, lots of people came from Mootools on the React, in the React world. Yeah, yeah.

00:11:07 There's my whole, there's my whole, how I got into the profession.

00:11:12 Speaker 0: Very cool. So You were 1 of the, holdouts isn't the right word, but everybody was moving over to AngularJS, but you had latched onto Ember, and that was working out pretty well for you over at Instructure, but then you discovered React.

00:11:32 Speaker 1: It didn't work.

00:11:32 Speaker 0: It never worked out very well.

00:11:34 Speaker 1: It didn't work, but we can keep going. I learned a ton there. I love that community. I love Tom and Yehuda, amazing engineers. And yeah, All the work in my career ever since meeting them has been immensely influenced by the way that they think of my writing software. So I mean, no disrespect to them, but yeah,

00:11:54 Ember didn't quite work out on our team.

00:11:57 Speaker 0: Yeah, yeah, I think any, so I was never really into Ember. I played around with it a little bit and I learned a little bit about it, but never shipped anything with Ember. But from what I understand, a lot of what React Router is, and even Remix in some ways, was pretty directly inspired by Ember, right?

00:12:16 Speaker 1: Totally, yeah. In fact, after we launched remix, Tom reached out and he was like, I think remix is, I can't remember the exact phrase. Someone's going to send this back to him and be like, that's not what I said, but Twitter deleted my account. So I can't go find exactly what he said, but it was basically something like, he basically kind of

00:12:36 created what we were after with Ember, with all the full stack stuff and the data coming through the loaders and they had Ember data, they had these idea of models and it's all very similar Like loader is, loader in action are your controllers. Your model, you get to bring your own Prisma or whatever you want to use, a drizzle or just talk

00:12:56 to database yourself. And then the components of the view, like it's still MVC. We just put different pieces of code together in a file instead of like, here's where you should make the boundaries, react and then remix. And now server components are kind of saying, actually, I think we like these boundaries better between things. Let's compose this

00:13:16 way instead of some other way, right?

00:13:19 Speaker 0: Yeah, like those constraints and those boundaries do exist. 1 way or another, it's just how you piece those things together, like where the boundary. How are you gerrymandering those requirements?

00:13:31 Speaker 1: How am I gerrymandering? Oh, man, we don't want to trigger people. Let's move on. Yeah. So, yeah, we got lots of inspiration, not just from the code, but also their approach to things as well. And you did a lot of stuff with MIRB too, which is a project in the Ruby community that both Michael and I have huge respect for.

00:13:52 It merged with Rails, which was huge for Rails. Rails got a whole lot better. Some people would say that MIRB was better than the Rails plus Merb merge. This is hard to say out loud, Merb merge. But yeah, so respect for him all over the place, but we got the nested routing

00:14:12 ideas from them, you know, that you couple segments of the URL to pieces of the UI and also data. Like that's an idea from Ember as well. Yeah. But obviously we got a ton of stuff from, I mean, we use React, but we got a ton of stuff from React too, where it's like, here's a good boundary. You know, a route is kind of like

00:14:33 a encapsulated piece of the page. Let's put everything that's relevant. It's a data, how you mutate that data and how you display that data. Let's put all of that together. Yeah. So it's a remix is very much like a everything we like from Rails, Merb, Ember, React, and the history of our careers.

00:14:55 We tried to wrap up in this idea we call Remix. We tried to remix all of these ideas.

00:15:02 Speaker 0: Yeah, so what's interesting about that is you tie to all of the UI and the data fetching and data mutating in 1 place and that's all attached to the URL, to the nested routing is what makes all that work. And now with the Remix v3,

00:15:22 you're going like a level deeper into the component with server components. Can you talk a little bit about like, what's the motivation behind that and How does that end up working?

00:15:32 Speaker 1: Yeah, I don't know if it'll be v3. There's a bunch of stuff we're going to ship that'll probably be v3, and then maybe the RSA stuff will come in v4.

00:15:40 Speaker 0: Okay, yeah.

00:15:42 Speaker 1: But yeah, so just, I'm being pedantic, but whatever.

00:15:46 Speaker 0: Next version, or future version.

00:15:49 Speaker 1: Yeah, I mean, it's pretty cool with nested routes how you can put all that stuff together, but you still, You know that graphic that people do all the time, and maybe you could post this in the course or something, but that graphic where people have the separation of concerns thing, and it shows

00:16:09 like HTML and it's green, and CSS and it's blue, and JavaScript and it's red, or something like that. And it's like these 3 bars that go this way. And then the next side says separation of concerns. But then you see these like gradients of HTML, CSS and JavaScript. And underneath those bars is like date picker

00:16:30 or tabs or user profile. That's what React really brought to the table was a way to separate the concerns, not by technology, HTML, CSS and JavaScript, or not by role, like in Rails, where it's like model, view, controller. You got

00:16:50 a controllers folder and that's where all the controllers live. And then you got a models folder and you got a view folder. And those views and the controllers are coupled and they would just couple them by name, but sometimes you configure them too. But there's this like, there's a separation and you can't compose a controller into another controller or a model into another model or have a view that then

00:17:10 renders another view that is talking to a different controller and then renders another 1, right? Yeah. And so React brought to the front end this idea of, all right, let's quit separating by tech and let's kind of separate it by a different kind of concern, a more product-oriented or user-oriented concern, which is like a date picker.

00:17:30 Yeah. And then Remix brings in Loader in action, but it doesn't compose right now in Remix V2. Yeah. Like for the add to cart button that Hydrogen has. So Hydrogen is a framework

00:17:51 or a library. I don't know. It's framework. So who knows the difference? Hydrogen is a framework for building headless e-commerce apps with Remix. And they have this Add to Cart button, and you can't just put it anywhere. You've got to wire up, like if you have a route

00:18:11 or a component that renders an Add to Cart button, it's got to know, like it's action at that route needs to know how to add something to the cart. So you got to bring in the button, then you got to bring in the action. And maybe like if you want to know if this product is already in the cart, you got to bring in a function to your loader too and like drill that down to the button to say, hey, you're already in the cart.

00:18:31 So the remix abstractions on top of the data abstractions don't really compose together with components. Great. That's fine. You can, you bring in the component and the 2 functions and like, it works. And it still is a really good experience for the developer.

00:18:51 But server components bring that extra layer of composition to this full stack approach that Next has been doing, that Remix has been doing, to where now, instead of needing a route that you configure and then bring in some functions to add something to a cart,

00:19:12 the button itself can just say, hey, my form action is this function over here. And then the framework can say, oh, okay, I'll make a route for that action. But you don't have to bring in a function and plug it into your routes. There's no configuration. Like you just get to skip that step. And you just got to say this button mutates this

00:19:32 data on the server. And then the framework connects that network gap. We say that all the time in Remix, right? Like it closes the network gap. RSC gives us a way to do it in a very composable way where the components get to know about data, get to know about how to change data, and they get to know how to render data. And now mix in the front end JavaScript,

00:19:52 HTML, and CSS. And so we kind of have like a 5 part component now. It's not just HTML, CSS, and JavaScript, but now we get data actions and data loaders all mixed in together.

00:20:07 Speaker 0: Yeah, that level of composition is like, cannot be underestimated, how powerful that is. But you can just ingest

00:20:15 Speaker 1: these things inside of each other as like props.children, right? And 1 of them is going to be sent to the browser, another 1 is only going to run on the server, 3 of them might talk to totally different action endpoints, and you just get to describe your UI with components. It's going to be rad. Yeah, I'm pretty excited

00:20:34 Speaker 0: about it. Yeah, yeah, we're definitely looking forward to that for sure. And honestly, I've been pretty skeptical of server components for various things and over time, certain concerns that I've had have mostly been addressed. But yeah, I still have a number of concerns

00:20:54 that from what you have told me, they will not be concerns. And So I'm really looking forward to seeing the early demos and stuff like that once there's some work published there.

00:21:09 Speaker 1: Yeah, they've made a lot of things better. I mean, props to them for showing their work so dang early.

00:21:17 Speaker 0: Yeah, yeah.

00:21:17 Speaker 1: It's kind of disingenuous of me to be too critical of it when they're like, you know, showing it so soon. But yeah, I think it'll be good.

00:21:28 Speaker 0: Yeah, yeah, it's exciting. But so let's talk about V3 then, because I just saw this morning some pretty something that Honestly is a little it's not embarrassing, but it's like how did this take so long talking about middleware and and then

00:21:48 like server context and stuff like that. So the people who are watching this have probably gone through a couple of exercises that maybe some of them already had experience with Remix. I think they'd be kind of interested to hear about the solution. Because we have an exercise where we say, okay, we're going to protect

00:22:08 routes. And so now let's go into all these different routes and say this 1 requires anonymous users, and this 1 requires authenticated users. And they're like this whole section of routes that all need require authenticated or require user on it. And yeah, they're probably hoping for some sort of middleware. So can you describe that a little bit, maybe explain why it took so long?

00:22:31 Speaker 1: So we first expected people, well, we expected to be more convenient to lean on the server that Remix's request handler is actually running on, whether that's Express or Fastify or Fastly or CloudFlare Edge or Vercells

00:22:51 Edge or AWS directly. We're kind of thinking like, oh, okay, that kind of middleware stuff maybe doesn't have a whole lot to do with the UI and we can lean on that.

00:23:03 Speaker 0: Cause you

00:23:03 Speaker 1: can do that. You can put a path like in Express. You can like put a path in there for just middleware. Don't render any UI. So that middleware will run before it then gets to Remix. And you remember when we first shipped Remix, we actually had a separate data folder that like, you just made endpoints in whatever server world you

00:23:24 were in and we would call them and expect that a JSON request, like there was no Remix over there. We were simply just saying, hey, set up some endpoints and we'll call them for data. But it didn't pan out in practice for a lot of reasons, but, cause you want the remix abstractions, right? You want request response.

00:23:45 Speaker 0: Yeah.

00:23:46 Speaker 1: Yeah. Whatever else there you've got going on the way our cookies and all that kind of stuff work And so you've got the adapter for your normal request handler and so to actually make that work You'd need a adapter for all those middleware handlers to to like do it the remix II way or whatever or the webby way Really? Yeah the web API so

00:24:07 and it's not that we ever didn't want middleware. It just felt like something that like, when you're building something new, especially when you're in the middle of a global pandemic and you're trying to figure out a new income source. You're always looking for, what are you trying to innovate

00:24:27 on and what are you not trying to innovate on?

00:24:30 Speaker 0: Yes, this is an important lesson, kids. Listen to this.

00:24:35 Speaker 1: And so you come across a thing and it's like, oh, people are probably gonna want middleware. And you see, well, they're probably shipping on Express or some other server that has middleware. Let's just, let's not tackle that. Let's keep going. Let's innovate on the things that we wanna, that we don't see yet, right? I had never seen

00:24:55 anyone do what we did with forms and actions. I mean, you can look at it naively and say, well, HTML and servers already always worked that way. And it's like, yes, exactly. But the implementation with the client-side routing and the revalidation, all that kind of stuff is wildly different and something I've never seen before. So that like, you know, you

00:25:15 got to spend these innovation tokens, what makes you unique. And so, yeah, we just saw middleware and it was like, we know we need it, we'll get back to it. We would like to have middleware in Remix, but we're just not going to work on that right now. So yeah, we always intended to do it. It's not that we thought that you didn't need it.

00:25:36 Speaker 0: Yeah, you know, I just wanna point out another important point here, and that is sometimes if you solve a problem before you feel the pain as much. Like, you know about middleware, we all know about, like, we know the pains that middleware solves, all that. But within the context of Remix, if

00:25:56 you try to solve that pain point within this new context, you'll come up with the wrong solution most of the time. And so having experienced the pain and going through that and having all the context we have now, it's so much easier to solve this in a way that is gonna work longer term.

00:26:15 Speaker 1: Yeah, we created a bunch of new abstractions that we hadn't used before. And the more things you put on the table, the worse they're probably going to fit. Where if

00:26:25 Speaker 0: you

00:26:25 Speaker 1: just say, let's only do these 3 or 4 things. Let's work with that a bit. OK, now we know where another piece is going to fit in better. That's totally 1

00:26:33 Speaker 0: of the areas.

00:26:33 Speaker 1: It was really easy to keep punting on it, too, because it's like, when you say require user, you usually still need that user object.

00:26:42 Speaker 0: Yeah.

00:26:43 Speaker 1: And so the function that asks for the user also acts as the middleware. So when you can throw a response in Loaders and Actions, it's like you have a call site. There is 1 line of code always to say, give me the user. It can either throw if they're not there, or redirect, or just give you the user. So even after middleware, that line of code isn't going to go away.

00:27:04 Speaker 0: Yeah. And that's actually the justification that I use in the instructions of this exercise where we do this. I'm like, middleware would be cool, but look, we're still going to need these lines of code. And even if you use server context or something, you're still gonna be pulling that from context anyway. So it's not reducing the number

00:27:23 Speaker 1: of lines. There's always at least 1 line of code accessing that thing. It's just a matter of can that function act as a middleware too. But no, there are huge...

00:27:33 Speaker 0: I would just point out the big benefit to adding middleware is, at least in this context, is you won't forget. So, like, let's say you've got an admin page that doesn't actually need the user's data, but you display stuff that's only for admins, right? So that is 1 area where I think having

00:27:53 middleware is a great idea.

00:27:54 Speaker 1: 1 thing that we think a lot about, and we don't mean this to put some developers on a pedestal and other ones not, But there's usually people on the team who understand the app or the abstractions or just the web better than other people on the team, right? Those people usually get put in positions of leadership. And so we often think about,

00:28:15 well, what's an API that the team lead can use that's going to protect the app from the people that don't have as much experience yet, but are still proficient in building the app. But they might forget, oh, this is on the admin page. If I don't protect it, then this endpoint is exposed.

00:28:35 And so the team lead or whoever, senior dev, they can go in and put in that middleware that's like, okay, I wrote this code and it protected all of this stuff and nobody else on the team even has to know that I did this and it's still protected.

00:28:47 Speaker 0: Yeah, even if they add new routes to it in the future and all that.

00:28:51 Speaker 1: Yeah. Yeah. And I mean, so yeah, other reasons we added middleware are just that middleware is good. It's the same reason all frameworks eventually have some kind of middleware. It's just we put it on a lower priority because you already had a server that had middleware. But yeah, I'm really excited about it. You're going to be able to do really good stuff there.

00:29:11 Some of the main things is like error reporting and logging requests. Just lots of things. 1 of my favorites is checking a CMS for redirects. Because a lot of websites, you log into your CMS, and that's where you configure redirects, Right? It's not a file in the source.

00:29:32 It's on some other server somewhere. And so you don't want to check that in front of every single request. Because now you're going off and checking redirects before you even check if your real app can respond to this. And so, Mailware allows you to let the request go through, come back, inspect

00:29:52 it, if it's a 404, now you can go up and go to the CMS and be like, hey, do you have a different page for this? No? Okay, here's the 404, otherwise here's a redirect. And there's really just no way in Remix to do that right now, because there's no point where you like,

00:30:12 I guess you could do it in the server entry. But

00:30:16 Speaker 0: yeah, there are ways, but yeah, they're not.

00:30:18 Speaker 1: It's just weird.

00:30:19 Speaker 0: They don't feel blessed.

00:30:21 Speaker 1: Yeah. Yeah. And then you mix it up with a couple other things that we're bringing in like server context. And I haven't made the proposal for this yet, but a default session. So a default session will come into loaders, actions, middleware and context. And so now like on the backend

00:30:41 of a request, you can just always set your own cookies. If you want to, you could replay a header like you need to do on fly with the Postgres replicas. Yeah, just you'll have that session come through and you can, flash messages will be a lot easier. They'll automatically get committed in 1 spot instead of every single loader that reads it having to then

00:31:02 recommit the cookie, depending on your session's story.

00:31:06 Speaker 0: Yeah, that'll be really nice too, for sure.

00:31:08 Speaker 1: Yeah, yeah, so lots of good stuff. So Remix, we mostly focused on innovation on the front end with V1 and V2. And this, we're now like backfilling all of the big pain points on the back end.

00:31:23 Speaker 0: Yeah, yeah. And I think there are probably lots of other things that like the team has grown a little bit. You've got lots of people working on various aspects of the framework and some, I suppose, working on some of those future things like RSC, React server components, and then others working on more

00:31:45 things that will happen sooner. There's also like exploration in changing the build tooling to Vite, which would be pretty interesting. I know people are really excited about that. Personally, I think that'll be cool, but I'm not like as excited as it seems like everybody else is.

00:32:03 Speaker 1: They're migrating existing React Router apps, right? Or trying to. And us not having an open compiler really just like... You're stopped dead in your tracks.

00:32:17 Speaker 0: Yeah, that's true.

00:32:18 Speaker 1: And then the second thing is the SPA mode for Remix. That also stops you dead in your tracks. It's like, okay, maybe I'm on React router, maybe I even started using loaders and actions, but they don't work on the server yet. And so how do you like make that jump from all this code is expected to run in a browser. And now to migrate to Remix, I need to somehow figure out

00:32:38 how to make every single 1 of these things work on the server. And so now you can bring your own bundler stuff with Vite. You can just bring over a bunch of client loaders and client actions and Remix will actually just probably render a mostly empty document and then do everything else on the client side and now you can just move like 1 loader

00:32:58 over. Yeah, it's going to be huge. But yeah, that work should be done really soon. VEET is, we've got an experimental release, I think, this week that we're recording.

00:33:09 Speaker 0: Oh, really? Yeah. OK. Hey, that's good.

00:33:12 Speaker 1: I'm glad we have it now. We already have an experimental release. We're putting it as, we're actually putting it in the dev branch with an unstable flag. So yeah, it should be there. Oh, okay.

00:33:21 Speaker 0: Hey, that's sick. So people watching this now, it's probably already out.

00:33:24 Speaker 1: Yeah, it's probably already out.

00:33:25 Speaker 0: Unstable, so yeah, that's very cool. So 1 thing I wanna talk about as we wrap up is why Remix decided, like back it up, most frameworks who are doing server side stuff, they have you do, like they kind of build an API around whatever server

00:33:45 request there is and they'll have their own special API. So if you'd have a loader equivalent in whatever framework, what you return is like an object that maybe has a status and it maybe has like a body or something. And then like on the front end, there would be some sort of,

00:34:06 I don't know, some mechanism for accessing that. What I'm driving at is Remix decided to go the route of, let's just look at the WebFetch API and use that. And it turns out that that worked out really well because all other frameworks are starting to do that too.

00:34:22 Speaker 1: And run times.

00:34:24 Speaker 0: Yeah, yeah. And what that opened up for Remix was just like being able to be used pretty much everywhere that WebFetch is available, which is increasingly everywhere. So what was it that motivated that change or that focus and what impact did that have?

00:34:44 Speaker 1: So Michael and I, I think make a great team because I daydream on the front end of like, where are your best practices, accessibility, web performance, what does the network graph look like, are you managing focus, All that kind of stuff.

00:35:06 And then, but I go pretty far into the back end too. I am interested in back end code. And maybe I should let Michael speak for himself, but in my experience with him, he thinks mostly about servers and back end stuff. Like, I wouldn't be surprised if 1 day he was like,

00:35:26 oh yeah, my home page is served from a computer in my kitchen. Like, I wouldn't be surprised by that. So he thinks in those abstractions a lot, and he's good at it. He has built lots of servers and clients, HTTP servers and clients. And

00:35:46 so when we were building Remix, we knew that we wanted to deploy anywhere because I was using Firebase a lot back then for our websites. Unpackage, a project of Michael's, is hosted on Cloudflare Workers. And of course, Serverless

00:36:07 was, I guess, I don't know if Serverless is having its heyday now or if it was back then, but Serverless was kind of like showing up when, I guess it was kind of maturing a bit when we started on Remix.

00:36:21 Speaker 0: It's hard to say where we are on the hype cycle.

00:36:24 Speaker 1: Yeah, I mean, it's awesome. Serverless is awesome. People are no longer saying serverless still has servers. So I think we're past like the initial. Right? And we're looking at all their APIs, like how are we going to run remix in all of these places? They all have these like, like you were just saying. Some

00:36:44 of them like Azure, you would return this object with like a context and that I can't remember it in the status and whatever else. And everyone had their own kind of different thing. And I was like, well, let's just do a little like inversion of control thing. Let's have like a, let's make a thing called an adapter and we'll do like a 2 JSON and they implement that and 2 HTML

00:37:05 and they implement that and just whatever Remix needs we'll just give them a method to like pop in there and I remember Michael and I were pairing on it and I was like to me I was like this is just a quick thing Let's just like get this done and move on to the front end stuff that I'm thinking about.

00:37:25 And then he was like, no, I've been thinking about this. It's like CloudFlare has done something interesting where they didn't copy the Connect API or the Node stuff or Express or come up with their own thing. They actually are basing theirs off of the Web Fetch API, the thing

00:37:45 that's in browsers. And I was just like scratching my head like, fetch, what does fetch have to do with any of this? At that time, my only interaction with the fetch API was like, I'd make a fetch and then I'd await to JSON on or I'd await.json on this req thing. And then I had my data. And I remember thinking like,

00:38:05 why do I have to do this stupid await part? This is so dumb. And he's like, no, no, no, no, check it out. And he pulls up the MDN docs and shows me there's request And then there's response too. And I was like, response? Why do you need a response in the browser? And then I realized, oh, when you make a fetch, that

00:38:25 thing you got back is a response instance. I was good enough at JavaScript at this point to have like figured that out on my own, but I have never even considered that this was a response, right? Like, and everything that that means with HTTP, it's going to have headers, it's going to have a body, it could be stream,

00:38:46 it's going to have a status on it, it's like it's going to have all this stuff. And, And he was like, I think with these 2, he's a CloudFlare already did it. So I think if we just base everything that we do on this API, we can build clients, We can build servers, we can build adapters, and we can actually expose just requests and

00:39:06 responses to Remix users so that we're all just using a spec'd out like community API here and not making up our own thing. And then, and the idea was it'll just work on CloudFlare cause we use the same API as them.

00:39:26 And that turned out pretty much true. Yeah, so that was, that was some awesome foresight for Michael to kind of realize everything that's happening between the front end and the backend in Remix is an HTTP server and client. And so let's pick the WebFetch API

00:39:46 for the abstraction to use there.

00:39:49 Speaker 0: Yeah, good call. What I love about Remix is, it actually is a little reminiscent of my work with Testing Library, where like Enzyme was the big thing at the time. And what Enzyme would do is it would kind of wrap the component, in fact, that's what they called it, it was a wrapper. And then you're using all these bespoke

00:40:09 APIs. With Testing Library, I was just like, I just want the DOM node, please just give me the DOM node. And then I can do whatever I want to with that thing because I know DOM. And so then I built testing library and instead of wrapping it, there are APIs you're calling into, you know, render and all that. But then I kind of expose

00:40:30 the API, the platform API to you. And that ended up working out really well. And I feel like Remix does the exact same thing. You know, it's gonna normalize all those APIs cause you do have Express and you have Fastify and all these other server architectures and things. They all have different APIs, and the Remix

00:40:50 Adapters normalizes that to the web API so that we can just transfer that knowledge wherever we go. When I went into React, I realized the better I get at React, the better I get at JavaScript.

00:41:06 Speaker 1: And

00:41:06 Speaker 0: that's what I loved about moving from AngularJS, which was great and everything, but I dropped a ton of knowledge when I did that. And then coming into React, I was like, oh, okay, I'm just getting better at JavaScript now. Remix makes me better at the web. So it doesn't matter what tools I end up using, because I used Remix, I'm a better web developer and I can

00:41:26 use those tools more effectively. And that's what I love about Remix.

00:41:30 Speaker 1: Yeah, man, it's always good to hear that from people. Yeah, like lots of people don't really know how cookies work or headers or any of that stuff. And then they start doing Remix and they're like, oh, maybe I can do backend code and I can go get a $50,000 raise.

00:41:47 Speaker 0: Yeah, yeah. Yeah, I often say Remix tricked me into being a full stack developer.

00:41:53 Speaker 1: Oh yeah, I remember our early conversations where I was like, why don't, like, just make a password table and Hash it, put it in there.

00:42:03 Speaker 0: Yeah, yeah. So like, I actually, I found the live stream recently and I was watching it where I initially implemented my own auth, I hand rolled auth. And I had these notes that you gave me that were like, step 1, step 2, step 3. And I just went through them in like an hour and I implemented Auth like by hand for,

00:42:23 I'd done a little bit of Auth stuff with Passport.js and Express for like years ago, but never like, never quite like that. And it was just, it was so cool. I felt so empowered to be able to do that stuff. So yeah, Remix empowers me. I really appreciate that.

00:42:42 Speaker 1: Yeah, I think I tricked myself into being a backend developer with Remix too.

00:42:48 Speaker 0: Well, cool, Ryan, we're down to the end of our time. Was there anything you wanted to talk about that we didn't get to?

00:42:58 Speaker 1: No, I didn't have an agenda. I'm just happy you're here and everybody else is here watching us.

00:43:04 Speaker 0: What's the best way for people to contribute or like keep up with what's going on and stay current with Remix?

00:43:12 Speaker 1: I mean, probably just follow our X account and star the repo on GitHub or I mean, who cares about stars, subscribe to it. So you get notified when we push releases and stuff like that. All of our releases have release notes on them. So you can just go to GitHub, click on tags, click on releases.

00:43:33 And we take those release notes pretty seriously. And that's how you can know the latest stuff. We also post RFCs and proposals in our discussions tab on GitHub. And so that's a great way to kind of see where our minds are at on what we're going to be doing. Our roadmap is public. If you go to our org on

00:43:53 GitHub and click on projects, you'll see the roadmap project. So that's what we're working on. And that's what we use internally at Shopify too. Like that's what the Shopify teams look at too to see what's the Remix team working on. It's all the stuff on GitHub, it's all the open stuff. So everything we do is open like that.

00:44:12 Speaker 0: Yeah, that's super cool that even after the Shopify acquisition, I feel like the Remix team just got even more resources to be able to continue doing exactly what it was doing.

00:44:23 Speaker 1: So super- Yeah, there's a lot of adoption internally at Shopify and a lot of autonomy too, where they're just like, we love the work you're doing, keep doing it. And so I know a lot of people are like, oh, it's just gonna become an e-commerce thing. And it's like, that's hydrogen. Like, and Shopify wants Remix to be successful for a lot of reasons, not just stores,

00:44:43 but internal apps, embedded apps, Shopify.com itself. And we've, it's kind of, it's a little stressful. Normally when you're a new framework, like you get adoption of like smaller scale stuff. And then like the scale of your customers goes

00:45:03 up with the scale of the code and the lifespan of the code. But at Shopify, it kind of got just like thrown at like some really big use cases immediately and it's like, oh crap there's a memory leak and everyone thinks it's remixed and you dig in deeper and it turns out, nope, it's not remixed, it's a notes, new request

00:45:23 response polyfill, not us, but.

00:45:26 Speaker 0: Oh dear.

00:45:27 Speaker 1: But yeah, you find, we find our own bugs too, I just don't want to admit them permanently

00:45:32 Speaker 0: on the video. Yeah,

00:45:35 Speaker 1: sure. But yeah, it's been huge for the project to just like throw us in the battlefield early and we're getting a lot better because of it.

00:45:45 Speaker 0: Yeah, I think it's just been awesome seeing that over the last year. Well, cool, thank you so much for giving us this time today. And yeah, I'm looking forward to seeing all the other cool stuff that y'all are working on. Thanks everybody. See ya.