[HN Gopher] RedwoodJS 1.0
___________________________________________________________________
RedwoodJS 1.0
Author : canyonero
Score : 204 points
Date : 2022-04-04 14:36 UTC (8 hours ago)
(HTM) web link (v1launchweek.redwoodjs.com)
(TXT) w3m dump (v1launchweek.redwoodjs.com)
| gojomo wrote:
| 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.
| [deleted]
| squishy47 wrote:
| and not just what it is but also how it makes my life better.
| khazhoux wrote:
| Also, even after manually typing in the main project URL, I
| can't find what language is supported on the backend ("api
| side").
| neogodless wrote:
| From
| 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 wrote:
| 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 wrote:
| GitHub README is here
| https://github.com/redwoodjs/redwood/blob/main/README.md for
| those looking for some background.
| adfm wrote:
| Their main site seems to do a better job telling you what it is
| and what it does.
|
| https://redwoodjs.com/
| [deleted]
| ryanchenkie wrote:
| 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.
| andrewingram wrote:
| 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 wrote:
| 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!
| pietromenna wrote:
| 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 wrote:
| 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!
| dmitriid wrote:
| 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 wrote:
| 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 wrote:
| Nice!
| dpkrjb wrote:
| 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.
| pistoriusp wrote:
| 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.
| mojombo wrote:
| 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!
| dthyresson wrote:
| 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.
| woah wrote:
| Not many details, but as far as i can tell, this is "react on
| rails"
| rglover wrote:
| You folks just made my day. This thing is a mess.
|
| If you want the zen approach:
| https://github.com/cheatcode/joystick.
| mplewis wrote:
| Super rude and unwarranted.
| rglover wrote:
| Achievement unlocked.
| https://www.youtube.com/watch?v=-h3ocCmOZ18
| qbasic_forever wrote:
| 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 wrote:
| 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.
| haffi112 wrote:
| When should I use RedwoodJS and why?
| tentacleuno wrote:
| 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 wrote:
| Did you look at the main website? 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.
| cephalization wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| From their main website (https://redwoodjs.com)
|
| "Redwood is the full-stack web framework designed to help you
| grow from side project to startup."
| haffi112 wrote:
| But why Redwood rather than some other framework? (I'm just
| interested in learning what opinions people have on here)
| mojombo wrote:
| 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!
| sandwichinvest wrote:
| 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 wrote:
| 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 wrote:
| 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.
| flybayer wrote:
| Blitz doesn't use GraphQL, one of the unique things about it.
| blunte wrote:
| 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?
| rgbrgb wrote:
| 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.
| maps7 wrote:
| 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 wrote:
| 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.
| pooya72 wrote:
| 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.
| rtcoms wrote:
| Does it support wbsockets ?
|
| I am thinking of implementing something like:
| https://www.viget.com/articles/phoenix-and-react-a-killer-co...
|
| Would it be feasible in RedwoodJS with or without websockets ?
| lefrenchy wrote:
| 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 wrote:
| 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
| rajangdavis wrote:
| This seems really nice, but is there a way to bypass GraphQL or
| is it a hard requirement?
| mojombo wrote:
| 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.
| thedavidprice wrote:
| 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
|
| So very excited to see what people with Redwood
| hit8run wrote:
| What's your business model?
| thedavidprice wrote:
| 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-fun...
| JimDabell wrote:
| What's your business model?
| number6 wrote:
| Millionaires Toy Project.
| blunte wrote:
| Much nicer for all of us than most millionaires' toys.
| junon wrote:
| Instead of giving an edgy reddit-like repeated response
| in clear pursuit of karma, perhaps you could read the
| link the GP comment just gave you.
|
| > So my million dollar spend on Redwood development comes
| with no strings attached, except that we continue to
| focus on building the best app framework for startups.
|
| It's a personal investment and a passion project. Unless
| they're lying, there is no business model.
| JimDabell wrote:
| I wasn't being edgy and I did read the link. A one-off
| donation isn't a business model.
|
| > Although it's not a typical for-profit business model,
| we are sustainable
|
| If it's sustainable, there's clearly something other than
| a one-off donation. What is it?
| [deleted]
| mojombo wrote:
| Right now there is no business model, on purpose. This is
| why I'm personally supporting it. I think what David
| meant is that we are sustainable because I am committed
| to sustaining the project. Our goal is to find a properly
| sustainable model in the future that meshes well with our
| mission and ambition. It will be exciting to figure that
| out!
| patrickaljord wrote:
| Preston-Werner is an investor in Netlify, RedwoodJS was
| built with Netlify in mind (though it supports others
| hosting companies but not to the same extend).
|
| Netlify is competing with Vercel that has Next.js. So
| basically RedwoodJS was built to sell more Netlify
| hosting plans the same way Next.js was for Vercel. It is
| therefore safe to say that RedwoodJS will continue to
| exist as long as Netlify is a thing... unless Next.js
| completely owns the market and RedwoodJS's reason to
| exist makes no sense because of too few users.
| noire-munich wrote:
| 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.
| Exuma wrote:
| 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.
| manquer wrote:
| It really depends on how the resolvers are written, GraqhQL
| is just a interchange mechanism like RESTful APIs . You can
| do same things good or bad on both.
|
| Depending on the framework that use for your DB-to-GraphQL
| layer (like Hasura / join monster/ PostGraphile / subZero
| etc) there can be some there can be some limitations on what
| it can and cannot do, but that is not really a GraphQL
| problem.
|
| The GraphQL specific gotchas for me where
|
| - For most part component level queries works well,
| occasionally batching in higher component is important for
| performance, for example instead of executing a secondary
| query on each row of the table ( say fetching photos of user
| profiles from a different store) doing it one level up can
| speed things up.
|
| - Caching has to be solved very differently than RESTful
| APIs, GraphQL has everything in one endpoint as POST and you
| cannot leverage CDN's to cache the canonical resource URLs
|
| - Less verbosity or nested request-responses could be
| important for UX performance, using HATEOS style
| discoverability usually results in many APIs calls 2-3 levels
| or more deep, in RESTful systems that is not a major problem
| if you are not caching API responses in nodes in dozen
| locations/CDNs near the user but that is not possible in
| GraphQL, so you have to keep mind of verbosity, that can also
| impact how you store and index your database and how you
| configure and run replicas etc at scale.
|
| ---
|
| Anecdotally I have used Hasura as GraphQL frontend for an
| existing mature PostgreSQL db and APIs, (1 tb+, 1000's of
| concurrent users), and it scales fairly well even with 4-5
| level nested joins or fetch ten of thousands of nested
| records. Hasura also does subscriptions reasonably well and
| they don't use triggers for implementing it.
|
| Some areas that needed a bit work around for me - recursive
| CTEs, cross-db joins, performance of very large counts (
| postgres problem - using HLL or tuples from the planner if
| approximate values are fine.
| beaconstudios wrote:
| GraphQL is designed around CRUD fetching patterns - so
| typically you would have a query per data type slice, and
| that query can be as complex as you like. In order to avoid
| N+1 queries, you should use dataloader:
| https://github.com/graphql/dataloader.
|
| You can also join additional data to reference in deeper
| resolvers, but that's an antipattern AFAIK.
| benatkin wrote:
| The latest release of dataloader happened more than 2 years
| ago.
| replygirl wrote:
| ever considered db views instead of doing a bunch of joins at
| fetch time?
| Exuma wrote:
| Yes, but not every query should be a view (materialized or
| not) because the ORM doesnt support things like lateral
| join, cross join, etc.
| srcreigh wrote:
| Nothing about GraphQL causes a join monster.. that's just
| unbounded limits on the front end queries.
|
| You could validate against having too many layers of nesting
| in one query, validate pagination, provide abstract
| relationships for the many nesting and special case those
| joins, etc.
|
| It's basically a question of how to efficiently query data.
| There's always ways, but it might require some trimming of
| allowed graphql queries.
| dthyresson wrote:
| > You could validate against having too many layers of
| nesting in one query
|
| The GraphQL Server in RedwoodJS does query depth limiting
| out-of-the-box. You can configure it, but by default the
| depth is 11 -- because all the best things go to 11.
|
| [1] https://redwoodjs.com/docs/graphql#query-depth-limit
| Exuma wrote:
| I was referring to this: https://join-
| monster.readthedocs.io/en/latest/
| ncrmro wrote:
| Postgraphile turns postgres schema into GraphQL schema, can
| do, filtering, aggregates, computed columns, filtering on
| computer columns etc
| gremlinsinc wrote:
| 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.o
| rg/api/errors.html#errors_common_system_errors)
| thedavidprice wrote:
| Any chance we could be of help over in either:
|
| Redwood Forums: https://community.redwoodjs.com
|
| Redwood Discord: http://discord.gg/redwoodjs
|
| ?
| andrew_ wrote:
| 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.
| thedavidprice wrote:
| Tell me more about "obsolete", because I don't think you mean
| what that word means?
| ascendantlogic wrote:
| It means no one has written a "Why we switched to webpack"
| article in years so that means it's completely obsolete and
| useless.
|
| Hacker News logic 101.
| oaxacaoaxaca wrote:
| 22M weekly downloads - that's pretty much zero. So yeah
| definitely obsolete.
|
| /s
| mojombo wrote:
| These were state of the art tools when we started work on
| Redwood more than two years ago. We're investigating other
| more modern alternatives, but swapping them out is a finicky
| and time consuming project and we've been focused on primary
| features. We will keep evaluating our dependencies and you
| may see some changes in v2!
| andrew_ wrote:
| Thanks for the open answer, appreciate you checking out the
| question.
|
| Can't help but giggle at the downvotes.
| ravenstine wrote:
| Webpack is obsolete?
|
| Man, this field really does move quickly.
| Sophistifunk wrote:
| Yarn too, apparently. We'd better go tell..... everybody :)
| maps7 wrote:
| What do the cool kids use instead of Yarn these days?
| [deleted]
| vosper wrote:
| I don't think Webpack's obsolete, it's just got a lot of
| competition these days, most of which is easier to use.
| replygirl wrote:
| webpack was older when rollup came out than gulp was when
| webpack came out. if not for create-react-app's impact,
| we'd probably all have moved on 2-3 years ago
| boomskats wrote:
| Wow. Weird reasoning. Never thought someone could be so
| openly ageist about... a module bundler.
|
| Could you maybe provide a better argument for why you
| think we'd all have moved on by now? Aside from 'wow its
| not as new as the new thing'?
| dgb23 wrote:
| I don't know much about rollup, it doesn't seem to be
| that different, but some of the newer tools are rust and
| go based and better tuned for performance during
| development. JS tooling is generally slow and weirdly
| complex, and people seem to acknowledge these issues and
| improve on them.
| hu3 wrote:
| Non frontend expert here trying to learn.
|
| What would you recommend instead o yarn and webpack?
|
| I have been using vite and npm in my small frontend projects.
| epolanski wrote:
| 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 wrote:
| > 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 wrote:
| Two thinks I did find appealing were "Cells" and the easy
| integration with Storybook.
| mattwad wrote:
| I'd love to hear a comparison between this and Next.js if someone
| has used both.
| thedavidprice wrote:
| You can use RedwoodJS API as the backend for Next. There are
| several startups with multi-client products including a Next
| front-end as one of many.
| mattwad wrote:
| Interesting.. I didn't know that, thanks!
| canyonero wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Being able to more quickly bootstrap a project is about
| 0.01% of the value of a platform. If that's the pitch
| then I'm not buying. I'll choose the platform that's
| easiest to debug, maintain and expand.
| mojombo wrote:
| RedwoodJS has been about long term maintainability from
| the very beginning. This is part of why we chose GraphQL
| as a core component. It's more complex at first, but in
| the long run it gives you multi-client capabilities
| without rewriting your backend, and provides excellent
| separation of concerns. We still try to make Redwood as
| easy to get started with as possible, but in the tradeoff
| between "quick bootstrapping" and "long term
| maintainability", we tend to choose the latter.
| fishtoaster wrote:
| That's definitely a valid view, but I'd say it's not the
| only one.
|
| For some usecases, quick bootsrapping is incredibly
| valuable - eg an early-stage startup.
|
| That was the historical case for Rails: quick to get
| started and not _too_ bad to maintain /expand as you grow
| (it got better about later stages in the later years as
| the ecosystem matured). That's a tradeoff that can make a
| ton of sense when you're starting a project that has a
| good chance of not existing in 6 months and where every
| day of initial productivity is incredibly valuable.
| leodriesch wrote:
| As far as I know Redwood has no server-side rendering solution.
| You can do both client-side rendering and static generation
| (although not as sophisticated as Next.js'), but not server-
| side rendering.
|
| Next.js also has a pretty small API surface and is generally
| quite unopinionated when it comes to your apps structure, while
| Redwood chooses more of the stack for you and what tools you
| should use (Storybook, Jest, Prisma, GraphQL).
|
| I would also like to point out that while there are a lot of
| people rooting for Redwood's success and they seem to have some
| active core contributors, there is actual financial backing for
| Next.js and they have large enterprise users.
|
| There are some startups that use Redwood listed on the 1.0
| update website, but at least I do not know any of them.
| thedavidprice wrote:
| > there is actual financial backing for Next.js and they have
| large enterprise users
|
| We haven't communicate this very well until today. Redwood is
| funded and will continue to be funded. Just not in a typical
| "for-profit" business model. See: https://tom.preston-
| werner.com/2022/04/04/redwood-v1-and-fun...
|
| > while Redwood chooses more of the stack for you and what
| tools you should use (Storybook, Jest, Prisma, GraphQL)
|
| Very true! Just know that the overall integration is modular
| and extensible. - byo DB Client - want to use REST, go for
| it! - power Next via the multi-client API, lots of startups
| doing that already
|
| > There are some startups that use Redwood listed on the 1.0
| update website, but at least I do not know any of them
|
| That makes sense because most of them are less than 1 year
| old. And the funding amount listed was raised in the previous
| 6 months.
| sdesol wrote:
| > they seem to have some active core contributors
|
| Looking at merged pull requests, the project is quite healthy
| as the following shows:
|
| https://oss.gitsense.com/insights/github?q=merged%3Atrue%2Bp.
| ..
|
| Next.js is on a whole new level though
|
| https://oss.gitsense.com/insights/github?q=merged%3Atrue%2Bp.
| ..
|
| The number that I'm really interested in, are last commits
| more than 28 days ago. With this number, you can guesstimate
| how popular Next.js is with non core contributors and in the
| case of Next.js, it really is staggering.
| pistoriusp wrote:
| I'm new to this tool, but can you break down how to
| correlate the 28 days ago commits with non-core
| contributors and concluding that it's staggering?
| sdesol wrote:
| The basic idea is, if somebody last committed more than
| 28 days ago, it is likely that they are not a "core
| contributor" since you would expect "core contributors"
| to commit more frequently than every 28 days. Hope that
| makes sense.
|
| For Next.js, the percentage of people that last committed
| more than 28 days ago accounts for 80% of all unique
| contributors, which is what makes their project quite
| staggering from a "popularity" standpoint. Assuming
| everybody that last committed more than 28 days ago are
| not "core contributors" (which may not be accurate of
| course) we can see that Next.js had 169 contributors that
| basically decided to create a pull request that was good
| enough to be merged. For Redwood they had 23, which is
| respectable but not on the same level as Next.js
|
| Based on my analysis of very popular open source
| projects, most projects typically only have 50% of their
| contributors in the +28 days range, while Next.js has
| 80%. Looking at last commits more than 28 days ago is a
| very good indicator of community health/interest.
| pistoriusp wrote:
| Very cool, thank you!
| mojombo wrote:
| > As far as I know Redwood has no server-side rendering
| solution.
|
| SSR is priority number one for v2. In the meantime, a number
| of users use Next.js as a client that talks GraphQL to the
| Redwood backend. It works very well!
|
| > there is actual financial backing for Next.js
|
| Today I announced I will be providing $1M of funding for
| future RedwoodJS framework development this year, so now we
| have funding too. =)
|
| https://tom.preston-werner.com/2022/04/04/redwood-v1-and-
| fun...
|
| The truth is, we can both succeed at the same time, there are
| so many great app ideas waiting to be explored, and different
| tools will work better for different situations!
| xrd wrote:
| I'm the author of Svekyll (https://svekyll.com) a static
| blog tool which models the simplicity of Jekyll. Svekyll
| uses SvelteKit under the hood, but rendering to a static
| site feels like it is a second class experience in
| SvelteKit (they are more focused on rendering to cloudflare
| or netlify or vercel serverless platforms). I would love to
| experiment with using RedwoodJS as the backend if SSR is a
| priority; how do I get more information on that work?
| dac09 wrote:
| Hi! Core team member here, right now we have our hands a
| little full with the launch week, but will be moving onto
| v2 very soon!
|
| Best way to get more info is to create a post on the
| forums, or an issue! The discord contributing channel is
| a great place too. All the links on the main website
| https://redwoodjs.com
|
| Speak to you over there!
| replygirl wrote:
| what happens when you get bored of it?
| chaostheory wrote:
| How does Blitzjs compare?
| o_m wrote:
| No one knows. The Blitzjs team is working on a pivoting Blitz,
| so its not worth comparing old Blitz with Redwood for now.
| chaostheory wrote:
| 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 wrote:
| No, DX will still be almost exactly the same on the user
| side.
| louissm_it wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| maps7 wrote:
| 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 wrote:
| 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.
| pistoriusp wrote:
| 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
| trhoad wrote:
| 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 wrote:
| 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)
| ogazitt wrote:
| 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 wrote:
| 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 wrote:
| 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
| noire-munich wrote:
| 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.
| sdesalas wrote:
| Is this likely to support SSR?
| neogodless wrote:
| Discussed elsewhere in this thread:
|
| https://news.ycombinator.com/item?id=30909134
| dang wrote:
| Related:
|
| _Redwood: An integrated, full-stack, JavaScript web framework
| for the JAMstack_ - https://news.ycombinator.com/item?id=22537944
| - March 2020 (167 comments)
| pistoriusp wrote:
| 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.
| [deleted]
| eternityforest wrote:
| 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 wrote:
| 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
| thedavidprice wrote:
| 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
|
| RedwoodJS Website: https://redwoodjs.com
|
| GitHub Repo and README: 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 wrote:
| Explanation and link added!
| techn00 wrote:
| Will the events be recorded?
| thedavidprice wrote:
| Yes, indeed! And then posted to YouTube
| https://youtube.com/redwoodjs
| jzig wrote:
| 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 wrote:
| You can use Redwood's API with your Angular frontend.
| jzig wrote:
| 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.
| thedavidprice wrote:
| 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 You
| just need a GraphQL Client, which The Guild already has an
| option ready for you 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-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
|
| No pressure at all! Just wanted you to know the invitation
| is open. Anytime.
| dac09 wrote:
| 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.
| pooya72 wrote:
| 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 wrote:
| I'm using it for a non-CRUD app. We have a "web", "api" and
| "cli" side and the experience still scales.
| pooya72 wrote:
| And what type of app is this, if you don't mind sharing?
___________________________________________________________________
(page generated 2022-04-04 23:01 UTC)