Fire-side chat on Remix

All right, hey Chance, how are you? Hey, Brittany, doing well. How are you? How are you, Paul? Hey, great to see you. Awesome. We're all doing good. Thank you so much for joining us for this fireside chat.

We've been asking all of our speakers, I know you don't have a talk but I want to ask you too, we asked the audience in the beginning, what is their favorite Remix feature. So what is your favorite Remix feature? Oh, and that's – how do you answer that question when you, like, work on the whole thing? Say all the things.

All the things, yeah. No, seriously, though, I think one of my favorite – I don't know if you'd call that feature, but my favorite things about Remix is just sort of the modular design that we sort of started on. We – the way it's designed, I think, is really – it's really helpful in some of our longer-term goals of being – supporting multiple rendering frameworks. And our current goals of supporting any run time, right? You can sort of tear it down into parts, different levels of abstraction and ship anywhere, which I think is great. Yeah, I guess just the ability to ship your app on any run time is a really awesome feature. You don't have to worry too much about us not supporting your run time because we're built on web standards, right? As long as your run time is built on web standards, you can ship Remix, right? And I just really love that. As far as individual features, I have to say, like, the mutation story in Remix is excellent, like being able to grab data from your actions immediately after using interactions without actually having to manage any of that state internally. I think it's just a superpower. I really enjoy working with those. Yeah, that's a great answer. Yeah, that's awesome.

My first question would be what would you say the biggest benefit for Remix is now that is part of Shopify? Yeah, no, that's a great question. And it's one that I think we were all asking ourselves internally at the very beginning of the process. And now that we've had some time to let it shake out, I'm very excited about it. I think it's going to be a huge deal for us to be able to sort of dog food some of our design questions and our early thoughts and ideas and features. To be able to dog food that through Shopify, which manages some of the largest e-commerce sites in the world, that's going to be invaluable data for us, and really is going to help us make a lot of our features and future intentions and our future designs are going to be that much more resilient and bulletproof because we're going to be able to test those things internally through Shopify and get lots and lots of feedback before we have to worry about going public with these things. Now, we still are very much an open source project. In fact, I think one of our biggest goals since joining Shopify is to lean into the open source side of things a lot more than we may have in the past. And so, we've recently instituted an open RFC process where folks can go into the Remix repo and submit RFCs, submit feature requests that go through a process and we debate those internally. And that's true of all of our internal discussions as well. Any features that we want to introduce in Remix, even internally, we are now enforcing this RFC process and it's done all in the open. So just because we are a part of Shopify, we really are still leaning into the open-source story of Remix. And I think it's going to be really cool to be able to get the feedback and the high amount of production usage from the Shopify team, but also being able to develop in open and public, I think it's still really, really important to us.

Absolutely. That's amazing that they're going to allow you to still work in the open and have that community feel that we've come to know about Remix and be able to contribute back to it. Do you think that Hydrogen is going to influence any of the Remix features now that you're kind of working alongside of it? Yeah, I think absolutely. In terms of just, again, the ability for that team to be able to provide insight and to provide feedback to us, I think that in of itself is highly valuable. And certainly will influence us. But to the degree that we become a Hydrogen or Shopify product, that's not in our cards. That's not the plan. That was never part of the story. And it's not how we're going forward with this. We are still very much Remix. We are what we were when we started and joined Shopify. And they invested in us because they believe in that vision. And they believe that Hydrogen is going to benefit from Remix, just like Remix is going to benefit from the usage in Hydrogen. So our intention is to work very closely with the Hydrogen team to help them ship really, really solid products for their users. And we are still very much a separate layer from that. But yeah, that feedback loop is highly valuable and that it's certainly going to influence us in the long term. But I think we're just such a naturally good fit for what they're doing already. So it's really just like a really great matchup in my mind.

Absolutely. Yeah, no, that's great. I tried Remix and I fell in love with it. So many amazing features and I literally, it's such a pleasure to work with. And my question is, what feature are you most excited about that is not currently released?

Oh, we have lots. We have lots of great ideas on the roadmap. We've got a public roadmap now too, which I'm really excited about. So going back to leaning more into the open, you can go and read about some of the features we're talking about releasing in the next few months. I'm really stoked about that. But yeah, if you take a look at that, we've got a few things. We've got the, so if anyone's used React Router 6.4, we just released React Router 6.4 just a few weeks ago, maybe a month ago at this point. And we really baked a lot of Remix features into React Router. And we've even baked in some features that are not in Remix yet, into React Router. So you can sort of get a sneak preview by going and checking out React Router 6.4.

