19 ms·

RedwoodJS 1.0

293 points by canyonero 5y ago

haffi112 5y ago
When should I use RedwoodJS and why?
- cephalization 5y ago
  https://github.com/redwoodjs/redwood/blob/main/README.md https://github.com/redwoodjs/redwood/blob/main/README.md The readme goes into details more in depth than I will, but as a dev raised on javascript and cloud tech, I like redwood for probably the same reasons that devs raised on ruby like ruby on rails. I get to keep using all the tech i'm comfortable with but the tooling is all preconfigured and the dev experience is smooth and optimized.
  - tootie 5y ago
    My reading is that this is an all-in-one package of the current best practices stuffed into a jar. It saves you some decision-making but also ossifies your platform into a fixed point in the hype cycle. It's probably a solid platform and get you to market a bit quicker but that isn't really a bottleneck for anyone as far as I can tell.
    - tomtheelder 5y ago
      IMO the main value of a framework like this isn't to save you time. That's what they advertise on the homepage, but I suspect that's just because it's an appealing concept to a lot of people. I think the real benefit is an increase in the chance that you build your app in a way that's sustainable. It's a pooling of experience and feedback on choices to create a whole that might not be flawlessly perfect for what you are building, but is likely worlds better than the disaster that usually occurs when you let the in house devs make too many choices. > ossifies your platform into a fixed point in the hype cycle Definitely true, but they have gone for some pretty established stuff here. The only ones I can see possibly being contentious in like 5 years or whatever timeline you want are Prisma and GraphQL, but even for those I'd bet on them still being sound choices for a long time. Also presumably the framework continues to develop (Rails 7 is a LOT different than Rails 1.), but that is a bit of a bet on it's adoption. As a dev I get the appeal of something more flexible that lets you make your own choices, but I think that almost universally ends up being a curse rather than a blessing.
      - thedavidprice 5y ago
        You make some great points here! > I think the real benefit is an increase in the chance that you build your app in a way that's sustainable Yes, indeed! We discuss "long-term maintainability" often in the project README and during interviews. This is one of the primary lessons Tom learned when building GitHub on Rails. > ossifies your platform into a fixed point in the hype cycle We are learning how to communicate these things better, but conventions, tight integration, and a "golden path" do not equate to lock-in of any kind. If you read through other comments, you'll find a lot of examples where devs are using alternatives for the API as well as front-end libraries.
