14 ms·

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

431 points by mojombo 7y ago

siquick 7y ago
This does look great compared to previos efforts like Sails. Is there support SSR out of the box?
- mojombo 7y ago
  Not currently, and we will prefer pre-rendering to SSR if we can make it work well enough. But we are planning to address SEO concerns.
  - siquick 7y ago
    Great stuff - looking forward to exploring this properly.
jaredcwhite 7y ago
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.
- mojombo 7y ago
  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 7y ago
    How tightly is it tied to React? Would it make sense to try to use with another client side layer?
    - mojombo 7y ago
      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 7y ago
        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.
    - bunsenhoneydew 7y ago
      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!
- rvz 7y ago
  > 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.
  - AlchemistCamp 7y ago
    > appealing to authority is hardly any valid reason here It's about competence. Would you not have increased confidence in an NBA team after hearing Stephen Curry had joined it after the previous season? I think you'd be highly irrational not to.
    - dfee 7y ago
      For better or worse (or better in this case, I believe), I don’t know the famous dude. I won’t tell you my bonafides, either. If you’ve got someone with a particular skill set joining your project, that’s great that you’ve got strong, additional perspective in that domain. However, this isn’t a sixty minute game, and no one is getting paid millions to hit a game winning shot. This is open source software. I hope as an industry we learn to drop the theatrics and recognize our unique way of bringing value to whichever projects we contribute to.
      - AlchemistCamp 7y ago
        > This is open source software. Well, he made Gravatar, Jekyll, TOML and quite a few other open source things I've used. Accuse me of "theatrics" if you like, but I am in fact inclined to check out projects made by people who have made other things I like. I also read books written by people who have written other books I like. I watch movies with directors and actors from other movies I like, too! It's not a sure-fire guarantee I'll like the next thing but odds are considerably improved. Not updating my priors when learning of their involvement would be ridiculous.
- joekrill 7y ago
  > At first I thought "oh great, this looks very nice but why does it exist when Next.js, Gatsby, etc. are already a thing?" I honestly will never understand why people say things like this. As though there's no room for progress. As though there aren't alternatives that may or may not be better. Imagine if the folks building React thought "ya know, we got Angular, so why are we doing this?"... Or any of the many, many other similar scenarios. It's how we make progress.
swyx 7y ago
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-distros-should-exist https://www.swyx.io/writing/react-distros/#what-other-react-...
- pistoriusp 7y ago
  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 7y ago
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!
- dmead 7y ago
  why do so many JS frameworks exist?
  - mojombo 7y ago
    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.
  - pistoriusp 7y ago
    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.
  - manigandham 7y ago
    Because JS has no standard library and was originally a very light scripting language designed in a few days and used for browser coding. It has evolved very rapidly as the web grew and these frameworks are a natural outcome of everyone trying to create some order from the chaos and figure out a proper architecture and way to do things. The good news is you have lots of choices and it runs everywhere. Bad news is the sprawling mess you have to go through to find the good stuff.
- ordinaryradical 7y ago
  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?
chaostheory 7y ago
Typescript support? Javascript is just too hard for larger projects.
- mojombo 7y ago
  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 7y ago
    Cool. Are named routes typesafe? In other words, if I change the name of a route, does it cause some sort compile time error?
    - deleted 7y ago
      [deleted]
    - pistoriusp 7y ago
      Nope, they're not, but you're right that they should be!
    - pistoriusp 7y ago
      I've created this issue to keep track of this: https://github.com/redwoodjs/redwood/issues/206 https://github.com/redwoodjs/redwood/issues/206
  - lets-surf 7y ago
    Very happy to hear TypeScript support is included! I wouldn't like to work on a large app without it.
  - sibeliuss 7y ago
    Gatsby is doing a full rewrite in TS https://github.com/gatsbyjs/gatsby/issues/21995 https://github.com/gatsbyjs/gatsby/issues/21995 -- all roads very sanely lead to TypeScript these days.
ctb9 7y ago
Could someone explain how this compares to Next.js?
- swyx 7y ago
  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.
Zaheer 7y ago
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 https://nextjs.org/blog/next-9-3
- yatsyk 7y ago
  Next is limited to browsers and doesn't prescribe how you access data. I would compare redwood to meteor.js but not next.js.
  - leerob 7y ago
    Is Redwood _not_ limited to browsers?
    - thedavidprice 7y ago
      Correct. One API. But chose the client (or as many) that you want.
      - mojombo 7y ago
        Like David said, we currently only help you build a web frontend, but we intend to eventually make it super nice to build a mobile app, desktop client, CLI, etc. All under the redwood umbrella (canopy?).
        tekknik 7y ago
        KISS / Single responsibility
- leerob 7y ago
  The difference is that Next.js is very unopinionated. GraphQL, Prisma, SQL – these are opinionated choices from Redwood and largely the point of the framework.
sytse 7y ago
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 https://twitter.com/mojombo/status/1237441122097487873
- mojombo 7y ago
  Yes! That is precisely how we see it. Well said!