One of the features I'm really excited about is the ability to send promises in your responses from your loaders and actions and wait on them to resolve in your components. So it's sort of modeled after the whole idea of suspense, right, to a certain degree. But being able to do that and defer certain responses that might take a little bit longer to resolve right there in your components in a very declarative way I think is really awesome. It's sort of our answer to what they're trying to do with server components to a certain degree. But we have a slightly different take on that. So I'm really excited about that feature. We're calling it the deferred feature. You can actually try that out today. We have an npm tag deferred where you can experiment with it. We cut new experiment releases with that work pretty frequently. So, yeah, it's really cool. You can do a lot of cool stuff with that, and we've got a few examples in our examples repo as well, using that. So that feature is going to be awesome.

We have a lot more work to do on the styling side of things, supporting certain styling solutions that require some compiler integration like CSS modules, vanilla extract. Those are two technologies we've been talking a lot about internally and being able to build support to those things directly into Remix without having to have that first step compiler pass is going to be really valuable, I think. So very excited about that as well.

Yeah, I'm very excited about those and what you said about the server components. I might come back to that in just a minute. Any of these new features that you're excited about coming into like Remix version 2, is there anything you can tell us or are you excited about Remix version 2?

Yeah, I mean, it's all out there in our roadmap. So if you go to GitHub and click on the projects tab under the Remix repo, you can check out a roadmap. That's everything's right there out in the open in the public. One of the things I've been working on this past couple of weeks, is we're making some changes to our route meta API. Maybe not as exciting of a feature to talk about, but it is something that I think our current API is a little lacking. One of the cool things we're doing with this, actually, is we are adding the ability to opt into these features before updating to v2. So when this new meta API is released, for example, you'll be able to opt into that with a flag in your remix config, so that you can get a head start on upgrading. When v2 comes around, you can upgrade incrementally, which will be really nice. I think we're planning to do that with pretty much every feature that we're going to release in v2 that is a break and change. I think it will be a really nice upgrade path, and will help ease some of the pain points. Because one of the challenges with any software in the v1 stage is that it's v1, right? This is our first go at it, and we're going to make some mistakes. We're going to maybe not fully understand some of the ways in which folks are going to interact with these APIs. So, at that stage, long term we aim for stability. But at this early stage, we are going to have to make some breaking changes to accommodate some of the things that we may have missed along the way. And so, being able to do that in a very smooth, incremental way, I think is going to be super helpful for folks who are trying to keep up with things as they progress and change.

Oh, I think that's huge, that you're providing a migration path for your users to go from v1 to v2. That makes so much sense. Yeah, that's awesome, that's awesome. And I want to ask you, has there been any more news about making Remix framework agnostic along with React Router?

Yeah, so I love that question, and I love talking about this because it's something I'm really excited about. Going back to what I was talking about very early on, where the way we've designed our APIs and the various packages is that everything exists in its own lair. And Remix was built on top of the fundamental ideas of React Router, which means that it was very much linked to React. But that's not necessarily the case anymore because when we re-architected React Router in 6.4, we separated out the React part of React Router from the underlying core logic, which now exists in its framework agnostic package, Remix run slash router. All of the logic lives there now, all the routing logic, all the superpowers right there in that package, completely separate from React. So we manage all the navigation, stay outside of React now. And I think that is going to really enable us to take off with this idea. And it's something that we've experimented internally. One of our guys, Matt Brophy, is a big Vue guy. He came from the Vue world and has done a lot of work in that space.

And he's already, months ago, created a proof of concept Vue router that we can use to create a Vue adapter. And we've had some really awesome contributors out there who have experimented in this space as well. I think just out in the open, some folks have developed Svelte adapters. And I think someone has developed an Angular adapter, right? There's been some really cool work in exploring this framework agnostic space. And it's absolutely something we aim to do. Internally, we work with Jason Miller now at Shopify, who obviously is the author and maintainer of Preact. So I'm really excited for Preact support because I still love React, but sometimes you don't need the whole thing, right? You just need the very simple APIs that you can bring a lot of that in with a lot less weight in your bundle. So I'll be really excited to start playing around with Preact when we get that router up and running. So, yeah, no, it's happening, and we're very excited about it. I'm very excited about it. I'm super excited about that. Yeah.

You spoke about the Svelte adapter, and Austin Krimm is the one that was working on that. He gave a talk at Svelte Summit on that, and I thought I was like, ooh, I love Remix already, but if I can use the language that I like to write in as well as use the framework that I love, I'm super excited about the future of all that.