- canyonero 5y ago
  From their main website (https://redwoodjs.com https://redwoodjs.com) “Redwood is the full-stack web framework designed to help you grow from side project to startup.”
  - haffi112 5y ago
    But why Redwood rather than some other framework? (I'm just interested in learning what opinions people have on here)
    - mojombo 5y ago
      Core team member here. Several reasons: 1. Redwood tightly integrates more of what you'll need as your app evolves: Storybook, Jest, Auth, Deploy, Logging, and a lot more. 2. A first class GraphQL experience so you can start from day one with the idea that you'll have multiple frontend clients (web, mobile, desktop, CLI, etc) so you only build your backend once. 3. Declarative data fetching with "cells" that make using that GraphQL backend super simple. 4. A community of builders and startup founders intent on helping each other succeed. 5. An amazing tutorial and set of documentation. Speaking of the tutorial, that's the best way to get started if you're curious to see how Redwood feels in action!
      - haffi112 5y ago
        Thanks, I'll check it out! ^^
- sandwichinvest 5y ago
  If your other option is "raw" React, Next.js: You'll do less yak-shaving and have to manage less engineering complexity versus using Next.js and rolling your own db/auth/testing/access control. If your other option is Blitz: you get a larger core team, GraphQL if you like that, and fancier generators. If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend.
  - leodriesch 5y ago
    Django/Rails comparison is a bit short I would argue, Redwood lacks a lot of their backend capabilities (Active Storage, mailing solution, jobs, Action Cable).
    - adfm 5y ago
      Add simplicity to your list. Tools like htmx and hotwire appeal to me because they cut down on the towering stack of fast-moving parts.
      - midrus 5y ago
        Have you tried Unpoly? It's like htmx but more "high level". I've used it for several projects and it is one of the more underrated tools out there. On my latest project.im using it in combination with Alpine.js on a Laravel application and I'm loving it.
  - flybayer 5y ago
    Blitz doesn’t use GraphQL, one of the unique things about it.
  - midrus 5y ago
    >If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend. And worse with the backend. Let's not pretend running code in the server are issuing queries to a database is all you do in the backend.
- tentacleuno 5y ago
  Further, what is it? Maybe I'm not a very good reader, but after looking at the website multiple times I'm not at all sure what RedwoodJS is. Comments here suggest it is some sort of React framework ...?
  - mojombo 5y ago
    Did you look at the main website? https://redwoodjs.com https://redwoodjs.com It is indeed a web app framework, based on React, GraphQL, Prisma, Storybook, Jest, and with many integrations for auth, logging, etc.
    - tentacleuno 5y ago
      > Did you look at the main website? https://redwoodjs.com https://redwoodjs.com I didn't. Thank you! It would be nice if this information was on the link posted to HN though, or maybe the link should be changed to something more clear.
dmitriid 5y ago
Is Redwood's own site running Redwood? I remember asking about it sometime ago, and the answer was "no, it's a marketing website, we don't use Redwood on it".
- mojombo 5y ago
  Yes, the new website we launched today is built with Redwood (except docs are done with Docusaurus). We're still doing some optimizations, but you are indeed looking at a Redwood app!
  - dmitriid 5y ago
    Nice!
qbasic_forever 5y ago
Wow this is a really well done little marketing thing to make the 1.0 an entire week 'event'. I like how it ends only with, 'here try the tutorial' and not 'please let's sign you up for newsletters, alerts, etc. etc.'.
- mojombo 5y ago
  Glad you appreciate it! My number one goal for launch week and the new homepage and this event reminder site is to drive the "tutorials taken" number. For me, that is success.
- yeskia 5y ago
  Interesting, I find it exhausting instead. I'm intrigued by Redwood and glad to hear it hit 1.0 but I'd rather see everything they have to say now instead of having to "stay tuned" for more. I either remember to come back in a few days to see what it was or I forget about it and miss out on what could have helped convert me into a user.
mattwad 5y ago
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
techn00 5y ago
Will the events be recorded?
- thedavidprice 5y ago
  Yes, indeed! And then posted to YouTube https://youtube.com/redwoodjs https://youtube.com/redwoodjs
andrewingram 5y ago
I've kept half an eye on Redwood since the early days, but i'll have to give it a proper look. My original understanding was that it was a static site generator, but this doesn't actually seem to be the case? In which case, i'm curious how the request waterfall problem is mitigated, given that the data loading is cell-oriented rather than interaction-oriented. My background with GraphQL comes from using Relay for 6+ years, so I'm used to there only being one query per interaction (pageview, click etc); whereas from the looks of Redwood, the nature of cells seems to indicate there can be multiple queries, potentially cascading ones involved in building a single screen.
- mojombo 5y ago
  You are correct, if you're not careful with your data fetching you can get into a waterfall situation. This is something we're keen to address in coming versions. Because we can get in the middle of your data fetching flow if you use cells, we should be able to do some optimizations without you having to do anything extra!
rajangdavis 5y ago
This seems really nice, but is there a way to bypass GraphQL or is it a hard requirement?
- mojombo 5y ago
  The golden path is to use GraphQL, but you are free to do data fetching to other data sources in the normal way you would in a React app.
pietromenna 5y ago
They did a really nice job creating an awesome experience by having picked up a nice set of tools and bundling them together. IMHO It is the first true full stack Javascript/Typescript framework that thought on all the important details: logging, great tutorial, community that helps, etc.
- mojombo 5y ago
  Thanks! Our mission is to help more startups explore more territory, more quickly. We're hoping to achieve this by integrating all the bits you need up front so you have less work to do on your framework, and can spend your precious time building and scaling your app or startup!
thedavidprice 5y ago
Co-founder of RedwoodJS here. We are so excited and proud of what Redwood has become, both as a project and as a community! Whether you are setting off to start your side project or looking to become an open-source contributor, I'd like to personally invite you to join us. With Redwood, no one has to go it alone. If you have any questions along the way, don't hesitate to reach out to me. I'll be watching comments here. And my DMs are open everywhere. Join the Redwood Community: https://redwoodjs.com/community https://redwoodjs.com/community So very excited to see what people with Redwood
- hit8run 5y ago
  What’s your business model?
  - thedavidprice 5y ago
    RedwoodJS is an open-source project. We are in a unique position to receive funding from Preston-Werner Ventures, which allows us to develop the codebase as well as cultivate an amazing community. Although it's not a typical for-profit business model, we are sustainable and will enthusiastically continue building Redwood to v2 and well beyond. You can read more about all of that in today's blog post from Tom (aka mojombo): 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...
    - JimDabell 5y ago
      What’s your business model?
      - number6 5y ago
        Millionaires Toy Project.
        blunte 5y ago
        Much nicer for all of us than most millionaires' toys.
rtcoms 5y ago
Does it support wbsockets ? I am thinking of implementing something like: https://www.viget.com/articles/phoenix-and-react-a-killer-combo/ https://www.viget.com/articles/phoenix-and-react-a-killer-co... Would it be feasible in RedwoodJS with or without websockets ?
- lefrenchy 5y ago
  Wouldn't this just be a matter of adding a component at the page level which calls the Phoenix Socket function? This should be framework agnostic since the post you linked above just works with React.
  - rtcoms 5y ago
    It works with react because phoenix framework can send request response with websocket rather than api, I'm thinking of replacing Phoenix with RedwoodJS. Rails also has websocket support but those are not as performant as Phoenix
chaostheory 5y ago
How does Blitzjs compare?
- o_m 5y ago
  No one knows. The Blitzjs team is working on a pivoting Blitz, so its not worth comparing old Blitz with Redwood for now.
  - chaostheory 5y ago
    They’re making it more modular so you can switch out components with what you want. So this is going to drastically change things on the user side?
    - flybayer 5y ago
      No, DX will still be almost exactly the same on the user side.
dang 5y ago
Related: Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - https://news.ycombinator.com/item?id=22537944 https://news.ycombinator.com/item?id=22537944 - March 2020 (167 comments)
- deleted 5y ago
  [deleted]
- pistoriusp 5y ago
  Co-creator of RedwoodJS here. Hard to imagine that this was just 2 years ago. 2 years in pandemic times is like 5 years in normal life! We put so much of our lock-down time into this framework. I can't actually think of a better way to have spent the time building something awesome with awesome people.
jzig 5y ago
I want to use an opinionated framework like this but with Angular on the frontend. Does anything like that exist? Closest thing I can think of is wiring together Nest.js + Prisma + Angular.
- thedavidprice 5y ago
  You can use Redwood's API with your Angular frontend.
  - jzig 5y ago
    That would be very cool to look into. Is there any documentation for that somewhere? I tried googling "redwoodjs angular" and didn't see anything obvious. Thanks for response.
    - dac09 5y ago
      Hey, another core team member. You certainly can use whatever client you want with the Redwood API - you just might not get all the bells and whistles that are built into our web side! The GraphQL api in Redwood is powerful, yet simple - so you would build your backend in Redwood, and have your angular front end make gql queries like you would with any other backend.
    - thedavidprice 5y ago
      Not that I know of. But here are a few things that may be of interest. Redwood's GraphQL API is built on Yoga (we collaborate tightly with The Guild) — https://www.graphql-yoga.com https://www.graphql-yoga.com You just need a GraphQL Client, which The Guild already has an option ready for you https://apollo-angular.com https://apollo-angular.com (Note: Apollo or other clients fine as well.) Here's an example "How To" about connecting Next (React) with Redwood: https://community.redwoodjs.com/t/how-to-connect-a-next-js-frontend-to-your-redwood-api/2606 https://community.redwoodjs.com/t/how-to-connect-a-next-js-f... I'm a co-founder of Redwood and help lead the project so I can say as a matter of fact we a highly collaborative and enjoy (and support) exploratory projects. It's a priority for us to better demonstrate the power of Redwood's API through examples. If you'd be interested in digging in collaboratively with the community, I can help connect the dots. Just kick things off over here and tag me @thedavidprice: https://community.redwoodjs.com https://community.redwoodjs.com No pressure at all! Just wanted you to know the invitation is open. Anytime.
pistoriusp 5y ago
I am in the unique position of having built a large part of the RedwoodJS framework (up until about a year ago), and then building Snaplet[1] in RedwoodJS. So I have the perspective as a creator and a user! Of course, as an author, there may be some bias, but I've found RedwoodJS to be malleable to all my, and my teams, needs: It's prescriptive all the way down to the architecture, with the intention that you have an "escape hatch" when you want or need something customized. [1] https://www.snaplet.dev https://www.snaplet.dev
ogazitt 5y ago
Congrats! It's nice to see that authentication and authorization are handled in the framework from day 1. This is often overlooked, but such a critical part of building new applications.
- pistoriusp 5y ago
  The auth package is a single interface that can be extended by 3rd party auth providers. When we originally created it we supported auth0 and magic.link, but now there are more 10! So, imagine you want something quick, so you pick magic.link and you launch to a bunch of demo user's, but decide it doesn't scale for your *new* needs, you'll be able to switch out to Auth0 without having to change any client side code (other than initialization). Of course you'll have to migrate your users. Having the ability to pick an auth provider, or host your own to suit your needs/ risk requirement, is very important to us!
  - ogazitt 5y ago
    I love that design decision. How about authorization? :) disclaimer: I am a co-founder of Aserto [0], an authorization platform for developers. I think it would be awesome to explore how to grow the authorization model from a simple set of roles / permissions to a fine-grained model as the application matures. [0] https://www.aserto.com https://www.aserto.com
    - pistoriusp 5y ago
      I am unfortunately no longer involved with RedwoodJS in terms of code, but it's open-source so anything's possible. I would reach out to David Price!
pooya72 5y ago
I followed the tutorial and made a toy app with it. I thought the tutorial was well written, easy to follow, and touched on topics of importance for developers. In regard to the framework, it is appereant they have thought about the developer workflow and designed a process that would lead to greater productivity.Two aspects I really enjoyed were cells (UI mixed with API calls) and integration with Storybook. I would say that its combination of scaffolding, easy authentication with dbAuth, and Storybook integration provides a lot of productivity benefits. This is of course if you're interested in basic CRUD. I don't know how it would be for non-CRUD apps.
- pistoriusp 5y ago
  I'm using it for a non-CRUD app. We have a "web", "api" and "cli" side and the experience still scales.
  - pooya72 5y ago
    And what type of app is this, if you don't mind sharing?
    - Kriscoulson 5y ago
      Just incase pistoriusp doesn't respond back a few comments up. He has said he is building https://www.snaplet.dev/ https://www.snaplet.dev/ on redwoodjs
      - pooya72 5y ago
        Thank you!
dpkrjb 5y ago
I find the bundling of stack + startup success to be quite a peculiar sell. I wouldn't have considered the two that strongly linked - but I may not be the wrong audience for it.
- mojombo 5y ago
  It is unusual, perhaps, but as Redwood has evolved, it's been natural for us to really offer support for startups using our tools. Redwood is a more complex, more integrated, and more aligned with long term maintainability than most of the alternatives, which means our market focus is on projects that need that kind of tooling. And who needs that tooling most? Startups! Plus, I do a lot of angel investing and so helping startups is of great interest to me, so I can combine my great loves!
- pistoriusp 5y ago
  Engineers often build products that "scratch their own itch." What I've found is that this product tends to attract users that are almost exactly like them! (My data is anecdotal, but I have done several user interviews, and the similarities are uncanny!) I think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
- dthyresson 5y ago
  Core Team member here. Many RedwoodJS contributors have startup experience and we applied much of that in delivering features that often get lost in the rapid MVP pace where you have a small team and iterate fast ... only to face those decisions later. And it's not a surprise that these feature get left out early on: they take time and money -- two things startups have to manage from the get go. Testing, logging, webhook support, setting up authentication, involving your designers more with Storybook, seeding data, mocking data, deploying, GraphQL best practices. These are all common solvable problems that RedwoodJS has already thought of so you can focus on building a product.
- tomatowurst 5y ago
  I disagree, I've never heard of them so it doesn't give me that confidence. In fact it hurts the brand, it signals that this is not mature enough to be used by Fortune 500 and from the description of its underlying choises, it is a Rube Goldberg machine, one that pulls you in with perceived productivity hacks only to end up with navigating the dozen of libraries wired up in ways to get the developer to not think about them because the battle tested and mature paths are boring and lacking in novelty. I've been down this path before, where claims of productivity gains to get you an MVP is true to a certain degree, only to have a giant web of wiring that creates implicit and explicit cognitive load, in my opinion, its like taking out a loan for an increasing cost of capital from rising interest and equity , where eventually, you can't hire, you can't debug, you can't reverse due to sunk cost since you've bet your horses on the shiny new trendy thing where you depend on other's opinions and their understanding of the problem which will offer no real benefits to your specific, specialized contexts. This is in fact the problem with many full stack or opinionated frameworks, it ignores the last mile problem. As I grow older, I realize now the wisdom of choosing boring tech, when I was younger it was quite frustrating but now I see that PostgreSQL + Server side rendered language + Progressive interactivity is still strong for a reason and it is not Luddism or gerontocracy, it is stability from time tested collective experience of all minds. PHP is still going strong to this date. At the end of the day, all tech stack, architectural decisions are economically constrained by time, capital and labor supply. An overly complex arrangement, especially one that focuses on novelty over what has worked and widely used, increases risks due to unknowns. Specific issues and challenges can be addressed in bite sizes, rarely do they require ripping out the established paths, instead of throwing in a dozen of new, complex dependency and opinion ridden web of tech that is highly novel & guarantees implicit volatile technical debt with false gains that require far more trouble than its worth.
louissm_it 5y ago
Congrats! I've been keeping up with Redwood since the original announcement, and the progress they've made has been incredible. The generators and command line utilities are top notch (compared to Rails, thats a high bar to clear) and the general structure of everything seems very well thought out. Still missing a good official solution for background jobs, but I see there is a workaround in the 'How To' section on the documentation. The core team members are super nice and the community is very welcoming. I'm not convinced the "client side app + Graphql server" is the best model for most startups, however. I tend to lean more on server rendered pages with a little bit of progressive enhancement. But I assume the people who made Redwood are more knowledgeable than me :)
- Kriscoulson 5y ago
  > I'm not convinced the "client side app + Graphql server" is the best model for most startups Startups don't know what they need when just getting started. When you have a Graphql api you can spin up any number of other tools not just "client side apps", it can connect to a mobile app, cli, any number of other tools and you don't need to go back to the drawing board to make it happen. I've been using Redwood for quite a while and on my app I just spun up a public api with api keys and still maintain my private api specifically for internal app use in less than a day. When I started my project I didn't know I would need that.
  - louissm_it 5y ago
    Alright, that is a very good point. If the possibility of other nodes interacting with your service is high (ie “you’re gonna need an API eventually”), this might well be the best option.
ryanchenkie 5y ago
I've been working with Redwood for 8-9 months now and it has been phenomenal. I can't imagine going back to wiring all the pieces together by hand.
noire-munich 5y ago
My two cents testimonial: we've been building our startup's core app with RedwoodJS and launched live in October 2021. It's been working great, the DX really lets you focus on your business and a lot - a lot - of the usual things that make a project require a bigger team are solved out of the box. I very reluctantly see myself starting any new project on anything different than RedwoodJS. I wouldn't, unless there really wasn't any other choice. You just get to the core of your project really fast, and don't lose touch of it, ever. RW is v1 so it's young but very satisfying, and having witnessed first hand how it's being built, I have faith and trust in its future releases. Looking forward to them actually.
gojomo 5y ago
Please, have landing pages & announcement pages explain up top what your thing is, or have the obvious click-targets (like the logo or project-name) take people to an introduction. If you've gone through all the trouble of designing/promoting a big launch/milestone site ("v1launchsite"!), don't require people to compose a Google query in another tab to get the one-sentence overview.
- squishy47 5y ago
  and not just what it is but also how it makes my life better.
- khazhoux 5y ago
  Also, even after manually typing in the main project URL, I can't find what language is supported on the backend ("api side").
  - neogodless 5y ago
    From https://github.com/redwoodjs/redwood/blob/main/README.md https://github.com/redwoodjs/redwood/blob/main/README.md: > Redwood is an opinionated, full-stack, JavaScript/TypeScript web application framework > A Redwood application is split into two parts: a frontend and a backend. This is represented as two JS/TS projects within a single monorepo. > The api side is an implementation of a GraphQL API. Not sure you'd want to choose this if you want to roll your own API (without taking advantage of the framework/integration).
    - khazhoux 5y ago
      Thanks, though what I'm looking for (and, I expect, many/most other developers too), is a simple statement of whether I can write my backend in Go, Java, python, node, etc.
- mikeiz404 5y ago
  GitHub README is here https://github.com/redwoodjs/redwood/blob/main/README.md https://github.com/redwoodjs/redwood/blob/main/README.md for those looking for some background.
eternityforest 5y ago
The first page you click on should say what something is and why I would want it. Is this primarily meant to show business people, after telling them what it is verbally?
- picometer 5y ago
  I was also feeling frustrated with this. The HN post links to an event lineup, not a product/marketing page. It would be much less frustrating if it had a link to the homepage, which does describe the product: https://redwoodjs.com https://redwoodjs.com
  - thedavidprice 5y ago
    Ah, that is exactly what's going on. Definitely deserving of a :facepalm: from myself and those of us on the Core Team who missed that. Tom is adding a link back to www. v1 Launch Week Schedule (this HN Post): https://v1launchweek.redwoodjs.com https://v1launchweek.redwoodjs.com RedwoodJS Website: https://redwoodjs.com https://redwoodjs.com GitHub Repo and README: https://github.com/redwoodjs/redwood/ https://github.com/redwoodjs/redwood/ All the conversation was happening here already, so we just jumped in! Apologies for the confusion. We could have caught that earlier.
    - mojombo 5y ago
      Explanation and link added!
trhoad 5y ago
Quite intrigued by this, and will definitely step through the tutorial. It will be interesting to compare it side-by-side with Adonis (and possibly Nest).
- thedavidprice 5y ago
  I am sincerely interested in what you learn. If you do a comparison and have some time to communicate the results, please look me up on the Redwood Forums or Twitter. This would be a helpful resource and discussion for our community and maintainers (because we are always learning and collaborating, to be clear): https://community.redwoodjs.com https://community.redwoodjs.com No pressure at all. (I'm one of the co-founders/leads of Redwood. Tag me @thedavidprice)
rglover 5y ago
- mplewis 5y ago
  Super rude and unwarranted.
  - rglover 5y ago
    Achievement unlocked. https://www.youtube.com/watch?v=-h3ocCmOZ18 https://www.youtube.com/watch?v=-h3ocCmOZ18
sdesalas 5y ago
Is this likely to support SSR?
- neogodless 5y ago
  Discussed elsewhere in this thread: https://news.ycombinator.com/item?id=30909134 https://news.ycombinator.com/item?id=30909134
woah 5y ago
Not many details, but as far as i can tell, this is "react on rails"
blunte 5y ago
I really appreciate endeavors like this, but... My experience with many other frameworks is that they really help you get started quickly, and some of them truly cover a vast majority of common use cases. But when you reach a point of need or situation where they don't work the way you want, you must then learn how to work around them or enhance them. That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins. This should be a pretty familiar scenario for many of us here, and perhaps some have experienced this with RedwoodJS. If so, how do you feel about the framework now? How was the workaround/change-behavior experience?
- maps7 5y ago
  The alternative here is that you DoItYourself from the start and never launch or burn company money _before_ you even have a product or users.
  - pooya72 5y ago
    I think that's taking the extreme end. Couldn't someone use a larger framework, for example Spring? It's pretty productive with Spring boot, but also large enough that you can expand for your use case. I'm not advocating for Spring per se, as I think .Net core is equivalent.
    - maps7 5y ago
      I was talking in wider terms of not using a framework at all and not specifically about Redwoodjs. I can't speak to whether RedwoodJS will lead you down a path of working around it.
- pooya72 5y ago
  Yes, and it's difficult to understand the tradeoffs without investing time in a framework. There are a lot of unknown unknowns, both in terms of the market fit and the framework. It's hard to know starting off what "situations" would be difficult for a framework like RedwoodJS.
- 5y ago
epolanski 5y ago
I don't have anything against Redwood per se but I find the collage of those technologies (personally) unappealing. Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps. But nothing of Redwood makes me think, "this is the missing piece I was waiting for" as I've worked with most of this stack in various combinations and I think it's a stack that's getting old and is not scaling or getting much better with time.
- sequoia 5y ago
  > Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps. If you can get this out of the box, this seems like a very good value prop. 'Boring and not innovative' isn't a flaw unless you're looking for something exciting and innovative, and most applications don't need this.
- pooya72 5y ago
  Two thinks I did find appealing were "Cells" and the easy integration with Storybook.
maps7 5y ago
I'm a Redwood user for my side project that I hope to launch in the next few days. For me Redwood has been great. I know React but was always frustrated with expanding past the UI layer e.g. data fetching, storing. I had tried NextJS in the past (didn't love the filename routing approach) but never actually got anything to production. I'm in an architect role for work now and I get to code less and less during the day. RedwoodJS has enabled me to actually build something in my own time and (hopefully) launch it. I didn't know GraphQL or Prisma before starting to use it but between the Redwood docs, Prisma docs and with some RW community help I've made good progress.
- thedavidprice 5y ago
  This is wind in our sails. Thank you for posting. And please do show off what you've built! I'd love to see it.
