
Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - mojombo
https://redwoodjs.com/
======
sytse
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)

~~~
ljm
I agree this is super exciting but those things come with a significant
operational overhead that your traditional full stacks don't have.

one vm => many lambdas/microservices

react => server side rendering and state hydration, throw redux in there too

prisma => you can't beat the DB with code. Learn SQL and remove the middleman.

Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest
out of the box

Caching/Static site => wut? ... wut? there's much more to caching than HTML.

routes.js => probably great on the server, not so much on the browser.

And the best for last...

graphql => not a replacement for REST. You can do more with less by just
making your client do the work or going with backend-for-frontends. If you
don't understand your network then graphql is an easy vector for DOS (speaking
from experience).

Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid
application running in a fraction of the time while in JS land, client server
arch is a seemingly unsolved problem.

I sound bitter but I'm more incredulous. I don't actually enjoy writing for
the browser any more, there are too many divergent trends.

~~~
onion2k
_Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid
application running in a fraction of the time while in JS land, client server
arch is a seemingly unsolved problem._

This might be a slightly controversial opinion, but I don't think the time it
takes to get an application running with a framework is a relevant metric.
Being able to get an application up and running fast is only a useful benefit
when you're first starting out and trying things. If you're choosing a tech
stack and you're going to be working on something for months or years, the
fact that you can see something on a screen after an hour or after 3 days is
_completely insignificant_ compared to how good it is to work with in the long
term.

Choosing a technology because you can start working on a new application
quickly is the wrong way of thinking about your tech stack.

~~~
hombre_fatal
I think your post summarizes a major reason why so many people ended up using
small frameworks and appreciating glue code after using Rails/Django.

My noob a-ha example is `rails generate devise:install` where I first thought,
wow, what a time saver. Eventually I learned lessons like, perhaps
authentication is too important to be hiding from your source code. In fact,
maybe almost everything is.

~~~
mikeappell
I think it's important to learn and understand, absolutely. But a default
installation/configuration which both works _correctly_ and is easy to set up
is pretty damn valuable.

~~~
onion2k
_But a default installation /configuration which both works correctly and is
easy to set up is pretty damn valuable._

It can be, especially when you're learning or putting together lots of small
projects, but my point is that people over-emphasis the benefit of that
feature on a long term project. It might be fine that a framework takes a lot
of time and effort to set up before you see any results, and it could actually
be a good thing if that initial time means other things about the framework
are better.

All other things being equal it'd great to be able to spin up quickly, but
things are never really equal between frameworks. So, to me, choosing a tech
stack because it's quick to initialise a new project feels like you're
optimizing for the wrong thing, and potentially you're making a less optimal
choice because of that.

~~~
tekknik
There are a couple of reasons you want a “quickly spun up” framework. First it
shows the API is thought through / not complicated. If it takes hours for you
to add a basic route the framework was overengineered. The second is hiring.
Rarely will you find devs with all the experience you require, so you’ll have
to train. Making things overly complicated increases the cost of your devs,
increases training time, and generally just slows you down.

So I completely and wholeheartedly disagree. Frameworks should be as simple as
they can be.

------
mhd
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…

~~~
crubier
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
TBF, Prisma2 also includes a sql breakout that allows you to run whatever
Postgres-flavor sql you want in your code.

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

------
mojombo
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!

~~~
rgbrgb
This is awesome, congrats! I love Rails but it does seem like nextjs has left
it in the dust in terms of making it easy to build simple, performant front-
ends in react and there's no official Rails graphql solution yet either. What
next is missing is a blessed omakase way to deploy it with a DB.

Can you talk about or point me to docs on the different philosophies between
this and nextjs? In particular next already makes bundle optimization,
splitting, lazy-fetching and serverless deploys pretty automatic. Why not
start with next and work on incorporating the DB/business logic functionality?
Related: why Prisma?

~~~
mojombo
Next.js is really great, and has definitely helped push the industry forward.
I'm not a fan of the way they handle routing, though, and we need to be able
to evolve Redwood without fighting against our dependencies. If I had to
guess, we may end up writing our own versions of other things as time goes on.
We're all about integration, and sometimes you have to own things yourself to
make it all work as seamlessly as possible.

~~~
andrewingram
FWIW we use Next.js without the pages folder convention, we use a routes.js
and just have the pages folder as a build artefact, then we have relatively
seamless integration with Relay to make data management super straightforward.

------
Zaheer
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
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
Is Redwood _not_ limited to browsers?

