On Rails

16 years ago, David Heinemeier Hansson (DHH) took the stage and delivered one of the most impressive code demos the world has ever seen. It was not only an impeccable presentation but also a very well-timed one.

In 2005, developers knew that in order to ship web apps, they needed to deal with a lot of boilerplate code. Ruby on Rails came to change all that.

Last week, Remix went open source and the founding team decided to host an event to celebrate it. Ryan Florence did a live demo that felt similar to DHH’s one in spirit, as they both seemed to have a similar sense of time.

I’ve been using Remix for a week now, and the similarities with Rails have only been strengthened. Don’t get me wrong, modern challenges while building websites are not the same. Yet, both frameworks seem to have a lot in common.

Let’s take a look at some of my early discoveries.

Good primitives

In Rails, the building block is a resource. It allows developers to build fast and polish later. Routes are Remix’s primitives, and while it’s fundamentally a different concept, it is equally productive and oriented towards the same goal.

The core of the idea is that each route has responsibilities beyond deciding which React component to render. They can load data, respond to user actions, apply visual styles, and many other things.

It gets fascinating when you start nesting those routes, allowing for responsibilities to compound. Suddenly, you are splitting your app in a way that feels cohesive, coherent, and performant. It seems to be taking a page from the code splitting manual and applying it to everyday tasks like fetching data or adding CSS.

The route is an ambitious primitive, one that could have gone wrong in many ways. But it feels right. The instructions to proceed are simple, and you quickly find yourself on the productive side by building rather than living on the docs.

Long live the king

With Rails, the default way to render a page is by using server-side rendering (SSR). With it, the responsibility for generating a web page is within the server. Before AJAX and static-site generation became popular, this was the only rendering strategy we needed to think about.

With the arrival of the Jamstack, the web ecosystem reached a new consensus: server-side rendering was too much of a burden for modern and highly dynamic websites, so it needed to go into oblivion. Even frameworks like Next.js, which started as a solution for SSR with React, incorporated newer techniques more in line with the modern narrative.

Lately, many developers have reached some sort of Jamstack fatigue, mainly because they’ve explored the limits of the paradigm. Techniques like incremental static regeneration have emerged to try to increase those limits, but the complexity keeps growing.

At the same time, exciting ideas have emerged in the SSR camp, aiming to solve a well-known problem: server latency. Companies like Fly can place your full-stack app (with databases) worldwide, drastically reducing the time a request has to travel to reach the server.

More interestingly, edge computing has made significant progress, and companies like Cloudflare can efficiently run your app at the edge, making server latency a thing of the past.

Remix wants to stand on the shoulders of those giants by offering a server-based solution designed for living on the edge.

We could probably add some SSG functionality very easily, but it’s just not that compelling when you can run your app at the edge for pennies. I mean seriously. You sacrifice so much flexibility when you prerender everything. But when you’re running your app at the edge on CF workers you can have SSG speed without sacrificing the flexibility of SSR.

Michael Jackson

As it turns out, being edge-friendly is not a happy accident but something considered from the ground up.

Remix is edge native. We built it for the edge by not depending on Node.js. You can deploy your Remix apps anywhere, like Cloudflare Workers.

Ryan Florence

If we get to a point where SSR can be perceived as fast as static sites, then the gains in flexibility and simplicity will probably outweigh what SSG brings to the table, and the pendulum might swing the other way again. We are not yet there, but Remix is doing its part to help.

It feels like there’s an SSR renaissance happening.

Colocation of concerns

Rails is based on a well-known pattern called MVC. In a nutshell, you have a place to fetch data (a model), one to display that data (a view), and one to coordinate interactions with the browser (a controller). The relationship between the three is managed by following a filename convention. Remix has similar opinions here, only that the convention it uses is a different one: it’s called colocation.

Routes have loaders to fetch data, actions to handle user interactions, and a React component for building the user interface. All colocated in the same file.

Tangentially, it’s pretty clear that while Remix is known as being a React framework, in reality, React’s role is limited to solving one thing: to build user interfaces with its fantastic component model.

Remix routes also offer convenient ways to manipulate metadata, links, and headers, reinforcing that colocation is a feature and not a bug.

To infinity… and beyond

Rails has a method called respond_to that lets you respond to requests in ways that go beyond just HTML pages. JSON, XML, a PDF file, a CSS stylesheet, anything is possible. Remix introduces a modern and convenient way to do a similar thing. It’s called resource routes.

Creating a resource route starts by adding a new route and only writing a loader on it. On that loader, you can define the type and the value of the content you want to respond with. Then it’s simply a matter of accessing the proper URL, and voilà, the resource is there for you to consume.

It’s a simple idea that opens the door for creativity. Here are some clever use cases I found around:

• Jacob Ebey is adding dynamic session-based CSS.

• MapleLeaf is compiling Tailwind on the fly.

• Someone on the Remix discord mentioned using a resource route to decouple data loading, allowing instant page transitions and client-side cache. Neat!

I have plans to explore this topic a whole lot more, so stay tuned for future posts.

Learning that scales

In the Information Age, searching for content has become trivial, but knowing where to spend our finite time is a crucial skill to acquire. In web development, fads come and go pretty quickly, but certain elements are atemporal: those known as web fundamentals. You typically make an educated guess by betting on thosebecause they tend to scale in your career.

Rails allows developers to learn about web fundamentals while building websites. Its abstractions are thin enough so that you can see through the glass if you are curious enough. Remix wants to walk in the same direction. As stated on the docs, the API makes working with web fundamentals a convenient thing, but those are not hidden from you at any point.

Web Standards, HTTP, and HTML. These technologies have been around for a long time. They’re solid. Remix embraces them completely. [...] Browsers and HTML got really good in the 20+ years we’ve been using it.

Remix docs

It’s possible that if you started doing web development in the past ten years, you’ve learned that in order to send some form data, you need to follow three basic steps:

1. Delegate the form submit event to a Javascript function of your own.

2. Inside that function, prevent default behavior from happening.

3. Finally, take care of submitting form data to the proper endpoint.

It’s also possible you don’t know what that default behavior you are canceling in (2) is. It turns out that forms can be sent without JS in a relatively simple way, and it is one of the most basic fundamentals on which a browser is built. That's what you are canceling. 🤯

Remix does not only favor this fundamental but even teaches about it. Whenever you need to send a form with Remix, you will not only do that, but you’ll also learn about HTTP requests and how to handle forms with them. This is a fantastic trait, because the framework invites you to discover beyond its abstractions. There are not many of them that can do that by design.

Let’s review another example. At some point, your app needs something most web apps need: to fetch some data from an external source. As we’ve already seen, Remix introduces loaders to do that, but there’s something particularly compelling about their implementation: rather than adding some arbitrary abstraction to handle HTTP requests, they just adopt the Web Fetch API.

There’s a similar story for most of Remix core parts. Whenever there’s a web fundamental behind it, you’ll get a clear message about which one it is, where to learn how it works, and the way Remix uses it. Progressive enhancement, cookies, HTTP headers, all concepts you will learn while using the framework.

If you ever decide to move on from Remix, you will travel with some new tales from the trenches and a 90L backpack full of web fundamentals.

Get good at Remix, accidentally get good at web development generally.

Ryan Florence

Final thoughts

Rails and Remix share a similar north star: they are both highly pragmatic with a strong sense of belonging to the web. However, Remix intends to captivate a different audience: it wants to meet React developers where they are and take them to the next level by teaching the fundamentals of the web.

Considering that React is currently the most popular front-end framework, it’s pretty exciting to think of an entire class of web developers who are good at React and can also champion for proper use of web fundamentals.

Remix looks like the pinnacle work of a couple of sharp and seasoned developers that have been around through multiple waves of best practices and modern tools, only to find an intuitive way to remix what’s going on these days with what has always been the backstory.

On a more personal note, Remix achieved something that not many modern web frameworks have been able to. I felt like a web developer again. The great divide, the front & back separation, the myth of the full-stack unicorn… all gone. I was building a website and having fun at it.

I will be for sure exploring more in-depth concepts and techniques that Remix brings to the table. I’m especially interested in its capabilities for the hybrid nature of blending traditional websites with highly dynamic web apps.

Good times are coming.