robertwt7 5y ago
I like Redwood, compared to Remix it has all the required opinionated boilerplate that is required for startups. It reminds me of using the whole battery included framework such as laravel or django as opposed to spring boot / aspnet.core If you work in big tech companies probably you would never use it as they have enough resources to build different services and have enough developers for different purposes. However if you're a solo dev for startups that wants to build MVP, it definitely reduces the amount of work needed to setup FE, BE, infra, etc. The amount of work needed to ship MVP is greatly reduced. Of course those are all in the expense of learning the framework itself.. but props to these guys with good docs! hopefully it will gain more and more traction!
gernb 5y ago
Is there are part that does the rest? Deployment, Staging, CI, Backups & Restore, Rolling Upgrades with fallback, etc.... or is that still left as an exercise for the reader?
- louissm_it 5y ago
  I found this[1] on the documentation. But in general staging environments, continuous integration and continuous delivery are not built into frameworks (Rails, Phoenix, etc). [1] - https://redwoodjs.com/docs/deployment/index https://redwoodjs.com/docs/deployment/index
Nijikokun 5y ago
I was going to use it for a project but it looks like it doesn't have electron support. :/
- thedavidprice 5y ago
  Tape.sh runs an Electron desktop app as one of it's 4 clients. GraphQL is a multi-client solution. Is there something more you're specifically looking for?
