Comparing Next.js and Remix Frameworks: Learning, Experience, and Ecosystem

Learning Next.js is easier than learning Remix due to the abundance of resources available for Next.js, while Remix excels in deployment flexibility.

### Next.js vs. Remix: Ease of Learning, Development Experience, Ecosystem, Deployment, and Framework Preference
* 📚 Learning Next.js is easier than learning Remix due to the **abundance of resources like blog articles, videos, and workshops available for Next.js**. The Remix documentation has deteriorated over time, and the **amount of content and courses for Remix is significantly less compared to Next.js**.
* ⚙ ️ Next.js 12 had a good development experience with the pages folder, but Next.js 13 with API routes introduced challenges. With Next.js 4.0, the development experience improved, and the framework became easier to understand. However, the Next.js dev server is still **not great**. On the other hand, Remix uses Vite, which makes it **much faster** in terms of Hot Module Replacement (HMR) and **overall development experience**.
* 🌐 Next.js has a larger ecosystem due to its longer existence, but Remix is more versatile in deployment. Next.js is tightly integrated with Vercel, making it **challenging to deploy to other serverless providers**. In contrast, Remix, being based on web APIs, can be deployed **anywhere without much configuration**.
* 🛳 When deciding between Next.js and Remix, the choice is influenced by the type of project. For **content-driven websites and those with basic data loading and mutations**, Next.js is preferred. On the other hand, for **dynamic applications like dashboards that require a fast dev server and minimal caching**, Remix is a better choice.
* 🔄 Both Next.js and Remix aim to achieve the same goal of creating performant websites but have different workflows. For example, the routing structures are different, with Next.js using a **folder-based approach** and Remix using **flat routes**.
* 👨 Both frameworks can be used to create the same end result, but one may be **easier to work with** than the other. Next.js is preferred for **content-driven websites**, while Remix is favored for **dynamic applications**.
* 🔒 "At the end of the day, the choice between Next.js and Remix depends on the **specific project requirements** and the **developer's preferences**."

look, 1 year ago, I created this video right here, which was Next.js versus Remix. What should you use? And you know what? When I created this video, I wasn't really proficient in the Next.js app router. I wasn't that sure about some things, and I was more of a Remix user. Today, I have used Next.js and app router extensively, and I also used the Remix router and also the Remix framework itself very, very extensively with a lot of use cases. And you know, my whole perspective on Next.js versus Remix has actually changed a lot. But you know what? Before I actually tell you what you should use, let's actually first get started with what is easier to learn. So let me be quite honest with you. Learning the framework Next.js or Remix is actually not that simple. But learning Next.js is way easier than learning Remix. You have to be honest with that. The list of resources with Next.js is way more. You have blog articles, you have videos, you have workshops, you have some

pod. You have so much resources to learn next shes, and even the docks are actually quite nice with remix. I will be again quite honest with you, the docks have gotten worse. They were quite nice at the start. Now they a bit of let's say, they aren't as nice as they were at the start. You don't have that many blog articles. You have a few prominent, uh, article, I guess, offers like Sergio or Jaob Harris. They do create nice blog articles for the remix Community, but still the amount of content is just not comparable to next shares. Also, in terms of YouTube videos, it really isn't that comparable with next shares. You have thousands, maybe also 10 thousands of videos with remix. Let's be honest, maybe 100 videos in total about remix, the framework. It really isn't that simple. It isn't that easy. So when learning remix and if you come from a fresh background, so you just don't react or the basics of react in my opinion, it will be a bit harder to actually pick up REM remix because let's

be honest. The resources are just not there. Nevertheless, this does not mean that Remix is worse or Next.js is better. I just want to tell you that learning Next.js, at least in my opinion, will be way easier than learning Remix just because of the amount of resources on the internet. And let's not even start with courses. You have way more courses which focus on Next.js than courses that focus on Remix. Since we have now talked about the actual ease of learning of the actual framework, let's talk about the dev experience when actually working with the framework and also the general ecosystem which lives with the framework. Let's start with Next.js. In my opinion, the dev experience was quite nice in Next.js 12 when we had the pages folder. But when we then had Next.js 13 and the API routes when that got released, the dev experience tanked to the bottom. It was so trash, you can't even imagine. First hour, second hour, third hour, fourth hour, and you couldn't really understand why the errors would happen. With Next.js 40, it has