- thebradbain 7y ago
  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.
  - cknoxrun 7y ago
    I feel as if Rails plus a progressive framework such as Vue.js is essentially what you are talking about?
    - thebradbain 7y ago
      Yeah, almost. That's essentially my current preferred stack already. But "almost" is the key word: sometimes there seems to be some overlapping duplication of functionality, if not necessarily code, and the handoff between Rails-world and Vue-land is still a kind of purgatory which can be solved and navigated with experience and knowledge of the ins-ands-outs of both frameworks / webpack / package management / etc., but it'd be _nice_ if all those options were solved in the first place, rather than having to work to cleanly and sustainably get two frameworks to talk to each other nicely.
- ljm 7y ago
insomniacity 7y ago
> 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-todo-app-with-netlify-gatsby-graphql-and-faunadb-53bb 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 https://pastebin.com/aJvFSjsa
- thedavidprice 7y ago
  FaunaDB is definitely on our radar. Thanks for the link -- will check it out now.
  - insomniacity 7y ago
    Just saw your TODO list at the end of the tutorial - that egghead course also covers Identity, and it also works really well!
gnalck 7y ago
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 7y ago
  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.time=09%3A00%20(9%3A00am)&event.timezone=America%20%E2%80%94%20Los%20Angeles%2FSan%20Francisco%2C%20US%20(-08%3A00%2C%20-07%3A00%20DST) 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 https://github.com/keithwhor/nodal [2] https://stdlib.com/ https://stdlib.com/
- k__ 7y ago
  As far as I know, at least GitHub actions can be triggered with a interval/cron.
- williamdclt 7y ago
  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
zaiste 7y ago
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 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/ https://darklang.com/) in the same, quite similar yet different.
- mojombo 7y ago
  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.
- techpeace 7y ago
  Just checked Huncwot out - looks like a great project, thanks! And congrats to mojombo and team! You probably already use something Tom wrote without realizing it.
doctorbuttes 7y ago
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.
msoad 7y ago
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__ 7y ago
  How come?
- pxtail 7y ago
  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.
- cies 7y ago
  > Most of these new frameworks are not suggesting you run the app in Docker. Not suggesting? Or suggesting not to? Also: I'm not sure what you are trying to say here, what FWs are you referring to?
rmetzler 7y ago
Please excuse my ignorance, what is JAMstack? I couldn't find an explanation on the landing page or the README.md.
- undefined-1 7y ago
  JavaScript, APIs, and Markup. https://jamstack.org/ https://jamstack.org/
  - nojvek 7y ago
    What does the markup stand for ? I get JavaScript and Apis.
    - paultannenbaum 7y ago
      Markup refers to html, or the fully rendered result.
    - camillovisini 7y ago
      HTML
  - rmetzler 7y ago
    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.
- 7y ago
yingw787 7y ago
Congrats on launching! I'm super jealous of that quality landing page. Is it built from scratch?
- pistoriusp 7y ago
  Thanks! That's https://twitter.com/cannikin https://twitter.com/cannikin 's amazing work!
- thedavidprice 7y ago
  That's all @cannikin doing!! Here's his framework, opinions included :) https://github.com/cannikin/cameronjs https://github.com/cannikin/cameronjs
z3t4 7y ago
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
- pistoriusp 7y ago
  The last time I wrote an ALU was ~4 years ago when I did NAND to Tetris and whilst that was fun I can't say that it was simple! (:
- ArchReaper 7y ago
  >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.
kostarelo 7y ago
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 7y ago
  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!
yatsyk 7y ago
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.
- dpacmittal 7y ago
  Because react killed it and by the time meteor switched to react from blaze lot of people had moved on.
  - TooCleverByHalf 7y ago
    If I remember correctly, React was only part of it. Lack of support for relational databases was a big issue as well. On top of that, people realized that they didn't need real time functionality and the overhead (and scaling) of mini-mongo et al was a difficult venture. Take with a grain of salt. This was all very long ago so my memory may not be accurate.
spamalot159 7y ago
Congrats on the launch. Looks interesting coming from rails stack. I hope you guys can develop a good community around this.
kingpiss 7y ago
Damn this looks pretty promising.
- pistoriusp 7y ago
  Thank you!
wmichelin 7y ago
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.
cfv 7y ago
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?
- mojombo 7y ago
  As a fully integrated framework solution, it may be hard to gradually adopt Redwood, and that's ok. If you already have a setup you like, and it gives you the flexibility that you need, then that's awesome! I want Redwood to be around for the majority of devs that don't already have a sweet setup going, and are lamenting the endless hours of choosing, setup, and integration ahead of them just to get something started.
  - cfv 7y ago
    First things first, thank you very much for the fast response! It's very true that all the prepwork is pretty costly, hence my eagerness to try and adopt random bits and pieces even at this stage; it might end up saving us time down the line haha While I have you around... what would be a good toy to build with this? Our megalithic, business rules heavy app sounds like a potential good fit for the Redwood, but it's entirely too large a bite to tease our engineering leads with.