tonis2 5y ago
In my experience, the best way to avoid fighting frameworks, is to keep framework use minimal, and just write the 30 lines of UI code yourself for your custom form. Why does the JavaScript rendering require so many abstractions layers ?. I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. I use Web Components and some minor libraries, having so much easier time going this way. Not to kick down the hard work on developing of Redwood, but I'm just tired of being forced to use these frameworks on jobs. At startup stage the team picks a monolithic framework, after 2 years the developers are depressed building with it and leave, then new developers that come are met with a mess and fixing even easy bugs, is practically rewriting 5000 lines of code of the app, because everything is so entangled.
- KronisLV 5y ago
  > I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. For the most part, i'd say that frameworks being largely standardized and having ecosystems around them is a really good thing: people who are familiar with Vue/Angular/React (front end) and with Spring Boot/Express.js/Django/Rails (back end) can start working with your application more quickly than if it uses your custom "sort-of-like-jQuery-but-not-really" set of libraries/framework for the front end or your own thing for back end, which obviously will fall short in regards to documentation, consistency or ready made components. You can hire for Vue/Angular/React and Spring Boot/Express.js/Django/Rails, you cannot hire for your bespoke in-house solution. Also, the devs behind those solutions can spend more time and resources on making them better than your entire app will have put into it. That's why i largely avoid projects which have bespoke solutions like that, especially for back end frameworks, which typically are a minefield of badly written and badly tested code, as well as present numerous security related challenges. That stance was truly cemented when in one project i was stuck with an untested framework that stored half of the functionality in the DB, used JDBC directly through numerous abstractions, had commented out sections of code strewn about the codebase and had comments in Lithuanian, a language that i don't speak and had no documentation whatsoever. Of course, i've also seen things go into the opposite direction too far: instead of something like Bootstrap or its integration with any of the aforementioned popular frameworks/libraries being used, picking Tailwind CSS and spending weeks if not months mucking about with custom components without actually shipping features and solutions to business problems. If you are lucky enough to have front ends simple enough to be adequately handled by a few hundred/thousand lines of JS then by all means go ahead (right tool for the problem and all that), but that has never been my experience in any of the enterprise projects that i've worked on. Admittedly, however, i do feel these standard frameworks/libraries also getting more and more complicated as time goes on, because their eventual transformation into something that tries to do "everything" (and thus downfall) feels almost inevitable.
hestefisk 5y ago
Imagine if DHH was able to raise several millions of dollars for what is a front end and crud framework packaged from existing open source libraries… money is indeed cheap at the moment and I guess private equity / VC have to put excess liquidity somewhere.
jatins 5y ago
Congrats on 1.0! Is it possible to do Redwood development completely on something like Github codespaces or CodeSandbox? Last time I checked (~6 months ago) this didn't play nicely with Docker but curious if things have changed since then.
- thedavidprice 5y ago
  Yes, indeed! First off, Redwood comes with a Fastify server. `yarn rw serve` is the command you're looking for. Check out the Deploy Docs and this repo thats coming along: http://github.com/redwoodjs/docker/ http://github.com/redwoodjs/docker/ Secondly, we use Gitpod extensively — starting with a Dev environment for contributing. And as of a week ago we now how a Gitpod starter that spins up a new install @latest using Postgres. Check it out here: https://github.com/redwoodjs/gitpod-starter https://github.com/redwoodjs/gitpod-starter Full Doc and being included at the intro to the Tutorial are coming soon!