And so earlier, I said I would come back to this with the server components that you were talking about. So how closely is the Remix team working with the React team and getting, like, those server components, and how is that working? Yeah, that's a great question. They've been in contact with us, and we've been in contact with them about just general offering feedback on some of their designs. I know that that feedback was crucial to a lot of the changes they made in the recent release of server components. If you've been following the server component story, there's been a lot of changes, right, from the initial RFC to where we are today, and it's still not finished, right? That story's not done. And so we're very excited to see where story components go and very open to providing feedback I know that some of our team members are speaking with the React team on a fairly regular basis. I'm actually gonna have lunch with one of the members of the React team today. So, yeah, there's certainly a lot of opportunities for us to collaborate, and I'm really excited to see where server components go.

Right now, a lot of folks are asking us right now, why don't you support server components? And the short answer is we just fundamentally have different takes on some of the same goals, right? That was a part of the motivation for Remix well before server components were a thing, right? So just sort of because of the different fundamental approaches we take to solving some of the same problems, we just don't need server components right now. However, I think there's a lot of opportunity in the future, depending on how that technology progresses. I think there's a lot of potential in reducing bundle size through partial hydration if we can sort of break that away from some of the data-loading APIs they're aiming for with server components. So, yeah, I'm very much looking forward to that collaboration and seeing where that story folds out and how we can bring some of the advances there.

Yeah, is that partial hydration story part of the reason why you would want to use server components? Because Remix is server-first already. So you're already on the server side. What's the benefit to adding these server components in React? Well, that's kind of what we have to figure out, right? Like, we don't know because the story of server components is just not done. It's still kind of a beta software, and, you know, I'm excited to see what happens with Next.js and their embracing of server components because, you know, we work— obviously, we've talked about working very closely with the Hydrogen team. They worked—they were one of the very early adopters of server components before— in the very early APIs, like, they really took a big risk on embracing that. And they ran into some issues, and that feedback is—was also highly, highly valuable for the React team in making some of the changes they did to server components. So, yeah, I see this as an ongoing saga that, you know, we'll see how it plays out, but that collaboration is going to be crucial in making sure that server components and Remix are successful in achieving their goals.

Awesome. Yeah, I could see a lot of people are excited for all the new features that you're all going to come up with because people are already asking, when is the first roadmap livestream planned? When is that happening? What is—come on, let's dig into that. What do we mean by that? When are we livestreaming? The question was, when are you going to livestream talking about the roadmap? I think that's what they were asking. We can do it right now. Do you want to pull it up? You're going to share your screen and we'll go through it? Yeah, I'm telling you, it's public. Go check it out. It's in GitHub. Yeah, it's all out in the open.

Yeah, it's all out in the open. If we want to talk about it, I'm happy to, but— I guess more like, are there going to be livestreams around building out the roadmap or the RFCs? Or anything like a community, maybe, discussion that could be had there? Is there anything for that?

Sure, yeah. Yeah, I love the idea. I haven't personally planned any livestreams around building out features or anything, but I could certainly do that. I'm trying to embrace that as my personal goals of being more of a content creator of sorts for Remix. That's a great idea. I don't know. Give me the ideas because I'm still new to this. They did clarify that Ryan and MJ are about to livestream bi-weekly. Ryan mentioned that somewhere, I guess. Okay. Yeah, we'll watch them because they're smarter than I am. But I like that transparency. Hey, our roadmap is public. You could just go and look at it if you have any questions, but that's pretty awesome. I actually want—

Yeah, and also, sorry, I just want to say, not only just go look at it, but we have a very active community Discord, too. So if you have questions, you can put them right there in GitHub. You can come talk to us in Discord. We're all very open. My DMs are open in Discord, so we can certainly figure out a livestream to talk specifically about the roadmap. I think that would be a cool idea. But in the meantime, we're all out there in the open. Come grab one of us and ask some questions if you've got them. I think that's an important thing to point out for these open-source communities. You going and commenting on these RFCs is so important for the ecosystem in general. You need to go and make your opinion known so people can talk about it. Maybe you have a different perspective that you haven't thought about before and the team hasn't thought about before, and you can open up a discussion on that. That's a great point. Yeah, there's always people using our software in ways that we never anticipated, so we would love to hear that. So everybody go and join the Remix Discord and become part of the conversation.

