Remix — The New Create React App

I today want to talk about the new Create React app. I should have called it Create React app 2.0. I like that. That's a good title, too. I'm going to stick with this one, the new Create React app. And I do need to focus keynotes, so I can actually move through it.

My name is Brooks Libran. You can find me on Twitter and Discord and GitHub at Brooks Libran. That's pretty much it for about everything. I work on the Remix team as the developer relations manager for React router, which is by the Remix team, which is from Shopify. Just to make it really, really clear. In fact, I took a crack at updating our logo. Please don't tell Ryan Florence I did this, because he will get really mad at me. I've messed up our logo so many times, and he's very particular about how it looks. And this is definitely wrong for a couple of reasons.

So here's my question. Has this ever happened to you? Have you ever found yourself in this situation where you want to try out the hot new UI library, React? You've been hearing a lot about it. It's been getting some attraction. But you don't want to spend forever configuring web pack and Babel and all these ridiculous things. You just want to build something.

You just want to build your application. And you want a good set of defaults so you can just get started. You don't want to be thinking about all the different stuff you have to set up. You just want it to be set up so you can get started building your application.

And you don't want to be locked in. You do want an option to eject from this nice, pure world if you need to add some more complicated stuff. Maybe eventually you do finally learn how web pack actually works, and you can decipher the documentation that you want the ability to eject. Also pretend that it's 2016, and this statement probably makes a lot more sense. So if this is true of you in 2016, well, I have great news.

Introducing create React app from the Facebook team. This is the default way to build a React app in 2016 at this time. The way that you would start a React app, for the most part, especially a new, fresh one, a pure spa, where everything is client-side and it's beautiful and jamstack is coming and it's going to save all the problems, the way that you would do this is you would typically copy and paste from someone else's starter kit or maybe cobble together a web pack and double yourself. And it was a very, very bad starting experience.

So the meta team at Facebook decided to build create React app as the de facto starting point. And it was very successful. So Dan Abramov and Chris Bruchardo, two of the kind of core members of the React team, kind of created this, and they set out with this vision, this goal, that this would be the blessed getting started experience for building spas in React that you can actually ship. You can actually ship these spas. It's not just like a demo thing. We want create React app to be a starting point where you can actually just go ahead and build and put this up on any sort of static server. And so the goal, like I said, was to make it very easy to get started with React.

And the way they did that, they had kind of three major pieces to their philosophy. So the first was zero configuration. You shouldn't have to set anything up. You should just be able to get going. Why am I messing with Babel and web pack? I just want to learn React. I just want to build in React.

Next, just one dependency. React scripts. Just that one dependency, right? I mean, let's hide the fact that, yes, it is Babel and web pack underneath, but that's how the tower of MPM node modules works anyway, right? It's always hiding other things. It's hiding that complexity behind this one dependency.

And then finally, there's this exit strategy that I talked about. Eventually, your application may get really complicated. Perhaps you want server side rendering. That's how you want to escape the Jamstack world. You want server side rendering. And so you're going to need to expose your web pack bundle and figure out building it yourself. And so you need an exit strategy or ejection as they called it. And they really believed that this would not fail. That this create React App experiment, not just experiment, project would not fail. They didn't think it was going to fail because they intentionally were offering this minimal set of tools.

You have this ability to exit, to eject the getting started experience. And they were going to promote the hell out of it on the website. This is the solution from the React team. And I actually think it worked really well. It really didn't fail. But of course, as the American journalist and author, Gene Fowler, once said that open source projects are never finished. They're just abandoned. And that is unfortunately what happened to create React App.

This slide I stole from Ryan. So it's actually outdated. But today is the birthday of the last commit to create React App. So happy birthday. This isn't to shame anyone. The create React App project really was successful. And it lived on a long time. And it's been on this slow path to deprecation. If you look at all those points, it's 2023, then 2022, 2022. It's not a project that's been actively worked on and it's not a project you should be using to start your React applications today. There's no shame in that. I think it's really at a point where it's deprecated.

In fact, even the React website, the docs themselves, do not recommend create React as a starting point for your next React App. So I think it was mostly successful.

There's one little gripe I have about create React App, actually. So when you start it, this is what you get. Hopefully, yeah, that's good size. You get a pretty simple setup, right? A read me package, package log, standard stuff, a public folder with very standard stuff, have a con, everything like that.