RedwoodJS 1.0

293 points by canyonero 5y ago

haffi112 5y ago

When should I use RedwoodJS and why?

cephalization 5y ago
https://github.com/redwoodjs/redwood/blob/main/README.md https://github.com/redwoodjs/redwood/blob/main/README.md The readme goes into details more in depth than I will, but as a dev raised on javascript and cloud tech, I like redwood for probably the same reasons that devs raised on ruby like ruby on rails. I get to keep using all the tech i'm comfortable with but the tooling is all preconfigured and the dev experience is smooth and optimized.
- tootie 5y ago
  My reading is that this is an all-in-one package of the current best practices stuffed into a jar. It saves you some decision-making but also ossifies your platform into a fixed point in the hype cycle. It's probably a solid platform and get you to market a bit quicker but that isn't really a bottleneck for anyone as far as I can tell.
  - tomtheelder 5y ago
    IMO the main value of a framework like this isn't to save you time. That's what they advertise on the homepage, but I suspect that's just because it's an appealing concept to a lot of people. I think the real benefit is an increase in the chance that you build your app in a way that's sustainable. It's a pooling of experience and feedback on choices to create a whole that might not be flawlessly perfect for what you are building, but is likely worlds better than the disaster that usually occurs when you let the in house devs make too many choices. > ossifies your platform into a fixed point in the hype cycle Definitely true, but they have gone for some pretty established stuff here. The only ones I can see possibly being contentious in like 5 years or whatever timeline you want are Prisma and GraphQL, but even for those I'd bet on them still being sound choices for a long time. Also presumably the framework continues to develop (Rails 7 is a LOT different than Rails 1.), but that is a bit of a bet on it's adoption. As a dev I get the appeal of something more flexible that lets you make your own choices, but I think that almost universally ends up being a curse rather than a blessing.
    - thedavidprice 5y ago
      You make some great points here! > I think the real benefit is an increase in the chance that you build your app in a way that's sustainable Yes, indeed! We discuss "long-term maintainability" often in the project README and during interviews. This is one of the primary lessons Tom learned when building GitHub on Rails. > ossifies your platform into a fixed point in the hype cycle We are learning how to communicate these things better, but conventions, tight integration, and a "golden path" do not equate to lock-in of any kind. If you read through other comments, you'll find a lot of examples where devs are using alternatives for the API as well as front-end libraries.
