Many think thoughtbot and think Ruby on Rails, and while it’s true that may be our calling card we also have many talented JavaScript focused developers.
Our go-to framework for the past few years has been Next.js.
Next.js is a great tool for building products quickly, and services like Vercel and Netlify allow us to deploy and iterate with ease. There is a huge community behind Next.js and resources are plentiful if you run into something tricky.
Compared to the older way of doing things, let’s say a create-react-app front end + a seperate Node server, Next.js allows us to drop the complexity of two separate apps and enables us to write our client and server code in one place, full-stack ftw!
Remix, another full-stack JavaScript framework has recently entered the arena as a serious alternative to Next.js.
Here are a few reasons why I’m intrigued by Remix:
- Remix embraces the web platform, standards documented on MDN
- Remix is edge-native, meaning it enables faster access to your app around the world
- Remix was built to be deployed on any platform that supports JavaScript
- Remix apps can work before client side JavaScript is loaded which can lead to faster UX on choppy connections
- Remix uses actions for mutations (everything is a Form), and loaders for fetching data (loaders only run on the server and automatically revalidate data after actions, neat!)
- Remix can prefetch any page since it uses rel=prefetch under the hood
What would it take for me to switch from Next.js to Remix?
I’m ready to give Remix a try on an upcoming client project. Choosing between the two is really a toss up with the main differences being routing, data fetching mechanics, and the fact that Remix has yet to implement server components (this is eventually coming, and when it does it should supercharge Remix).
Shoutout! Kent Dodds who we’ve been learning from for years has been a big promoter of Remix (oh, and recently dropped by on the thoughtbot podcast!) See his interesting write up on Remix vs Next.js.