from Hacker News

Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack

by mojombo on 3/10/20, 6:13 PM with 167 comments

  • by sytse on 3/10/20, 7:27 PM

    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

  • by mhd on 3/11/20, 8:13 AM

    I'm still not sure that those entry-level frameworks using GraphQL aren't repeating Rails' ActiveRecord issues when it comes to more complex data relationships. Both work alright for "blog post" and "user" entities, but become a bit awkward when it comes to even basic CRM-type examples (contact/company/address/junctions). I know that Facebook is using this at scale, but that's a whole different issue, with lots of custom optimizations and special backends.

    I've heard GraphQL proponents call joins "premature optimization", and I don't even know how to respond to that…

  • by mojombo on 3/10/20, 6:24 PM

    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!

  • by zaiste on 3/10/20, 8:08 PM

    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.

  • by Zaheer on 3/10/20, 6:59 PM

    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

  • by yatsyk on 3/10/20, 9:22 PM

    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.

  • by jaredcwhite on 3/10/20, 6:53 PM

    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.

  • by davedx on 3/11/20, 8:35 AM

    Just want to chime in that I think this looks very promising but I would really want to see full TypeScript support before I picked it up. In particular what would be a killer feature for me would be sharing model types between api and web sides. This is something currently possible (using e.g. lerna) but not trivial to setup for my smaller projects, and if it was a feature of Redwood I'd seriously considering switching my tech stack for future and possibly current projects.

    Will be watching it with great interest. Good luck!

  • by tehin on 3/11/20, 3:44 AM

    While prisma2 is probably the best node ORM, it still has a lot of issues. It seems to take a lot of inspiration from the mongo api, which is a good idea, as that is the one thing mongo got right. There are a bunch of issues with it though:

    It should be closer to the mongo api.

      await prisma.users.findOne({ where: { id: 1 } })
    should just be

      await prisma.users.findOne({ id: 1 })
    for example.

    It is trying to do too much. There is a hard limit of where ORMs try to take over too many of the things you do in SQL and become slow and complex and a big black hole. prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.

    Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests. You have to look through your entire function to understand which fields are inside and outside of the scope of the query, and add more includes or whatever.

    There are security issues with ORMs that traverse and save relationships, as github itself found out. You add user__roles form field maliciously on the client side to a form that was just supposed to update the user and not the roles, then suddenly you find your user.save() method on the server-side has traversed and added new roles to a user.

    I am writing a kind of orm today based on the mongo api without all the $ signs, much like prisma, but closer and without all the additional things. github username is thebinarysearchtree.

    ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.

  • by rmetzler on 3/10/20, 8:18 PM

    Please excuse my ignorance, what is JAMstack? I couldn't find an explanation on the landing page or the README.md.

  • by swyx on 3/10/20, 6:19 PM

    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-...

  • by gnalck on 3/10/20, 7:52 PM

    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.

  • by chvid on 3/11/20, 6:18 AM

    Great presentation.

    I took a look at the example:

    https://github.com/redwoodjs/example-blog

    As I understand "JAM Stack" the point of the M is to have large chunks of your application pre-rendered.

    However in this example; the blog pages are client-side rendered based on a graphql query that goes into postgres database.

    Am I missing the point of this? It looks like a standard rich-client with API backend architecture.

  • by miguelmota on 3/11/20, 12:34 AM

    Surprised to see it not written in TypeScript since TS helps immensely with large projects

    https://github.com/redwoodjs/redwood

  • by chaostheory on 3/10/20, 6:33 PM

    Typescript support? Javascript is just too hard for larger projects.

  • by sandGorgon on 3/11/20, 8:21 AM

  • by larrywright on 3/11/20, 3:56 PM

    I think this looks interesting, and I applaud the team.

    That said... am I the only one that thinks that anything that is JS based seems ridiculously complicated to use? I don’t do much UI work, but any time I look at using react or similar it feels like there are a lot of moving parts and a lot of steps to perform before you can even get started on something useful.

  • by beardedman on 3/11/20, 7:21 AM

    Nice!

    Building any "Rails for JS" idea is a huge undertaking, purely from the sheer scope of the Javascript (inc. NodeJS) ecosystem.

  • by spamalot159 on 3/10/20, 9:29 PM

    Congrats on the launch. Looks interesting coming from rails stack. I hope you guys can develop a good community around this.

  • by frequentnapper on 3/11/20, 5:17 AM

    hi, just reading through the tutorial and want to say, it's quite enjoyable and beautiful to read. Personally I feel and many would agree that docs and tutorials deserve equal if not more effort for tools that are aimed at making our lives easier. Please keep making the docs stronger.

  • by insomniacity on 3/10/20, 7:47 PM

    > 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

  • by chrysoprace on 3/11/20, 5:09 AM

    Glad to see more batteries-included solutions to frontend development. In particular, I'm glad to see you've addressed a lot of the pain points with building a fullstack application with React: Forms, lack of "laravel artisan-like" CLI generators, integrating GraphQL (and picking between one of the many server and client-side libraries/frameworks).

    I only had time for a brief look through it but searching for "redux" and "state" didn't bring up anything; do you have an opinionated approach to global state management?

    Keen to check this out when I have more time this week!

  • by cies on 3/10/20, 11:24 PM

    Nice work! And a good project page. One thing: there's a concept used but not introduced, which, at least to me, does not ring a bell... What's "SDL" in the context of Redwood?

  • by kostarelo on 3/10/20, 9:03 PM

    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.

  • by Etheryte on 3/11/20, 9:58 AM

    This is incredibly ambitious: every subheading on the landing page, such as form validation & handling, routing, service logic, is enough to have many big libraries already working on the problem. Yet here's this thing that says here it's all wrapped up in one solution. Historically, Vue has more than demonstrated that well opinionated whole solutions can be very popular on the frontend too so it's interesting to follow where Redwood will end up.

  • by msoad on 3/10/20, 8:16 PM

    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!

  • by cfv on 3/10/20, 10:52 PM

    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?

  • by z3t4 on 3/10/20, 8:41 PM

    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

  • by sodez117 on 3/21/20, 6:08 AM

    This look great. How does this compare to other JS fullstack frameworks like Vulcan.js, Meteor or Keystone?

  • by vvoyer on 3/11/20, 6:28 AM

    Nice to see the JS ecosystem taking this route: fullstack frameworks.

    Just like Next.js was built for zeit/now, redwood was built for Netlify.

    Since Top Prester-Werner (Author) is in the board of Netlify this makes sense. But is it a good idea for frameworks to be tied to specific deployment platforms? Unsure, we’ll see!

  • by jcarlosweb on 3/11/20, 7:54 PM

    Congratulations, but I don't think I'll use it, I don't like being forced to use GraphQL

  • by yingw787 on 3/10/20, 8:41 PM

    Congrats on launching! I'm super jealous of that quality landing page. Is it built from scratch?

  • by doctorbuttes on 3/10/20, 8:11 PM

    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.

  • by kingpiss on 3/10/20, 9:30 PM

    Damn this looks pretty promising.

  • by wmichelin on 3/10/20, 9:45 PM

    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.

  • by jaequery on 3/10/20, 11:03 PM

    This is really great. Node.js really needs more of these type of frameworks. I for one would love a non-Graphql version.

  • by thegagne on 3/11/20, 1:05 AM

    Will this work with Cloudflare Workers?

  • by siquick on 3/11/20, 1:02 AM

    This does look great compared to previos efforts like Sails. Is there support SSR out of the box?

  • by ctb9 on 3/10/20, 6:54 PM

    Could someone explain how this compares to Next.js?

  • by harryadelb on 3/11/20, 2:21 PM

    hey guys, ever heard of meteor.js? It's pretty cool too! https://github.com/meteor/meteor https://www.meteor.com/

  • by LessDmesg on 3/11/20, 7:04 AM

    > JavaScript

    No thanks, we have Blazor now.