canyonero 5y ago
From their main website (https://redwoodjs.com https://redwoodjs.com) “Redwood is the full-stack web framework designed to help you grow from side project to startup.”
- haffi112 5y ago
  But why Redwood rather than some other framework? (I'm just interested in learning what opinions people have on here)
  - mojombo 5y ago
    Core team member here. Several reasons: 1. Redwood tightly integrates more of what you'll need as your app evolves: Storybook, Jest, Auth, Deploy, Logging, and a lot more. 2. A first class GraphQL experience so you can start from day one with the idea that you'll have multiple frontend clients (web, mobile, desktop, CLI, etc) so you only build your backend once. 3. Declarative data fetching with "cells" that make using that GraphQL backend super simple. 4. A community of builders and startup founders intent on helping each other succeed. 5. An amazing tutorial and set of documentation. Speaking of the tutorial, that's the best way to get started if you're curious to see how Redwood feels in action!
    - haffi112 5y ago
      Thanks, I'll check it out! ^^
sandwichinvest 5y ago
If your other option is "raw" React, Next.js: You'll do less yak-shaving and have to manage less engineering complexity versus using Next.js and rolling your own db/auth/testing/access control. If your other option is Blitz: you get a larger core team, GraphQL if you like that, and fancier generators. If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend.
- leodriesch 5y ago
  Django/Rails comparison is a bit short I would argue, Redwood lacks a lot of their backend capabilities (Active Storage, mailing solution, jobs, Action Cable).
  - adfm 5y ago
    Add simplicity to your list. Tools like htmx and hotwire appeal to me because they cut down on the towering stack of fast-moving parts.
    - midrus 5y ago
      Have you tried Unpoly? It's like htmx but more "high level". I've used it for several projects and it is one of the more underrated tools out there. On my latest project.im using it in combination with Alpine.js on a Laravel application and I'm loving it.
- flybayer 5y ago
  Blitz doesn’t use GraphQL, one of the unique things about it.
- midrus 5y ago
  >If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend. And worse with the backend. Let's not pretend running code in the server are issuing queries to a database is all you do in the backend.
tentacleuno 5y ago
Further, what is it? Maybe I'm not a very good reader, but after looking at the website multiple times I'm not at all sure what RedwoodJS is. Comments here suggest it is some sort of React framework ...?
- mojombo 5y ago
  Did you look at the main website? https://redwoodjs.com https://redwoodjs.com It is indeed a web app framework, based on React, GraphQL, Prisma, Storybook, Jest, and with many integrations for auth, logging, etc.
  - tentacleuno 5y ago
    > Did you look at the main website? https://redwoodjs.com https://redwoodjs.com I didn't. Thank you! It would be nice if this information was on the link posted to HN though, or maybe the link should be changed to something more clear.

dmitriid 5y ago

Is Redwood's own site running Redwood? I remember asking about it sometime ago, and the answer was "no, it's a marketing website, we don't use Redwood on it".

mojombo 5y ago
Yes, the new website we launched today is built with Redwood (except docs are done with Docusaurus). We're still doing some optimizations, but you are indeed looking at a Redwood app!
- dmitriid 5y ago
  Nice!

qbasic_forever 5y ago

Wow this is a really well done little marketing thing to make the 1.0 an entire week 'event'. I like how it ends only with, 'here try the tutorial' and not 'please let's sign you up for newsletters, alerts, etc. etc.'.

mojombo 5y ago
Glad you appreciate it! My number one goal for launch week and the new homepage and this event reminder site is to drive the "tutorials taken" number. For me, that is success.
yeskia 5y ago
Interesting, I find it exhausting instead. I'm intrigued by Redwood and glad to hear it hit 1.0 but I'd rather see everything they have to say now instead of having to "stay tuned" for more. I either remember to come back in a few days to see what it was or I forget about it and miss out on what could have helped convert me into a user.

mattwad 5y ago

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

techn00 5y ago

Will the events be recorded?

thedavidprice 5y ago
Yes, indeed! And then posted to YouTube https://youtube.com/redwoodjs https://youtube.com/redwoodjs

andrewingram 5y ago

I've kept half an eye on Redwood since the early days, but i'll have to give it a proper look. My original understanding was that it was a static site generator, but this doesn't actually seem to be the case? In which case, i'm curious how the request waterfall problem is mitigated, given that the data loading is cell-oriented rather than interaction-oriented. My background with GraphQL comes from using Relay for 6+ years, so I'm used to there only being one query per interaction (pageview, click etc); whereas from the looks of Redwood, the nature of cells seems to indicate there can be multiple queries, potentially cascading ones involved in building a single screen.

mojombo 5y ago
You are correct, if you're not careful with your data fetching you can get into a waterfall situation. This is something we're keen to address in coming versions. Because we can get in the middle of your data fetching flow if you use cells, we should be able to do some optimizations without you having to do anything extra!

rajangdavis 5y ago

This seems really nice, but is there a way to bypass GraphQL or is it a hard requirement?

mojombo 5y ago
The golden path is to use GraphQL, but you are free to do data fetching to other data sources in the normal way you would in a React app.

pietromenna 5y ago

They did a really nice job creating an awesome experience by having picked up a nice set of tools and bundling them together. IMHO It is the first true full stack Javascript/Typescript framework that thought on all the important details: logging, great tutorial, community that helps, etc.

mojombo 5y ago
Thanks! Our mission is to help more startups explore more territory, more quickly. We're hoping to achieve this by integrating all the bits you need up front so you have less work to do on your framework, and can spend your precious time building and scaling your app or startup!

thedavidprice 5y ago

Co-founder of RedwoodJS here. We are so excited and proud of what Redwood has become, both as a project and as a community! Whether you are setting off to start your side project or looking to become an open-source contributor, I'd like to personally invite you to join us. With Redwood, no one has to go it alone. If you have any questions along the way, don't hesitate to reach out to me. I'll be watching comments here. And my DMs are open everywhere. Join the Redwood Community: https://redwoodjs.com/community https://redwoodjs.com/community So very excited to see what people with Redwood

hit8run 5y ago
What’s your business model?
- thedavidprice 5y ago
  RedwoodJS is an open-source project. We are in a unique position to receive funding from Preston-Werner Ventures, which allows us to develop the codebase as well as cultivate an amazing community. Although it's not a typical for-profit business model, we are sustainable and will enthusiastically continue building Redwood to v2 and well beyond. You can read more about all of that in today's blog post from Tom (aka mojombo): 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...
  - JimDabell 5y ago
    What’s your business model?
    - number6 5y ago
      Millionaires Toy Project.
      - blunte 5y ago
        Much nicer for all of us than most millionaires' toys.

rtcoms 5y ago

Does it support wbsockets ? I am thinking of implementing something like: https://www.viget.com/articles/phoenix-and-react-a-killer-combo/ https://www.viget.com/articles/phoenix-and-react-a-killer-co... Would it be feasible in RedwoodJS with or without websockets ?

lefrenchy 5y ago
Wouldn't this just be a matter of adding a component at the page level which calls the Phoenix Socket function? This should be framework agnostic since the post you linked above just works with React.
- rtcoms 5y ago
  It works with react because phoenix framework can send request response with websocket rather than api, I'm thinking of replacing Phoenix with RedwoodJS. Rails also has websocket support but those are not as performant as Phoenix

chaostheory 5y ago

How does Blitzjs compare?

o_m 5y ago
No one knows. The Blitzjs team is working on a pivoting Blitz, so its not worth comparing old Blitz with Redwood for now.
- chaostheory 5y ago
  They’re making it more modular so you can switch out components with what you want. So this is going to drastically change things on the user side?
  - flybayer 5y ago
    No, DX will still be almost exactly the same on the user side.

dang 5y ago

Related: Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - https://news.ycombinator.com/item?id=22537944 https://news.ycombinator.com/item?id=22537944 - March 2020 (167 comments)

deleted 5y ago
[deleted]
pistoriusp 5y ago
Co-creator of RedwoodJS here. Hard to imagine that this was just 2 years ago. 2 years in pandemic times is like 5 years in normal life! We put so much of our lock-down time into this framework. I can't actually think of a better way to have spent the time building something awesome with awesome people.

jzig 5y ago

I want to use an opinionated framework like this but with Angular on the frontend. Does anything like that exist? Closest thing I can think of is wiring together Nest.js + Prisma + Angular.

thedavidprice 5y ago
You can use Redwood's API with your Angular frontend.
- jzig 5y ago
  That would be very cool to look into. Is there any documentation for that somewhere? I tried googling "redwoodjs angular" and didn't see anything obvious. Thanks for response.
  - dac09 5y ago
    Hey, another core team member. You certainly can use whatever client you want with the Redwood API - you just might not get all the bells and whistles that are built into our web side! The GraphQL api in Redwood is powerful, yet simple - so you would build your backend in Redwood, and have your angular front end make gql queries like you would with any other backend.
  - thedavidprice 5y ago
    Not that I know of. But here are a few things that may be of interest. Redwood's GraphQL API is built on Yoga (we collaborate tightly with The Guild) — https://www.graphql-yoga.com https://www.graphql-yoga.com You just need a GraphQL Client, which The Guild already has an option ready for you https://apollo-angular.com https://apollo-angular.com (Note: Apollo or other clients fine as well.) Here's an example "How To" about connecting Next (React) with Redwood: https://community.redwoodjs.com/t/how-to-connect-a-next-js-frontend-to-your-redwood-api/2606 https://community.redwoodjs.com/t/how-to-connect-a-next-js-f... I'm a co-founder of Redwood and help lead the project so I can say as a matter of fact we a highly collaborative and enjoy (and support) exploratory projects. It's a priority for us to better demonstrate the power of Redwood's API through examples. If you'd be interested in digging in collaboratively with the community, I can help connect the dots. Just kick things off over here and tag me @thedavidprice: https://community.redwoodjs.com https://community.redwoodjs.com No pressure at all! Just wanted you to know the invitation is open. Anytime.

pistoriusp 5y ago

I am in the unique position of having built a large part of the RedwoodJS framework (up until about a year ago), and then building Snaplet[1] in RedwoodJS. So I have the perspective as a creator and a user! Of course, as an author, there may be some bias, but I've found RedwoodJS to be malleable to all my, and my teams, needs: It's prescriptive all the way down to the architecture, with the intention that you have an "escape hatch" when you want or need something customized. [1] https://www.snaplet.dev https://www.snaplet.dev

ogazitt 5y ago

Congrats! It's nice to see that authentication and authorization are handled in the framework from day 1. This is often overlooked, but such a critical part of building new applications.

pistoriusp 5y ago
The auth package is a single interface that can be extended by 3rd party auth providers. When we originally created it we supported auth0 and magic.link, but now there are more 10! So, imagine you want something quick, so you pick magic.link and you launch to a bunch of demo user's, but decide it doesn't scale for your *new* needs, you'll be able to switch out to Auth0 without having to change any client side code (other than initialization). Of course you'll have to migrate your users. Having the ability to pick an auth provider, or host your own to suit your needs/ risk requirement, is very important to us!
- ogazitt 5y ago
  I love that design decision. How about authorization? :) disclaimer: I am a co-founder of Aserto [0], an authorization platform for developers. I think it would be awesome to explore how to grow the authorization model from a simple set of roles / permissions to a fine-grained model as the application matures. [0] https://www.aserto.com https://www.aserto.com
  - pistoriusp 5y ago
    I am unfortunately no longer involved with RedwoodJS in terms of code, but it's open-source so anything's possible. I would reach out to David Price!

pooya72 5y ago

I followed the tutorial and made a toy app with it. I thought the tutorial was well written, easy to follow, and touched on topics of importance for developers. In regard to the framework, it is appereant they have thought about the developer workflow and designed a process that would lead to greater productivity.Two aspects I really enjoyed were cells (UI mixed with API calls) and integration with Storybook. I would say that its combination of scaffolding, easy authentication with dbAuth, and Storybook integration provides a lot of productivity benefits. This is of course if you're interested in basic CRUD. I don't know how it would be for non-CRUD apps.

pistoriusp 5y ago
I'm using it for a non-CRUD app. We have a "web", "api" and "cli" side and the experience still scales.
- pooya72 5y ago
  And what type of app is this, if you don't mind sharing?
  - Kriscoulson 5y ago
    Just incase pistoriusp doesn't respond back a few comments up. He has said he is building https://www.snaplet.dev/ https://www.snaplet.dev/ on redwoodjs
    - pooya72 5y ago
      Thank you!

dpkrjb 5y ago

I find the bundling of stack + startup success to be quite a peculiar sell. I wouldn't have considered the two that strongly linked - but I may not be the wrong audience for it.

mojombo 5y ago
It is unusual, perhaps, but as Redwood has evolved, it's been natural for us to really offer support for startups using our tools. Redwood is a more complex, more integrated, and more aligned with long term maintainability than most of the alternatives, which means our market focus is on projects that need that kind of tooling. And who needs that tooling most? Startups! Plus, I do a lot of angel investing and so helping startups is of great interest to me, so I can combine my great loves!
pistoriusp 5y ago
Engineers often build products that "scratch their own itch." What I've found is that this product tends to attract users that are almost exactly like them! (My data is anecdotal, but I have done several user interviews, and the similarities are uncanny!) I think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
dthyresson 5y ago
Core Team member here. Many RedwoodJS contributors have startup experience and we applied much of that in delivering features that often get lost in the rapid MVP pace where you have a small team and iterate fast ... only to face those decisions later. And it's not a surprise that these feature get left out early on: they take time and money -- two things startups have to manage from the get go. Testing, logging, webhook support, setting up authentication, involving your designers more with Storybook, seeding data, mocking data, deploying, GraphQL best practices. These are all common solvable problems that RedwoodJS has already thought of so you can focus on building a product.
tomatowurst 5y ago
I disagree, I've never heard of them so it doesn't give me that confidence. In fact it hurts the brand, it signals that this is not mature enough to be used by Fortune 500 and from the description of its underlying choises, it is a Rube Goldberg machine, one that pulls you in with perceived productivity hacks only to end up with navigating the dozen of libraries wired up in ways to get the developer to not think about them because the battle tested and mature paths are boring and lacking in novelty. I've been down this path before, where claims of productivity gains to get you an MVP is true to a certain degree, only to have a giant web of wiring that creates implicit and explicit cognitive load, in my opinion, its like taking out a loan for an increasing cost of capital from rising interest and equity , where eventually, you can't hire, you can't debug, you can't reverse due to sunk cost since you've bet your horses on the shiny new trendy thing where you depend on other's opinions and their understanding of the problem which will offer no real benefits to your specific, specialized contexts. This is in fact the problem with many full stack or opinionated frameworks, it ignores the last mile problem. As I grow older, I realize now the wisdom of choosing boring tech, when I was younger it was quite frustrating but now I see that PostgreSQL + Server side rendered language + Progressive interactivity is still strong for a reason and it is not Luddism or gerontocracy, it is stability from time tested collective experience of all minds. PHP is still going strong to this date. At the end of the day, all tech stack, architectural decisions are economically constrained by time, capital and labor supply. An overly complex arrangement, especially one that focuses on novelty over what has worked and widely used, increases risks due to unknowns. Specific issues and challenges can be addressed in bite sizes, rarely do they require ripping out the established paths, instead of throwing in a dozen of new, complex dependency and opinion ridden web of tech that is highly novel & guarantees implicit volatile technical debt with false gains that require far more trouble than its worth.

louissm_it 5y ago

Congrats! I've been keeping up with Redwood since the original announcement, and the progress they've made has been incredible. The generators and command line utilities are top notch (compared to Rails, thats a high bar to clear) and the general structure of everything seems very well thought out. Still missing a good official solution for background jobs, but I see there is a workaround in the 'How To' section on the documentation. The core team members are super nice and the community is very welcoming. I'm not convinced the "client side app + Graphql server" is the best model for most startups, however. I tend to lean more on server rendered pages with a little bit of progressive enhancement. But I assume the people who made Redwood are more knowledgeable than me :)

Kriscoulson 5y ago
> I'm not convinced the "client side app + Graphql server" is the best model for most startups Startups don't know what they need when just getting started. When you have a Graphql api you can spin up any number of other tools not just "client side apps", it can connect to a mobile app, cli, any number of other tools and you don't need to go back to the drawing board to make it happen. I've been using Redwood for quite a while and on my app I just spun up a public api with api keys and still maintain my private api specifically for internal app use in less than a day. When I started my project I didn't know I would need that.
- louissm_it 5y ago
  Alright, that is a very good point. If the possibility of other nodes interacting with your service is high (ie “you’re gonna need an API eventually”), this might well be the best option.

ryanchenkie 5y ago

I've been working with Redwood for 8-9 months now and it has been phenomenal. I can't imagine going back to wiring all the pieces together by hand.

noire-munich 5y ago

My two cents testimonial: we've been building our startup's core app with RedwoodJS and launched live in October 2021. It's been working great, the DX really lets you focus on your business and a lot - a lot - of the usual things that make a project require a bigger team are solved out of the box. I very reluctantly see myself starting any new project on anything different than RedwoodJS. I wouldn't, unless there really wasn't any other choice. You just get to the core of your project really fast, and don't lose touch of it, ever. RW is v1 so it's young but very satisfying, and having witnessed first hand how it's being built, I have faith and trust in its future releases. Looking forward to them actually.

gojomo 5y ago

Please, have landing pages & announcement pages explain up top what your thing is, or have the obvious click-targets (like the logo or project-name) take people to an introduction. If you've gone through all the trouble of designing/promoting a big launch/milestone site ("v1launchsite"!), don't require people to compose a Google query in another tab to get the one-sentence overview.

squishy47 5y ago
and not just what it is but also how it makes my life better.
khazhoux 5y ago
Also, even after manually typing in the main project URL, I can't find what language is supported on the backend ("api side").
- neogodless 5y ago
  From https://github.com/redwoodjs/redwood/blob/main/README.md https://github.com/redwoodjs/redwood/blob/main/README.md: > Redwood is an opinionated, full-stack, JavaScript/TypeScript web application framework > A Redwood application is split into two parts: a frontend and a backend. This is represented as two JS/TS projects within a single monorepo. > The api side is an implementation of a GraphQL API. Not sure you'd want to choose this if you want to roll your own API (without taking advantage of the framework/integration).
  - khazhoux 5y ago
    Thanks, though what I'm looking for (and, I expect, many/most other developers too), is a simple statement of whether I can write my backend in Go, Java, python, node, etc.
mikeiz404 5y ago
GitHub README is here https://github.com/redwoodjs/redwood/blob/main/README.md https://github.com/redwoodjs/redwood/blob/main/README.md for those looking for some background.

eternityforest 5y ago

The first page you click on should say what something is and why I would want it. Is this primarily meant to show business people, after telling them what it is verbally?

picometer 5y ago
I was also feeling frustrated with this. The HN post links to an event lineup, not a product/marketing page. It would be much less frustrating if it had a link to the homepage, which does describe the product: https://redwoodjs.com https://redwoodjs.com
- thedavidprice 5y ago
  Ah, that is exactly what's going on. Definitely deserving of a :facepalm: from myself and those of us on the Core Team who missed that. Tom is adding a link back to www. v1 Launch Week Schedule (this HN Post): https://v1launchweek.redwoodjs.com https://v1launchweek.redwoodjs.com RedwoodJS Website: https://redwoodjs.com https://redwoodjs.com GitHub Repo and README: https://github.com/redwoodjs/redwood/ https://github.com/redwoodjs/redwood/ All the conversation was happening here already, so we just jumped in! Apologies for the confusion. We could have caught that earlier.
  - mojombo 5y ago
    Explanation and link added!

trhoad 5y ago

Quite intrigued by this, and will definitely step through the tutorial. It will be interesting to compare it side-by-side with Adonis (and possibly Nest).

thedavidprice 5y ago
I am sincerely interested in what you learn. If you do a comparison and have some time to communicate the results, please look me up on the Redwood Forums or Twitter. This would be a helpful resource and discussion for our community and maintainers (because we are always learning and collaborating, to be clear): https://community.redwoodjs.com https://community.redwoodjs.com No pressure at all. (I'm one of the co-founders/leads of Redwood. Tag me @thedavidprice)

rglover 5y ago

mplewis 5y ago
Super rude and unwarranted.
- rglover 5y ago
  Achievement unlocked. https://www.youtube.com/watch?v=-h3ocCmOZ18 https://www.youtube.com/watch?v=-h3ocCmOZ18

sdesalas 5y ago

Is this likely to support SSR?

neogodless 5y ago
Discussed elsewhere in this thread: https://news.ycombinator.com/item?id=30909134 https://news.ycombinator.com/item?id=30909134

woah 5y ago

Not many details, but as far as i can tell, this is "react on rails"

blunte 5y ago

I really appreciate endeavors like this, but... My experience with many other frameworks is that they really help you get started quickly, and some of them truly cover a vast majority of common use cases. But when you reach a point of need or situation where they don't work the way you want, you must then learn how to work around them or enhance them. That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins. This should be a pretty familiar scenario for many of us here, and perhaps some have experienced this with RedwoodJS. If so, how do you feel about the framework now? How was the workaround/change-behavior experience?

maps7 5y ago
The alternative here is that you DoItYourself from the start and never launch or burn company money _before_ you even have a product or users.
- pooya72 5y ago
  I think that's taking the extreme end. Couldn't someone use a larger framework, for example Spring? It's pretty productive with Spring boot, but also large enough that you can expand for your use case. I'm not advocating for Spring per se, as I think .Net core is equivalent.
  - maps7 5y ago
    I was talking in wider terms of not using a framework at all and not specifically about Redwoodjs. I can't speak to whether RedwoodJS will lead you down a path of working around it.
pooya72 5y ago
Yes, and it's difficult to understand the tradeoffs without investing time in a framework. There are a lot of unknown unknowns, both in terms of the market fit and the framework. It's hard to know starting off what "situations" would be difficult for a framework like RedwoodJS.
5y ago

epolanski 5y ago

I don't have anything against Redwood per se but I find the collage of those technologies (personally) unappealing. Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps. But nothing of Redwood makes me think, "this is the missing piece I was waiting for" as I've worked with most of this stack in various combinations and I think it's a stack that's getting old and is not scaling or getting much better with time.

sequoia 5y ago
> Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps. If you can get this out of the box, this seems like a very good value prop. 'Boring and not innovative' isn't a flaw unless you're looking for something exciting and innovative, and most applications don't need this.
pooya72 5y ago
Two thinks I did find appealing were "Cells" and the easy integration with Storybook.

maps7 5y ago

I'm a Redwood user for my side project that I hope to launch in the next few days. For me Redwood has been great. I know React but was always frustrated with expanding past the UI layer e.g. data fetching, storing. I had tried NextJS in the past (didn't love the filename routing approach) but never actually got anything to production. I'm in an architect role for work now and I get to code less and less during the day. RedwoodJS has enabled me to actually build something in my own time and (hopefully) launch it. I didn't know GraphQL or Prisma before starting to use it but between the Redwood docs, Prisma docs and with some RW community help I've made good progress.

