Hacker News Reader

Comment by canyonero | Hacker News Reader

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.

View on HN

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?

> 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.

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.

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.

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.

Reply on news.ycombinator.com