And then your source is actually really pretty easy. You've got setup tests. So it's got some tests for you that's nice and like a single app and whatnot. They used to ship a server worker with it, which was super obnoxious. So, unfortunately, they got rid of that. Man, we all learned how those worked really quickly. And it was not good. But the thing is where that escape hatch, that ejection would end up doing this. It would explode it into this Babel and Webpack config and all this kind of stuff that you're immediately slapped in the face with, oh, yeah, I did want to escape. I did want to eject. I wanted something a little bit more complicated. But man, you just gave me everything. So, yeah, kind of tough.

I also found it interesting that when you eject, they shared a Google form where you could give feedback.

You can go fill out this if you want. I have no idea if anyone's going to ever read that again. Again, I have no idea where this even goes to. But it still exists. I actually really like that. I like that they wanted the feedback. But basically, the Google form would ask things like, why did you eject? Maybe not. That sounded kind of aggressive. Just like, why did you eject? Why did you want to... What were we missing? What could have been better about Create React App? And so that was kind of what they had to do with Create React App.

They kept on having to add new features. If like styled components came out, they'd have to add that into in support for it. And eventually, they were just holding this giant Webpack config that could just do everything under the sun for you. And it just kind of ballooned. It ballooned in a way that wasn't super sustainable. So what happened next? How are people building their React applications, especially like a spa like Create React App if you can't really use Create React App? Well, along comes Vite. Who here has used Vite before? Okay. That's, I mean, basically the entire room. Maybe 80%, 90%. Vite is such a cool project.

It came out of the Vue ecosystem. It's been adopted by so many different frameworks beyond Vue. And more recently, it's gained traction in the React community through Redwood, I believe, was before us. Astro, of course, uses it. And then, Remix most recently. So it's this very cool project that we've all kind of centered around.

And it's very much a... It's designed for frameworks is really the way that it's kind of built. And it also, when you're using it for React App, it also makes it really easy to get started with React. And it's kind of a similar philosophy. At least, this is what I've been able to parse. It's a really easy configuration. It's not zero config, but it's pretty easy. In fact, if you want to create a new Vite project, you just do npm create vite, you tell it, you know, React, and then you get these five options. That fifth one is really interesting. We'll get back to it. And then you just have this one dependency, or maybe two, kind of depending on how you think about it. Again, dependencies are kind of weird because they hide things anyway. You just have this one dependency of the React plugin. So you've already bought into Vite, you're already using that.

That's essentially the replacement for the webpack piece. And it's doing all your build and everything. And yeah, you just have this React plugin. Very simple. Just one dependency. It's really nice.

And then finally, you have a exit strategy. So what is the exit strategy in Vite? Well, it's a little bit different. And anytime there's quotes around a word, you shouldn't be suspicious. The exit strategy is the fact that it really doesn't have an exit strategy. It has a quote strategy. It has this really nice plugin system that's actually really easy to author plugins and for them to all work together in a way that webpack just is a little bit more difficult.

So how's this been working out? Well, here's good old npm trends of React Scripts, which is how create React app works. That's that one dependency versus Vite. And as you can see, in early 2023, Vite took off and just meteorically, I guess maybe not meteorically, much, much better trend than how React Scripts has gone, which is fine because React Script, again, it's dead at this point."

It wasn't an injection and here's all the crap that you now have to deal with. It was a, no, just start with the React plugin and then build up as you need more stuff.

So how's this been working out? Well, here's good old npm trends of React Scripts, which is how create React app works. That's that one dependency versus Vite. And as you can see, in early 2023, Vite took off and just meteorically, I guess maybe not meteorically, much, much better trend than how React Scripts has gone, which is fine because React Script, again, it's dead at this point. It is deprecated. That line should be going down. I would like to see it go down a little bit faster, but that's just the reality.

Also npm trends are, it's a trend. That's all. We're not worried about raw numbers here necessarily. But the reality is Vite is being used way more than React Scripts. Of course, that's including things like Vue and all sorts of other things that are using Vite. So it's not necessarily a one-to-one comparison, but the point is just that it is winning at this point, which is really good.