jaequery 7y ago
This is really great. Node.js really needs more of these type of frameworks. I for one would love a non-Graphql version.
- mojombo 7y ago
  Thanks! What would you use instead of GraphQL? Curious what your specific needs are.
  - iamEAP 7y ago
    I'm personally in the same boat (and use a philosophically similar JS-based framework called SailsJS instead, right now) For me: I need services that support the UI, as well as a public-facing API with basically the same data. I don't have the time/resources to build/maintain them separately, and my perception is that GraphQL and the wider ecosystem around it haven't yet reached the same level of ubiquity/maturity as plain-old REST. A single, well-designed REST API that can be consumed by my own UI as well as public clients is how I'd prefer to handle it right now.
    - Rapzid 7y ago
      Would have to agree. GraphQL is kind of a non-starter for every project I've worked on in the past few years, and a GraphQL ONLY framework is right out.
cies 7y ago
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?
- mojombo 7y ago
  That’s the Schema Definition Language native to GraphQL.
  - cies 7y ago
    Ah. Thanks for clarifying, maybe im not the only one a little confused. I'd call 'm "GraphQL schemas (SDL)" on the landing page to avoid confusion for some visitors.
miguelmota 7y ago
Surprised to see it not written in TypeScript since TS helps immensely with large projects https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood
- mtm7 7y ago
  > "We are working on full end-to-end TypeScript support for Redwood, all they way from the DB schema definition to the frontend and back via GraphQL. It's in the works!" - Tom Preston-Werner (https://twitter.com/mojombo/status/1237474978825564162 https://twitter.com/mojombo/status/1237474978825564162)
thegagne 7y ago
Will this work with Cloudflare Workers?
- mojombo 7y ago
  Unfortunately, no. Cloudflare workers are heavily restricted in what they can do, both from an outbound request and compute time perspective. If those restrictions are reduced, it’s possible we could make it work someday. It sure would be awesome!
tehin 7y ago
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.
- sbr464 7y ago
  I didn't see your project on the github user profile you mentioned? Was curious.
- nikolasburk 7y ago
  Nikolas from the Prisma team here! > It seems to take a lot of inspiration from the mongo api That's an interesting comment but I'm not sure it's quite accurate. I think where we're taking quite a bit of inspiration from MongoDB is the idea of "thinking in objects" because this is much closer to the mental model developers have when they work with data. We are currently already working on an improved API of Prisma Client [1] that looks less like MongoDB but should feel a lot more ergonomic. Regarding your example of removing the `where` from a `findOne` call. In this case it's needed because you can also select/include [2] fields and/or relations: await prisma.users.findOne({ where: { id: 1 }, include: { posts: true } }) But we're aware that the API is quite verbose at times, so we're already working on slimming it down. Here's the proposal from the new API spec: await prisma.users.findOne(1).load({ include: { posts: true } }) > 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. I just want to stress that Prisma is not an ORM! ORMs are characterized by the fact that classes are mapped to tables and you have complex model instances that carry logic for storage, retrieval, serialization, deserialization and often custom business logic. Prisma does none of that! It provides an auto-generated and fully type-safe database client that's tailored to your database schema. Any data you'll ever retrieve is fully typed and comes in the form of plain old JS objects that a are easy to reason about. > prisma tries to do migrations, table creation, etc, etc. These things rarely work properly. I'd love to learn more about where you think Prisma's migrations approach falls short! IMHO moving towards a dclarative migration system based on an intuitive data modelling language is much closer to how developers are thinking about their data than using SQL migrations. One of our users once described it like this: "What Prisma does for migrations is essentially what React does for rendering. A user need only describe the current state, but not the operations to get to that state. So, thank you for doing this to databases as React (and others) has for UIs!" > 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. Do you mind elaborating how/where you see this problem happening in Prisma? > There are security issues with ORMs that traverse and save relationships, as github itself found out. Again, Prisma is not an ORM and I have a hard time seeing how this applies to it. > 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. I fully agree with this poinit and it's one of the core desiign goals of Prisma. If you feel Prisma doesn't achieve this, we're doing something wrong... All that being said, I really appreciate your thoughts and feedback and would love to see you in the Prisma Slack [3] and sharing your thoughts in our GitHub issues. [1] https://github.com/prisma/specs/issues/356 https://github.com/prisma/specs/issues/356 [2] https://github.com/prisma/prisma2/blob/master/docs/prisma-client-js/api.md#field-selection https://github.com/prisma/prisma2/blob/master/docs/prisma-cl... [3] https://slack.prisma.io https://slack.prisma.io
chrysoprace 7y ago
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!
frequentnapper 7y ago
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.
- mojombo 7y ago
  Thanks for noticing our hard work! We spent a LOT of time making sure the tutorial was rock solid and very clear. We will continue investing time into making the tutorial and our docs even better!
chvid 7y ago
Great presentation. I took a look at the example: https://github.com/redwoodjs/example-blog 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.
- mojombo 7y ago
  Your understanding is accurate. We do plan to support pre-rendering on a route-by-route basis, which will perhaps be more inline with what JAMstack tends to mean today. But Redwood is still all about JavaScript (client) and APIs (backend), with markup to follow, as I just mentioned. But more than that, it's about the development and deployment philosophy of JAMstack that we fully embrace.
vvoyer 7y ago
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!
- mojombo 7y ago
  While Redwood is currently optimized for deployment on Netlify, it is by no means restricted to that environment. Our intention is for Redwood apps to be deployable to a variety of JAMstack providers in addition to traditional serverful setups. My main interest is in providing an integrated, joy-inducing experience for app developers that want to leverage the full awesomeness of modern JavaScript and friends. It's true that if Netlify wins, I win too, but I'd rather DEVELOPERS win, and that's what keeps me motivated.
  - vvoyer 7y ago
    Thanks for the honest answer here!
LessDmesg 7y ago
> JavaScript No thanks, we have Blazor now.
beardedman 7y ago
Nice! Building any "Rails for JS" idea is a huge undertaking, purely from the sheer scope of the Javascript (inc. NodeJS) ecosystem.
mhd 7y ago
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…
- ralusek 7y ago
  Same, am I the only person that uses inner/right joins? A lot of times I'm not doing it in order to minimize subsequent calls, but rather because the logic of my query depends on being able to do a join. Obviously my understanding is that at Facebook-scale you're not really able to have the luxury of joins, and have to accomplish your query logic in other ways...but that strikes me as joins being something you have to relinquish if necessary, rather than being a premature optimization.
- crubier 7y ago
  Prisma is definitely limited when it comes to advanced use cases. I have been using it for two years and we are now moving to postgraphile because of this. And Prisma 2 doesn’t help, it makes it worse.
  - hokumguru 7y ago
    TBF, Prisma2 also includes a sql breakout that allows you to run whatever Postgres-flavor sql you want in your code.
    - crubier 7y ago
      Yes, Prisma allows you to run hand crafted SQL queries. That’s is the bare minimum I would expect from it. Graphile on the other hand allows you to do this AND to systematically generate whole classes of such requests, through plugins.
- 7y ago
sandGorgon 7y ago
this is very interesting. nextjs gives a lot of this : for example - frontend and backend in the same code https://nextjs.org/docs/api-routes/introduction https://nextjs.org/docs/api-routes/introduction - graphql based - https://github.com/zeit/next.js/tree/canary/examples/api-routes-apollo-server-and-client-auth https://github.com/zeit/next.js/tree/canary/examples/api-rou... - hybrid static page support - https://nextjs.org/blog/next-9-3#next-gen-static-site-generation-ssg-support https://nextjs.org/blog/next-9-3#next-gen-static-site-genera... - jest - https://github.com/zeit/next.js/tree/canary/examples/with-jest https://github.com/zeit/next.js/tree/canary/examples/with-je... - CMS providers - https://nextjs.org/blog/next-9-3#collaboration-with-cms-providers https://nextjs.org/blog/next-9-3#collaboration-with-cms-prov... - pretty url routing - https://github.com/zeit/next.js/tree/canary/examples/with-pretty-url-routing https://github.com/zeit/next.js/tree/canary/examples/with-pr...
davedx 7y ago
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!
- rienbdj 7y ago
  This is pretty easy to do with yarn workspaces
- pistoriusp 7y ago
  Thanks! We'll definitely support Typescript, we're almost there and will make the experience feel amazing. The boundary between the API and WEB sides is GraphQL and we're looking at making the schema typing available on the WEB side. We're using yarn workspaces!
Etheryte 7y ago
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.
- pistoriusp 7y ago
  Thanks, sometimes I need to take a step back and realize the scale of what we're building! Thankfully, we're building on the backs of giants here. We're glueing a bunch of the technology together in a way that makes it feel idiomatic, documenting it and asserting our opinions on how to use it.
harryadelb 7y ago
hey guys, ever heard of meteor.js? It's pretty cool too! https://github.com/meteor/meteor https://github.com/meteor/meteor https://www.meteor.com/ https://www.meteor.com/
larrywright 7y ago
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.
- brailsafe 7y ago
  I currently work on a codebase that is in part React based, and I have no idea how to get it running from scratch or how data flows through. It seems asinine.
- robertakarobin 7y ago
  Eh, I feel like that's any web framework in any language. Take Django for instance. If you're doing a very boilerplate project, then it's pretty slick. But as soon as you start trying to do any customization you go down a rabbithole of subclasses and mixins, where looking at the source is usually more helpful than the documentation. I think the reality is web applications stand on the shoulders of lots of giants. We're only able to get anything done thanks to abstraction that someone else did for us. We still have a need to see below the surface occasionally, though, and finding the balance between readability and customizability is an eternal struggle. Plus, everyone has their preferences: I hated Angular at first because of its steep learning curve, and now love it for its strictness.
  - larrywright 7y ago
    I guess my feeling comes from spending time with opinionated frameworks like Rails. There are sane defaults and you’re up and running quickly. Any time I look at something like React or similar, the instructions for getting started are written like “If you’re using yarn, do this. If you’re using grunt, do this other thing”. I don’t have either, so now I have to choose one before I can proceed. Instead, I just close the browser tab and go on to something else.
jcarlosweb 7y ago
Congratulations, but I don't think I'll use it, I don't like being forced to use GraphQL
sodez117 7y ago
This look great. How does this compare to other JS fullstack frameworks like Vulcan.js, Meteor or Keystone?

431 points by mojombo 7y ago

siquick 7y ago

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

mojombo 7y ago
Not currently, and we will prefer pre-rendering to SSR if we can make it work well enough. But we are planning to address SEO concerns.
- siquick 7y ago
  Great stuff - looking forward to exploring this properly.

jaredcwhite 7y ago

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.

mojombo 7y ago
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 7y ago
  How tightly is it tied to React? Would it make sense to try to use with another client side layer?
  - mojombo 7y ago
    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 7y ago
      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.
  - bunsenhoneydew 7y ago
    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!
rvz 7y ago
> 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.
- AlchemistCamp 7y ago
  > appealing to authority is hardly any valid reason here It's about competence. Would you not have increased confidence in an NBA team after hearing Stephen Curry had joined it after the previous season? I think you'd be highly irrational not to.
  - dfee 7y ago
    For better or worse (or better in this case, I believe), I don’t know the famous dude. I won’t tell you my bonafides, either. If you’ve got someone with a particular skill set joining your project, that’s great that you’ve got strong, additional perspective in that domain. However, this isn’t a sixty minute game, and no one is getting paid millions to hit a game winning shot. This is open source software. I hope as an industry we learn to drop the theatrics and recognize our unique way of bringing value to whichever projects we contribute to.
    - AlchemistCamp 7y ago
      > This is open source software. Well, he made Gravatar, Jekyll, TOML and quite a few other open source things I've used. Accuse me of "theatrics" if you like, but I am in fact inclined to check out projects made by people who have made other things I like. I also read books written by people who have written other books I like. I watch movies with directors and actors from other movies I like, too! It's not a sure-fire guarantee I'll like the next thing but odds are considerably improved. Not updating my priors when learning of their involvement would be ridiculous.
joekrill 7y ago
> At first I thought "oh great, this looks very nice but why does it exist when Next.js, Gatsby, etc. are already a thing?" I honestly will never understand why people say things like this. As though there's no room for progress. As though there aren't alternatives that may or may not be better. Imagine if the folks building React thought "ya know, we got Angular, so why are we doing this?"... Or any of the many, many other similar scenarios. It's how we make progress.

swyx 7y ago

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-distros-should-exist https://www.swyx.io/writing/react-distros/#what-other-react-...

pistoriusp 7y ago
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 7y ago

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!

dmead 7y ago
why do so many JS frameworks exist?
- mojombo 7y ago
  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.
- pistoriusp 7y ago
  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.
- manigandham 7y ago
  Because JS has no standard library and was originally a very light scripting language designed in a few days and used for browser coding. It has evolved very rapidly as the web grew and these frameworks are a natural outcome of everyone trying to create some order from the chaos and figure out a proper architecture and way to do things. The good news is you have lots of choices and it runs everywhere. Bad news is the sprawling mess you have to go through to find the good stuff.
ordinaryradical 7y ago
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?

chaostheory 7y ago

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

mojombo 7y ago
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 7y ago
  Cool. Are named routes typesafe? In other words, if I change the name of a route, does it cause some sort compile time error?
  - deleted 7y ago
    [deleted]
  - pistoriusp 7y ago
    Nope, they're not, but you're right that they should be!
  - pistoriusp 7y ago
    I've created this issue to keep track of this: https://github.com/redwoodjs/redwood/issues/206 https://github.com/redwoodjs/redwood/issues/206
- lets-surf 7y ago
  Very happy to hear TypeScript support is included! I wouldn't like to work on a large app without it.
- sibeliuss 7y ago
  Gatsby is doing a full rewrite in TS https://github.com/gatsbyjs/gatsby/issues/21995 https://github.com/gatsbyjs/gatsby/issues/21995 -- all roads very sanely lead to TypeScript these days.

ctb9 7y ago

Could someone explain how this compares to Next.js?

swyx 7y ago
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.

Zaheer 7y ago

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 https://nextjs.org/blog/next-9-3

yatsyk 7y ago
Next is limited to browsers and doesn't prescribe how you access data. I would compare redwood to meteor.js but not next.js.
- leerob 7y ago
  Is Redwood _not_ limited to browsers?
  - thedavidprice 7y ago
    Correct. One API. But chose the client (or as many) that you want.
    - mojombo 7y ago
      Like David said, we currently only help you build a web frontend, but we intend to eventually make it super nice to build a mobile app, desktop client, CLI, etc. All under the redwood umbrella (canopy?).
      - tekknik 7y ago
        KISS / Single responsibility
leerob 7y ago
The difference is that Next.js is very unopinionated. GraphQL, Prisma, SQL – these are opinionated choices from Redwood and largely the point of the framework.

sytse 7y ago

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 https://twitter.com/mojombo/status/1237441122097487873

mojombo 7y ago
Yes! That is precisely how we see it. Well said!
thebradbain 7y ago
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.
- cknoxrun 7y ago
  I feel as if Rails plus a progressive framework such as Vue.js is essentially what you are talking about?
  - thebradbain 7y ago
    Yeah, almost. That's essentially my current preferred stack already. But "almost" is the key word: sometimes there seems to be some overlapping duplication of functionality, if not necessarily code, and the handoff between Rails-world and Vue-land is still a kind of purgatory which can be solved and navigated with experience and knowledge of the ins-ands-outs of both frameworks / webpack / package management / etc., but it'd be _nice_ if all those options were solved in the first place, rather than having to work to cleanly and sustainably get two frameworks to talk to each other nicely.
ljm 7y ago

insomniacity 7y ago

> 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-todo-app-with-netlify-gatsby-graphql-and-faunadb-53bb 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 https://pastebin.com/aJvFSjsa

thedavidprice 7y ago
FaunaDB is definitely on our radar. Thanks for the link -- will check it out now.
- insomniacity 7y ago
  Just saw your TODO list at the end of the tutorial - that egghead course also covers Identity, and it also works really well!

gnalck 7y ago

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 7y ago
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.time=09%3A00%20(9%3A00am)&event.timezone=America%20%E2%80%94%20Los%20Angeles%2FSan%20Francisco%2C%20US%20(-08%3A00%2C%20-07%3A00%20DST) 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 https://github.com/keithwhor/nodal [2] https://stdlib.com/ https://stdlib.com/
k__ 7y ago
As far as I know, at least GitHub actions can be triggered with a interval/cron.
williamdclt 7y ago
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

zaiste 7y ago

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 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/ https://darklang.com/) in the same, quite similar yet different.

mojombo 7y ago
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.
techpeace 7y ago
Just checked Huncwot out - looks like a great project, thanks! And congrats to mojombo and team! You probably already use something Tom wrote without realizing it.

doctorbuttes 7y ago

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.

msoad 7y ago

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__ 7y ago
How come?
pxtail 7y ago
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.
cies 7y ago
> Most of these new frameworks are not suggesting you run the app in Docker. Not suggesting? Or suggesting not to? Also: I'm not sure what you are trying to say here, what FWs are you referring to?

rmetzler 7y ago

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

undefined-1 7y ago
JavaScript, APIs, and Markup. https://jamstack.org/ https://jamstack.org/
- nojvek 7y ago
  What does the markup stand for ? I get JavaScript and Apis.
  - paultannenbaum 7y ago
    Markup refers to html, or the fully rendered result.
  - camillovisini 7y ago
    HTML
- rmetzler 7y ago
  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.
7y ago

yingw787 7y ago

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

pistoriusp 7y ago
Thanks! That's https://twitter.com/cannikin https://twitter.com/cannikin 's amazing work!
thedavidprice 7y ago
That's all @cannikin doing!! Here's his framework, opinions included :) https://github.com/cannikin/cameronjs https://github.com/cannikin/cameronjs