thedavidprice 5y ago
This is wind in our sails. Thank you for posting. And please do show off what you've built! I'd love to see it.

robertwt7 5y ago

I like Redwood, compared to Remix it has all the required opinionated boilerplate that is required for startups. It reminds me of using the whole battery included framework such as laravel or django as opposed to spring boot / aspnet.core If you work in big tech companies probably you would never use it as they have enough resources to build different services and have enough developers for different purposes. However if you're a solo dev for startups that wants to build MVP, it definitely reduces the amount of work needed to setup FE, BE, infra, etc. The amount of work needed to ship MVP is greatly reduced. Of course those are all in the expense of learning the framework itself.. but props to these guys with good docs! hopefully it will gain more and more traction!

gernb 5y ago

Is there are part that does the rest? Deployment, Staging, CI, Backups & Restore, Rolling Upgrades with fallback, etc.... or is that still left as an exercise for the reader?

louissm_it 5y ago
I found this[1] on the documentation. But in general staging environments, continuous integration and continuous delivery are not built into frameworks (Rails, Phoenix, etc). [1] - https://redwoodjs.com/docs/deployment/index https://redwoodjs.com/docs/deployment/index

Nijikokun 5y ago

I was going to use it for a project but it looks like it doesn't have electron support. :/

thedavidprice 5y ago
Tape.sh runs an Electron desktop app as one of it's 4 clients. GraphQL is a multi-client solution. Is there something more you're specifically looking for?

