8 ms·

I'd love to hear a comparison between this and Next.js if someone has used both.

canyonero 5y ago
I've used both and I can say some key differentiators are: - The routing is quite different. RedwoodJS handles routing in a single file rather than doing file-based routing. - Next.js is full-stack available while RedwoodJS is full-stack by design. A Next.js developer needs to make many decisions about how they will design their API (the DB, GraphQL vs REST, choosing an ORM, etc). RedwoodJS is more opinionated and provides Prisma, *SQL, and GraphQL out-of-the-box. - RedwoodJS has code scaffolding out-of-the-box. You can easily scaffold out models across frontend and backend based on your Prisma/DB schema. - Next.js is intentionally designed to have first-class support on Vercel whereas RedwoodJS is by design, more agnostic toward to the deploy target.
- booi 5y ago
  Would you recommend RedwoodJS for green field projects? How would you say an opinionated framework like this works in the medium to late maturity? Is it easy or even possible to switch out components with more "enterprisy" solutions?
  - canyonero 5y ago
    > Would you recommend RedwoodJS for green field projects? IMO if you want to run PostgreSQL, React and GraphQL with the least amount of friction and decision making, RedwoodJS is great choice. > How would you say an opinionated framework like this works in the medium to late maturity? If you run a frontend-heavy and/or TS/JS shop and don't mind the tradeoffs of something like Ruby on Rails, then I see no limitations to building whatever you want with it. > Is it easy or even possible to switch out components with more "enterprisy" solutions? Not sure what that would look like, so I can't comment.
    - tootie 5y ago
      Being able to more quickly bootstrap a project is about 0.01% of the value of a platform. If that's the pitch then I'm not buying. I'll choose the platform that's easiest to debug, maintain and expand.
      - mojombo 5y ago
        RedwoodJS has been about long term maintainability from the very beginning. This is part of why we chose GraphQL as a core component. It's more complex at first, but in the long run it gives you multi-client capabilities without rewriting your backend, and provides excellent separation of concerns. We still try to make Redwood as easy to get started with as possible, but in the tradeoff between "quick bootstrapping" and "long term maintainability", we tend to choose the latter.
      - fishtoaster 5y ago
        That's definitely a valid view, but I'd say it's not the only one. For some usecases, quick bootsrapping is incredibly valuable - eg an early-stage startup. That was the historical case for Rails: quick to get started and not too bad to maintain/expand as you grow (it got better about later stages in the later years as the ecosystem matured). That's a tradeoff that can make a ton of sense when you're starting a project that has a good chance of not existing in 6 months and where every day of initial productivity is incredibly valuable.
leodriesch 5y ago
As far as I know Redwood has no server-side rendering solution. You can do both client-side rendering and static generation (although not as sophisticated as Next.js'), but not server-side rendering. Next.js also has a pretty small API surface and is generally quite unopinionated when it comes to your apps structure, while Redwood chooses more of the stack for you and what tools you should use (Storybook, Jest, Prisma, GraphQL). I would also like to point out that while there are a lot of people rooting for Redwood's success and they seem to have some active core contributors, there is actual financial backing for Next.js and they have large enterprise users. There are some startups that use Redwood listed on the 1.0 update website, but at least I do not know any of them.
- mojombo 5y ago
  > As far as I know Redwood has no server-side rendering solution. SSR is priority number one for v2. In the meantime, a number of users use Next.js as a client that talks GraphQL to the Redwood backend. It works very well! > there is actual financial backing for Next.js Today I announced I will be providing $1M of funding for future RedwoodJS framework development this year, so now we have funding too. =) https://tom.preston-werner.com/2022/04/04/redwood-v1-and-funding.html https://tom.preston-werner.com/2022/04/04/redwood-v1-and-fun... The truth is, we can both succeed at the same time, there are so many great app ideas waiting to be explored, and different tools will work better for different situations!
  - xrd 5y ago
    I'm the author of Svekyll (https://svekyll.com https://svekyll.com) a static blog tool which models the simplicity of Jekyll. Svekyll uses SvelteKit under the hood, but rendering to a static site feels like it is a second class experience in SvelteKit (they are more focused on rendering to cloudflare or netlify or vercel serverless platforms). I would love to experiment with using RedwoodJS as the backend if SSR is a priority; how do I get more information on that work?
    - dac09 5y ago
      Hi! Core team member here, right now we have our hands a little full with the launch week, but will be moving onto v2 very soon! Best way to get more info is to create a post on the forums, or an issue! The discord contributing channel is a great place too. All the links on the main website https://redwoodjs.com https://redwoodjs.com Speak to you over there!
thedavidprice 5y ago
You can use RedwoodJS API as the backend for Next. There are several startups with multi-client products including a Next front-end as one of many.
- mattwad 5y ago
  Interesting.. I didn't know that, thanks!

