How This Site Was Made

May 26, 2022

When I'm choosing technologies at work, I try to consider their maturity, ongoing backwards compatibility, and future outlook. When it's my personal site, all bets are off. The goal is to have fun and try out shiny new tech.

And so, I've chosen to build this site with Remix. Yes, it's overkill. But it is fun.

The site's code is open sourced here

To me, the Remix paradigm feels like the next big step for React.

- Breakthrough way to create interactive user interfaces on the web

Create React App
- Provide common preset defaults, to avoid needing to set them up from scratch

- Filesystem routing, managed dependencies with easy upgrade path, server-side and static rendering options to make apps faster

- Use React to output static HTML with progressive enhancement, move back to web standards

The thing is, React can get noticeably slow once you get a decent amount of data or components on the page. Pretty soon you're thinking about useMemo and useCallback, going nuts trying to track the flow of side effects through dependency arrays. It's not fun, and although I enjoy the composability of hooks, they make it difficult to reason about your app's renders. "Why did this render get triggered?"... "Why is this effect running 5x?"... 🤦‍♂️

We're hitting the limits of the virtual DOM. And downloading large JS bundles to the browser seems increasingly silly.

NextJS made server-side and static rendering easy to achieve. Automatic code splitting meant less JS got downloaded to the browser. Sites got faster - much faster. But between SSR, SSG, and ISR, it got bloated. Which one should you use? Where is the backend computation running - on a Node server somewhere? It still felt like we were playing defense against React's limitations.

Remix feels like a new way to think about things. It places more emphasis on HTML output than it does on React. Instead of being the goal, React is a means to an end. Server-side rendering isn't a choice; it's a given. Computation happens on the edge. If you want to cache a page, you learn the appropriate HTTP headers instead of the framework's abstraction. To me, although I really love NextJS, Remix is a cleaner conceptual model.

Funny enough, a day before Remix's conference, NextJS just announced it will be implementing many of the same features.

This feels like an endorsement of the Remix paradigm. It's likely that NextJS will end up implementing these features in a more polished way and with better backwards compatibility, but they'll be fighting against more baggage from the old paradigm than Remix will be.

Either way, these are two great open source projects and we all win.

ps. You know what I'd really like? Remix + Svelte.

So that's a long winded way of saying why I built this site with Remix. I used TailwindCSS for styling and Cloudflare for deployment. Cloudflare's GitHub integration means a new version deploys to the edge worldwide on each git push. At all levels of the stack, this was quite easy and fast. As engineers we have it pretty good these days!

The repo is open sourced here if you'd like to take a look.