tonis2 5y ago

In my experience, the best way to avoid fighting frameworks, is to keep framework use minimal, and just write the 30 lines of UI code yourself for your custom form. Why does the JavaScript rendering require so many abstractions layers ?. I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. I use Web Components and some minor libraries, having so much easier time going this way. Not to kick down the hard work on developing of Redwood, but I'm just tired of being forced to use these frameworks on jobs. At startup stage the team picks a monolithic framework, after 2 years the developers are depressed building with it and leave, then new developers that come are met with a mess and fixing even easy bugs, is practically rewriting 5000 lines of code of the app, because everything is so entangled.

KronisLV 5y ago
> I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. For the most part, i'd say that frameworks being largely standardized and having ecosystems around them is a really good thing: people who are familiar with Vue/Angular/React (front end) and with Spring Boot/Express.js/Django/Rails (back end) can start working with your application more quickly than if it uses your custom "sort-of-like-jQuery-but-not-really" set of libraries/framework for the front end or your own thing for back end, which obviously will fall short in regards to documentation, consistency or ready made components. You can hire for Vue/Angular/React and Spring Boot/Express.js/Django/Rails, you cannot hire for your bespoke in-house solution. Also, the devs behind those solutions can spend more time and resources on making them better than your entire app will have put into it. That's why i largely avoid projects which have bespoke solutions like that, especially for back end frameworks, which typically are a minefield of badly written and badly tested code, as well as present numerous security related challenges. That stance was truly cemented when in one project i was stuck with an untested framework that stored half of the functionality in the DB, used JDBC directly through numerous abstractions, had commented out sections of code strewn about the codebase and had comments in Lithuanian, a language that i don't speak and had no documentation whatsoever. Of course, i've also seen things go into the opposite direction too far: instead of something like Bootstrap or its integration with any of the aforementioned popular frameworks/libraries being used, picking Tailwind CSS and spending weeks if not months mucking about with custom components without actually shipping features and solutions to business problems. If you are lucky enough to have front ends simple enough to be adequately handled by a few hundred/thousand lines of JS then by all means go ahead (right tool for the problem and all that), but that has never been my experience in any of the enterprise projects that i've worked on. Admittedly, however, i do feel these standard frameworks/libraries also getting more and more complicated as time goes on, because their eventual transformation into something that tries to do "everything" (and thus downfall) feels almost inevitable.

hestefisk 5y ago

Imagine if DHH was able to raise several millions of dollars for what is a front end and crud framework packaged from existing open source libraries… money is indeed cheap at the moment and I guess private equity / VC have to put excess liquidity somewhere.

jatins 5y ago

Congrats on 1.0! Is it possible to do Redwood development completely on something like Github codespaces or CodeSandbox? Last time I checked (~6 months ago) this didn't play nicely with Docker but curious if things have changed since then.

thedavidprice 5y ago
Yes, indeed! First off, Redwood comes with a Fastify server. `yarn rw serve` is the command you're looking for. Check out the Deploy Docs and this repo thats coming along: http://github.com/redwoodjs/docker/ http://github.com/redwoodjs/docker/ Secondly, we use Gitpod extensively — starting with a Dev environment for contributing. And as of a week ago we now how a Gitpod starter that spins up a new install @latest using Postgres. Check it out here: https://github.com/redwoodjs/gitpod-starter https://github.com/redwoodjs/gitpod-starter Full Doc and being included at the intro to the Tutorial are coming soon!