And a more interesting trend that I think Evan View shared yesterday in his talk at JS Nation, but I first saw it by Patak, who is on the Vite core team, mentioned that Vite just crossed 13 million weekly npm downloads. But more importantly, it's actually like half the Webpack downloads at this point. So Vite is really gaining traction. It's really in this good place. And even Webpack kind of is having a little bit of a stutter. I am going to call this out because people, there's always someone who's a little bit like, what in the world are those dips? So on npm trends, when you see those dips, that's just the holidays because everyone turns out their CI, CD, and we all stop working for a little bit."

I am going to call this out because people, there's always someone who's a little bit like, what in the world are those dips? So on npm trends, when you see those dips, that's just the holidays because everyone turns out their CI, CD, and we all stop working for a little bit. So if you're ever confused and you think npm trends is unreliable, it's December. That's all it is.

Okay. So I titled this Remix, the new Create React app. And Pierre was very, very nice to point out to me that that made no sense. I said, what? Space, question mark. I'm not saying that Remix isn't good, isn't a good tool, but ViteJS is unquestionably the replacement for Create React app. And by the way, in case you didn't know, I compared a framework with a builder, colon D.

So I told him, I guess you have to go to talk. I actually agree with Pierre. I hope he's here. I have no idea. But I actually 100% agree. Vite is the replacement for Create React app. I was talking to a colleague, Mark Douglas, and he even, he had a better way of putting it. He said, really, Vite is the Create JavaScript app at this point. It's so much more than just Create React app, but it absolutely does replace the experience that we had with Create React app. I did not title my talk Remix, the replacement for Create React app, though. That's not very interesting, and also I'm not going to compete with Vite.

That's not very interesting, and also I'm not going to compete with Vite. Vite is the winner there, and we're using Vite, in fact. I titled it the new Create React app. I use that word specifically because the React docs themselves talk about how you, as you're starting a new React project, if you're starting a new app, a new Fuli website built fully on React, they really do recommend using a framework. They list some popular frameworks in the library, Next.js, Remix, and a few others, Expo, if you're using native.

Most people have this question of, hey, what if I just don't want to use a framework? Can I use React without a framework? Of course, their answer is no, you cannot use it without a framework. This is a joke. This is not what it says. But it does say, if you're building a new app or a site full of React, we do recommend using a framework. And the reason being, we found, the React team has just found that most apps and sites eventually build solutions to common problems such as code splitting, routing, data fetching, and generating HTML. This is something that Create React app never fully supported just out of the box. These were all choices you had to make eventually as you were building your Create React app anyway. There's really no such thing as a Create React app, as much as I've been saying that, because you end up building kind of your own little thing.

In fact, when you go and you're trying to figure out if you're going to use Bootstrap and Flow and Relay and all these really relevant technologies that we're all using today, if you go down to the adding a router section, it says, hey, you can use any router you want. React Router, that's a very popular one. So even back then in, what was this, 2018? Cool, like five and a half years ago, they were even recommending React Router as your routing solution at the time. And recently Rick Hanlon, on a panel at React Conf, when he was talking about this specific kind of question in the React docs, he made a really good statement that really resonates with me. He said, you're either using a framework or building a framework. And building a framework is really hard. I know this because I work on a team with a bunch of people who build a framework for a living and they don't even let me touch it because it's that hard.

I can use it, I just can't commit the actual code, you know. And I also have experience with this with my previous job. I was at a grocery store in Texas called H-E-B and we had built our own framework. It was even before my time, I was about four years old at the time and it had server side rendering and data fetching patterns and all this kind of stuff. And it was kind of antiquated, honestly.

And even though I was like a remix shill at the time, didn't even work for Shopify, I was not the biggest proponent of getting rid of it. The creator of it was the biggest proponent of getting rid of this framework that he had built and adopting something that actually has a core team around it like a remix or an XJS. So where could you get all of this? Where could you get code splitting, routing, and data fetching, and generating HTML all just built in when you create this new React app 2.0? Oh, wait, sorry, that slide's wrong. There we go. React router, of course. That is the solution, right?

