Hacker News Reader

Comment by rpastuszak | Hacker News Reader

How would you compare it to sveltekit or next in this regard?

Remix is _just_ a really nice request handler. That means you can bring your own server (instead of getting locked into some specific implementation). There's a lot of benefit to the Remix team's "Use the platform" mantra. This means that you don't always have to go looking for "the Remix way to...." on Google. This was a major frustration with NextJS. "How do I run a function when the server boots up in NextJS?"

To be fair, you can use a custom server with Next.js too.

As someone who's evaluating both Remix and Next right now Remix makes it very clear and front-and-centre that you can (and perhaps should) bring your server. Next documentation barely mentions it, if you're lucky to find anything at all and in some parts they discourage it and push you to embrace the "serverless/edge" future.

Haven't tried sveltekit but I think it's nicer than next because it "uses the platform" more like the standards are supposed to. You will never get a button that is not clickable because some javascript is not loaded.

It's also more straightforward to get started and has sane defaults for the different "stacks" that exist. It's also way easier to self-host. So there are many positives for remix.

I would say if you know that you are going to use Vercel, use Next.js but otherwise I would always argue for Remix. I was a bit hesitant towards React before but Remix had me totally converted due to how easy it feels developing a full stack react app. Nothing even comes close in the javascript land imo. I have done years of work with SPA with web components/Vue/Angular and an api but using Remix I feel like I am several times more productive.

You don't need a state machine with remix as long as you use a backend (I haven't tried the new Remix SPA mode yet), even if you have a backend in another language it is a great way to do backend for frontend meaning that you can gather the data you need and provide it to the client in a nice way. No more spinners everywhere, let your fast server do the api calls and serve the rendered page to the client. You won't have the issues that usually comes with a SPA if you use Remix with a backend. You can stream stuff if you know you have requests that will take a bit longer to complete: https://remix.run/docs/en/main/guides/streaming

You can read more about why remix is nicer here: https://www.epicweb.dev/why-i-wont-use-nextjs

> I would say if you know that you are going to use Vercel, use Next.js but otherwise I would always argue for Remix.

Exactly. It makes absolute no sense to deal with all of Next's artificially imposed limitations if you're running it on your own servers.

What limitations? You mean like not being able to use the full node API in your middleware that's being run by the node server that you control in your own infrastructure?

And how about that dev rel... no response since August of last year.

https://github.com/vercel/next.js/discussions/46722

This is done so that you never use it (even in your own servers) because otherwise you won’t be able to move to their cloud.

This is why you don’t use VC backed dependencies that are not easy to move away from.

Remix is really cool and agree with most of your link, but:

> Next.js is on version 13. React Router (built by the same team as Remix) has been around for much longer

this is not a selling point for me. React Router has been such a pain to deal with and upgrade, Next was much nicer to use in apps in comparison.

I think (hope) they learned a lesson from this, as Remix is very good at not introducing breaking changes:

https://remix.run/docs/en/main/start/future-flags

> "if you know that you are going to use Vercel, use Next.js but otherwise I would always argue for Remix"

Hmm. I'm using Remix and Vercel for a side-project right now and it's pretty awesome. Lightning fast build times (around 30 seconds).

At work, I use Vercel with Next.js and our build times are in the one-three minute range.

Yeah obviously you can use Remix at Vercel as well, but since Vercel is the company behind Next.js I would think you will probably have a better time using Next.js with Vercel.

Altough, I have never used Vercel so that was just an assumption from my part. From my understanding though, they make it really easy to host Next.js apps with Vercel.

I guess the good part of using Remix if you use Vercel is that when they pull the rug from beneath you, you can always switch to another hosting provider.

> You will never get a button that is not clickable because some javascript is not loaded.

I'm open to being wrong here, but this is symptomatic of the developers who implement the components, not the frameworks no? I'm unaware of any major framework that hijacks buttons, you very specifically have to not use the `<button>` element to not get a button.

If what you really mean is an action can still take place even though some JS wasn't loaded (e.g. web standard form submission) then I understand, but otherwise I'm not sure how frameworks are at fault for this issue

A telling example from the Remix docs [0]. It is an elegant layer over native APIs.

> This is a Fetch Request instance. You can read the MDN docs to see all of its properties.

Compare this to Next's app router equivalent of fetching the request headers [1]:

> The headers function allows you to read the HTTP incoming request headers from a Server Component.

[0] - https://remix.run/docs/en/main/route/loader#request

[1] - https://nextjs.org/docs/app/api-reference/functions/headers

Next's headers function is an elegant layer over the Web Headers API.

But I want the request. Remix points the reader to the MDN docs. Next invents its own little thing. This is the fundamental difference in philosophy.

The Web Headers API isn't Next's own thing. They point you to the MDN docs.

And if you want a route's request object in Next, use a route.js file.

Reply on news.ycombinator.com