Why am I investing in the Remix framework?

Updated 31. Jul 2023

In this blog post I will go into the details and reasons why am I investing my time and energy into Remix instead of any other framework like Next.js or Redwood, which killer features convinced me to go with Remix and what unexpected hurdles I encountered while using it.

Killer Feature 1: It doesn’t reinvent the wheel

One thing I like a lot is how Remix embraces how the web works. Most notably this is seen when it gets to the behaviour of forms. You define a form as you would with native HTML:

<form action="..." method="POST">

and things should work as you would expect in traditional frameworks like Django, Laravel and others. Quite easily you can progressively enhance your form by

  1. replacing form with Form that is provided by Remix. This will change the behaviour so that requests happen with fetch instead of full document reload.

  2. you can replace Form with ValidatedForm validator={zodValidator} and enhance your Inputs to show errors and have frontend validation finished extremely simply.

The fact that ValidatedForm uses a validator built by Zod, means you can consume exactly the same validator on the backend, meaning your validations will always match between the frontend and the backend.

While it embraces the web and does things in an “old school” way, it doesn’t prevent you from managing your state in the client and building a really complex app that runs on the client only.

I consider this a massive benefit over Next.js - last time - a couple of years ago, my experience with Next was not the best. Few things felt better than what PHP frameworks offer, while it felt worse in other cases. Remix feels like a smaller beast that builds on top of the existing web instead of trying to reinvent the wheel.

remix vs other frameworks

Killer Feature 2: Easy SEO

While SEO doesn’t suddenly become easy, because the main part is still based on the content, it does make the technical part of SEO straightforward to manage.

It’s really easy to handle tags correctly and make your own framework on top of it. Server-side rendering works as you would expect.

Getting a 90+ Page Speed score in Lighthouse (supposedly a requirement for a good SEO) is pretty much trivial.

remix js seo performance 90+

You can even completely disable javascript loading on certain pages, making TTI (Time To Interactive) even faster.

I consider this a huge benefit over Redwood - in 2022, I experimented with Redwood, and although it offers the best developer experience from all the frameworks I’ve tried in JS world, it does lack server-side rendering. If you are okay with server-side generation (build time rendering), then it’s absolutely fantastic, especially if you are a fan of GraphQL.


It’s not all perfect from the beginning, you will need to work around some things (for example, having dynamic <link />s because you need them for canonical URLs), and you will need to build some things on your own because the ecosystem is not giant (like RSS feed and sitemap.xml)

Killer Feature 3: Easy Data Management

As mentioned above, you can easily re-use the input validator on both the front and backend. And because it’s built on top of Zod it’s trivial to get the correct typescript types out of it. This means that your request data is always in sync with the typescript types, on top of having client-side interactive validation and backend validation for security.

If you use Remix as it’s intended to be used, you will never get into out-of-sync state issues. This is due to how it handles form resubmissions and reloads the document afterwards. By default, whenever you submit a form, Remix reloads all other currently active loaders to ensure their data is up to date. Of course, you can completely avoid this and make normal fetch requests if you want.

It does come with the cost of extra database requests, but it is flexible enough to let you optimise for the cases where performance could be costly. You can do this by opting-out specific components from reloading on every form submission with shouldRevalidate.

I believe that you should not optimise until it’s needed, so this non-optimal behaviour doesn’t bother me.

I consider this a huge benefit over custom-built solutions - It’s simple, it requires so little boilerplate and mostly does already what you want it to. Building a layer of similar quality takes considerable effort - I’ve tried multiple times in the past!

Other Thoughts

Shopify acquisition

Shopify recently acquired Remix (source), which looks like a good thing so far!

  1. Other open-source software (OSS) from Shopify is doing pretty well - github.com/shopify.

  2. Their press release states they are committed to continuing to run it as an independent project - and it seems that is the case so far.

  3. The core team is still working on it.

  4. Shopify.com just recently adopted Remix for their main page.

  5. They already announced further plans to use remix in their own framework (hydrogen)

  6. They are publicly streaming their planning sessions on YouTube 🤯

I think their commitment is genuine and will probably stay like this for at least a few years, given all the signals above.


Although remix-auth gives you the ability to add basic authentication fairly easily, it’s still up to you to handle a lot of things. For example, it doesn’t make any assumptions about a database, forcing you to implement your own session tracking and validation. You still need to build your own login and sign-up system, password hashing, …

In a way, remix-auth feels like a black box that doesn’t do much, but I assume the feeling comes because I used only a couple of OAuth providers, which is easy to manage at the start but gets really complicated once you have loads of providers. But who has loads of login options anyways?

Not to mention authentication (the user is who they claim they are) is only part of the issue. You also need an authorization layer (the user has permission to do X). So you need to some kind of RBAC layer yourself.

Maybe I should use an external authentication platform? I tried Supabase, but this complicates things even more. It was manageable, but having consistent and easy developer experience on both SSR and Client side turned out to be a mess.

I’m considering going with Zitadel or Keycloak in the future. Any thoughts? It seems like at least ZItadel, solves authorization as well, with built in RBAC (role based access control).

Some batteries included

Initially, I thought I would get more out of Remix, but it turns out it’s quite a thin layer, and people built different stacks on top of it. Meaning the community and ecosystem at large are doing this differently. But it also means you will have to figure out a lot of things yourself, things you would expect from mature frameworks in other languages, for example:

  • Caching

  • Validation

  • Database Integration

  • Mailing

  • Queues / Job System

Of course, npm is the size of the universe, so you can find all of these pieces as libraries, but it’s up to you to figure them out and fit them into the system. Look at the documentation of one of the most used PHP frameworks - Laravel Docs, and you will notice how many things it includes.


Remix feels like a solid step forward while removing loads of things that were re-invented in the last few years and are not needed most of the time. And it doesn’t take away from what we’ve figured out recently, as you can still use all those techniques. For example, redux feels like an anti-pattern with remix, but you can still use it if you have a good reason.

Is this the final stop? I don’t think so, but I feel like the next step is a framework similar to Remix with batteries included. Maybe built on top of it with a really opinionated set of tools that not only help you get started but also help you scale.

I’ve also tried vite & vite-plugin-ssr if you are curious how that went, let me know, and I might write about it.


If you're going to use Remix, I highly recommend these two libraries: