My thoughts on Remix and the future of React development

Remix is a new web framework that normalizes development into the native Request/Response lifecycle. Focused on what you don't have to do as much as what you do, its quickly gets out of the way when you are trying to get features shipped.

What is it really

A websites behavior is just a series of requests and responses. Get this page, send this data, delete this thing, etc. Remix facilitates these actions by coordinating user behavior with the functions that you define.

The heart of a remix app is react router, and the routes folder. Thats where you put your page fragments¹, your loaders and your actions. I'll not go into to much depth, as you can go through the docs, but you can think of page fragments as all or part of the UI for a given route; loaders create the data for a fragment and actions perform route specific tasks.

Remix is also a state manager. It pulls a potential tree of router loaders and maps them internally into a state tree that you can then use directly in your app. This allows you to co-locate data and view, but the actual execution happens at the correct stage of the request lifecycle. (I apologize if thats confusing - if I find a really good example I'll link it in the future.)

I have alluded above to trees of data, hinting at another other massive feature: nested routes. This isn't a new concept - I remember doing this with Ember.js many years ago - but in combination with co-locating data, mutation and view partial we get a powerful way to structure applications as they feel rather than a way predefined by the framework author.

Nested routes let you think about individual parts of a page as separate and distinct routes with there own data, mutations and views. You can see this on the front page of the Remix website. There are many ways to slice this feature and I would highly recommend a deeper dive.

The final piece of the Remix pie is the execution adapters. You can describe Remix as being deployment agnostic. There is a single entry point into the framework, a handleRequest function that will let you map your production environment into remix. Deploying to a simple VPS is as easy as on an edge provider such as Netlify, Vercel, Cloudflare or any other.

It is important to note that while this does lead to in theory being able to deploy anywhere, not every environment supports all the features as every other. For example, this site is hosted on Cloudflare Pages, and in that environment you cannot use the node.js fs library. This means I can't render markdown by first loading from the disk - I would have to include the markdown as "code" or just write them in a react components (which is what I am doing for now).

What does this mean for React

React is one of the most deeply integrated tools of frontend that there has ever been. I am not sure how it competes with jQuery in size, but just like it, React has shaped what modern javascript looks like. Depending on who you are this is both a good and bad thing.

React is a consuming technology. At a certain point after you adopt it, it takes over all parts of your development. And in making it fit into the pipeline, there are sometimes very large hoops to jump through.

Remix presents us now with a way of simplify React back to the initial promise of a view library, for while Remix has React at the core, it encourages you to solve problems without leaning on React. Instead they help you use the tools native to the web platform. Or as people have been suggesting - #usetheplatform.

I think with this push from the Remix team, we are about to see a renaissance in the web space as more and more people throw out weight libraries for forms and networking and data management and pair back to a simpler, feature driven approach.

What does this mean for me

Remix is going to be a core part of the next part of life. My focus will be on building apps for fun, and hopefully launching a few of them. This is mostly because of everything I won't have to do while working with remix.

I won't have to manage state across my application. I won't have to write complicated useEffect function to fetch data on the client. I won't have to work out how to combine a complicate API backend into my application to manage user data or user preferences. I won't have to think about how I can maintain scroll position between pages. This list could go on forever.

Because of all the things that I won't have to do, I can focus on the things that I want to do. Things such as accessibility as a first class citizen in my hobby projects. Actually handle errors, all the tricky edge case ones that you know you should but never getting around to because it complicated to handle all the potential intermediate states. Shipping features that benefit users rather than benefit developer productivity.

This is an exciting shift and I cannot wait to see how it progresses

1. I made up the term page fragments because while they are react components, that term doesn't accurately represent what you doing. I was looking for a more generic way to say "describe your UI".