Exploring Remix

After getting frustrated with trying to port a NextJS project from version 12 to 14, I found myself looking around at other frameworks, as it was clear I was going to have to rewrite a significant amount of code anyway. I was pleased to find Remix seeing a growing fanbase which was echoing many of my sentiments about the many gymnastics required to keep up with the latest demands of Next.

For those of us who have been coding for quite a while, it’s been a bit like ping pong watching the area of development focus bounce back an forth between client and server. I entered the workforce after the mainframe area (server-focus) and found myself writing Powerbuilder and VisualBasic (client-side focus) and soon we were into the hypertext thin-client era with the web. Early projects were Perl backend spitting out html server-side.

Then came PHP and then came Ruby (on Rails) with its opinionated configuration but ultimate synchronous response handling. Then the MERN stack taking advantage of the asynchronous nodejs request handling for scale, and finally after one could handle only so much JQuery fetching and callback hell, we entered the era of the SPA with the advent of React.

An entire era of server-side rendering moved to the client side with React and useQuery from the Apollo Client. Or if you were early into this movement, it was using Redux and dispatching REST calls, updating your store asynchronously and then rendering components reactively to store changes observed by React components.

But we had lost something. We would pursue terrible gymnastics to let our deep URLS be able to show a webcrawler a semantically ingestable webpage for SEO purposes, and so we had to provide some means of Server-Side-Rendering for these cases, which led to the pursuit of being able to “render” React components in a non-browser environment, which seemed silly, as that was something we had done with ease using HTML only years before. And it was here, caught between SPA (Single Page Apps), SSG (Static Site Generation), SSR (Server Side Rendering) and the imminent RSC (React Server Components) that I discovered Remix.

Remix sets out to let your write components that will render on the server by default, but with clear methods that will fetch the data necessary for them (named “loader” appropriately) and make changes (named “action”) - all the while providing the mechanics for invalidating stale data when an action is taken, such that no “useEffect” dependencies are needed for handling this ourselves. It truly feels like a “goldilocks” solution that merges the best of what we’ve come to expect to do on the client side and the server side.