Why you should use Remix for SaaS instead of Nextjs
3 things that come to mind:
1. Developer Experience
I tried migrating the React (Frontend only) to Next.js and I got tired, I built about 50-70% but I did not like all the workarounds I had to do, such as getLayout. I'm about to finish a Frontend AND Backend (previously with NET Core) version with Remix, and I learned about Remix last Saturday I think.
2. React Router / Layouts
Since Remix is built on top of react-router v6, I set up my application using multiple layouts. For example, I have 2 application layouts, AppLayout (/app) and AdminLayout (/admin). When migrating to Next.js, look at all the "AppLayout" occurrences:
Notice the 114 occurrences? And this is just for AppLayout, I have worked with many more layouts. I'm sure there's a better and cleaner way to do this, but I did not find it. That's part of the Developer Experience.
Now with Remix, 9 occurrences in 3 files:
3. State management
Instead of using redux to get the state, I can get it with useMatches. This is what my app loader looks like:
So I can access this data anywhere that starts with /app/* or /admin/* with the useMatches() hook, without spinners all over the page.
The reasons I chose NextJS over remix:
Agree with everything you point out. Regarding the shadiness, I would be as exciting as they are if I was working on such a project, I've never felt this powerful as a developer on any framework (the same thing happened with Tailwind CSS, design-wise).
I'm also excited about react server components!
Can I suggest you this article on React Server Component vs Remix: https://remix.run/blog/react-server-components ?
They explain it and some of my doubts about Remix performance vs React Server Comp disappears.
Anyway i suggest for anyone who is young with React to use Next.js over create-react-app and to try Remix or Blitz.js if they want to go far
I’ve read it before. That is an unfair and biased comparison as the RSC demos are prototypes for experimentation and not suitable for real-world use. See https://github.com/reactjs/server-components-demo/pull/57/files
There’s a joke about NextJS vs. Create React App. Use NextJS when SEO matters. Otherwise, use NextJS.
You already know my thoughts on RemixJS. BlitzJS isn’t inspiring confidence either—they have a “Blitz is pivoting to framework agnostic toolkit. Click to learn more.” banner on their homepage. To quote BlitzJS directly:
Anyway, my opinion is to choose NextJS for real projects for now.
Yes Blitz.js pivoting is the reason why I look at Remix .
You're funny when It's not Next.js 🤣🤣🤣.
I think also (Next.js) it's the most mature and complete react framework. I used it for my daily tasks.
Lols, I’m just opinionated… like NextJS
But, I am glad that other frameworks like RemixJS are trying to compete. Competition will make everyone better.
Me too. It has it’s flaws. Personally, I think:
But, it’s the best tool for the job today, so NextJS is what I’m using.
Yes you're right. I remember the first day I was happy to read: "you don't need to install a router lib", it's great.
And may be with React Server Component, they will implement nested routes
I totally agree with using a larger project for the simple reason that there are more eyes on it finding bugs and creating workarounds.
I'm just curious why you chose keystone over a headless cms with a larger userbase like Strapi?
Sure, I chose keystonejs because:
For those looking at frameworks, I would like you to consider NuxtJS (specially if you prefer Vue over React).
This comment was deleted 4 years ago.
I’ve built a couple of apps with Remix so far. I’ve really loved it.
It’s a bit more “low level” than Next, which can be a good thing if you know what you are doing. For example, it’s encouraged to use cache headers to replicate the incremental static generation feature Next gives you.
Data mutations are where Remix really shines for me. Everything is just a form! You don’t even have to ship JS to the client.
I built Second Thought with Remix. I don’t even load any JavaScript until the user visits a more interactive analytics page.
Yeah, the only drawback I find with forms is TypeScript, BUT it's ok to give up some TS for web standards.
What are the downsides of using Remix so far?
Little community documentation. While the official repo has many closed issues, there are a few things I found difficult to implement, such as locale selector (i18n).
Some would consider that server side fetching, instead of doing it client side, making you write your app in a specific way, but I think it's the right direction, you'd only need a little mind shift.
Also, sharing data between loaders is a little difficult, Remix needs something like a middleware.
And most importantly, not being backed by Vercel, a GREAT platform/company.
Keep in mind I've only used it for a week, so I can elaborate in 3 more weeks 😊.
can you elaborate now?
What are some good resources for learning Remix?
I've only took the Jokes Tutorial they have on their docs. That was enough for me because it covers: ORM (prisma), loaders (to GET data), actions (to perform POST, PUT, DELETE data mutations), sessions, server error handling, client error handling, SEO and best practices (Optimistic UI).
Just use rails and have peace.
Interesting. I'm happy with Next but will definitely keep an eye on Remix.
You can build a SaaS with whatever tool fits your process and makes you productive. (re: post title)
IMHO Remix provides data fetching and routing benefits that make no difference for building a SaaS MVP. Benefits that can be achieved eventually on Nextjs with some architectural alternatives.
If you are still using redux you are missing out on a lot of new packages that will make your state management simpler: SWR, Zustand, ...
I think you had unnecessarily complex state management on your Nextjs app that suddenly became easier on a Remix app.
Right on point. But also, I've built the same SaaS application with Vue2 (November), Vue3 (December), React and Svelte (January), and tried with Next.js (couldn't), and finally Remix (March). I thought the best for app state management was React (CRA) and Next.js (I had no trouble), but to my application, Remix was the easiest implementation. I'm judging each framework by building the same app, but this app could definitely have some architecture enhancements.
Thank you for sharing this! Remix looks very promising and I will consider it. I’m currently investigating everything across the stack before trying out a few ideas. Cheers!
Thanks for posting this. I'm currently going down the React learning path and Next.JS and Remix have been a concern.
Glad to help if you have any trouble!
One js lib/framework over another is choosing which trade-offs best suits you.
If you are tired of js/ts, you can always try blazor. Refresh a page to recompile takes longer, but almost every other experiences are better.
are you usig server or wasm? Do you notice interaction lag on server one?
I use both. Interaction lag during certain use cases on the server side such as processing file contents, but we should offload that to another server anyways. I host on azure, so it's pretty fast. If the server is running all the time, then there's no startup lag, which is better first time experience than wasm. I am thinking the best is to use server side for landing and anything that can be offload to client side, use wasm.
My current plan for the upcoming projects is to have landing and few basic stuff on server side, then when user is logging in, I redirect that to wasm. Haven't done this yet though.
Developer Experience
I tried migrating the React (Frontend only) to Next.js and gave up after about 50-70 percent because I didn't like all the workarounds I had to do, such as getLayout. I'm about to finish a Remix Frontend AND Backend (previously with NET Core) version, and I discovered Remix last Saturday, I believe.
React Router / Layouts
Because Remix is built on top of react-router v6, I configured my application to use multiple layouts. I have two application layouts, for example, AppLayout (/app) and AdminLayout (/admin).
State Management
Instead of using redux to get the state, you can get it with useMatches.
you switched NET core with Prisma in Remix or how?
You're not describing a real problem. If the code shows up over 100 times...so what? It looks simple enough that you can do a global find/replace to update anything involved.
There's also workarounds to not have to copy-paste over 100 times.
You don't have to use redux for nextjs. React hooks are available.
I think the good parts of all of these features or libs based on React.js (Next, Remix, Redwood, Blitz) is that:
And why the build these tools over React.js ? May be because it is the best tool for web developers and the most able to allow us to be really FullStack.
I’d go with Next as that’s what I’m more familiar with and feel more productive using. Remix looks cool though, I’ve played around with it a few times and like what I see so far.
I’ll publish a Remix SaaS kit, if your interested, free for only 24 hrs
I solved the getLayout issue when I first started the project and literally haven't touched it since then since it works perfectly. It's really not an issue at all once you frame it all out. I have been asked numerous times why I didn't go with Remix, and mainly it's because I saw no reason to. NextJs also has a significantly larger community, and eco system so if I do have an issue I can lean on that.
I'd like to give Next.js another try, if you have a link to a solution could you please share?
IMO, an indie using React at all for a SaaS is a little bit crazy, masochistic or both. Unless you're doing something really innovative on the front-end, there's no need for such a huge JS framework.
Just use a good, modern back-end framework and "sprinkles" of Javascript.
Agree. I was in love with Vue, and I learned to love React, but it's not for every project; that's the reason I made SaaS kits, open source starters too, to test them all and have a starting point on each one of them.
All of those front-ends are assuming a huge front-end frameworks which are a mistake for 95% of SaaS products, especially in early stage or run by indies.
Why would you need React or Vue or Svelte? Use Phoenix LiveView or something it inspired like Laravel Livewire or Rails Hotwire and you'll build 5x faster.
Most SaaS just aren't so highly unique or FE-intensive that they need a huge bloated JS framework. I used to think they did, but then met more senior dev who had worked with a wider variety of paradigms and realized I was wasting a lot of time on over-engineered JS frameworks for SaaS projects.
My biggest suggestion would be to build 5-10 projects that don't do routing on the front-end. See what's out there and how fast you can go.
This is actually one of the best comments I saw on IH about frameworks.
I learned webdev 2-3 years ago, and I started right away with FE frameworks. I have a few projects that are working well with Next.JS and I'm really comfortable with it.
But I always felt that it was overkill and/or that it doesn't necessarily fit the need.
Last week I checked several tutorials about Laravel and Ruby on rails but it was difficult to grasp because I have had a FE oriented approach from the beginning.
The other thing is, we are spoiled in terms of simplicity of hosting with these JS frameworks. Vercel/Netlify/Cloudflare pages etc... I still have the impression that by switching to other technologies, it will not be as easy (and I am certainly wrong!)
What would you recommand for a guy like me, that want to test something totally different, but don't know where to start? Building something with Laravel? Do you know any good tutorial?
When I saw the possibility Laravel offered out of the box I was like "wow... took me 3 months to do that with Next.JS..."
Laracasts is absolutely top-notch and a lot of the beginner level tutorials are free. Even the paid version is a great deal.
what exactly took you 3 months?
I’m using NuxtJS + Vuetify a lot to actually save me a lot of time.
The nice thing about Remix is that you can skip the client side JavaScript if you don't need it. I love the dev experience of React so I'm happy to be able to use it for my interfaces. That said, use whatever makes you happy 😌
I follow this advice for hobby projects! But if a project is for-profit, I choose productivity over happiness.💰
Just use what you already know and don't worry about the frameworks, unless you're doing something really specific, 99% of the products here can be built and built well with any of the available frameworks