An important piece of this conversation to me is I need to talk a little bit about spawn mode. So if you're not following Remix and what we've been doing there, last October-ish or end of the year, when we were working on the Vite plugin, when we were switching to using Vite as the build tool and making Remix just a plugin, we also released spawn mode. It's kind of a misnomer, honestly, because Remix has always been a spawn. It's always been server side rendered, but then it's enhanced as a spawn. You can opt out of that and make it a full multi-page app, but you did have to have server side rendering, and then everything has these client-side navigations. And then we released this thing called spawn mode, which actually works exactly how create React app worked. It's a pure spawn, as people say. I don't know why a server rendered spawn is an impure spawn, but it is. So a pure spawn, totally client-side rendered. That's it.

Just your initial shell of your HTML is all that you can render, some initial shell. And so this was also really helpful, because it created that migration for people who just want a pure spawn. Even at Shopify, we actually had really good use cases for people who did not need server side rendering, even though we think for the majority of applications and websites, you benefit from server side rendering. It's just not the case for everything.

So this was a really big piece in conjunction with the Vite plugin. And in fact, Patak, on the Vite team again, said that once we released spawn mode, he kind of noted that there was really a high chance that Remix would end up filling that create React app void that was left. So this is a Vite team, this is not me saying it, making this point too. And he went on to say, people wanted us to turn Vite React starters into the create React equivalent. So even the Vite team is saying, that's not really what we want. That's not the right path.

The new create React app, the new one, not the replacement, the new create React app has to come deep from within the React community. And so that's why we actually have that little Remix option at the bottom, is because once we released spawn mode, he followed through, and we got to put that option in there.

So recently I've been joking about it, maybe you haven't caught on exactly, but we have this little bit of a branding issue, which is really fun as the dev role person, right? We're actually merging Remix into React Router. The reason that we're doing that is because React Router's always been, rather Remix has always been React Router, the framework. That's really what we could have called it and would have been just as true. We've been building migration paths so that people on React Router can get to Remix very, very easily.

We made that migration path way too good, and they are the same project now, essentially. Especially with the Vite plug-ins. We just got to this point where it's the same project, essentially. We have two versions of it and that really doesn't make any sense. Plus for all the React Router users, we want them to be able to migrate more easily. Migrating is a much different conversation. Rather, I said that wrong. We want them to upgrade really easily to a new major version. Upgrading to a major version is a very different conversation than migrating to a framework. If you want to learn more about this, I would recommend reading this blog, Merging Remix and React Router. And then Ryan Florence gave a really good talk talking all about the motivation here, so I'm not going to go into all the details. More just trying to say that React Router 7 is our full vision of everything we wanted Remix to be and more. So what should this new Create React app do? Let's take a step back. Let's forget Remix and React Router and all that for a second.

I just want to say what I think a new Create React app should have. I don't think that Remix is 100% there. I made the cheeky title, but I actually think I was wrong too. So what should the new Create React app have? So I think the new Create React app should make it easy to get started with React. Can't lose that. That's still got to be true, right? What are we doing if we've lost that piece of it? Should have solutions for code splitting, routing, data fetching and generating HTML straight from the React docs. That's like the four big things that you should have out of the box that your framework is doing. You're going to build that otherwise. Be nice if you can just do it. A lot of stuff is related to routing anyway. It should be up to date on the latest React features. React Scripts is not up to date on the latest React features. All right. I'm running out of time. I'm going to go through these. Have good community buy in and also have a defined future. So how easy is this? We're talking about getting started with the getting started experience. We already talked about this being incredibly easy. This is not much different. It's the same thing.

It's just a little bit longer on that first line. This is the experience with Remix. Getting started with the Remix app is this on beat. And when we go to React Router, it will look like this. It's no different. API is not final. That slash dev might be called something else. I don't know.

We want it to be a plugin. Incredibly simple getting started experience. What about the code splitting and routing and data fetching and generating HTML? We have all that stuff. We have a built into React Router. Remix with this plugin is going to make it a lot easier. And with V7, which is coming pretty soon, we're also going to support not just SSR and client side rendering, but RSEs.

It's a very interesting topic. Server actions, of course. Static free rendering, static site generation is how you hear that. We don't like that term. We like static free rendering because it makes more sense.

We like static free rendering because it makes more sense. And type safety. Just to throw that in there. People have been complaining forever that React Router isn't type safe and threatening that they're not going to use it anymore. Which is okay. You don't have to use our stuff. I think it's good.

So we're coming along with all this stuff. And we're going to stay up to date on the latest React features. We'll have support for React 18 still and React 19 and React components and the compiler. And the community buy-in piece, this is it. This is the reason. Remix is at the bottom there. It's just that Y-axis is so messed up you can't even tell. We have been gaining traction.