actually changed you now get actually good hours. You now actually also understand the framework better. The docs got way better, and just in general the death experience got way nicer. Also, one minus point, which I have to give to Next.js, is the death server. Let's be honest, it isn't great. It was very bad. It has gotten better, but it isn't great. It really isn't. Now, I know they're trying to fix that with Turbo, and yeah, it's okay, but I used it in my project and still isn't that nice. And if you now compare the death experience, or I guess the death server in other words, to Now Remix, it isn't comparable. Remix uses Vite, and Vite is very fast and very cool. And recently, I just spun up two projects, one with Next.js, one with Remix, two identical projects with a bit of loading, with a bit of mutations, so with server actions and then with Remix actions, and just in general, the death experience and the fastness of the HMR of the refresh was not comparable. It is

how it is. It really isn't remix is so much faster. The next shares and yeah, it is what it is. Now one thing we also have to talk about is, of course, the ecosystem. It's very important when you make a decision between framework A and framework B, and I will be again quite honest. NEX Shar takes the lead right here. The ecosystem which lives around NEX Shar is huge, and of course you have to also say that because NEX shess already lives or exists for many years. I don't even know when they actually got uh created. I would pop up a number right here, and remix is still quite fresh. So the whole ecosystem which actually lives around next shares is so much bigger. One point which I haven't talked about right now is deployment. Deployment is very, very important. You have to have a good hosting provider to have fast websites, accessible websites, because at the end you want to get the best experience to your users, and you know with NEX shs verel and next sh they are.

like made for each other. And of course, I mean Vercel creates. But the downside of that is that they are so tightly coupled with each other that it's actually quite hard to deploy Next.js to different serverless providers. So if you try to deploy Next.js to, I don't know, Fly.io or Render or any serverless deployment, it's quite easy. You have to create a Docker file, and I mean you will get a hang of it, but deploying Next.js to a serverless environment to anything different than Vercel, so I guess, uh, you have Cloudflare and whatever that is on the world, it isn't that easy. It really isn't. You don't have the same benefits as Vercel, and with Vercel, you pay a big premium to use, I guess, pros that Vercel offers. But Remix, on the other hand, is very open. What I mean with that is Remix, at the end of the day, just lives off web APIs, and that means you can deploy to anywhere. I mean, I don't know where you

couldn't deploy it to where cell works. Netlify works. Cloud FL Pages Works. Render works. Fly.io works. Everything works without any problems. No weird configuration. You just deploy it, create in Docker file if you need it, and you're done. That's all. So in terms of deployment, Remix takes the lead right here. It is 10 times easier to deploy to a different provider than well with Remix than with Next shares itself. And now the last thing I want to talk about is what is actually nicer to use. Is Remix nicer to use or is Next shs nicer to use just in general like the structure of the whole framework. And you know it isn't that easy to answer because even though they try to achieve the same thing so to create nice websites performant websites they are still kind of different when you try to create in websites. For example, the router, the most basic thing is completely different in Next shes in Remix. With Remix, for example, you have flat routes. That means you don't create any folder structure but you just create

I don't know index do abc. TSX. This is your route so you don't use any folders, but just points and uh, I guess you just create one file, no folders with next. That's a bit different. You create in folder, so in parent folder, I don't know your route will be ABC, and then in the folder, you create a file, which is page. TSX. And with that, you create a new route, so the whole look looks a bit different, and the whole feel is also a bit different, but in general, just when I compare them both, I can't really say that one is better or one is worse. They both have a bit of different workflows, but I wouldn't say that one is better than the other in terms of just using it all right. Since we have now talked about all the points regarding remix next shares, what they offer, what they don't offer, what is better than some points and worse than other points, let's now actually talk about what I would prefer when creating a project. So let's come to

