5 ms·

I've been hearing about Remix since they were sponsorware, but I don't really get the appeal. They don't seem to show how it's different from e.g. Next.js, espe

I've been hearing about Remix since they were sponsorware, but I don't really get the appeal. They don't seem to show how it's different from e.g. Next.js, especially version 12 which seems to have a similar feature set of server-side plus static rendering, as well as React server components, and then a separate /api folder for any backend apis you want to set up.

Bilal_io 5y ago
They just did (maybe still going) Q&A session where they did a demo and answered question. Remix seems to be more like PHP or Ruby On Rails, it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.
- cercatrova 5y ago
  Next.js has an /api folder that does that, is it similar?
  - Bilal_io 5y ago
    Take what I say with a grain of salt since I haven't used either. The API folder in Next.js simply exposes API routes that you can use in the frontend code of your Next.js app, or not use it if you don't want to. Remix does support this behavior, but it also supports exporting a data loader function and/or an action function for forms that can only consumed by by the page you're working on. All of that runs on the backend. Again, very similar to how things are done in PHP where data is loaded from a DB and then consumed all within the same file.
  - mcintyre1994 5y ago
    Their form demo is definitely worth checking out. You could build the same thing with a Next API route. You’d need to write some code to do the validation that they do, but it should largely look something like their hook does. Hopefully Next will build something like it because this is a much more sane way to write forms than the controlled inputs and state way. I do think it’s nice having it in the same file as the form itself, but it’s not clear how well that’ll scale in a more complex page with many forms. So I think Next could get most of the way there with a few helpers to make a form submit to an API route with similar DX.
- vosper 5y ago
  > it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file. Blitz JS does this to an extent, by magicking away the API and letting you right your queries in your front-end code. It actually works really well, and it's quite a nice dev experience once you get used to it. My favourite bit is writing my zod schemas and having them validate (with feedback in the form) on the frontend, and also on the backend.
  - aarpmcgee 5y ago
    Any chance you could share an example in a codesandbox? I realize that might be asking a lot, so no worries, but I'm super curious to see it.
- micahbule 5y ago
  That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps Some of the notable differences between NextJS and Remix are the following: - While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions - NextJS banks on its static site generation to generate "cache-able" websites whereas Remix utilizes cache headers for its server-rendered pages - NextJS has no baked-in support for handling session and cookies; Remix has
  - andrewingram 5y ago
    It doesn't really promote its use, but it's exceedingly easy to use cache headers with Next.js if you're using getInitialProps or getServerSideProps. My issue with Next.js (alongside lack of nested routes) is that it has a handful of weird light abstractions which make things marginally easier for developers for the most common cases, but completely tie the hands of people who know what they're doing. To that end, Remix is a little more appealing.
    - micahbule 5y ago
      While it is easy to use cache headers with NextJS -- as you said -- you have to know what you're doing. It still boils down to use case, implementation, and quite possibly preference. Personally, I'd still pick NextJS any time for any enterprise-level projects. Remix would be a fun little new framework to toy with for personal projects.
  - brundolf 5y ago
    > NextJS banks on its static site generation to generate "cache-able" websites Does it? You can still do traditional SSR in Next
    - micahbule 5y ago
      You can. I'm stating SSG in the context of caching and in comparison with Remix's approach.
  - 5y ago
- difu_disciple 5y ago
  Remix might be a few years too late to be honest. After watching the session, there does not appear to be any significant differences from Next.
  - danr4 5y ago
    the team behind remix probably has the biggest following in the react scene, so even without having any major differentiation (though I happen to think they do have) it's going to gain popularity.
    - remote-dev 5y ago
      I'm sure outside of my personal bubble this won't be an issue, but I've found the buzz generated from this announcement to be kind of off-putting. The sheer amount of promotion leading up to this announcement has been in my face now for weeks and kind of driving me nuts. That being said I see no reason to not welcome another competitor in this space... and it's free. I'm sure you are right and this will gain popularity, though the competition is stiff.
      - archeroe 5y ago
        I get what you mean, the frontend dev community on Twitter seem childish and unnatural, spamming self gratification (don't know if it's the good term, basically trying to spread fake positivity all the time, trying to over talk about the inclusivity and woke social trends ) stuff and overusing using emojis. I rarely check twitter but yesteday's Kent Dodds message section about a tweet announcing Remix's launch made me cringe.
        remote-dev 5y ago
        I'm sure many of the frontend dev Twitter influencers are genuine, but I do get a similar vibe. Some of the conversations just don't feel real at all, very similar to _some_ church circles.
    - brundolf 5y ago
