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?
My experience is that full-stack frameworks like rails (and hopefully redwood) free you from a ton of bike-shedding and customization up front and help you get to a point where you outgrow parts of the framework. An advantage of using something like rails today (or over the past 5 years) is that there was a huge crop of unicorn rails startups that all hit those challenges before and a lot of their solutions are codified in open source tools that can be plugged into the framework. In some cases those startups (like shopify, github) have made huge investments in ruby and rails themselves. I hope in a few years that will be the case for redwood.
I like the concept of innovation budgets for startups. You can only innovate on so many vectors because time is typically your most limited resource. Very few startups have a good reason to spend any of that budget on innovations that are not core to their product differentiation. These things include web frameworks, corporate structure, credit card processing, low-level hosting. Just pick a pretty standard solution that fits your use-case and move on. I don't think it's a coincidence that so many of the big startups over that past 10 years were built with big batteries-included frameworks (would be so curious about a larger study of this, I just have cloudy anecdotes).
Don't get me wrong, I love bleeding edge web stuff and playing with new frameworks. But if my priority is making a new company succeed I'm going to look for a framework that minimizes time spent picking libraries and gluing them together nicely and maximizes time I have to iterate on the product and tweak user-facing business logic.
While this thinking isn't wrong, it is optimizing for the wrong thing. By focusing on future development velocity you are trading off current velocity, which is extremely important to build an MVP, test (and eliminate) potential product paths and generally get from 0 to 1 as fast as possible.
There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity.
If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.
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.
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.
I have a simple question -- I've looked at GraphQL in the past and it seems extremely limited when you start wanting to do more complicated types of joins for performance, etc. This is such a fundamental thing to any webapp in my mind, and yet when I ask this previously people are often like "uhhh yeah...... use joinMonster I GUESS?"
Has GraphQL improved? I literally can't fathom using some kind of external plugin just to load data using more complex queries for performance reasons.
My utmost gratitude to you David, Tom, Peter & Rob, getting on the RedwoodJS train early on has been a great choice of life changing vehicle.
Also, very excited about that launch week! Can't wait to see the community grow.
So, going through your tutorial and coming up on an issue/error... when I scaffold the 'posts' I keep getting an error:
API listening on http://localhost:8911/
api | GraphQL endpoint at /graphql
api | 15:23:32 Server listening at http://[::]:8911
web | <e> [webpack-dev-server] [HPM] Error occurred while proxying request
localhost:8910/graphql to http://[::1]:8911/ [EADDRNOTAVAIL]
(https://nodejs.org/api/errors.html#errors_common_system_errors)
web | <e> [webpack-dev-server] [HPM] Error occurred while proxying request
localhost:8910/graphql to http://[::1]:8911/ [EADDRNOTAVAIL]
(https://nodejs.org/api/errors.html#errors_common_system_errors)
Any details you can share about why the project is using rather obsolete tools (yarn, webpack)? I understand they're old and stable, but I took the project for trying to be on the leading edge.
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.
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.
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!
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 :)
> 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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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!
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!
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.
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!
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.
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.
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.
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 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
No pressure at all.
(I'm one of the co-founders/leads of Redwood. Tag me @thedavidprice)
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.
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.
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 ...?
[+] [-] blunte|4 years ago|reply
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?
[+] [-] rgbrgb|4 years ago|reply
I like the concept of innovation budgets for startups. You can only innovate on so many vectors because time is typically your most limited resource. Very few startups have a good reason to spend any of that budget on innovations that are not core to their product differentiation. These things include web frameworks, corporate structure, credit card processing, low-level hosting. Just pick a pretty standard solution that fits your use-case and move on. I don't think it's a coincidence that so many of the big startups over that past 10 years were built with big batteries-included frameworks (would be so curious about a larger study of this, I just have cloudy anecdotes).
Don't get me wrong, I love bleeding edge web stuff and playing with new frameworks. But if my priority is making a new company succeed I'm going to look for a framework that minimizes time spent picking libraries and gluing them together nicely and maximizes time I have to iterate on the product and tweak user-facing business logic.
[+] [-] 10x-dev|4 years ago|reply
There will be a point in the product lifetime when you will outgrow the framework and you will need to rewrite large portions of it and pay off the tech debt. Most projects don't get to that point. Once there, it is also the right time to make those decisions that were classified as premature optimization. Now they are merely tech decisions with one crucial difference: at this point you have much more information about the product, the market, the customers, and your team than you had initially, so now you can take the best decisions about what will really increase your velocity.
If speed to market is not essential (such as a side project for fun) then by all means, it's you now, and it's you later, so take the time to enjoy your craft and become proficient at combining the best tools to make your project shine, instead of opting for the cookie cutter frameworks.
[+] [-] maps7|4 years ago|reply
[+] [-] pooya72|4 years ago|reply
[+] [-] Lorin|4 years ago|reply
[+] [-] thedavidprice|4 years ago|reply
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
So very excited to see what people with Redwood
[+] [-] Exuma|4 years ago|reply
Has GraphQL improved? I literally can't fathom using some kind of external plugin just to load data using more complex queries for performance reasons.
[+] [-] noire-munich|4 years ago|reply
[+] [-] gremlinsinc|4 years ago|reply
[+] [-] hit8run|4 years ago|reply
[+] [-] andrew_|4 years ago|reply
[+] [-] pistoriusp|4 years ago|reply
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
[+] [-] pietromenna|4 years ago|reply
[+] [-] mojombo|4 years ago|reply
[+] [-] eternityforest|4 years ago|reply
Is this primarily meant to show business people, after telling them what it is verbally?
[+] [-] picometer|4 years ago|reply
It would be much less frustrating if it had a link to the homepage, which does describe the product: https://redwoodjs.com
[+] [-] louissm_it|4 years ago|reply
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|4 years ago|reply
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.
[+] [-] maps7|4 years ago|reply
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|4 years ago|reply
And please do show off what you've built! I'd love to see it.
[+] [-] pooya72|4 years ago|reply
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|4 years ago|reply
[+] [-] dang|4 years ago|reply
Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - https://news.ycombinator.com/item?id=22537944 - March 2020 (167 comments)
[+] [-] tonis2|4 years ago|reply
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|4 years ago|reply
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.
[+] [-] epolanski|4 years ago|reply
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|4 years ago|reply
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|4 years ago|reply
[+] [-] noire-munich|4 years ago|reply
[+] [-] ryanchenkie|4 years ago|reply
[+] [-] mattwad|4 years ago|reply
[+] [-] ogazitt|4 years ago|reply
[+] [-] pistoriusp|4 years ago|reply
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!
[+] [-] robertwt7|4 years ago|reply
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!
[+] [-] qbasic_forever|4 years ago|reply
[+] [-] dpkrjb|4 years ago|reply
[+] [-] mojombo|4 years ago|reply
[+] [-] dthyresson|4 years ago|reply
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.
[+] [-] pistoriusp|4 years ago|reply
I think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
[+] [-] tomatowurst|4 years ago|reply
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.
[+] [-] trhoad|4 years ago|reply
[+] [-] thedavidprice|4 years ago|reply
No pressure at all.
(I'm one of the co-founders/leads of Redwood. Tag me @thedavidprice)
[+] [-] haffi112|4 years ago|reply
[+] [-] cephalization|4 years ago|reply
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.
[+] [-] sandwichinvest|4 years ago|reply
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.
[+] [-] tentacleuno|4 years ago|reply
[+] [-] canyonero|4 years ago|reply
“Redwood is the full-stack web framework designed to help you grow from side project to startup.”