Next.js와 리믹스 프레임워크 비교: 학습, 경험 및 에코시스템

### Next.js와 리믹스 비교: 학습의 용이성, 개발 경험, 에코시스템, 배포 및 프레임워크 선호도 비교
* 📚 블로그 글, 동영상, 워크샵 등 풍부한 리소스가 제공되므로 **Next.js를 배우는 것이 Remix를 배우는 것보다 쉽습니다.** Remix 문서는 시간이 지남에 따라 노후화되었으며, **Remix의 콘텐츠 및 강좌의 양은 Next.js에 비해 현저히 적습니다.**
* ⚙ Next.js 12에서는 페이지 폴더를 사용한 개발 환경이 좋았으나 API 경로가 포함된 **Next.js 13에서는 문제가 발생**했습니다. **Next.js 4.0에서는 개발 환경이 개선**되고 프레임워크가 더 이해하기 쉬워졌습니다. 그러나 **Next.js 개발 서버는 여전히 좋지 않**습니다. 반면에 **Remix는 Vite를 사용**하므로 핫 모듈 교체(HMR) 및 전반적인 개발 경험 측면에서 훨씬 빠릅니다.
* 🌐 Next.js는 더 오래 존재했기 때문에 더 큰 에코시스템을 가지고 있지만, **Remix는 더 다양한 배포**가 가능합니다. Next.js는 **Vercel과 긴밀하게 통합**되어 있어 다른 서버리스 제공업체에 배포하기가 어렵습니다. 반면 웹 API를 기반으로 하는 **Remix는 많은 구성 없이 어디에나 배포**할 수 있습니다.
* 🛳 Next.js와 Remix 중 하나를 결정할 때는 프로젝트 유형에 따라 선택이 달라집니다. **콘텐츠 중심 웹사이트와 기본적인 데이터 로딩 및 변경이 필요한 웹사이트**의 경우 Next.js가 선호됩니다. 반면에 **빠른 개발 서버와 최소한의 캐싱이 필요한 대시보드**와 같은 동적 애플리케이션의 경우 Remix가 더 나은 선택입니다.
* 🔄 Next.js와 Remix는 모두 성능 좋은 웹사이트를 만든다는 동일한 목표를 달성하는 것을 목표로 하지만 워크플로우가 다릅니다. 예를 들어 라우팅 구조가 다른데, **Next.js는 폴더 기반 접근 방식을 사용**하고 **Remix는 플랫 라우트를 사용**합니다.
* 👨 두 프레임워크 모두 동일한 최종 결과물을 만드는 데 사용할 수 있지만 한 프레임워크가 다른 프레임워크보다 작업하기가 더 쉬울 수 있습니다. **콘텐츠 중심 웹 사이트에는 Next.js가 선호**되는 반면, **동적 애플리케이션에는 Remix가 선호**됩니다.
* 🔒 "결국 **Next.js와 Remix 중 어떤 것을 선택할지는 특정 프로젝트의 요구 사항과 개발자의 선호도**에 따라 달라집니다."

Next.js에 사용할 수 있는 리소스가 풍부하기 때문에 Next.js를 배우는 것이 Remix를 배우는 것보다 쉬우며, 배포 유연성 측면에서는 Remix가 뛰어납니다.

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와 리믹스 프레임워크 비교하기

기사, 동영상, 워크샵 등 풍부한 리소스가 제공되므로 Next.

js를 배우는 것이 Remix를 배우는 것보다 훨씬 쉽습니다.

js는 Remix에 비해 학습자를 위한 훨씬 더 광범위한 지원 시스템을 제공합니다.

js의 개발 환경은 버전 12에서는 좋았으나 버전 13에서 API 경로가 출시되면서 크게 저하되어 많은 혼란과 불만을 야기했습니다.

js는 개발 환경과 서버 성능이 개선되었지만 속도와 HMR에서는 여전히 Remix에 뒤쳐져 있습니다.

js는 최신 Remix 프레임워크에 비해 더 크고 확립된 에코시스템을 갖추고 있습니다.

js 배포는 Vercel과 긴밀하게 결합되어 있는 반면, Remix는 어디서나 배포할 수 있는 유연성을 제공합니다.

js에 비해 다른 제공업체에 배포하기가 10배 더 쉽습니다.

두 프레임워크는 라우팅에 대한 접근 방식이 다른데, Remix는 플랫 라우트를 사용하고 Next.

전반적으로 사용자 경험은 둘 사이에 차이가 있으며 어느 쪽이 다른 쪽보다 낫다고 단정적으로 말할 수는 없습니다.

다양한 웹 프로젝트에 대해 Next.

com은 인증, 캐싱 및 앱 라우터에 Next.

js를 사용하는 기본 웹사이트라면, Versel과 같은 동적 대시보드는 Remix에 더 적합할 것입니다.

기본적인 데이터 로딩 및 변경이 있는 간단한 웹사이트에는 Next.

js가 선호되는 반면, 보다 복잡하고 동적인 애플리케이션, 특히 더 빠른 개발 서버에는 Remix가 선택됩니다.

캐싱은 Remix가 선호되는 동적 애플리케이션에서 최소한의 역할만 수행합니다.

넥스와 리믹스를 사용한 동적 웹사이트 대시보드의 복잡성

넥스 캐싱으로 동적 웹사이트 대시보드를 만드는 것은 복잡할 수 있으며, 일부 버그와 문제가 남아 있어 100% 해결되지 않은 상태입니다.

개선이 이루어졌음에도 불구하고 Remix에서 시간을 이해하고 작업하는 것은 여전히 어려울 수 있지만, Nex와 Remix 모두 궁극적으로 동일한 최종 결과를 만들 수 있지만, 동적 웹사이트에는 Nex를 사용하기가 더 쉬울 수 있습니다.