Remix is doing well. It's been influential more so than doing numbers or whatever. But the true unsung hero is React Router. Roughly if these numbers are to be trusted, roughly half of the React websites, so React DOM usage has React Router coupled with it. That's a lot of applications.

That's where we want to focus our energy. This has been really fun and really influential. But we just believe that React Router is really where we should be focusing. Because it's just a lot easier. It's more vanilla. It's more of that you're not locked into a framework anymore. You're using this library. And if you want the framework in pieces, then use this vplugin. That's all it is. That to me is a lot simpler than trying to pick tribal I'm a remix fan, I'm a this other thing fan, all that stuff.

So React Router is the new create React app, right? At least I think that... It didn't go through. I think that React Router is the new create React app. This is my opinion. And the nice thing about opinions is you can tell me I'm wrong. I actually genuinely want you to come try and change my mind. More specifically than that, I don't want you to change my mind. I actually just want you to tell me what's missing.

So this QR code has a genuine form. You can come talk to me afterwards, of course.

But if you're online, I'd love you to fill out this form. I tried to make it very simple and very quick just to say, hey, if you agreed with everything I said, awesome. If you disagreed, though, please give me specifics. What do you think that we're missing that would allow you to say, like, yeah, no, I agree. It's a new create React app. It's a remix. Thank you so much for your time.

I'm going to put that QR code back up one more time just so you have it. Let's jump into the audience questions. First question is from Chris Brooks. What ceilings have Shopify... Sorry, common mistake. I do it too. Shopify run into running remix in production at scale. Is remix used for Shopify admin? That's a great question. So I'll answer the end of that. No, remix is not used for Shopify admin. Shopify admin is a, like, five million line React router application. It is built on React router six something something. It's using those data APIs that we have.

There are specific reasons that they haven't been able to move to remix and things that we have actively worked on. But at this point, the path forward is for them to get to React router 7 and they're fully aligned in that. Where we have used it is shop.app is a fully built, like, e-commerce website that completely uses remix from Shopify. We have Shopify embedded apps, first party and third party, that you can build with remix. Hydrogen completely uses remix. So there are a lot of great e-commerce stores built on hydrogen that are using remix. So we use it at a lot of places in Shopify. And yeah, every time we run into an issue or a ceiling or whatever, it's been pretty quickly fixed. An example of that is fog of war is something that we're working on right now that fixes shopify.com. It has this big issue with the manifest and that's a very recent thing that we're about to ship.

All right, thanks. If you're stepping out, please try to keep your voice down so we can understand each other here. Thank you.

Next question is from, it's a hard name, Metin Parzinski. So is the remix branding going to disappear now?

Yeah. No, not at all. Great question. Yeah, we've tried to clarify this a number of times. And I meant to say something in the talk, but again, this talk wasn't really about the remix React merger. The brand is not dying. What we're doing is we're trying to say everything that we've been building, we think fits best in React router. And so we are completing the React router arc seven, you know, number of completion. We're trying to get to that end. And with remix, what we're trying to do is we're actually reserving it for a RSC first build of what a framework could look like. So it's going to look pretty different than what we've been doing with React router. And we didn't want to do this thing where we'd have remix v3 and then remix v4 is just completely different thing. That you're just like... They're not even the same project. So instead of trying to pretend that they're the same project, we're just actually saying they're not the same project. This is what React router is.

And we have another project coming down the road. But no, we're not getting rid of it. I have a bunch of swag, actually. Please come grab the swag afterwards, because I don't want to take it back to America.

Okay. Good, good. Thanks. Next question. React router breaking changes are making it hard to migrate from version to version. How good is the new remix to handle those issues? Migration is the stop factor.

Yeah, that's a great question. So we're pretty obsessed on breaking changes. And I definitely... Yeah. I would love to hear... When people say this, it would be really helpful when you're giving this feedback to tell us specifically what the problems you've had are. Because I agree. React router v4 to v5 was a terrible breaking change. The reality is, I wasn't even an engineer when that happened. Or I was just starting.

Most of the people in this room honestly didn't actually go through that. If you just heard that from Reddit, then I would ask you to stop just repeating things you hear from Reddit.

Now, if you've actually gone through difficult breaking changes with React router, I'd absolutely love to hear that.

But what we've done is from v5 to v6, there's a complete... We had to rebuild it on hooks. Every single major React library did the exact same thing at that time.

And what we did is we tried to actually create APIs and bridge APIs at the time. And I say we, this was way before I was even on the team.

React router v6 has been around for several years at this point. No breaking changes. We added layers to get you to the data fetching from the routers. So we've had that migration path all the time.

We're talking about remix, the remix v1 to v2 upgrade. We use these things called future flags.

And for everyone we talked to, when they upgraded from v1 to v2, the word they used was boring. It was just a boring upgrade. When they're all on the v3 flags, or v2 flags, once they're ready, it was a very easy upgrade.

So that's the exact same thing we're gonna do now. We're gonna provide APIs that are bridge APIs. We're gonna have great migration guides.

We're gonna code mod as much as we possibly can. If you're using remix right now, going from remix to React router 7, it would be incredibly simple. If you're using React router, it's a more nuanced story, because it just depends where you're at with React router, because it has a 10 year history. So we'd have to talk about where you're at. But if you're on React router and you've been using the latest and greatest, it's also gonna be incredibly simple to upgrade.

Yeah, the smaller the difference, the easier to upgrade, of course. Yeah.

All right, next question from Lucas. Will React router 7 have support for middlewares? Yes, with an asterisk. We're not gonna do it in 7.0. I'm very sad. I really wish that we would. I think it's gonna be a 7.1. Basically, we're at this point where we already have a lot of new features we're trying to add and anything else. We're creating more complexity, more opportunity for the migration path to be difficult. So what we're doing is we're trying to get 7.0 out as soon as possible. And the nice thing is, everything is built for middleware to work really easily. We already have the patterns in place and everything, so it should be pretty easy. And when we've been in a steady place with a new version, it's been about two-week release cycles to get to a new version. So I feel very confident that once we're at 7.0, it will be really easy to get to middleware in that next minor.

So would you recommend Lucas to wait for 7.1, then? I would really need to know what Lucas specifically needs middleware for. Because if you're using something like Express, you already do have middleware. I agree, it's not as ergonomic as what we have. There's also a homegrown middleware solution that Killamon, who's really big in our community, has created. I would maybe recommend looking into that and see if it fixes your issues. I agree, middleware is something really nice, but there's a lot of people who haven't stopped using Remix because there's no middleware support, because there's middleware support in, again, Express and these other places where maybe that's where you should reach first. But I agree, middleware should come. But I just, yeah. If it's the reason you're not using Remix, please explain to me why, because I haven't yet understood that part. Which you can do right after this Q&A in the private Q&A or find him online. Because it's his job to help you. He gets paid to help you, right? Yeah.

All right. How easy will it be to migrate from Remix SPA mode to SSR? Yeah, it's a great question. It's a flip of a bullion. So it's one line change, yeah. Of course, you have to deploy to a server, so I'm being a little bit facetious. But yeah, you just flip it, and then you're immediately server-side rendering everything. And so you do need to check if you're relying on, like, window and all these sorts of things. You do need to go through that and check.

So that piece is normal, but there's nothing you have to do from the configuration side except turn on the bullion of use SPA mode or whatever is false. It was so easy. Your answer was so fast that I thought, I'm not done yet. Yeah. All right.

Next question. I think last question. Is Remix a good starting point to find best practices with Remix? Yeah, that's a great question. It depends what you mean by best practices, but the docs are the best thing we have. If you have trouble with the docs, please let us know because we're always trying to make them better. We're also in a process of... The reason migrations kind of take a while or this upgrade takes a while is because we're also really trying to combine two documentation. That was another issue we had is ReactRouter had some good information, then Remix had other good information. We're really trying to combine and simplify so it will get better. If you feel like we don't have something, then please reach out. But for the most part, the React docs should get you started. And then our... Sorry, the Remix docs, geez. And then the Remix, our YouTube channel has some pretty good content as well if you're more of a video, visual learner. Video kind of guy. All right. Then last question for me. Who here is using Remix in production? Nice. Who's using ReactRouter in production? Yeah. What did you expect? Yeah, yeah. More on the Remix side, actually.

That's all the time we have. So, thanks a lot.