5 ms·

This is awesome news. Remix has become my standard go-to for all new projects. They have really sane defaults and together with stuff like their indie-stacks et

This is awesome news. Remix has become my standard go-to for all new projects. They have really sane defaults and together with stuff like their indie-stacks etc developing apps goes really super fast. I have never been so productive as I have been with Remix and it's really good that the finally have embraced Vite so I can use all the different plugins etc that exist for it.

rpastuszak 3y ago
How would you compare it to sveltekit or next in this regard?
- ecmascript 3y ago
  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 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 https://www.epicweb.dev/why-i-wont-use-nextjs
  - 0xblinq 3y ago
    > 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.
    - ervine 3y ago
      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 https://github.com/vercel/next.js/discussions/46722
      - 0xblinq 3y ago
        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.
  - gedy 3y ago
    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.
    - colinramsay 3y ago
      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 https://remix.run/docs/en/main/start/future-flags
  - peterb0yd 3y ago
    > "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.
- nobleach 3y ago
  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?"
  - dham 3y ago
    To be fair, you can use a custom server with Next.js too.
    - laurels-marts 3y ago
      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.
- gherkinnn 3y ago
  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 https://remix.run/docs/en/main/route/loader#request [1] - https://nextjs.org/docs/app/api-reference/functions/headers https://nextjs.org/docs/app/api-reference/functions/headers
  - robertoandred 3y ago
    Next's headers function is an elegant layer over the Web Headers API.
    - gherkinnn 3y ago
      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.
      - robertoandred 3y ago
        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.

rpastuszak 3y ago

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

ecmascript 3y ago
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 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 https://www.epicweb.dev/why-i-wont-use-nextjs
- 0xblinq 3y ago
  > 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.
  - ervine 3y ago
    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 https://github.com/vercel/next.js/discussions/46722
    - 0xblinq 3y ago
      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.
- gedy 3y ago
  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.
  - colinramsay 3y ago
    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 https://remix.run/docs/en/main/start/future-flags
- peterb0yd 3y ago
  > "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.
nobleach 3y ago
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?"
- dham 3y ago
  To be fair, you can use a custom server with Next.js too.
  - laurels-marts 3y ago
    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.
gherkinnn 3y ago
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 https://remix.run/docs/en/main/route/loader#request [1] - https://nextjs.org/docs/app/api-reference/functions/headers https://nextjs.org/docs/app/api-reference/functions/headers
- robertoandred 3y ago
  Next's headers function is an elegant layer over the Web Headers API.
  - gherkinnn 3y ago
    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.
    - robertoandred 3y ago
      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.