[HN Gopher] Redwood: An integrated, full-stack, JavaScript web f...
___________________________________________________________________
Redwood: An integrated, full-stack, JavaScript web framework for
the JAMstack
Author : mojombo
Score : 179 points
Date : 2020-03-10 18:13 UTC (4 hours ago)
(HTM) web link (redwoodjs.com)
(TXT) w3m dump (redwoodjs.com)
| swyx wrote:
| congrats on the launch! I've been hoping for someone to make a
| "Rails for JS" for a long time, with the performance capabilities
| of JAMstack apps (prebuilt, served from CDN). This is a peek into
| the future!
|
| as a React dev as well, I particularly like the integration of
| GraphQL into the Cell format. This will work especially well with
| render-as-you-fetch React Suspense. I think if you throw in
| scoped css you'll have the ultimate vision of the React Single
| File Component format.[1]
|
| 1: https://www.swyx.io/writing/react-distros/#what-other-
| react-...
| pistoriusp wrote:
| Thanks! I was very nervous about how people would receive the
| concept of Cells, but people seem to like it, and we'll improve
| the implementation!
|
| I personally love styled-components and I had tighter
| integration with it in the start, but we decided to not be
| opinionated about CSS frameworks... That may change ;)
| mojombo wrote:
| Hi! One of the Redwood authors here. I'm really excited to launch
| Redwood today and happy to answer any questions you have about
| the framework and what makes it special!
| btown wrote:
| This is amazing - I'm very much in Django land right now, but
| I'd love to see a successor that combines all its productivity
| strengths with the modern world of JS/Typescript-all-the-way-
| down.
|
| A few questions:
|
| - Do you intend to have strong typing (Typescript) all the way
| through? Most of the examples seem to be in plain JS. Not that
| that's a bad place to start, but I have a dream of typing a
| schema for a new model once and having it immediately typecheck
| all the way to the frontend code.
|
| - Will there be an ability to automatically generate admin
| interfaces, form and all, from database schema? Django's
| ModelAdmin is annoying to customize, but it's unparalleled in
| getting a GUI together in minutes for a trusted operational
| team. And React-Hook-Form's support for dynamically generated
| fields could be really powerful in this regard.
|
| - Both Rails and Django have patterns of "as long as this file
| is in the right place and/or has the right inheritance
| hierarchy, I won't need to write boilerplate." Is this a goal
| of this project as well? For instance, for the service file in
| https://redwoodjs.com/tutorial/side-quest-how-redwood-works-...
| seems to be something that would be nearly identical, save for
| the name of the model, across a number of things. Rather than
| scaffolding, could there be a way to inherit from a generic
| superclass (or the functional equivalent), fully overrideable,
| similar to how
| https://docs.djangoproject.com/en/3.0/topics/class-based-vie...
| allows any view to inherit from a ListView or DetailView?
| thedavidprice wrote:
| Thanks for the kind words and questions! Others from the team
| can go into more detail, but here's some high-level for now:
|
| - Typescript is definitely a priority for us. But
| implementation so far is starting with the backend (see
| https://github.com/redwoodjs/redwood for current), which
| isn't inclusive as of yet. We are looking for community
| involvement here as well.
|
| - Admin interface: ah, very interesting. Could definitely be
| on the roadmap in the future. We're off to a great start with
| the Scaffold generator, which uses the schema to create all
| the pages necessary to run end-to-end CRUD operations on a
| database table. See https://redwoodjs.com/tutorial/getting-
| dynamic
|
| - Boilerplate: The short answer is "yes indeed"! It's not
| 1-to-1 with your example, but there are lots of cases where
| you'll find this thinking+implementation. Again, the tutorial
| walkthrough is the best place to see some of this in action.
| hokumguru wrote:
| I think Prisma, the database layer of Redwood, plans on
| shipping their admin solution later this year.
| dmead wrote:
| why do so many JS frameworks exist?
| pistoriusp wrote:
| If you asked me a few years ago if I could imagine building a
| framework, let alone a JS one, my answer would've been "hell
| no!"
|
| But here I am... There was a lot of time spent trying to
| figure out how to use these technologies, and we're glueing
| those technologies together with our personal taste.
| mojombo wrote:
| I think it's a natural consequence of new possibilities
| existing in the JS world. Build tools like webpack,
| transpilers like Babel, type systems like TypeScript;
| deployment architectures like JAMstack; all these things mean
| we can do new and interesting things with code, and
| developers are excited to explore them. It's a good thing! We
| want to explore the domain as much as possible to find the
| best solutions. Eventually you'll see consolidation around a
| smaller number of the best projects.
| msoad wrote:
| Why it was not written in TypeScript? (Sorry for fanboy type
| question)
| pistoriusp wrote:
| We're working on full Typescript support for Redwood and we
| would like tot take it all the way from the DB definitions to
| GraphQL to the frontend!
|
| It's on the way!
| rgbrgb wrote:
| This is awesome, congrats! I love Rails but it does seem like
| nextjs has left it in the dust in terms of making it easy to
| build simple, performant front-ends in react and there's no
| official Rails graphql solution yet either. What next is
| missing is a blessed omakase way to deploy it with a DB.
|
| Can you talk about or point me to docs on the different
| philosophies between this and nextjs? In particular next
| already makes bundle optimization, splitting, lazy-fetching and
| serverless deploys pretty automatic. Why not start with next
| and work on incorporating the DB/business logic functionality?
| Related: why Prisma?
| veeralpatel979 wrote:
| > there's no official Rails graphql solution yet either
|
| I use https://github.com/rmosolgo/graphql-ruby!
| ordinaryradical wrote:
| What level of site complexity do you think would justify using
| your framework versus a simpler approach? (wordpress with
| wp2static, for example) Is there a concrete level of
| interactivity or architecture at which you think a framework
| like this starts to shine?
| mojombo wrote:
| We're looking to be a modern replacement for something like
| Ruby on Rails, so think full-on web application vs a blog or
| simple eCommerce site. Another way to think about is: do you
| have a lot of custom business logic you need to implement in
| order to drive your application? If so, then Redwood is set
| up really well do deal with that.
| garysieling wrote:
| Do you intend to have built-in support for user management?
|
| Setting up stuff like Oauth / Okta / etc and handling
| things like who can access admin screens seems to consume a
| lot of time on new projects - it'd make for an awesome app
| platform if some of that was well-supported out of the box.
| thedavidprice wrote:
| You bet. See our roadmap list here
| https://redwoodjs.com/tutorial/wrapping-up And if you
| haven't read the README yet, that will help with the
| overall vision + direction https://redwoodjs.com/docs
| pistoriusp wrote:
| Totally! We wanted to have a way of doing auth included
| in the launch but we ran out of time. It's definitely on
| the roadmap. Our goal is to make it "just work!"
| wmichelin wrote:
| Interesting the documentation uses the term "generators" to refer
| to scaffolding tools. I read that word and got excited that they
| had python-esque generators.
| yatsyk wrote:
| Congratulation on launching!
|
| I like rails, but in js world may be not so good idea to
| reimplement or integrate everything related to ui, routing etc.
| Meteor.js was not very successful with this model. I think
| routing or UI on react-native/web/blessed/VR is too different to
| be part of one framework.
|
| But I see the usefulness of framework with functionality related
| to data fetching and business logic.
|
| I consider perfect stack for this things is Postgress->Hasura (or
| also Prisma)->mst-gql->mobx-state-tree. You create database
| schema and everything up to models on client is autogenerated and
| each part of this stack could be updated, customized or
| completely rewritten. This stack could be used on react-native or
| web or any other js platform.
| jaredcwhite wrote:
| At first I thought "oh great, this looks very nice but why does
| it exist when Next.js, Gatsby, etc. are already a thing?"
|
| Then I saw Tom Preston-Werner's involvement and my interest level
| raised considerably. I'm still not sure if there's a market for
| this per se, but the bone-fides of the dev team is certainly a
| good sign.
| rvz wrote:
| > Then I saw Tom Preston-Werner's involvement and my interest
| level raised considerably.
|
| I would have agreed with you already until I read the above
| sentence. Having a famous programmer isn't really a great
| reason or argument to adopt yet another N + 1 web frameworks.
| Sure, some have reasons to exist but appealing to authority is
| hardly any valid reason here.
|
| Even that aside, if everyone were to adopt this by the time it
| reaches v1.0, someone will complain via writing a Medium blog-
| post and introduce another web framework on top of Redwood or
| introduce some other improvement for Redwood but as a fork of
| the project rather than a contribution back to Redwood.
|
| Here we go again.
| mojombo wrote:
| Thanks for the kind words!
|
| Redwood started as an experiment, and we'll see where it goes,
| but my intuition is that it will fill a need that many React
| developers currently have (namely: the lack of integrated
| solutions to all the technologies available in the ecosystem).
| It's certainly something that _I_ want!
| tobr wrote:
| How tightly is it tied to React? Would it make sense to try
| to use with another client side layer?
| bunsenhoneydew wrote:
| This was my first thought too. I much prefer Vue so would
| love it if you could choose the client side layer. Not
| taking anything at all away from this, it looks awesome and
| I can't wait to give it a try. I get that this is an
| opinionated framework and the effort to achieve multi
| client side options is likely pretty high. I'm also
| conscious that releasing something and have people say "I
| want it to be different" straight away is annoying so
| really trying not to be 'that guy'. Knowing the js
| community, someone is probably already working on it
| anyway. Loving the innovation in this space!
| mojombo wrote:
| Quite tightly at this point, as really nice integration is
| a primary goal. That said, it's not impossible that another
| rendering layer could be used, but it's not our focus right
| now.
| freehunter wrote:
| I appreciate the focus. React might not be everyone's
| choice but what the JS world is missing is super tight
| integration between multiple tools. We forgot everything
| Rails taught us. People who want to pick their own
| technologies already have the ability to do so today,
| what's missing is one off-the-shelf convention-over-
| configuration solution to be the Rails of JavaScript.
|
| Good luck to you guys.
| zaiste wrote:
| Congrats on the launch, Tom & the team!
|
| I'm working on something similar. I hope to pick up some ideas ;)
|
| My project is about helping create more traditional JavaScript
| applications, not necessarily JAMstack. It is inspired by the
| Self programming environment created at Sun Microsystems in '95,
| so it's not a framework per-se, but a combination of a framework,
| an editor (VS Code plugin) and (in the future) infrastructure.
|
| The project is called Huncwot:
| https://github.com/huncwotjs/huncwot
|
| * it supports TypeScript out of the box * it provides background
| processing (via Postgraphile Worker) * it aims to support _only_
| PostgreSQL, so that we could conveniently use all those beautiful
| PostgreSQL features that are usually <<hidden>> by ORMs * I 'd
| also like to make SQL more popular ;) * there is a bit of
| inspiration from Clojure * it favors the function composition,
| e.g. for handlers * it comes with a built-in
| authentication/authorization, which you shouldn't probably use in
| production just yet * it is still very alpha * for the front-end
| you can use React, but also Vue.js and possibly Angular or Svelte
| * and many other things which I haven't yet described in the
| README as I work on this on the side, mostly alone
|
| There is also fantastic Dark Lang (https://darklang.com/) in the
| same, quite similar yet different.
| mojombo wrote:
| Cool! I'll take a look and see if there are any ideas we can
| pick up from YOU! I love that so much area is being explored in
| the JS world right now.
| insomniacity wrote:
| > For now, you need to set up your own database, but we are
| working with various infrastructure providers to make this
| process simpler and more JAMstacky.
|
| I recently stepped through this tutorial, which does somthing
| similar, and uses FaunaDB - turned out pretty nicely.
|
| https://egghead.io/playlists/building-a-serverless-jamstack-...
|
| Code for the DB part is here - I know it doesn't use Prisma,
| would be great to see Redwood support this:
| https://pastebin.com/aJvFSjsa
| thedavidprice wrote:
| FaunaDB is definitely on our radar. Thanks for the link -- will
| check it out now.
| insomniacity wrote:
| Just saw your TODO list at the end of the tutorial - that
| egghead course also covers Identity, and it also works really
| well!
| ctb9 wrote:
| Could someone explain how this compares to Next.js?
| swyx wrote:
| next is primarily focused on the rendering layer, capable over
| static, server, and serverless rendering. it makes it easy to
| set up api routes but doesnt have any opinions whatsoever on
| data layer.
|
| redwood is full-stack, has an opinion on graphql/prisma as part
| of your data layer, integrated into Cells for declarative
| loading states. its still super early days but you can feasibly
| view it as doing the same thing Rails does in terms of
| organizing and picking techs for you for all parts of a stack,
| including setting up scaffolding for you.
| spamalot159 wrote:
| Congrats on the launch. Looks interesting coming from rails
| stack. I hope you guys can develop a good community around this.
| kostarelo wrote:
| Congrats on the release, you've certainly done a great job
| documenting it and creating a great webpage. Hope I will put my
| hands on it soon.
|
| One question, is the React app being pre-rendered at all before
| being stored on the CDN? If not, how does it qualifies as a
| JAMstack project? If the React app is being completely rendered
| on client side, then I don't see any difference with a regular
| Next.js (without generating a static site) project but I
| certainly see lots of differences with Gatsby for example.
| mojombo wrote:
| We are currently not doing any pre-rendering, but it's on the
| roadmap to enable pre-rendering on a route-by-route basis. Even
| so, Redwood is still JAMstack because it's JavaScript, APIs,
| and Markup; it's just that we're delivering the entire client
| via JavaScript, and the API is our entire backend. Our goal is
| to let you build a full-stack web app but still deploy in the
| JAMstack style. We're pushing the boundaries of JAMstack
| intentionally!
| chaostheory wrote:
| Typescript support? Javascript is just too hard for larger
| projects.
| mojombo wrote:
| Yes! Our intention is to support TypeScript as a first-class
| citizen in Redwood apps (while still supporting JavaScript as
| well). We're currently working to make sure all of the
| framework code is written in TypeScript.
| latchkey wrote:
| Cool. Are named routes typesafe? In other words, if I change
| the name of a route, does it cause some sort compile time
| error?
| pistoriusp wrote:
| I've created this issue to keep track of this:
| https://github.com/redwoodjs/redwood/issues/206
| [deleted]
| pistoriusp wrote:
| Nope, they're not, but you're right that they should be!
| kingpiss wrote:
| Damn this looks pretty promising.
| pistoriusp wrote:
| Thank you!
| doctorbuttes wrote:
| Really big fan of everything in this stack; I've been building my
| product on React/Apollo/Prisma/Postgres and it's been a pleasure.
| It's nice to see a well-thought-out architecture added to the
| process. Great work.
| Zaheer wrote:
| The latest update from Next.js [1] seems to cover all that
| redwoodjs does. In particular, the Static Site Generation
| portion. Next.js already supports API's in the same monorepo.
|
| [1] https://nextjs.org/blog/next-9-3
| yatsyk wrote:
| Next is limited to browsers and doesn't prescribe how you
| access data. I would compare redwood to meteor.js but not
| next.js.
| sytse wrote:
| Congrats on the release. This feels like Rails for the javascript
| age. Moving from: REST => GraphQL, Sprockets => Babel/webpack, VM
| => Lambda, Caching => Static site, ERb => React, Active Record =>
| Prisma, Rspec => Jest, routes.rb => Routes.js
|
| Edit: The twitter thread from the author is a great summary of
| Redwood and its benefits
| https://twitter.com/mojombo/status/1237441122097487873
| ljm wrote:
| I agree this is super exciting but those things come with a
| significant operational overhead that your traditional full
| stacks don't have.
|
| one vm => many lambdas/microservices
|
| react => server side rendering and state hydration, throw redux
| in there too
|
| prisma => you can't beat the DB with code. Learn SQL and remove
| the middleman.
|
| Jest => fair enough I guess, but I wouldn't use rspec when Ruby
| had minitest out of the box
|
| Caching/Static site => wut? ... wut? there's much more to
| caching than HTML.
|
| routes.js => probably great on the server, not so much on the
| browser.
|
| And the best for last...
|
| graphql => not a replacement for REST. You can do more with
| less by just making your client do the work or going with
| backend-for-frontends. If you don't understand your network
| then graphql is an easy vector for DOS (speaking from
| experience).
|
| Meanwhile I can spin up Laravel, Rails, Spring or Django up and
| get a solid application running in a fraction of the time while
| in JS land, client server arch is a seemingly unsolved problem
| mojombo wrote:
| Yes! That is precisely how we see it. Well said!
| thebradbain wrote:
| Super exciting, I've always believed a Rails-like philosophy of
| convention-over-configuration and the Javascript ideal of
| perfectly-tailored customization could supplement rather than
| compete each other. Redwood looks like a big step toward that,
| and I think it speaks to the overall growth of the Javascript
| ecosystem as a whole.
| gnalck wrote:
| Is there a plan for how backend jobs would work in this "Rails
| for the Javascript age"?
|
| I find that JAMstack is great until the need for recurring or
| out-of-band processes comes up. In Rails of course there are jobs
| that can be backed by Sidekiq or what have you, and additionally
| on a VM one can always set up a cron job to invoke some Rails
| tasks.
|
| For JAMstack there is no clear alternative, as far as I can see.
| Manually setting up a recurring lambda function (granted, I have
| not yet done it) seems to be annoying enough that I would rather
| just deal with a VM instead.
| keithwhor wrote:
| If you're interested in setting up easy scheduled functions, I
| can recommend checking out Autocode:
|
| https://autocode.stdlib.com/new/?event=scheduler.daily&event...
|
| This link will set up an automatically scheduled script /
| endpoint you can deploy in a click. Disclaimer; I built a lot
| of it. (Founder.) Warning is that there's a signup wall right
| now but it _is_ free to use. Based on feedback we might be
| removing the signup wall at some point just so more people can
| check it out.
|
| I'm previously the author of Nodal [1], a Node.js API framework
| that had quite a bit of early popularity -- we transitioned to
| building Standard Library [2] to focus on easily building APIs
| and combining them for simple backend workflows / integrations.
| Fits with JAMStack pretty well, generally, and our users aren't
| just developers; it's accessible to business users as well,
| provided they don't mind learning a little code. :)
|
| [1] https://github.com/keithwhor/nodal
|
| [2] https://stdlib.com/
| pistoriusp wrote:
| My personal hope is that your hosting provider would offer a
| solution that's configurable during deployment.
|
| Then we could undoubtedly abstract this into something and deal
| with it at deploy time.
| k__ wrote:
| As far as I know, at least GitHub actions can be triggered with
| a interval/cron.
| williamdclt wrote:
| Not using JAMstack, but I did set up recurring lambda functions
| and it's dead simple. It's a few clicks in the web console, of
| course you'll want some provisioning/deployment that's more
| solid than "click in the web console", but it's still probably
| way easier (and exposes way surface for bugs) than managing an
| entire server
| godot wrote:
| My understanding is JAM stack refers to mostly the frontend,
| being a statically generated site, and talks to server via API,
| but doesn't dictate anything about your API server or server
| side jobs, etc. You can still run serverless/lambdas, or actual
| backend API servers, or whatever else you want to do.
|
| I guess Redwood's model is a little more than JAM stack, since
| "Rails" for JS would imply it does a lot more than the JAM
| part, and that's what it looks like on the site.
| thedavidprice wrote:
| We are stretching the definition of "JAMstack" here. But the
| primarily intended emphasis is not just React+API -- it's
| making structure+design choices that target serverless
| infrastructure out of the box. It's not perfect and we have a
| ways to go, but being able to deploy fully serverless is what
| RedwoodJS is all about.
| msoad wrote:
| Kind of unrelated but love how we moved on from Docker in
| development. Most of these new frameworks are not suggesting you
| run the app in Docker.
|
| I hate docker in development!
| k__ wrote:
| How come?
| pxtail wrote:
| I'm on the opposite side - maybe thanks to Docker I got lazy or
| something but when I don't see docker (or even better - ready
| to use docker-compose file with whole required stack prepared)
| then I think I'm like 10 times less eager to give it try.
| yingw787 wrote:
| Congrats on launching! I'm super jealous of that quality landing
| page. Is it built from scratch?
| pistoriusp wrote:
| Thanks! That's https://twitter.com/cannikin 's amazing work!
| thedavidprice wrote:
| That's all @cannikin doing!! Here's his framework, opinions
| included :) https://github.com/cannikin/cameronjs
| z3t4 wrote:
| The further from the metal you are the harder it will become to
| do even the most simple of things. In this case, the code will be
| "compiled" up to ten times before it hits the metal. And every
| time some information will be lost, and unnecessary extra
| instructions will be added. / Debbie Downer
| ArchReaper wrote:
| >The further from the metal you are the harder it will become
| to do even the most simple of things
|
| >And every time some information will be lost
|
| Maybe from an embedded systems/OS point-of-view, but these
| statements are just not true on the web.
| pistoriusp wrote:
| The last time I wrote an ALU was ~4 years ago when I did NAND
| to Tetris... Whilst that was fun I can't say that it was
| simple! (:
| cfv wrote:
| While this looks great I'm having trouble fitting it to any of
| the projects I'm already working on.
|
| We already have all those pieces in place, along with the ability
| of swapping any one piece with a different one; say, if we wanted
| to go RESTful we only need to swap one block.
|
| It does look gorgeous tho; how would one go about gradually
| adopting it?
| rmetzler wrote:
| Please excuse my ignorance, what is JAMstack? I couldn't find an
| explanation on the landing page or the README.md.
| bryanrasmussen wrote:
| When I go to https://jamstack.org/ the title element is
| <title>Jamstack | JavaScript, APIs, and Markup</title>
|
| so, I guess that's good. I was afraid the M was going to be
| Meteor.
| undefined-1 wrote:
| JavaScript, APIs, and Markup.
|
| https://jamstack.org/
| nojvek wrote:
| What does the markup stand for ? I get JavaScript and Apis.
| paultannenbaum wrote:
| Markup refers to html, or the fully rendered result.
| rmetzler wrote:
| Reading about it, I realized I've built stuff like this for a
| long time. I built websites with Hugo and other static HTML
| generators before that, adding React components to make some
| pages dynamic and calling into an API for some of the user
| interaction. The simplest case of this was a contact form in
| React which posted to /api/contact, a simple Ruby server
| which sent emails.
|
| Some "dynamic" server side content was also easily included
| in a cronjob. That way I fetched the Twitter feed of a few
| accounts and rendered this into the static HTML.
|
| I did it, because it was really fast to build, could scale,
| development and deployment was easy for the HTML, etc.
|
| What I didn't had at the time was FaaS and I think the
| architecture could benefit from this. I had Docker containers
| running the API and the reverse proxy needed to do some
| routing, so I still had a server running, but I didn't need a
| database. I had to teach the marketing department how to
| write Markdown in GitLab editors, though.
___________________________________________________________________
(page generated 2020-03-10 23:00 UTC)