Here's a funny story. I love everything about Remix, and I was doing something. I asked a question on Twitter and one of the responses was like, hey, why don't you join the Remix Discord. I'm like, obviously, duh. A lot of great folks there, a lot of great communication, so a lot of great places to get your answers. But I had a question around what motivated you to create Remix in the first place. How did that come to be? Well, I can't speak 100 percent with 100 percent authority there because I didn't create Remix. I joined Remix. I was one of the first employees, but I, unfortunately, cannot take credit for the creation of it. But I can tell you some of our philosophies that motivated us. You know, this is all also out there in the public. We have a section of our docs that outlines our philosophy. And really what it comes down to is just nothing else in this space existed that met the goals of our philosophy. We wanted to be built on top of web standards first and foremost. A lot of existing tools sort of abstract those away from you. And abstractions are sometimes hard to unwind from. And they can lock you into certain technologies that you might not be personally invested in. So going back to this idea of runtime agnostic, framework agnostic, that would be very difficult to do if we did not lean into the web APIs. So just being able to lean on those, to use those, to expose those directly to users, I think is a very powerful design. And that was one of the biggest underlying motivators for that is that that just didn't really exist. And a lot of the ways that we've been building React apps over the years also just prevent … React is great. We all love React. Obviously we built React Router. So if we didn't really love React, we wouldn't be there. But React encourages by its component-driven nature some things that I think have created some undesirable user experiences over the years. You see this in a lot of React apps where you go into – you go to your app and you see all these loading spinners pop up because different components are doing their own data loading and they're not hoisting that stuff up to the route level. And so you just get all of these data waterfalls that really slow things down and make the user experience a little janky and unfortunately much slower. And so in pursuit of building better user experiences, we wanted to create designs that made the right thing the easy thing. And that was also a big motivator for Remix and just designing something that made it easy to move data loading where it needs to be at the route level and parallelize a lot of concurrent data requests where possible. And so we reduced the number of requests going on.

We can speed up the whole experience and reduce the number of janky loading spinners everywhere on the screen. So those are sort of two points. But yeah, go check out our — I won't read every bullet of our philosophy, but it's on our docs too. So if you're curious to dig in there, a lot of our motivation is outlined in that section.

That was kind of my understanding as well is that that focus on the web fundamentals are really where the desire came from to create Remix. And I love that it's embracing that and becoming more of kind of just a standard.

I do have an aside to that. So is there any story — is server side first and only going to be the story for Remix, or is there maybe like — I know you can do some caching, but is there any way to — our potential future to do static generation or any other type of rendering? Yeah, that's not in the roadmap today. We do very much lean into — your data is often dynamic. It runs on a server, and yeah, right today you need a server to build Remix. Obviously, we've got adapters for things like Netlify. You don't have to like actively load data from a server. You can obviously create static content if you want to. But static generation is not in our roadmap today. That said, I don't think any of us have necessarily ruled it out. We do have some workarounds right now for folks who do really want to generate some static content. We've been experimenting with this internally a bit, and I think the potential is there. But we have to do so in a way that sort of still fits within our overall goals. One of the other points in our philosophy is that your data is fundamentally separate from your code. And we just think that's generally a better design. So if we can sort of still achieve that while being pragmatic and realizing that, in some cases, some folks might want to or need or prefer static generation, it's possible. We haven't ruled it out, but it's not in our immediate roadmap.

Yeah, that makes sense. There was something else I was going to say, and I just lost it, but it was about the web platform and the way that, yeah, my mind is gone. Do you have another question, Paul? No, I was just going to say, you know, I mean, to me, I'm surprised when someone says to me they didn't try Remix, but there are actually people that exist that haven't tried Remix. If you were to give them one reason to try it, what would it be? Well, so here's the thing I have to admit. I'm not an early adopter myself. I'm like – I like to get stuff done and ship software that's built on top of other things that I know have been battle tested, so I get it. I'm not – I'm still out there using CSS modules because that's what I love to use, and they've been around forever, and the idea just checks out, right? So I'm not jumping on top of all these new things just because someone on Twitter is talking about it, so I totally get it. But I think it's worth a shot, honestly.

When I used it for the first time, it really did simplify a lot of the things, and to me, that was the biggest selling point, honestly. In the early days before I actually worked for Remix, and I was just one of the subscribers when we were a paid product. I chipped in some money and actually bought Remix in the early days and tried it out, and the first thing that struck me was just how much it simplified a lot of really hard problems. And so if you're really interested in simplifying a lot of the code that you write in your app and removing a lot of the logic that has driven you nuts in the past, to me the huge selling point right off the bat is just seeing how much of your code just melts away and Remix handles a lot of that complexity for you. It's pretty awesome. Yeah, if you want to go try it out and you need a reason, deleting code is a good reason to do anything. Yes.