I really appreciate endeavors like this, but...<p>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.<p>That usually means doing a lot of digging and learning, essentially repaying that early time gift you received from all the nice built-ins.<p>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?
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.<p>With Redwood, no one has to go it alone.<p>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.<p>Join the Redwood Community: <a href="https://redwoodjs.com/community" rel="nofollow">https://redwoodjs.com/community</a><p>So very excited to see what people with Redwood
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.<p>So I have the perspective as a creator and a user!<p>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.<p>[1] <a href="https://www.snaplet.dev" rel="nofollow">https://www.snaplet.dev</a>
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.
The first page you click on should say what something is and why I would want it.<p>Is this primarily meant to show business people, after telling them what it is verbally?
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.<p>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 :)
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.<p>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.<p>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.
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.<p>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.<p>This is of course if you're interested in basic CRUD. I don't know how it would be for non-CRUD apps.
Related:<p><i>Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack</i> - <a href="https://news.ycombinator.com/item?id=22537944" rel="nofollow">https://news.ycombinator.com/item?id=22537944</a> - March 2020 (167 comments)
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.<p>Why does the JavaScript rendering require so many abstractions layers ?.<p>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.<p>I use Web Components and some minor libraries, having so much easier time going this way.<p>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.<p>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.
I don't have anything against Redwood per se but I find the collage of those technologies (personally) unappealing.<p>Looks to me what it is: a "safe", as in common, meshed stack for new teams to develop mvps.<p>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.
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.
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.
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.
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<p>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.<p>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!
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.'.
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.
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).
I've kept half an eye on Redwood since the early days, but i'll have to give it a proper look.<p>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.
Does it support wbsockets ?<p>I am thinking of implementing something like: <a href="https://www.viget.com/articles/phoenix-and-react-a-killer-combo/" rel="nofollow">https://www.viget.com/articles/phoenix-and-react-a-killer-co...</a><p>Would it be feasible in RedwoodJS with or without websockets ?
Congrats on 1.0!<p>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.
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.
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".
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?
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.
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.<p>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.