bern4444 5y ago
They just did a demo with a simple form and looking at it seemed so obvious. There was no useState per form element, form data was trivially validated on the server, errors were trivially sent down to the server. If you look at this example[0] you'll see there's not a single useState, useEffect, etc. Fundamentally, Remix is about using native browser behavior to build websites. The imported `Form` component is replaceable with the HTML `form` element and it all still works. I think Remix is going to be even better than NextJS. This isn't a rivalry though, just an alternative solution. Clearly NextJS and React frameworks broadly are valuable, Remix is now another option. I really like that Remix's architecture means you end up writing code that would execute on your server and not the client. It feels like a much nicer balance rather than doing everything on the client. [0] https://github.com/remix-run/remix/blob/a56bdfd7f7e7fa9d8a3bd969ca9bed429bc0f8d7/examples/basic/app/routes/demos/actions.tsx#L68 https://github.com/remix-run/remix/blob/a56bdfd7f7e7fa9d8a3b...
- genezeta 5y ago
  > If you look at this example[0] you'll see there's not a single useState, useEffect, etc. Sorry to point it out, but there is useRef, useEffect and a useUserData on lines 48, 53, and 47 respectively.
  - bern4444 5y ago
    Ah i missed those cause this is different from the demo they showed. But the point still stands. There’s not a useDtate per form field which is how react normally handles forms
    - Aeolun 5y ago
      Hmm, you can easily use a normal form submit to pull field information from. We always want to do fancy things where we need the info while it is being changed though.
    - bpicolo 5y ago
      Forms are one of those things that are so much easier to manage in Vue (and no extra dependencies) https://v3.vuejs.org/guide/forms.html https://v3.vuejs.org/guide/forms.html
umariomaker 5y ago
If you're looking for some of the benefits of co-located components and "loaders", I would recommend checking out: https://github.com/smeijer/next-runtime https://github.com/smeijer/next-runtime . That was the main thing that intrigued me about Remix, but you can get a lot of the same benefits using this

Bilal_io 5y ago

They just did (maybe still going) Q&A session where they did a demo and answered question. Remix seems to be more like PHP or Ruby On Rails, it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.

cercatrova 5y ago
Next.js has an /api folder that does that, is it similar?
- Bilal_io 5y ago
  Take what I say with a grain of salt since I haven't used either. The API folder in Next.js simply exposes API routes that you can use in the frontend code of your Next.js app, or not use it if you don't want to. Remix does support this behavior, but it also supports exporting a data loader function and/or an action function for forms that can only consumed by by the page you're working on. All of that runs on the backend. Again, very similar to how things are done in PHP where data is loaded from a DB and then consumed all within the same file.
- mcintyre1994 5y ago
  Their form demo is definitely worth checking out. You could build the same thing with a Next API route. You’d need to write some code to do the validation that they do, but it should largely look something like their hook does. Hopefully Next will build something like it because this is a much more sane way to write forms than the controlled inputs and state way. I do think it’s nice having it in the same file as the form itself, but it’s not clear how well that’ll scale in a more complex page with many forms. So I think Next could get most of the way there with a few helpers to make a form submit to an API route with similar DX.
vosper 5y ago
> it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file. Blitz JS does this to an extent, by magicking away the API and letting you right your queries in your front-end code. It actually works really well, and it's quite a nice dev experience once you get used to it. My favourite bit is writing my zod schemas and having them validate (with feedback in the form) on the frontend, and also on the backend.
- aarpmcgee 5y ago
  Any chance you could share an example in a codesandbox? I realize that might be asking a lot, so no worries, but I'm super curious to see it.
