Hacker News Reader

Comment by mojombo | Hacker News Reader

Hi! One of the Redwood authors here. I'm really excited to launch Redwood today and happy to answer any questions you have about the framework and what makes it special!

View on HN

This is awesome, congrats! I love Rails but it does seem like nextjs has left it in the dust in terms of making it easy to build simple, performant front-ends in react and there's no official Rails graphql solution yet either. What next is missing is a blessed omakase way to deploy it with a DB.

Can you talk about or point me to docs on the different philosophies between this and nextjs? In particular next already makes bundle optimization, splitting, lazy-fetching and serverless deploys pretty automatic. Why not start with next and work on incorporating the DB/business logic functionality? Related: why Prisma?

Next.js is really great, and has definitely helped push the industry forward. I'm not a fan of the way they handle routing, though, and we need to be able to evolve Redwood without fighting against our dependencies. If I had to guess, we may end up writing our own versions of other things as time goes on. We're all about integration, and sometimes you have to own things yourself to make it all work as seamlessly as possible.

FWIW we use Next.js without the pages folder convention, we use a routes.js and just have the pages folder as a build artefact, then we have relatively seamless integration with Relay to make data management super straightforward.

> there's no official Rails graphql solution yet either

I use https://github.com/rmosolgo/graphql-ruby!

It's not official, but it may as well be. Fantastic library.

I love Rails but it does seem like nextjs has left it in the dust i

What next is missing is a blessed omakase way to deploy it with a DB.

So its missing a complete "rails" solution? that's a big "missing"

I mean, why are you even comparing them?

This is amazing - I'm very much in Django land right now, but I'd love to see a successor that combines all its productivity strengths with the modern world of JS/Typescript-all-the-way-down.

A few questions:

- Do you intend to have strong typing (Typescript) all the way through? Most of the examples seem to be in plain JS. Not that that's a bad place to start, but I have a dream of typing a schema for a new model once and having it immediately typecheck all the way to the frontend code.

- Will there be an ability to automatically generate admin interfaces, form and all, from database schema? Django's ModelAdmin is annoying to customize, but it's unparalleled in getting a GUI together in minutes for a trusted operational team. And React-Hook-Form's support for dynamically generated fields could be really powerful in this regard.

- Both Rails and Django have patterns of "as long as this file is in the right place and/or has the right inheritance hierarchy, I won't need to write boilerplate." Is this a goal of this project as well? For instance, for the service file in https://redwoodjs.com/tutorial/side-quest-how-redwood-works-... seems to be something that would be nearly identical, save for the name of the model, across a number of things. Rather than scaffolding, could there be a way to inherit from a generic superclass (or the functional equivalent), fully overrideable, similar to how https://docs.djangoproject.com/en/3.0/topics/class-based-vie... allows any view to inherit from a ListView or DetailView?

Thanks for the kind words and questions! Others from the team can go into more detail, but here's some high-level for now:

- Typescript is definitely a priority for us. But implementation so far is starting with the backend (see https://github.com/redwoodjs/redwood for current), which isn't inclusive as of yet. We are looking for community involvement here as well.

- Admin interface: ah, very interesting. Could definitely be on the roadmap in the future. We're off to a great start with the Scaffold generator, which uses the schema to create all the pages necessary to run end-to-end CRUD operations on a database table. See https://redwoodjs.com/tutorial/getting-dynamic

- Boilerplate: The short answer is "yes indeed"! It's not 1-to-1 with your example, but there are lots of cases where you'll find this thinking+implementation. Again, the tutorial walkthrough is the best place to see some of this in action.

I think Prisma, the database layer of Redwood, plans on shipping their admin solution later this year.

Indeed! It's already usable though, we have an online demo here: https://prisma-studio.now.sh/

I really hope your (or a similar) project takes off.

Modern web development desperately needs a framework that integrates well with technologies like SSG, Graphql and Nodejs in general, that ships with sane configuration defaults for all the involved layers.

This is important, since SSG/SPA hybrids solve a lot of frontend issues by default and Graphql is a very expressive protocol which helps to avoid tightly coupled data transformation logic on the frontend.

I'm currently very interested in Nodejs specifically since JS is a transpilation target for a lot of languages and WASM.

I'll keep my fingers crossed, that you find a solution for integrating the persistence layer nicely as well. A simple and reliable DB like SQLite could be a very good default, since now you are essentially just dealing with files.

I think database and ORM integration in a framework like yours is very tricky in general. It has to be flexible enough to serve different needs but also well integrated and easily deployable. Good luck with that!

Looking forward to try this stuff out and possibly provide further feedback.

What level of site complexity do you think would justify using your framework versus a simpler approach? (wordpress with wp2static, for example) Is there a concrete level of interactivity or architecture at which you think a framework like this starts to shine?

We're looking to be a modern replacement for something like Ruby on Rails, so think full-on web application vs a blog or simple eCommerce site. Another way to think about is: do you have a lot of custom business logic you need to implement in order to drive your application? If so, then Redwood is set up really well do deal with that.

Do you intend to have built-in support for user management?

Setting up stuff like Oauth / Okta / etc and handling things like who can access admin screens seems to consume a lot of time on new projects - it'd make for an awesome app platform if some of that was well-supported out of the box.

You bet. See our roadmap list here https://redwoodjs.com/tutorial/wrapping-up And if you haven't read the README yet, that will help with the overall vision + direction https://redwoodjs.com/docs

Totally! We wanted to have a way of doing auth included in the launch but we ran out of time. It's definitely on the roadmap. Our goal is to make it "just work!"

You could use/checkout AccountsJS, been a small contributor to the project and it's great. TypeScript/GraphQL compatible etc.

Maybe you can integrate it into Redwood fairly easily, not sure about prisma though

Wow! This is awesome, thanks! I've added this: https://github.com/redwoodjs/redwood/issues/214

This looks really interesting, I like the focus on developer ergonomics, launching with a fleshed-out tutorial is a nice touch. The deployment story, however, seems to be tied to using Netlify as a hosting platform, which could affect adoption. I understand that that's where the roots of this project lie, are there any plans to decouple Redwood from Netlify to enable the framework to be self-hosted or used with other CI/CDN/FaaS services?

Why it was not written in TypeScript? (Sorry for fanboy type question)

We're working on full Typescript support for Redwood and we would like tot take it all the way from the DB definitions to GraphQL to the frontend!

It's on the way!

why do so many JS frameworks exist?

I think it's a natural consequence of new possibilities existing in the JS world. Build tools like webpack, transpilers like Babel, type systems like TypeScript; deployment architectures like JAMstack; all these things mean we can do new and interesting things with code, and developers are excited to explore them. It's a good thing! We want to explore the domain as much as possible to find the best solutions. Eventually you'll see consolidation around a smaller number of the best projects.

Because JS has no standard library and was originally a very light scripting language designed in a few days and used for browser coding.

It has evolved very rapidly as the web grew and these frameworks are a natural outcome of everyone trying to create some order from the chaos and figure out a proper architecture and way to do things.

The good news is you have lots of choices and it runs everywhere. Bad news is the sprawling mess you have to go through to find the good stuff.

If you asked me a few years ago if I could imagine building a framework, let alone a JS one, my answer would've been "hell no!"

But here I am... There was a lot of time spent trying to figure out how to use these technologies, and we're glueing those technologies together with our personal taste.

Reply on news.ycombinator.com