the actual summary of this video so to actually explain it to you let's actually take two examples. One example will be just to create a standard content-driven website. For that, let's take my website as an example, janm_marshall.com. This website is pretty basic. We have an index page, courses page where you just fetch all the courses from Sanity. Then you have, of course, your authentication. So, nothing groundbreaking, but also a bit of layouts and also a bit of caching authentication. So, you still build something. And you know what, in that case, I would actually use Next.js and not Remix. Well, in this example, we rely heavily on, first of all, the ecosystem for authentication. So, Next.js. Off, we rely on caching, which is baked in Next.js, and the app router. Also, in this example, for example, the dev server does not play a huge role because, again, the website isn't that huge. And also, Next.js has very basic data loading and also mutations. You have your just normal async function where you fetch your data. You have the server component.

server actions to mutate data so it's all quite simple. Easy to do in such a basic website in quotations. You know. And now let's take a second example. And this will be a standard dashboard. Let's just take for example the Versel dashboard. Or. You know any bank will have a dashboard. So just a standard dashboard which is very dynamic. Has very minimal caching as you know it. And you know in such an example. I would probably choose Remix. And you know what. When you create such a big actual project. Such a dynamic application. I want to have a fast dev server. I don't have that with Nexs right now. It will change in the future. I'm pretty sure. But right now. V is 10 times faster. And I will choose Remix for that. Of course. That's not all. I mean. Let's be honest. In dev server is such a minimal point. It does not really make the difference. But there's still a lot of other stuff. So first of all. Let's again come to caching. Again caching is great.

when you have content-driven websites, when you create dashboards which are highly dynamic, it can be quite complicated with Nexs caching, and Nexs is still not 100% figured out. Caching still has some bugs, some stuff you don't really understand, and it just not really makes your life easy when you try to create dynamic websites. Also, for example, hours, hours are still a thing which got 10 times better, but they still aren't perfect. I still have hours where I really don't understand what they mean. I just get some webpack la la la la la la. I look at myself, I have no clue, and they just happen, and you have to live with that. And again, they got better, but they aren't perfect. So in general, again, there's no better or worse. Nevertheless, I personally lean to Nexs when I talk about content-driven websites and when I talk about very, very actual, um, dynamic websites, I prefer Remix. Nevertheless, both create at the end of the day good websites. You can use Nexs shares to.

create dynamic websites. It will work. You can create. You can use Remix to create content-driven websites. It also works both. At the end of the day, create the same product, the same end result. So you can actually create the same result with both actual frameworks. Still, I would say with one, it will be easier than with the other one. Nevertheless, both will do the same job and will do a good job. So now, friends, I hope you could learn something. I hope you could learn something about Next.js or Remix, the pros, the cons, and what you probably should choose. And now, I hope you also like this video, you subscribed, and I hope I will see you in the next video. So now, enjoy your day and bye.

Is Next.js better than Remix.run? | Next.js vs Remix in 2024

Jan Marshal

js is much easier than learning Remix, due to the abundant available resources such as articles, videos, and workshops.

js offers a far more extensive support system for learners compared to Remix.

js is described as good in version 12, but faced a significant decline in version 13 with the release of API routes, causing a lot of confusion and frustration.

js has improved its development experience and server performance, but still lags behind Remix in speed and HMR.

js has a larger and more established ecosystem compared to the newer Remix framework.

js is tightly coupled with Vercel, while Remix offers more flexibility to deploy anywhere.

Comparing Deployment and User Experience of Remix and Next.

Remix is 10 times easier to deploy on different providers compared to Next.

The two frameworks have different approaches to routing, with Remix using flat routes and Next.

Overall, the user experience differs between the two, and neither can be definitively said to be better than the other.

js for authentication, caching, and the app router, while a dynamic dashboard like Versel's would be better suited for Remix.

js is preferred for simple websites with basic data loading and mutations, while Remix is chosen for more complex and dynamic applications, especially for its faster development server.

Caching plays a minimal role in dynamic applications where Remix is preferred.

The Complexity of Dynamic Website Dashboards with Nexs and Remix

Creating dynamic website dashboards with Nexs caching can be complicated and not 100% figured out, with some remaining bugs and issues.

Despite improvements, understanding and working with hours in Remix can still be challenging, although both Nexs and Remix can ultimately create the same end result, Nexs may be easier to use for dynamic websites.