I've used both and I can say some key differentiators are: - The routing is quite different. RedwoodJS handles routing in a single file rather than doing file-based routing. - Next.js is full-stack available while RedwoodJS is full-stack by design. A Next.js developer needs to make many decisions about how they will design their API (the DB, GraphQL vs REST, choosing an ORM, etc). RedwoodJS is more opinionated and provides Prisma, *SQL, and GraphQL out-of-the-box. - RedwoodJS has code scaffolding out-of-the-box. You can easily scaffold out models across frontend and backend based on your Prisma/DB schema. - Next.js is intentionally designed to have first-class support on Vercel whereas RedwoodJS is by design, more agnostic toward to the deploy target.

booi 5y ago
Would you recommend RedwoodJS for green field projects? How would you say an opinionated framework like this works in the medium to late maturity? Is it easy or even possible to switch out components with more "enterprisy" solutions?
- canyonero 5y ago
  > Would you recommend RedwoodJS for green field projects? IMO if you want to run PostgreSQL, React and GraphQL with the least amount of friction and decision making, RedwoodJS is great choice. > How would you say an opinionated framework like this works in the medium to late maturity? If you run a frontend-heavy and/or TS/JS shop and don't mind the tradeoffs of something like Ruby on Rails, then I see no limitations to building whatever you want with it. > Is it easy or even possible to switch out components with more "enterprisy" solutions? Not sure what that would look like, so I can't comment.
  - tootie 5y ago
    Being able to more quickly bootstrap a project is about 0.01% of the value of a platform. If that's the pitch then I'm not buying. I'll choose the platform that's easiest to debug, maintain and expand.
    - mojombo 5y ago
      RedwoodJS has been about long term maintainability from the very beginning. This is part of why we chose GraphQL as a core component. It's more complex at first, but in the long run it gives you multi-client capabilities without rewriting your backend, and provides excellent separation of concerns. We still try to make Redwood as easy to get started with as possible, but in the tradeoff between "quick bootstrapping" and "long term maintainability", we tend to choose the latter.
    - fishtoaster 5y ago
      That's definitely a valid view, but I'd say it's not the only one. For some usecases, quick bootsrapping is incredibly valuable - eg an early-stage startup. That was the historical case for Rails: quick to get started and not too bad to maintain/expand as you grow (it got better about later stages in the later years as the ecosystem matured). That's a tradeoff that can make a ton of sense when you're starting a project that has a good chance of not existing in 6 months and where every day of initial productivity is incredibly valuable.

leodriesch 5y ago

As far as I know Redwood has no server-side rendering solution. You can do both client-side rendering and static generation (although not as sophisticated as Next.js'), but not server-side rendering. Next.js also has a pretty small API surface and is generally quite unopinionated when it comes to your apps structure, while Redwood chooses more of the stack for you and what tools you should use (Storybook, Jest, Prisma, GraphQL). I would also like to point out that while there are a lot of people rooting for Redwood's success and they seem to have some active core contributors, there is actual financial backing for Next.js and they have large enterprise users. There are some startups that use Redwood listed on the 1.0 update website, but at least I do not know any of them.

mojombo 5y ago
> As far as I know Redwood has no server-side rendering solution. SSR is priority number one for v2. In the meantime, a number of users use Next.js as a client that talks GraphQL to the Redwood backend. It works very well! > there is actual financial backing for Next.js Today I announced I will be providing $1M of funding for future RedwoodJS framework development this year, so now we have funding too. =) https://tom.preston-werner.com/2022/04/04/redwood-v1-and-funding.html https://tom.preston-werner.com/2022/04/04/redwood-v1-and-fun... The truth is, we can both succeed at the same time, there are so many great app ideas waiting to be explored, and different tools will work better for different situations!
- xrd 5y ago
  I'm the author of Svekyll (https://svekyll.com https://svekyll.com) a static blog tool which models the simplicity of Jekyll. Svekyll uses SvelteKit under the hood, but rendering to a static site feels like it is a second class experience in SvelteKit (they are more focused on rendering to cloudflare or netlify or vercel serverless platforms). I would love to experiment with using RedwoodJS as the backend if SSR is a priority; how do I get more information on that work?
  - dac09 5y ago
    Hi! Core team member here, right now we have our hands a little full with the launch week, but will be moving onto v2 very soon! Best way to get more info is to create a post on the forums, or an issue! The discord contributing channel is a great place too. All the links on the main website https://redwoodjs.com https://redwoodjs.com Speak to you over there!

thedavidprice 5y ago

You can use RedwoodJS API as the backend for Next. There are several startups with multi-client products including a Next front-end as one of many.

mattwad 5y ago
Interesting.. I didn't know that, thanks!