I've been building React applications since 2015. Since then, React was the biggest single productivity boost for my development by a long shot. React's declarative model for rendering UI based on state drastically simplified the way I thought about building UIs for the web. It also gave me a great way to think about state that was miles ahead of what I had been doing with Angular.js and Backbone before it.
React's tagline is:
React does an excellent job of this by giving you that declarative component
model it pioneered. You can't build a user interface without managing some state
(is the combobox menu
closed?). This is why React has component
The trick is that there's a lot more to Web applications than local component state. In fact, the vast majority of the "state" loaded in the typical React application is not state at all, but a cache of state that came from the server (which it probably got from a persistence layer like a database for example). While React has always given us a nice way to manage state, it can't hide the fact that much of the state we're managing is actually a cache and suffers from the problems of caching.
As Phil Karlton's famous quote states:
There are only two hard things in Computer Science: cache invalidation and naming things.
In many ways this is a joke, but cache invalidation is definitely a challenging problem. And up to this point, React hasn't given us anything out of the box for managing this problem, as evidenced by the myriad of libraries and tools that have been built around React to make this easier. Whether you're using Redux (toolkit), MobX, Apollo, React Query, SWR, or something else, you're only reaching for those tools because there's a common, shared problem in web development that React doesn't have a built-in answer for:
Here's what I mean by the network chasm:
As web developers, we get to write code that runs in the client (the browser) and the server. We don't get any control over the network. This is why we have to think about caching in the first place. When our React component re-renders as the user makes their taco selection 🌮 we need to have synchronous access to the options available for that particular taco 🤤. So we make HTTP requests over the network, and store those values in an in-memory cache via React state (or some library) so they're available for our re-render.
Do you know the number one cause of bugs in apps both large and small?
The code required for this grappling hook to work all exists on the frontend. For data fetching, you have to know what data to fetch, and often that's a challenging problem because we like to co-locate our data fetching with the code that requires the data (reduces bugs/mistakes/data overfetching a great deal by doing things this way). This has the unfortunate side-effect of not being able to fetch data until the components have rendered.
Add to that the desire to implement code-splitting to make our app load faster, and now you have to not only wait for the component to render, but once it starts rendering you have to fetch the code that does the fetching too. This leads to network waterfalls (and we all know about the danger of waterfalls).
Unfortunately, data fetching by itself can't solve this problem. In fact, even React Suspense for Data fetching won't be able to solve this problem. Suspense will take the place of many data fetching libraries in being able to get the data from within the components (and if it's not cached yet it'll trigger the data to be fetched which is so fetch), but if you want to avoid the waterfall effect, you've got to start fetching the data before the code for those components are rendered.
This is why I'm so excited that React Router is going to solve this problem by
bringing much of what I love about Remix into React Router.
Ryan explains this in his post
Remixing React Router. With the
power of layout nested routes and
loaders (getting data) and
(mutating data), you can decouple the data fetching from the components, but
still benefit a lot from colocation. The fetching code might not be inside the
component in this case, but because of the nature of nested layout routes, it's
pretty darn close.
With these features, we go from "I have to render to know data requirements" to "I know data requirements from the URL."
On top of this, React Router is now managing some of that network chasm for you, meaning you have much less of your own code that has to worry about loading/error states. It also means that React Router can handle cache revalidation for you! Oh, and form resubmissions and race conditions too (some of the more challenging problems in UI development). And building excellent user experiences (like optimistic UI patterns) has never been easier. This effectively narrows the network chasm for you a bit:
Having those features within React Router will be a huge benefit for anyone looking to simplify their code and speed up their app. React Router will be a best friend for anyone using React Suspense for Data Fetching (unless you have the infrastructure/compiler/router that Meta has I suppose).
Wouldn't it be great, if we could just move all of that code out of the browser and onto the server? Isn't it annoying to have to write a serverless function any time you need to talk to a database or hit an API that needs your private key? (yes it is). These are the sorts of things React Server Components promise to do for us, and we can definitely look forward to that for data loading, but they don't do anything for mutations and it'd be cool to move that code out of the browser as well (and not have to wait for it to be released).
Enter stage right: Remix 💿
To really take your app to the next level, you'll want to server render your app. And the best way to do that is to use Remix. Remix finishes the bridge across the network boundary for you in such a way that you don't even have to think about it. You take all your data fetching and data mutation code and move it to be exported functions from conventional "Remix route modules" and all of a sudden all of that code stays on the server and Remix handles the entire network chasm for you:
And get this, because now you can write code that runs on the server, you don't have to worry about making direct database calls or hitting APIs with private keys anymore. Your loaders and actions only run on the server so they can do whatever you need them to. Nice DX improvement there!
Remix giving you the power of the server means that it can actually handle your entire app if you need it to. Not everyone wants to do things this way, but because you've got a backend that can talk directly to databases and third party services, you can make your app structure look more like this:
The cool thing is, you get all the benefits of a fully managed network chasm by using Remix whether you go with 100% Remix or not, so if you're happy with your existing backend you can certainly stick with that.
React's tagline is:
And it does a terrific job at that. React has never promised "network chasm management," but every web application needs it. With Remix managing that network chasm, we finally have a yang to React's yin. With a great rendering library and a super network chasm manager, you can build better, faster web applications with fewer bugs, simpler code, and more fun.
On a personal note, this is what made me fall in love with building web apps with Remix. The website you're reading this on today is the result of a rewrite to Remix. I had no idea when I started what cool things it would become. Remix enabled all of that because when I was finished with the basic features I realized I had time and capability to do so much more (read more about my site rewrite here). Remix made me feel like I could say "yes" to the fun ideas I had and that was really refreshing.
I hope this helps you in your pursuit of building better websites. Stay cool 😎