I recently tried out Remix.run and found it to be an absolute pleasure to work with, and extremely productive as well. My initial reaction of "This is just another competitor of NextJS" quickly turned into "Wow! This is so cool!" when I realized exactly what Remix is all about. When I finally recognized the beautiful design choices baked into Remix, I recognized them for what they are: pure genius.
Remix unifies the backend and the frontend
Remix mixes backend and frontend functionality in the same file. But that's not all it does–it then provides a simple way to transfer data to the frontend using hooks.
As simple as this sounds at first, it is revolutionary in terms of its impact.
Before I wax poetic about it, here is a code sample from one of Remix's two official tutorials. Notice how the posts loaded in the exported `loader` function are easily available in the React component using the `useLoaderData` hook.
This is huge.
We no longer have to do any of the activities below—Remix's loader abstraction handles all of it for us. The amount of saved time & effort is phenomenal.
- Create an API utility function that contains the GET call for the `getPosts` controller
- Write the backend controller that handles the GET call
- Write a route for the controller
- Manually test that the API util function works against the controller
- Manually synchronize any future route changes between FE and BE
- Manage multiple files for backend code, which breaks flow states
Right now, we all do this stuff over and over again, for no good reason. In fact, we're so used to it, we don't even think about it – it just feels like "part of the way we've always done things.
Not only is this a lot of saved effort, but it also leads to greater levels of flow state than previously possible. Remix fixes this problem so nicely that the old way of doing things now feels icky and unnecessary.
But what about separation of concerns?
Separation of concerns is good, right? If the frontend and the backend get mixed into one file, that causes all sorts of issues, right?
Well, once upon a time, developers would write HTML, CSS and JavaScript in different files.
Then, React came along and revolutionized the way frontend developers thought about frontend architecture. React pushed the use of JSX, which recommended that HTML and JavaScript should live in the same file.
That made a lot of people very angry. Team leads and architects railed against how JSX completely went against traditional separation between HTML and JS, and banned React from their projects. Many early teams rejected the idea outright because it went against the way they had always done things. Mixing HTML and JavaScript was a very controversial design decision at the time.
However, it soon became very clear that blending HTML and JS in the same file was a very large improvement in terms of productivity. All of a sudden, developers were much faster when it came to implementing complex JS behavior. And they enjoyed it a lot more, too.
This was because JSX, by keeping all related code in one place regardless of whether it was HTML or JS, reduced context-switching. We no longer had to juggle multiple files when dealing with JS and HTML. This, in turn, greatly improved the ergonomics & developer experience of working with React. This approach proved to be so popular that eventually, many of us started mixing our JavaScript and CSS in the same file as well, thanks to CSS-in-JS.
All in all, JSX made it possible for developers to become much more productive and enter into deeper flow states, for longer periods of time, because of better unification between layers.
Remix boosts productivity by unifying and simplifying the frontend and the backend
Remix takes this JSX philosophy a whole lot further by allowing us to mix backend and frontend code in the same file.
For the first time ever, I was able to code an entire page, from the database to the request handler to the React component and the CSS, in a single file. It obliterated the separation between frontend and backend that we're so used to, and brought forward a brand new sense of unity and flow that I hadn't felt in a long time.
That in itself is a huge achievement, but Remix doesn't stop there. It also offers a beautiful way to build nested components which are connected to the backend via Remix's loader abstraction, so that backend-connected layouts are also easy to build without having to context-switch into the backend.
On top of all of this, Remix somehow – impossibly – manages to make frontend development simpler instead of more complicated. Until now, web frameworks have consistently made web development more complex, not less. But Remix brings back plain HTML and manages to keep things simple. Even Remix's forms are essentially plain HTML forms, and are a pleasure to wire up to the backend. Goodbye, complicated React form libraries!
With built-in support for environment variables, multiple runtime environments, file routing, Typescript, and more, Remix also fits the same niche as NextJS. It has all the makings of an amazing framework and a worthy evolution building on top of the spirit of NextJS. I can't wait to dive into it again.
Learn more about hiring a Remix developer to simplify your next project.