z3t4 7y ago

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

pistoriusp 7y ago
The last time I wrote an ALU was ~4 years ago when I did NAND to Tetris and whilst that was fun I can't say that it was simple! (:
ArchReaper 7y ago
>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.

kostarelo 7y ago

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 7y ago
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!

yatsyk 7y ago

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.

dpacmittal 7y ago
Because react killed it and by the time meteor switched to react from blaze lot of people had moved on.
- TooCleverByHalf 7y ago
  If I remember correctly, React was only part of it. Lack of support for relational databases was a big issue as well. On top of that, people realized that they didn't need real time functionality and the overhead (and scaling) of mini-mongo et al was a difficult venture. Take with a grain of salt. This was all very long ago so my memory may not be accurate.

spamalot159 7y ago

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

kingpiss 7y ago

Damn this looks pretty promising.

pistoriusp 7y ago
Thank you!

wmichelin 7y ago

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.

cfv 7y ago

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?

mojombo 7y ago
As a fully integrated framework solution, it may be hard to gradually adopt Redwood, and that's ok. If you already have a setup you like, and it gives you the flexibility that you need, then that's awesome! I want Redwood to be around for the majority of devs that don't already have a sweet setup going, and are lamenting the endless hours of choosing, setup, and integration ahead of them just to get something started.
- cfv 7y ago
  First things first, thank you very much for the fast response! It's very true that all the prepwork is pretty costly, hence my eagerness to try and adopt random bits and pieces even at this stage; it might end up saving us time down the line haha While I have you around... what would be a good toy to build with this? Our megalithic, business rules heavy app sounds like a potential good fit for the Redwood, but it's entirely too large a bite to tease our engineering leads with.