micahbule 5y ago
That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps Some of the notable differences between NextJS and Remix are the following: - While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions - NextJS banks on its static site generation to generate "cache-able" websites whereas Remix utilizes cache headers for its server-rendered pages - NextJS has no baked-in support for handling session and cookies; Remix has
- andrewingram 5y ago
  It doesn't really promote its use, but it's exceedingly easy to use cache headers with Next.js if you're using getInitialProps or getServerSideProps. My issue with Next.js (alongside lack of nested routes) is that it has a handful of weird light abstractions which make things marginally easier for developers for the most common cases, but completely tie the hands of people who know what they're doing. To that end, Remix is a little more appealing.
  - micahbule 5y ago
    While it is easy to use cache headers with NextJS -- as you said -- you have to know what you're doing. It still boils down to use case, implementation, and quite possibly preference. Personally, I'd still pick NextJS any time for any enterprise-level projects. Remix would be a fun little new framework to toy with for personal projects.
- brundolf 5y ago
  > NextJS banks on its static site generation to generate "cache-able" websites Does it? You can still do traditional SSR in Next
  - micahbule 5y ago
    You can. I'm stating SSG in the context of caching and in comparison with Remix's approach.
- 5y ago
difu_disciple 5y ago
Remix might be a few years too late to be honest. After watching the session, there does not appear to be any significant differences from Next.
- danr4 5y ago
  the team behind remix probably has the biggest following in the react scene, so even without having any major differentiation (though I happen to think they do have) it's going to gain popularity.
  - remote-dev 5y ago
    I'm sure outside of my personal bubble this won't be an issue, but I've found the buzz generated from this announcement to be kind of off-putting. The sheer amount of promotion leading up to this announcement has been in my face now for weeks and kind of driving me nuts. That being said I see no reason to not welcome another competitor in this space... and it's free. I'm sure you are right and this will gain popularity, though the competition is stiff.
    - archeroe 5y ago
      I get what you mean, the frontend dev community on Twitter seem childish and unnatural, spamming self gratification (don't know if it's the good term, basically trying to spread fake positivity all the time, trying to over talk about the inclusivity and woke social trends ) stuff and overusing using emojis. I rarely check twitter but yesteday's Kent Dodds message section about a tweet announcing Remix's launch made me cringe.
      - remote-dev 5y ago
        I'm sure many of the frontend dev Twitter influencers are genuine, but I do get a similar vibe. Some of the conversations just don't feel real at all, very similar to _some_ church circles.
  - brundolf 5y ago

bern4444 5y ago

They just did a demo with a simple form and looking at it seemed so obvious. There was no useState per form element, form data was trivially validated on the server, errors were trivially sent down to the server. If you look at this example[0] you'll see there's not a single useState, useEffect, etc. Fundamentally, Remix is about using native browser behavior to build websites. The imported `Form` component is replaceable with the HTML `form` element and it all still works. I think Remix is going to be even better than NextJS. This isn't a rivalry though, just an alternative solution. Clearly NextJS and React frameworks broadly are valuable, Remix is now another option. I really like that Remix's architecture means you end up writing code that would execute on your server and not the client. It feels like a much nicer balance rather than doing everything on the client. [0] https://github.com/remix-run/remix/blob/a56bdfd7f7e7fa9d8a3bd969ca9bed429bc0f8d7/examples/basic/app/routes/demos/actions.tsx#L68 https://github.com/remix-run/remix/blob/a56bdfd7f7e7fa9d8a3b...

genezeta 5y ago
> If you look at this example[0] you'll see there's not a single useState, useEffect, etc. Sorry to point it out, but there is useRef, useEffect and a useUserData on lines 48, 53, and 47 respectively.
- bern4444 5y ago
  Ah i missed those cause this is different from the demo they showed. But the point still stands. There’s not a useDtate per form field which is how react normally handles forms
  - Aeolun 5y ago
    Hmm, you can easily use a normal form submit to pull field information from. We always want to do fancy things where we need the info while it is being changed though.
  - bpicolo 5y ago
    Forms are one of those things that are so much easier to manage in Vue (and no extra dependencies) https://v3.vuejs.org/guide/forms.html https://v3.vuejs.org/guide/forms.html

umariomaker 5y ago

If you're looking for some of the benefits of co-located components and "loaders", I would recommend checking out: https://github.com/smeijer/next-runtime https://github.com/smeijer/next-runtime . That was the main thing that intrigued me about Remix, but you can get a lot of the same benefits using this