~~~
thedavidprice
Correct. One API. But chose the client (or as many) that you want.

~~~
mojombo
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
KISS / Single responsibility

------
jaredcwhite
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
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
How tightly is it tied to React? Would it make sense to try to use with
another client side layer?

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

------
davedx
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!

~~~
pistoriusp
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!

------
yatsyk
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
Because react killed it and by the time meteor switched to react from blaze
lot of people had moved on.

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

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

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

~~~
manigandham
You should check out the .NET platform with ASP.NET framework and Entity
Framework ORM. It's the gold standard when it comes to these tools and has
none of the issues you mentioned. There's even Blazor now to for frontend UI
powered by WebAssembly or server-side websocket connection.

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

~~~
undefined-1
JavaScript, APIs, and Markup.

[https://jamstack.org/](https://jamstack.org/)

~~~
nojvek
What does the markup stand for ? I get JavaScript and Apis.

~~~
paultannenbaum
Markup refers to html, or the fully rendered result.

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

~~~
pistoriusp
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 ;)

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

~~~
godot
My understanding is JAM stack refers to mostly the frontend, being a
statically generated site, and talks to server via API, but doesn't dictate
anything about your API server or server side jobs, etc. You can still run
serverless/lambdas, or actual backend API servers, or whatever else you want
to do.

I guess Redwood's model is a little more than JAM stack, since "Rails" for JS
would imply it does a lot more than the JAM part, and that's what it looks
like on the site.

~~~
thedavidprice
We are stretching the definition of "JAMstack" here. But the primarily
intended emphasis is not just React+API -- it's making structure+design
choices that target serverless infrastructure out of the box. It's not perfect
and we have a ways to go, but being able to deploy fully serverless is what
RedwoodJS is all about.

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

------
miguelmota
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
> "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))

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

~~~
mojombo
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
Cool. Are named routes typesafe? In other words, if I change the name of a
route, does it cause some sort compile time error?

~~~
pistoriusp
I've created this issue to keep track of this:
[https://github.com/redwoodjs/redwood/issues/206](https://github.com/redwoodjs/redwood/issues/206)

------
sandGorgon
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-
rou...](https://github.com/zeit/next.js/tree/canary/examples/api-routes-
apollo-server-and-client-auth)

\- hybrid static page support - [https://nextjs.org/blog/next-9-3#next-gen-
static-site-genera...](https://nextjs.org/blog/next-9-3#next-gen-static-site-
generation-ssg-support)

\- jest - [https://github.com/zeit/next.js/tree/canary/examples/with-
je...](https://github.com/zeit/next.js/tree/canary/examples/with-jest)

\- CMS providers - [https://nextjs.org/blog/next-9-3#collaboration-with-cms-
prov...](https://nextjs.org/blog/next-9-3#collaboration-with-cms-providers)

\- pretty url routing -
[https://github.com/zeit/next.js/tree/canary/examples/with-
pr...](https://github.com/zeit/next.js/tree/canary/examples/with-pretty-url-
routing)

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

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

------
beardedman
Nice!

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

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

------
frequentnapper
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
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!

------
insomniacity
> 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-...](https://egghead.io/playlists/building-a-serverless-jamstack-
todo-app-with-netlify-gatsby-graphql-and-faunadb-53bb)

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)

------
chrysoprace
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!

------
cies
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
That’s the Schema Definition Language native to GraphQL.

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

------
kostarelo
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
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!

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

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

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

------
z3t4
The further from the metal you are the harder it will become to do even the
most simple of things. In this case, the code will be "compiled" up to ten
times before it hits the metal. And every time some information will be lost,
and unnecessary extra instructions will be added. / Debbie Downer

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

------
vvoyer
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
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
Thanks for the honest answer here!

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

~~~
thedavidprice
That's all @cannikin doing!! Here's his framework, opinions included :)
[https://github.com/cannikin/cameronjs](https://github.com/cannikin/cameronjs)

------
msoad
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!

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

------
kingpiss
Damn this looks pretty promising.

~~~
pistoriusp
Thank you!

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

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

~~~
mojombo
Thanks! What would you use instead of GraphQL? Curious what your specific
needs are.

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

------
thegagne
Will this work with Cloudflare Workers?

~~~
mojombo
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!

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

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

~~~
mojombo
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
Great stuff - looking forward to exploring this properly.

------
ctb9
Could someone explain how this compares to Next.js?

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

------
harryadelb
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/)

------
LessDmesg
> JavaScript

No thanks, we have Blazor now.