jaequery 7y ago

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

mojombo 7y ago
Thanks! What would you use instead of GraphQL? Curious what your specific needs are.
- iamEAP 7y ago
  I'm personally in the same boat (and use a philosophically similar JS-based framework called SailsJS instead, right now) For me: I need services that support the UI, as well as a public-facing API with basically the same data. I don't have the time/resources to build/maintain them separately, and my perception is that GraphQL and the wider ecosystem around it haven't yet reached the same level of ubiquity/maturity as plain-old REST. A single, well-designed REST API that can be consumed by my own UI as well as public clients is how I'd prefer to handle it right now.
  - Rapzid 7y ago
    Would have to agree. GraphQL is kind of a non-starter for every project I've worked on in the past few years, and a GraphQL ONLY framework is right out.

cies 7y ago

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?

mojombo 7y ago
That’s the Schema Definition Language native to GraphQL.
- cies 7y ago
  Ah. Thanks for clarifying, maybe im not the only one a little confused. I'd call 'm "GraphQL schemas (SDL)" on the landing page to avoid confusion for some visitors.

miguelmota 7y ago

Surprised to see it not written in TypeScript since TS helps immensely with large projects https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood

mtm7 7y ago
> "We are working on full end-to-end TypeScript support for Redwood, all they way from the DB schema definition to the frontend and back via GraphQL. It's in the works!" - Tom Preston-Werner (https://twitter.com/mojombo/status/1237474978825564162 https://twitter.com/mojombo/status/1237474978825564162)

thegagne 7y ago

Will this work with Cloudflare Workers?

mojombo 7y ago
Unfortunately, no. Cloudflare workers are heavily restricted in what they can do, both from an outbound request and compute time perspective. If those restrictions are reduced, it’s possible we could make it work someday. It sure would be awesome!

tehin 7y ago

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.

sbr464 7y ago
I didn't see your project on the github user profile you mentioned? Was curious.
nikolasburk 7y ago
Nikolas from the Prisma team here! > It seems to take a lot of inspiration from the mongo api That's an interesting comment but I'm not sure it's quite accurate. I think where we're taking quite a bit of inspiration from MongoDB is the idea of "thinking in objects" because this is much closer to the mental model developers have when they work with data. We are currently already working on an improved API of Prisma Client [1] that looks less like MongoDB but should feel a lot more ergonomic. Regarding your example of removing the `where` from a `findOne` call. In this case it's needed because you can also select/include [2] fields and/or relations: await prisma.users.findOne({ where: { id: 1 }, include: { posts: true } }) But we're aware that the API is quite verbose at times, so we're already working on slimming it down. Here's the proposal from the new API spec: await prisma.users.findOne(1).load({ include: { posts: true } }) > 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. I just want to stress that Prisma is not an ORM! ORMs are characterized by the fact that classes are mapped to tables and you have complex model instances that carry logic for storage, retrieval, serialization, deserialization and often custom business logic. Prisma does none of that! It provides an auto-generated and fully type-safe database client that's tailored to your database schema. Any data you'll ever retrieve is fully typed and comes in the form of plain old JS objects that a are easy to reason about. > prisma tries to do migrations, table creation, etc, etc. These things rarely work properly. I'd love to learn more about where you think Prisma's migrations approach falls short! IMHO moving towards a dclarative migration system based on an intuitive data modelling language is much closer to how developers are thinking about their data than using SQL migrations. One of our users once described it like this: "What Prisma does for migrations is essentially what React does for rendering. A user need only describe the current state, but not the operations to get to that state. So, thank you for doing this to databases as React (and others) has for UIs!" > 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. Do you mind elaborating how/where you see this problem happening in Prisma? > There are security issues with ORMs that traverse and save relationships, as github itself found out. Again, Prisma is not an ORM and I have a hard time seeing how this applies to it. > 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. I fully agree with this poinit and it's one of the core desiign goals of Prisma. If you feel Prisma doesn't achieve this, we're doing something wrong... All that being said, I really appreciate your thoughts and feedback and would love to see you in the Prisma Slack [3] and sharing your thoughts in our GitHub issues. [1] https://github.com/prisma/specs/issues/356 https://github.com/prisma/specs/issues/356 [2] https://github.com/prisma/prisma2/blob/master/docs/prisma-client-js/api.md#field-selection https://github.com/prisma/prisma2/blob/master/docs/prisma-cl... [3] https://slack.prisma.io https://slack.prisma.io

chrysoprace 7y ago

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!

frequentnapper 7y ago

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.

mojombo 7y ago
Thanks for noticing our hard work! We spent a LOT of time making sure the tutorial was rock solid and very clear. We will continue investing time into making the tutorial and our docs even better!

chvid 7y ago

Great presentation. I took a look at the example: https://github.com/redwoodjs/example-blog 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.

mojombo 7y ago
Your understanding is accurate. We do plan to support pre-rendering on a route-by-route basis, which will perhaps be more inline with what JAMstack tends to mean today. But Redwood is still all about JavaScript (client) and APIs (backend), with markup to follow, as I just mentioned. But more than that, it's about the development and deployment philosophy of JAMstack that we fully embrace.

vvoyer 7y ago

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!

mojombo 7y ago
While Redwood is currently optimized for deployment on Netlify, it is by no means restricted to that environment. Our intention is for Redwood apps to be deployable to a variety of JAMstack providers in addition to traditional serverful setups. My main interest is in providing an integrated, joy-inducing experience for app developers that want to leverage the full awesomeness of modern JavaScript and friends. It's true that if Netlify wins, I win too, but I'd rather DEVELOPERS win, and that's what keeps me motivated.
- vvoyer 7y ago
  Thanks for the honest answer here!

LessDmesg 7y ago

> JavaScript No thanks, we have Blazor now.

beardedman 7y ago

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

mhd 7y ago

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…

ralusek 7y ago
Same, am I the only person that uses inner/right joins? A lot of times I'm not doing it in order to minimize subsequent calls, but rather because the logic of my query depends on being able to do a join. Obviously my understanding is that at Facebook-scale you're not really able to have the luxury of joins, and have to accomplish your query logic in other ways...but that strikes me as joins being something you have to relinquish if necessary, rather than being a premature optimization.
crubier 7y ago
Prisma is definitely limited when it comes to advanced use cases. I have been using it for two years and we are now moving to postgraphile because of this. And Prisma 2 doesn’t help, it makes it worse.
- hokumguru 7y ago
  TBF, Prisma2 also includes a sql breakout that allows you to run whatever Postgres-flavor sql you want in your code.
  - crubier 7y ago
    Yes, Prisma allows you to run hand crafted SQL queries. That’s is the bare minimum I would expect from it. Graphile on the other hand allows you to do this AND to systematically generate whole classes of such requests, through plugins.
7y ago

sandGorgon 7y ago

this is very interesting. nextjs gives a lot of this : for example - frontend and backend in the same code https://nextjs.org/docs/api-routes/introduction https://nextjs.org/docs/api-routes/introduction - graphql based - https://github.com/zeit/next.js/tree/canary/examples/api-routes-apollo-server-and-client-auth https://github.com/zeit/next.js/tree/canary/examples/api-rou... - hybrid static page support - https://nextjs.org/blog/next-9-3#next-gen-static-site-generation-ssg-support https://nextjs.org/blog/next-9-3#next-gen-static-site-genera... - jest - https://github.com/zeit/next.js/tree/canary/examples/with-jest https://github.com/zeit/next.js/tree/canary/examples/with-je... - CMS providers - https://nextjs.org/blog/next-9-3#collaboration-with-cms-providers https://nextjs.org/blog/next-9-3#collaboration-with-cms-prov... - pretty url routing - https://github.com/zeit/next.js/tree/canary/examples/with-pretty-url-routing https://github.com/zeit/next.js/tree/canary/examples/with-pr...

davedx 7y ago

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!

rienbdj 7y ago
This is pretty easy to do with yarn workspaces
pistoriusp 7y ago
Thanks! We'll definitely support Typescript, we're almost there and will make the experience feel amazing. The boundary between the API and WEB sides is GraphQL and we're looking at making the schema typing available on the WEB side. We're using yarn workspaces!

Etheryte 7y ago

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.

pistoriusp 7y ago
Thanks, sometimes I need to take a step back and realize the scale of what we're building! Thankfully, we're building on the backs of giants here. We're glueing a bunch of the technology together in a way that makes it feel idiomatic, documenting it and asserting our opinions on how to use it.

harryadelb 7y ago

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

larrywright 7y ago

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.

brailsafe 7y ago
I currently work on a codebase that is in part React based, and I have no idea how to get it running from scratch or how data flows through. It seems asinine.
robertakarobin 7y ago
Eh, I feel like that's any web framework in any language. Take Django for instance. If you're doing a very boilerplate project, then it's pretty slick. But as soon as you start trying to do any customization you go down a rabbithole of subclasses and mixins, where looking at the source is usually more helpful than the documentation. I think the reality is web applications stand on the shoulders of lots of giants. We're only able to get anything done thanks to abstraction that someone else did for us. We still have a need to see below the surface occasionally, though, and finding the balance between readability and customizability is an eternal struggle. Plus, everyone has their preferences: I hated Angular at first because of its steep learning curve, and now love it for its strictness.
- larrywright 7y ago
  I guess my feeling comes from spending time with opinionated frameworks like Rails. There are sane defaults and you’re up and running quickly. Any time I look at something like React or similar, the instructions for getting started are written like “If you’re using yarn, do this. If you’re using grunt, do this other thing”. I don’t have either, so now I have to choose one before I can proceed. Instead, I just close the browser tab and go on to something else.

jcarlosweb 7y ago

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

sodez117 7y ago

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