Skip to content

Instantly share code, notes, and snippets.

@ngbrown
Created June 22, 2022 02:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ngbrown/d202c37d5fec8bee42d69df314a11916 to your computer and use it in GitHub Desktop.
Save ngbrown/d202c37d5fec8bee42d69df314a11916 to your computer and use it in GitHub Desktop.

cryptosi: Hi guys, looking to convince my company to use Remix but need some compelling arguments. This new project is definitely a good use case so I want to be able to articulate why we should use Remix. I've been doing my own research but wanted to reach out here to see if anyone had resources they might use for me to read and compile a list of reasons to use remix.

From purpler:

  • helped me avoid needing a graphql layer between my frontend and prisma

From Julienng:

  • simpler model than next : no isr, & all : it's easier to explain to new developer
  • simpler form than anything in the react world when you don't need anything fancy, and you can still do fancy stuff when needed
  • auto reload of loader when an action is fired : bye bye refreshListeners on parents for us and reloadPage() callback 😅
  • fast compilation
  • based on react router : we already use it internally
  • ErrorBoundary & CatchBoundary : it's easier to get good error page, like a lot
  • so much useEffect gone, my debug experience is just so much better
  • it's so good a have access to the server again on the same place as your client code when you came back from CRA. So much place for caching there, it helps a lot when you deploy on premise and don't have vercel, fly & co to help you

from sergiodxa:

  • Cookie & session handling is built-in in Remix
  • Forms are way simpler, drop a Form with some inputs, read it on the action, no more onSubmit and preventDefault, or keeping all inputs in states just to send them in the fetch, keep on state what you really need
  • Loaders and actions API is superior to getServerSideProps/getStaticProps/getInitialProps/APIs, both follow the same interface (even for API routes) and it's based on standards (Request and Response object) instead of custom objects
  • Embracing web standards is the right approach, Next hides them for you, Remix makes you a better web developer
  • While more people may know Next over Remix, Remix reliance on web standards makes hiring simpler, you just need to hire a web developer who knows React
  • Ramix makes progressive enhancement a breeze, you can use useTransition and other hooks enhance the UX once JS load, while retaining basic behavior even if JS didn't load (e.g. it failed due internet issues or code errors)
  • Nested routes is superior to not nested routes, Next future nested route feature is not yet there and the spec is inferior to Remix (why force layout.js and page.js files everywhere!)
  • Remix Link prefetching feature is superior to Next, it not only prefetch the JS code, it also can prefetch data and assets like images or CSS
  • Remix compiler is fast AF
  • More advanced patterns are simple to implement because you will have access to all React + multiple hooks from Remix and React Router
  • There's a lot of code you will not need to write anymore and that it's always better
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment