RedwoodJS vs Remix?

RedwoodJS vs Remix ?

Does anyone have any comparisons they can share?

Is it possible that we might have a Remix ‘side’ ? Should we ?

You might find this post interesting: But why Redwood rather than some other framework (Remix, Blitz, Vue, NextJS, Gatsby, SvelteKit, 11ty, NuxtJS)? - Get Help and Help Others / Solutions - RedwoodJS Community

That is a good post, but I’m looking for talking points as to why we should choose Redwood over Remix

Unless we could do a Remix-side ?

My latest project is using SQLite to manage all the app themes & configs settings (later I can transition to a remote database)

All the rest of the remote services will be via RabbitMQ

A Remix side might make that even easier?

I wrote a tweet thread a while ago with my own opinion on RW vs Remix, here’s what I said:

As you know, I’m a huge proponent of frameworks learning from each other and I think both have a ton to offer. I love Remix’s emphasis on web standard APIs and shipping less JS whenever possible. The conventions they add on top are very intuitive.

Biggest differences to me are the degree to which they emphasize the part of the stack that talks to the database and how the auth is managed. Remix says it’s the View and Controller in MVC, but leaves the Model up to you. You can bring in Prisma easily to handle the M but it’s not included by default.

RW, on the other hand, does the opposite. It includes Prisma by default and you can rip it out if you want. Redwood also has built in authentication and a ton of third party provider integrations.

I have no doubt Remix will be building out similar features but as of now I think there’s mostly just community packages and one section in the docs about auth. And then of course there’s the question of do you want to use GraphQL or not which is its own debate unto itself.

This is already a little out of date because a few weeks after I wrote this Remix released Remix Stacks which are Remix starters that are much more similar to Redwood apps than what they offered before they had these stacks.

In terms of having a Remix side, you could use Remix today to make GraphQL calls to a Redwood API much like I do in my Next and SvelteKit examples.

Hope that’s helpful :+1:.

3 Likes

That’s exactly the information I was looking for !!

Perfect, Thanks!

1 Like

Couple things. A monorepo approach from RW is clean and explicit. It shares typescript definitions across both, so you have some isomorphic benefits. Routes in a router file are also explicit. The bundling/integration of storybook should not be sneezed at, nor should the testing framework and scaffolding inclusions. This keeps your components tidy, composable and very robust.

In Remix, the sell seems to be more about reducing boilerplate associated with Form handling and data boilerplate stuff through magic. The following the web API and supporting deployments to multiple serverless clouds is nice. The caching and validation are nice. Their todoMVC example is a hot mess. Not sure if it really showcases the weak points of this framework vs RW, but it sure doesn’t help their case.

One of the reasons I like RW so much is because things stay isolated, encapsulated, tiny and tidy. Common tasks become simpler and trivial and if i have to refactor or dig into a file, I don’t feel like I’m slogging through a swamp of mixed up data, functions and decoration markup mashed into one monolith. The things I want most from a framework beyond the norm right now are documentation/spec driven functionality for generating searchable/sortable data grids and validating large scaffolded up forms, bundled/solved i18n and some baseline support for a11y. Last I looked, these weren’t first class support considerations, but they’re pretty foundational elements if you want to start from an existing database schema with globalization in mind rather than trying to revisit it after getting your native language version rolling, then porting all your text nodes and things over to some system. RW and the market kinda decided on the best tech stack with GraphQL and Prisma, testing and deployment, so it’s a bummer that it’s mid 2022 and the world still doesn’t have an agreed upon best standard/lib for how we’re tackling these that can just roll in.

2 Likes

Does RW have an analog to Optimistic UI? Error/Boundary handling? Avoiding fetch waterfalls via the routing conventions? URL Normalization and Canonical URL generation? Splat routes?

1 Like

I am finding that @PantheRedEye has very similar opinions as I do. For example, @jeffreytgilbert writes:

One of the reasons I like RW so much is because things stay isolated, encapsulated, tiny and tidy. Common tasks become simpler and trivial and if i have to refactor or dig into a file, I don’t feel like I’m slogging through a swamp of mixed up data, functions and decoration markup mashed into one monolith.

And I believe that it is this text that made @PantheRedEye like @jeffreytgilbert’s evaluation of RWJS :grinning: