FSJam Roundtable with Chris Ball, Brandon Bayer, and David Price

Episode Description

Core contributors from Redwood, Blitz.js, and Bison discuss Prisma's impact, CLI tooling, serverless deployment challenges, and their 2021 goals.

Episode Summary

This inaugural FSJam podcast episode brings together core contributors from three full-stack JavaScript frameworks—RedwoodJS, Blitz.js, and Bison—to reflect on 2020 and look ahead to 2021. The conversation traces how these frameworks emerged as a recognizable ecosystem, with Anthony Campolo recounting his early comparison post that helped spark the community. The group rallies around Prisma 2 as the year's most valuable technology, each sharing how it became foundational to their respective projects and discussing wishlists like MongoDB and document database support. A deep technical exchange follows on CLI tooling and code generation, where the frameworks diverge in approach—Bison using Hygen with EJS templates, Blitz employing AST parsing with Babel for more dynamic templating, and Redwood leveraging Yargs with Cypress-driven testing. The discussion shifts to deployment and infrastructure, where frustrations with serverless limitations, lambda monoliths, and hosting provider constraints surface, with Render, AWS Lambda containers, and Cloudflare Workers all floated as potential paths forward. The group wrestles with defining "full-stack Jamstack" itself, settling loosely on first-class database support and a monolithic development workflow as key differentiators from Next.js or Gatsby alone. Closing out, each contributor shares excitement about reaching version 1.0, growing communities, startup adoption, and the sustainability challenges facing open-source projects.

Chapters

00:00:00 - Introductions and the Origin of FSJam

The episode opens with Christopher Burns welcoming listeners and introducing the panel: David Price from RedwoodJS, Chris Ball from Echo Bind working on Bison, and Brandon Bayer, creator of Blitz.js. Each shares a brief background and expresses enthusiasm about closing out 2020 together.

Anthony Campolo then recounts the origin story of the FSJam community, tracing it back to when Chris Ball released Bison with the tagline "full stack Jamstack in a box." Anthony's comparison post on the Redwood Community Forums drew significant attention and inspired Christopher Burns to formalize the concept. The group acknowledges how having three distinct frameworks tackling similar problems validated the emerging full-stack Jamstack movement.

00:02:35 - Comparing Framework Approaches to GraphQL and Type Safety

The conversation turns technical as the group compares how each framework handles the GraphQL layer and type safety. Redwood uses SDL-first API definitions with Apollo Client, Bison pairs Nexus with Apollo Client for a code-first approach, and Blitz eliminates the GraphQL layer entirely, generating everything the developer needs so there's no explicit API to manage.

Brandon explains how Blitz achieves end-to-end type safety by leveraging TypeScript and Prisma types that flow automatically from the database schema through server-side resolvers into React components—no code generation step required. This sets up a natural contrast between the three philosophies: SDL-first, code-first with Nexus, and zero-API with direct imports.

00:04:45 - Prisma 2 as the Year's MVP

All three contributors agree that Prisma 2 was the most impactful technology of 2020 for the full-stack JavaScript ecosystem. David Price explains how Redwood's co-creators built much of the framework's architecture around early Prisma 2 betas, while Chris Ball describes Echo Bind's journey from Prisma 1's production shortcomings to renewed confidence in Prisma 2's developer experience.

Brandon shares that Prisma's existence was a primary motivation for creating Blitz in the first place, praising the team's user research practices and collaborative spirit. The group discusses wishlists for 2021, with MongoDB support emerging as a top request—David argues it would significantly boost Redwood adoption among developers coming from the MEAN stack. Anthony notes Prisma's journey to finally embrace the "next-generation ORM" label after resisting the ORM designation throughout the year.

00:10:15 - CLI Tooling, Generators, and Code Templates

The panel explores how each framework approaches code generation and CLI tooling, drawing inspiration from Ruby on Rails and Ember. Chris Ball describes Bison's use of Hygen with EJS templates for generators, while Brandon details Blitz's custom templating system that uses regular TypeScript files with string replacement and Babel-powered AST parsing to support both JavaScript and TypeScript outputs.

David discusses Redwood's Yargs-based CLI and their Cypress test suite that runs through the entire tutorial as an integration test. The conversation surfaces shared pain points around testing CLI commands with TypeScript and managing version upgrades. Brandon describes Blitz's recipe system, which uses JSCodeShift for AST-based codemods to handle complex setup tasks like adding theme providers, and offers to collaborate with Redwood on extracting these utilities into shared packages.

00:17:20 - Community, Collaboration, and Defining FSJam

David reflects on the relationships that formed across the ecosystem in 2020, noting that despite never all being in a live conversation before, the group feels like a family. This leads to a broader question about what FSJam actually is and who belongs in the conversation, with the group debating whether Gatsby or Next.js should be included.

The consensus settles on first-class database support and a monolithic development workflow as key distinguishing features. Brandon argues that neither Gatsby nor Next.js focuses on end-to-end full-stack developer experience the way these frameworks do—they serve as building blocks rather than complete solutions. David adds that much of the terminology around "full-stack Jamstack" is rooted in continuous deployment methodology and leveraging modern infrastructure.

00:24:34 - Serverless Deployment Challenges and Infrastructure

The discussion shifts to real-world deployment struggles. Brandon shares his experience moving a Blitz app from Vercel to Render after hitting bundle size limits with serverless Puppeteer, and references Laravel Vapor as an aspirational model for serverless JavaScript deployment. Anthony introduces the concept of the "lambda monolith" problem—an impedance mismatch between how serverless functions were designed and how full-stack frameworks use them.

David highlights emerging solutions like AWS Lambda's container support and Cloudflare Workers, while articulating his ideal: low cost, high performance, and zero infrastructure management. The group discusses how current Jamstack hosting providers may not end up being the final home for FSJam applications, and Chris raises the need for isolated database environments tied to preview deployments. Railway.app surfaces as a promising newcomer, though with current limitations around serverless Next.js support.

00:36:09 - Looking Ahead to 2021

Each contributor shares their priorities for the coming year. David emphasizes Redwood's path to V1, community growth, and the exciting emergence of funded startups built with Redwood. Chris echoes the theme of consolidation and collaboration, noting that startup success stories will be crucial for ecosystem credibility. Brandon outlines Blitz's 1.0 roadmap alongside an ambitious goal of first-class mobile app support with zero-API integration.

Anthony highlights the teaching potential of these frameworks for bootcamps and students, while David makes a passionate case for financial sustainability in open source, urging listeners to sponsor projects directly. The episode closes with contact information for each participant and an optimistic send-off into 2021, with the group acknowledging that the commercial ecosystem around these frameworks is still in its earliest stages and represents a major opportunity.

Transcript

00:00:10 - Christopher Burns

Welcome to the first podcast. This is a really special episode. We have core contributors from each of the main FSJam frameworks. You already know who I am. You already know who Anthony is. We'll start with David, then Chris, then Brandon.

00:00:28 - David Price

All right, David Price. Thank you, gents, for hosting and kicking us off this year. Really a pleasure. Hard to believe we're at the end of the year. It went so fast, yet took ten years to get here. Happy 2021, everyone. I am on the core founding team at RedwoodJS.

00:00:44 - Chris Ball

Awesome. I'm Chris Ball, a CTO at Echo Bind. Also very excited to be here with you all. I feel like this has become my recent tech family. It's been good because conferences have shifted around and not really traveling as much, so it's good to have a little pod doing work on Bison over at Echo Bind.

00:00:59 - Brandon Bayer

And I'm Brandon Bayer, the creator of Blitz.js. Awesome to be here and talk about this awesome new full stack framework stuff.

00:01:08 - Anthony Campolo

Thanks for being here, guys. I'm really excited for this.

I remember going back to when Chris, you first released Bison. This was kind of what I think of as the catalyst for a lot of this. When you released it, you had your kind of tagline, full stack Jamstack in a box. I saw that and I'm like, oh, this is interesting. I started digging into the technology, and I wrote just a little post about it for the Redwood Community Forums. It was one of the most liked things I've ever posted on the forums. It actually got a lot of attention.

That was when Chris Burns saw that, and he was like, oh, I'm going to start this thing. And you guys actually talked about this in your very first roundtable, although you got the story completely wrong and wrote me out of it. But that is what actually happened.

00:01:53 - Christopher Burns

Okay.

00:01:54 - David Price

That's probably my fault. Wait, wait, you were posting about other things in the Redwood forums? Anthony, how did I miss that? I remember that article. It might actually be where people go when they look for Bison right now.

00:02:04 - Anthony Campolo

As far as I know, that's the only blog post that's ever been written that actually compares all three of them. And there's a lot to compare: Redwood and Blitz. The fact that there was a third one just validated it for me. In my mind, I was like, okay, there's something going on here that's really important and really significant.

Being able to compare Blitz and Redwood was really helpful for me. So then getting to see this kind of third one, to be like, all right, now there's this whole different set of choices you can make for this tech. Also, now you can just create a mad lib, just start picking pieces from all three.

00:02:35 - Chris Ball

You all have done a lot more work on some of the other frameworks, but when something is this early on in an ecosystem, I think it's really good for everybody to get all their ideas out there. We're all kind of iterating, all just trying to see how it all fits.

00:02:47 - Christopher Burns

What we're trying to do is use all of the same kind of tools, but they're all opinionated in different ways. For example, Nexus. Redwood looks at it and went, we'll prefer to write our API in SDLs. Bison, you use Nexus, don't you?

00:03:07 - David Price

We do. Shocking. Actually, I didn't know that.

00:03:10 - Chris Ball

For us, one of the reasons was it's allowing us to move very quickly. However, if we ever needed to go out of it, you have the SDL files all generated. If this didn't work out, we can always kind of roll back to the default.

00:03:21 - David Price

Where did it land for V1? It's handling, it provides an SDL. It handles types and resolvers. Is that correct? Yeah. Okay.

00:03:29 - Christopher Burns

But then we have the other side where we have Brandon, who says you don't even need to communicate through GraphQL. We'll do it ourselves. We're just going to generate all of the stuff you will need. So there was never technically an API for you.

00:03:44 - Brandon Bayer

That's true. We do it for you.

00:03:46 - Anthony Campolo

And for you, it'd be kind of like React Query would be the client. And then for Redwood, Apollo's the client. But Nexus isn't a client, so I'm kind of confused. What's the client for Bison, I guess is my question.

00:03:59 - Chris Ball

Then it's Apollo Client. Yeah. So it's basically what Nexus is doing is giving you a really concise way to write your typedefs and your resolvers. It stops at the server, and it does have a plugin for Prisma. So if you've opted into Prisma as well, you get some additional benefits.

00:04:14 - Anthony Campolo

So for Brandon, because you guys are using TypeScript.

00:04:18 - Brandon Bayer

Yeah, by default.

00:04:19 - Anthony Campolo

So that's where you get all the typing from. So that's why you wouldn't need something like Nexus.

00:04:23 - Brandon Bayer

Correct. We get all the types from Prisma, your Blitz queries and mutations, the actual resolvers that run on the server. Those can be manually typed or just automatically inferred, like whatever the return type is. And then when you import that into your components to use it, the types are just there automatically. Since you're importing it, there's no generated code step. Types just flow all the way through.

00:04:45 - Christopher Burns

Let's all move on to a technology we can all agree has fundamentally impacted FSJam, and that's Prisma 2.

00:04:55 - David Price

That's the one thing I was thinking coming into this conversation. If there's an MVP this year for the Jamstack, it's got to be Prisma. I was not around for the conversations that were happening in 2018 and 2019, when it was Tom and Peter specifically. Things hadn't formalized. They were in experimentation mode. For example, they were looking at Nexus. When they saw early betas of Prisma 2, a lot clicked into gear. They'd been researching, putting a lot of pieces together. Prisma 2 became a backbone that they could hang a lot of their ideas on.

Man, that team has just crushed it this year. For anyone who's thinking about using Prisma 2, highly recommend it. For anyone from the Prisma team that's listening, hell yeah. What an amazing year and product. Redwood would not be the same without it. Well done.

00:05:40 - Chris Ball

Totally agree with that. Our sort of evolution for Prisma started back with GraphQL and the original version of Prisma. There's a lot of promise there. It works pretty well. It did kind of fall down a little bit for us in a production setting, and that was unfortunate. I mean, there were still some really good ideas there.

When Prisma 2 really started developing, it was like, okay, the choice for us was, hey, there's this thing here. Traditionally, we've been using TypeORM, which is pretty good, but it just didn't have the right feel or the developer experience. It's fine. It's certainly an option to go with. But looking at those two things, it was even more of a, hey, we're actually going to go with this despite what happened last time. Just kind of a testament to how good that tech felt already. It's evolved since then, and I think it's just gotten better.

00:06:22 - Christopher Burns

I think that's everyone's opinion with Prisma. One is the idea was so fundamentally different. It's just the implementation fell a bit flat, and it did with me too. But the hardest part was knowing that you are using Prisma 1. Prisma 2 is now out and they're sunsetting Prisma 1, and you need to move over.

00:06:44 - Brandon Bayer

I'll absolutely agree with you all about Prisma being the MVP this year. So whenever I was thinking about starting Blitz, Prisma was one of the main reasons that I started it because if Prisma didn't exist, I probably wouldn't have. Your database access is one of the most important parts when you're building a full stack app. It's just been phenomenal. I've been repeatedly just super impressed with the team. They work with us. I'm sure they're working with you to just like, hey, here's, you know, we're working on this thing, what do you think about it? Or like, hey, we have some breaking changes upcoming.

I've been really impressed with their user research skills. I guess with this new migration thing they just released, they've talked to me a few times about it and they just have excellent questions. They really dig in and understand what their customers are trying to do. What's the best way to solve it? Yeah, kudos to them.

00:07:30 - David Price

They're just good people. They're a pleasure to work with. Anyway, here's to Prisma.

00:07:34 - Christopher Burns

And if we look to 2021, what would you personally hope that Prisma 2 would get? For me, better integration into multi-team support and role support at Prisma level.

00:07:47 - David Price

Easy. For me, it's Mongo support. I think a lot of people have not adopted Redwood yet because people coming from the MEAN stack are looking to use Mongo. GraphQL and Mongo kind of grew up together in a sense. So I think there's a lot of sense that, oh, I want to use Mongo, not necessarily understanding how Prisma could help with another database. That's the main thing that I would hope for.

I just think Redwood adoption is going to go up a lot more quickly. That's one of the top two things keeping people from trying Redwood—Mongo support—which we could do now. It just won't be as much fun without Prisma.

I think another thing that's going to come with Prisma that's going to be really interesting is when it's not just databases that you could use them for queries, when it could be other types of endpoints. That's going to be really powerful. That's probably two years out, to be honest. Just trying to think of what the roadmap to get there might be and the other things they'd want to support.

[00:08:39] But Mongo and then other types, I actually would say Mongo is more important than something like Fauna would be. Although I'm far more excited for a database-like technology to be supported first class by Prisma.

00:08:51 - Christopher Burns

After finally reading about Fauna, I'm very jealous, and it makes me sweat by the day-to-day choices I've made.

00:08:59 - Anthony Campolo

Yeah, I definitely think that the Mongo thing is going to be huge for Prisma. They're trying to get it to work with all sorts of document databases, which is going to take longer, but I think it's probably the right thing in the end, because then you could get it to work with something like DocumentDB or even maybe something like Fauna. I'm a little skeptical because Fauna is not really just a document database, so we'll see about that.

Also, something to note is that, as someone learning Prisma throughout the course of this year, they've done a really great job of honing how they talk about Prisma and what Prisma is. They've had this whole battle the whole year about whether to call themselves an ORM or not. And they seem to have finally landed on a next-generation ORM, which I think is fine because the type of people that the tool is really appealing to, and who it is going to be useful to, probably don't really know what the difference between a query builder and an ORM is.

[00:09:57] Having to explain that to them before they can use the tool seems like a barrier to me.

00:10:02 - Brandon Bayer

Yep, I agree.

00:10:03 - Christopher Burns

And it's interesting that even in this post in August on the comparison table, you said, not an ORM Prisma.

00:10:12 - Anthony Campolo

I made lots of jokes about them refusing to call themselves an ORM.

00:10:15 - Christopher Burns

Each of the frameworks also build their own technology, and I think one of the biggest MVPs is the concept of generators and setup commands. I think that is way, way cool.

00:10:29 - Brandon Bayer

I think we're just finally catching up to what everybody else enjoys, like Ruby on Rails and Ember.

00:10:35 - Chris Ball

And that's like the first thing we've done with every single JavaScript project. We've typically used Hygen for that to power most of it. And so it's just like, let's just add all this in and make sure we have _templates in the repo. And that folder contains everything that we're going to use going forward.

00:10:49 - Anthony Campolo

You've been doing a lot of work on the Bison CLI recently, actually. Can you talk a little bit about how that is going to kind of enable more complicated workflows in Bison?

00:10:59 - Chris Ball

Step one was just get the thing out and generate a project. Step two is like, you have something generated, how do you use it daily? Still want to keep a lot of the flexibility in there, which probably will eventually lead to some type of eject command. But generally speaking, we wanted to make sure to roll up some of those commands that are kind of cluttering package.json.

Give people an upgrade path. It's not doing anything smart like codemods or anything like that right now. It's literally just there's a repo that every time there's a new release called Bison Versions, I think, and it's just like we tag it. And then when you run the upgrade command in the CLI, we're just going to diff the tags and at least give people like, hey, make these changes in your project. It's a way to move forward outside of like, what the heck do I do here?

So definitely an incremental step, but prior to that, needed to get everything into Lerna, even though Lerna has its own fun. Seems like still sort of the best path at the moment.

00:11:46 - Anthony Campolo

Redwood uses Lerna. Lerna.

00:11:48 - David Price

Now, I really want to talk because we've talked about these things and tried a few things to get to that same handling versions. What more can we do with the command line? And it's all derivative, right? So all of our inspiration came from people's experience with Rails. And this has definitely been done before. But it is interesting that things like extending that, making the templates extendable, handling upgrade, and then what are the choices now to do that and what's the right way to handle that now, people have in the past. We'd love to talk more about that. Those are all cherry-on-top type situations that'll make it even more powerful.

But command line has been a fun thing to work on. We've just used Yargs for building out ours, and we've got a restructuring we want to do on the, oh, that's right, because it's Hygen.

00:12:28 - Chris Ball

Hygen is specifically for the generator templates that use EJS. And you basically just write an EJS file per command and you can replace things. And it's not as powerful as some of the stuff, Brandon, I've seen you doing. And I'm assuming, David, you're doing some similar stuff, but it's pretty easy to do some complex workflows with it. And so if you need multiple actions for a generator, you just add multiple files.

00:12:49 - Anthony Campolo

EJS is something that has been a little bit of a barrier for me in Bison because I've never seen EJS before. I'd heard of it, but I'd never worked with it.

00:12:56 - Chris Ball

It was just a way to have a template that's interpolated.

00:12:58 - Brandon Bayer

That's why we went down the road of creating a custom brand new templating system. So our templates are just regular JavaScript or TypeScript. We do string replace like underscore underscore model name model names. You can do different cases like capital model, capital name or lowercase model capital name, and then end with a double underscore. Then we do basically a string replace on that.

But then we also do AST parsing. So you can do hang variables on process.env. If we have templates that support both JavaScript and TypeScript, we can say in the template, if process.env dot is TypeScript, then in an if statement, we can put the TypeScript code, and then you can have else just the JavaScript code and vice versa. And then we actually parse the AST and then parse that out. It's pretty nice because you get TypeScript autocomplete, ESLint, and all that stuff. So it's still a very familiar thing in your template.

00:13:50 - Anthony Campolo

Does the AST come from TypeScript or from Babel, like where is the AST here?

00:13:55 - Brandon Bayer

I think we use Babel to parse it.

00:13:57 - Anthony Campolo

Okay. Got it.

00:13:58 - Chris Ball

That's one of the big advantages. While you're writing some of these templates, you can actually tell if it's compiling properly with the workflow that we've chosen. You have to run a linting command and make sure that it compiles there versus kind of more of a real time.

00:14:10 - Brandon Bayer

There's still a component where you still have to run it to see for sure.

00:14:14 - David Price

But here's the nasty problem we haven't talked about with CLI is TS. We've had to do so many workaround hacky things on tests and fixtures, and then we're always breaking something and then you're like, oh, this test is just dumb anyway. Like, why should I even write a test? Just ship the code. We are most guilty of that in the CLI package for sure. It hasn't been terrible, but there's been a few times where, like, yeah, it might not. We might need to work on that.

00:14:40 - Brandon Bayer

Yeah, it's been challenging.

00:14:41 - Chris Ball

I've been experimenting with Cypress.

00:14:43 - David Price

That's what we have. We have a test suite with Cypress. We use our tutorial. It's kind of the template. We run all the commands you need to do to go through the tutorial from install. And then now we're adding on things like our test command, our Storybook. Basically it's like, well, if it didn't generate the code to get the next step, then we know something is wrong, right?

00:15:01 - Christopher Burns

One of the other things that I don't think has really been tackled yet, but I believe Redwood is tackling it with their generators. It's great to set it up for the first time, but what happens if you then go change the Prisma model and you then have to do what? Tweak all of the files that it's created yourself? Are any of the projects actually doing the regeneration of the functions to now add the extra variables or the stuff you removed?

00:15:27 - David Price

Kind of. We have a wonderful command. I think Anton put this thing in. It's probably one of the most lines committed in a single command we've ever had, called destroy. You can always destroy whatever you just did. It's kind of the undo and then go back. And then.

00:15:42 - Chris Ball

Most.

00:15:42 - David Price

Most of our generator commands allow you to force. It's effectively an overwrite or regeneration. It's challenging with some of the setup commands that we have. And again, I think this is a little bit like a Gatsby plugin might be. We have these one-off commands that could do a lot of other things inside of them: instantiate, initialize, config, install. That would be a setup command for us.

00:16:04 - Brandon Bayer

It would be like a Gatsby recipe and a Blitz recipe.

00:16:07 - David Price

Okay, there you go. Sorry, that might be the analogy. Those get challenging because other things might already exist that those have to come in and overwrite. It's hard. There's just a lot of edge cases.

00:16:17 - Brandon Bayer

Are you doing AST parsing for that?

00:16:19 - David Price

No, no. I mean, no.

00:16:21 - Brandon Bayer

Okay. We are. So we're actually parsing AST and basically doing a codemod, which has worked pretty well.

00:16:28 - David Price

Okay.

00:16:28 - Anthony Campolo

Is that what you're calling the recipe?

00:16:30 - Brandon Bayer

Yeah. We call the recipe the thing that you actually run, the definition of what to install. And then we have a Blitz installer package that actually does all of that stuff. Right now it's written in TypeScript. It's like a builder pattern for actually writing the recipe. We have like a simple shortcut to add a regular dependency or add a development dependency. And then you also have access directly to jscodeshift, I believe it is, to write custom AST parsing.

For example, right now to add theme providers in the root of your app, you have to write all of that AST directly in the recipe. So every recipe has a bunch of complex code to do that. But we need to abstract that out into another utility that just says add theme provider or add context provider or whatever the correct name would be. And then that makes it easy. So happy to collaborate on that and pull it out into a separate package and stuff if you're interested.

00:17:20 - David Price

Before we started recording, we were talking about how this feels like, well, Chris, you said it feels like a family. And actually we've never all been in a conversation before live, but I feel like we have many times this year. What a wonderful time and experience to be a part of an ecosystem that has really taken off and just all the relationships that form. And this is probably something Anthony and Chris wanted to get to, but one of my biggest takeaways from this year is just all the relationships that got to happen because of these things, technology that's happening and creating an ecosystem around it.

But anyway, yeah, I would love to. I think, and I love how low level this conversation has already gotten, but these are the important problems that make everything else work. Yeah, that'd be really fun. Yeah, exactly the same kind of problem. We need to get V1 out the door. After that, there's some things we really want to do on the CLI side that we'd like to come around back to, so we will take you up on that.

00:18:07 - Brandon Bayer

And we've also talked with Gatsby about collaborating with their recipe stuff because their recipes are written in MDX. So yeah, earlier on we talked with them and they're open to collaborating with us and abstracting out their stuff, and it would take some work, but we decided to just go ahead and get something working in our own stuff. But long term, I think it'd be good to get more toward the Gatsby MDX stuff.

00:18:28 - David Price

I've got a Gatsby question. Why aren't they here? Why is Gatsby not a part of FSJam?

00:18:34 - Anthony Campolo

We didn't invite them, so that's partly on us.

00:18:38 - David Price

Should they be? So here's the higher level question. Are there other frameworks, people, things missing from this conversation right now?

00:18:46 - Anthony Campolo

I'd love to have Guillermo here, that's for sure.

00:18:48 - Christopher Burns

I believe so, but the question is where is the framework's role and a meta framework's role? As Chris, you did a talk about this at Next.js conf. Is the thing that Gatsby is missing a Blitz alternative built on top of Gatsby potentially, or is that just the framework? If Gatsby is here, it's an open door. Come on in. Should Next be here? It's that thing of what is FSJam? It is very much up in the air. We're a community and we're trying to figure that out. It's only been going since August the 14th when I coined the term. So the question is, what do you guys think FSJam is?

00:19:35 - David Price

Great question, Chris. Is it just maybe even a little bit more? Is it just first class database support inside of a framework?

00:19:42 - Anthony Campolo

That tends to be how I have found it, the easiest to at least describe it to people. Like when people ask me the difference between any of these things and a Next or Gatsby, the database is what I talk about, what I try to emphasize. So yeah, I think that's a very important piece because that's what we want. We need a thing to persist our data so that we can read and write to it, so that we can do all the types of activities we want to do with our data. And you can't do that without a database at this current date and time, and we'll see where things go.

I think that's a really good touchstone. And for me, that kind of touches on the larger thing, which is just having a fully coherent structure to your project, all the code being in one place.

00:20:25 - Brandon Bayer

Monolithic development workflow.

00:20:27 - Chris Ball

You're less separation of teams where like this is your front end team, this is your API team, and it's more like you're building the product. And I feel like that mindset before this whole thing, to me, it was basically you're talking about a monorepo that both things are included. And that was it. But that's the evolutionary step, I feel like, towards getting to where we are.

You want all your pull requests to have the full context on both sides, and you want it to feel like just kind of one thing. And then it's morphed into what I would just consider a single project and not these two isolated things that are still sort of related, but you treat them isolated.

00:20:57 - Christopher Burns

I still keep up with Gatsby. I have a few projects in Gatsby that I maintain. They're doing some really cool stuff lately. What I think Gatsby is doing most right now is refinement. They've built very fast and grew very big, and now I think it's coming to the time where they're refining things.

For example, the Next.js image component came out. Gatsby had that for a year, two years. As soon as Next.js came out with their alternative, Gatsby now have refined their Gatsby image plugin, and now it is even smaller, faster, and does more things. What is a meta framework? What is normal? Would we expect generator commands, setup commands, database support, function support, uploading functions to the cloud? We're all going to the same north light no matter what path we're taking.

I think Gatsby's not quite there yet, or Next.js by themselves.

00:22:00 - Brandon Bayer

Neither one of those are focused on an end-to-end, full stack developer experience. They're really focused on just their framework. It's a pretty smallish scope. What we're trying to do is much larger in scope. Gatsby, Next can be a part of that.

I mean, I think it works out nice because in our case, Next.js is just totally focused on the framework itself and the runtime. So it's Blitz. We don't even have to think about that. We just get features for free and it allows us to focus on the higher level developer experience and features on top.

00:22:29 - Chris Ball

I think when you know what your back end looks like, you can make a lot of really good decisions about developer experience. Everything from the way you're generating types to use. On the other side of the coin, you kind of know what both things are using versus if you're focusing only on the front end or only on the back end, you can't make those same kind of assumptions.

00:22:46 - David Price

So a lot of things were happening first and then now we're trying to put names to them, which is a very natural part of the process and is also showing that progress is happening. And so what I'm thinking around is with Redwood, and we started off even naming Redwood a full stack Jamstack framework. What do we mean? Why was that a part of descriptive marketing language even to start?

And it's been a lot around the methodology, leveraging infrastructure that's available now, leveraging the infrastructure we want to be available in a year from now. But it was all very methodology based and focused heavily on CD. I think a lot of terminology, I don't know if I've actually talked about this in a recorded podcast setting, but for me, when we say things like developer experience or infrastructure Jamstack, for me it all boils down to CD and continuous deployment. The more seamless that is, the more available CD is. And actually there's a lot of research on this, the more productive a project can be. It's just one of the key drivers to it.

[00:23:42] So what is full stack Jamstack and what isn't? I can tell you that we've already busted through what's available in a Jamstack infrastructure, since some of the more complex projects running Redwood right now are using container based deployment, and they've had to move off of the Jamstack infrastructure providers because they couldn't do what they needed to do for a complex application.

What is full stack Jamstack? I don't know. What do we want it to be? Now that I could talk about for a while. I think I am surprised. The reason I asked the question at the beginning is maybe we just don't know about it, but are other frameworks trying to do the same thing, given what our piece of the ecosystem, what we represent here have proven as possible this year? That's cool because that's happening, like possibilities.

But I am a little bit, I guess, surprised at how quickly we hit some limitations on the Redwood side with the projects we see being built.

00:24:34 - Brandon Bayer

That's really interesting. That is the very reason why I haven't hung the Blitz hat on the Jamstack post, because the limitations that, you know. So Blitz, just to be clear, you can deploy Blitz to a server or serverless. Redwood's the same way, same as Next.js. And so if you deploy serverless, then your endpoints are all serverless functions, can scale automatically and independently. So I love that. That's like the dream.

But I had an app where a Blitz app, I first deployed it to Vercel, but then it was failing because one of my API routes uses Puppeteer, serverless Puppeteer to generate a PDF. But on Vercel, Vercel is consolidating API routes in Next.js apps down to like one or two, or maybe more, depending on how many API routes you have. So you have a ton of code being bundled together, and then your bundle is too big and you don't have any control over it. That's because of Vercel itself. That's frustrating.

So I go back to Render. So now it's running on Render, but then I have some other issues.

[00:25:27] But anyway, so yeah, I love the serverless model. And I think Laravel Vapor, I look at that and people using it and it just sounds incredible. It sounds like the analytics company that's kind of privacy focused, they're running on Laravel Vapor. It's an alternative for Google Analytics, and it's a small company. Fathom. Yes, Fathom. It's built on Laravel and they're deployed on Laravel Vapor. And so it's all serverless. They have like serverless job processing there. They have server-side rendering. That's all serverless. Their API, and they're just scaling to like massive amounts. They had a DDoS attack. There's like an article that went to the top of Hacker News about this DDoS attack.

00:26:04 - Anthony Campolo

Yeah. Jack Ellis, I did see this.

00:26:05 - Brandon Bayer

Yeah, yeah. So they just like cranked up their limits or whatever. And they were just, they could handle the DDoS attack because of this. Serverless is just through the roof, like millions of requests per second or something. And it's just mind blowing. It's like, why is this so hard to get to that? Do we really have to learn Laravel? Like, well, let's bring that experience to JavaScript.

00:26:24 - Anthony Campolo

I've spent a lot of time kind of in the serverless world and listening to serverless podcasts and things like this. And what we're trying to do is kind of breaking the technology in the way it's intended to be used, because at least with Redwood, what we're doing is we're creating what they call a lambda monolith. And that's the problem is, these things were made to be small functions that can be invoked very, very quickly. And you can write your entire application as one giant function being executed by these things. But that's not what they were intended to do.

There's an impedance mismatch happening here between what the technology is meant for and what we're using it for. Either we need to break up our applications into smaller functions, or we need to invent a new type of lambda technology that works better for giant functions.

00:27:14 - David Price

A couple of things are happening there. AWS Lambda now supports containers and it's up to gigabytes of size. So that's really interesting. That's a Google Cloud Run model. Also, there's a Google Cloud Run deploy PR in our repo that I need to get committed. A phenomenal developer named Benko has been waiting patiently for me.

But right, that's all regions, multi-region, container based, serverless model. So that's changing. And I'm a huge fan of Cloudflare. There's a lot of runtime limitations, but what they're doing with V8s and their Workers edge network is really interesting because there is no latency on it. So I think those problems will be solved.

What I really want: low cost, high performance, and not to have to think about my infrastructure.

00:27:58 - Brandon Bayer

Totally.

00:27:58 - David Price

Where's that genie with those three wishes? Because those are the things, right? So I want a lot of magic and I want it really cheap. Are you listening, hosting providers? I say it out loud. It sounds just ridiculous, but that's kind of where they're going.

I find all these constraints on the Jamstack side. When we're using serverless, we're not getting charged the serverless model. We're paying in bulk, and it's actually quite expensive on some of the Jamstack providers. So that's interesting. We have all these constraints everywhere. So I'm not sure what's going to happen here, but it is available. I do think these types of infrastructure at a low cost, high performance are available. I'm just not sure what the final recipe is going to be. I'm not sure if the Jamstack hosting providers are going to end up being the final hosting providers for this FSJam model. I think it's actually up to us to create enough market share to force them to look at serving what we need. That's the mission that's before us.

00:28:49 - Chris Ball

From a technical standpoint, there's got to be some trickle down effect. If it's supported on AWS and it's supported over on, theoretically, Cloudflare. I don't have as much knowledge with that, but I saw they just released some stuff recently with Cloudflare Pages. All of these things are sort of like moving that way. You would think that services that are built on top of those primitives, if you will, should at least get some trickle down at some point and have the ability to go that route.

00:29:13 - David Price

Or we, this ecosystem here that we represent, start taking advantage of like the best of the hosting providers. So maybe there's some things from Cloudflare we want. Maybe there's some things from AWS we want, and maybe there's some things from Netlify or Vercel that we want.

00:29:25 - Anthony Campolo

So I like how Blitz is really driven into Render. And you guys have really found this kind of more niche layer to cloud that works really well for you. I think that's cool.

00:29:34 - David Price

Tell me, Brandon, I'm not familiar with what you're all doing.

00:29:37 - Christopher Burns

Can I interject first? Because I think what I'm going to say leads on to Brandon. I would love to see PM2 scalable without having to worry about Linux. And I think that may be almost Render because I found when I run my FSJam application, PM2 is the best place so far. It's the most responsive place, and it just feels a lot easier than hosting it on serverless.

And the other thing is, it's not quite Git-based deploy. I know you can do it, but it means making your own GitHub actions that call the PM2 commands and managing SSL certificates. And you start to get complex really, really fast. If a provider can literally be, here's a PM2 container, run whatever you want on it, I think that could also really work with FSJam. I think Render's already half there.

00:30:35 - Brandon Bayer

I'm not sure. When I hear PM2, I want to run away for my life. My eyes glaze over, like, what is this? This is scary. But Render, it's a simpler, cheaper Heroku. You can host static sites on Render. You can run containers on Render. It's easy to deploy a Node.js app. You can also deploy Docker. So it's really powerful. It's easy to host a database there, to link your database to certain containers, like automatically provide the environment variables, etc. It's really affordable. You don't get as many metrics and stuff as with Heroku, but it's cheaper and it's worked out pretty well.

A couple thoughts here with Next.js and Blitz. I feel like we're really close to this thing that I talked about with Laravel Vapor for deploying straight to AWS using the Serverless Framework. So there's already a Next.js plugin for the Serverless Framework. It supports basically everything that Vercel does with all of their serverless fancy stuff with Next.js and static prerendering and regeneration and so forth.

[00:31:34] This plugin is always some amount behind Vercel in actually implementing it, but people are implementing those features. All of those features run. You get them by default when you run next start. But to get that serverless, it's a lot more work.

So we're very close there. But the problem is it deploys to Lambda Edge and currently there's no way to deploy it to regional Lambda, which is what you need to be able to access the VPCs and be able to connect to RDS Proxy and all of that. There's a gap there that needs to be solved to be able to deploy using Serverless Framework to AWS regional Lambda.

And then a touch on what we talked about, like Vercel, that type of provider that's built on top of AWS. I think the problem is that providers are handcuffed to the big enterprise players, and they don't care about us. It's a power curve, right? So 99% of people in the United States work at companies less than 100 employees, 99%.

[00:32:29] But those providers are targeting the 1% that are the massive enterprise companies. That's where the money is, right? But then we get left out in the cold and we have to fend for ourselves. I think the best solution probably is to have nice frameworks and things to deploy directly to AWS, Google Cloud, etc., which is, I think, one reason that Laravel Vapor is so nice.

00:32:51 - Christopher Burns

It's almost like if any listeners want to create their own hosting platform for the FSJam infrastructure, I'm sure everybody would be very interested.

00:33:02 - Brandon Bayer

That has crossed my mind for sure.

00:33:04 - David Price

Yeah. No, we've talked about it. I'm sure you guys are the same place too. There's a lot of developer talent gathering around the FS, and a lot of those people are looking for things they want to build and start their own companies. Conversations come up a lot on the hosting.

So here's what I need for anyone out there that's looking to do a startup. Here's what I want you to build for me. I want you to look at my app, and I want you to intelligently figure out what my app needs. And then when I hit deploy, you go do all the things that need to be done to give my app what it needs, and I don't want to think about it. I just want to pay you for that service. Intelligently inspect my application, tell me what it needs, and then charge me accordingly. That would be fun.

You're right. On AWS, they're serving their customers, and their customers want granular control. Man, this sounds terrible. I also don't want to think about PM2.

[00:33:53] Right? As soon as I'm in there, I realize I'm off the track of the continuous deployments, the experience that I want.

00:33:58 - Chris Ball

Here's another one that conceptually I really want, but I know there's lots of stuff around it, and databases play into it as well. So we have this whole concept of workflows and preview deployments and all of that. That's a really big thing. And the big missing part for that for me is like separate database schemas.

We have a proof of concept of just being able to basically like you want an isolated version of your database for that pull request. And, you know, like Heroku has a similar thought to this, where like, but they spin up an entirely new environment for it. But it's one of those things where you need it for the lifetime and then you want to destroy it.

And so probably something that's like, I know Postgres can support tens of thousands of schemas and it's okay. Everything else, I'm not really sure the right path to do it. And so maybe schemas is a bad way to go. But just that general concept of we have isolated environments all the way up to the database.

[00:34:46] And then the database is shared. And so usually people just leverage the staging database and screw that one up with their migrations or anything like that. And I don't know if the answer there is, you now have to bring the entire database ecosystem into your hosting provider as well. I don't know, but having that integration somewhere would be huge.

00:35:04 - David Price

That's interesting. Won't Fauna? I have not used Fauna, but I think Fauna might provide that kind of integration workflow. Possibly. I'm not going to do FQL. I will tell you that. Speaking of things I don't like. Sorry.

00:35:17 - Anthony Campolo

Yeah. With FQL, your whole schema would be basically you're creating everything with functions. So it would be very easy to just have one giant function that sets up your database and seeds it exactly the way you want.

00:35:29 - Christopher Burns

I think Railway.app could be a solution to this. I've heard it linger in the Redwood community, but I believe they're brand new and they're still very early.

00:35:43 - Brandon Bayer

They're a competitor to Vercel, I think, if I'm thinking of the right company.

00:35:47 - Anthony Campolo

Tom has invested in Railway. I'm pretty sure that's true.

00:35:50 - David Price

I was gonna say I know a guy. He talked about it from the database side. That's what I know Tom was interested in when he brought it up.

00:35:55 - Brandon Bayer

The limitation that I think it has is it does not work with Next.js serverless apps. So like you can deploy static apps there, but the serverless function part of it doesn't work. I've talked to him and been like, as soon as you get that we can deploy Blitz apps there, but not until.

00:36:09 - Christopher Burns

This area is forever building. We have demand. We can say that when I checked statistics on frameworks on GitHub, Blitz is at over 5,000 stars. Redwood is at over 5,000 stars. Bison is somewhere under 1,000. If everybody wants to support this podcast, give a star to Bison, Redwood, and Blitz. That's how you support this podcast.

00:36:36 - Anthony Campolo

Yeah, stars. GitHub stars. You gotta have those internet points. Wrapping up here, why don't we give everyone kind of a chance to say what you're looking forward to for 2021, where you think FSJam is gonna go, who wants to go first?

00:36:50 - David Price

I'd like to kind of kick it off. I've already talked a little bit about it. It's amazing what happened in 2020 and there's so many things we didn't talk about. But Peter Pistorius, one of the co-creators of Redwood and who has authored a majority of the code, he said in March, when we put 0.1 out for Redwood publicly, we're going to get to the end of the year and we won't even recognize this framework. It'll be so different. And that's really true. It's come a long way. Again, the ecosystem has just come a long way and it's been really fun.

Hard to take that and go, oh man, what's going to happen next year? Because I think we're going to continue to see this, this rate of growth. We really haven't tapped into what this is going to be. We're still in the building phase. We're not in the acceleration phase right now.

Some things that we're looking forward to just in the framework itself is V1, which will communicate to the world that it's production ready and stable. Not much will change other than we'll put a label of V1, but there's some feature requirements we want to get done, and that's coming in the next couple of months. So that's really exciting.

The things that my part of the project that I'm focused on, the community that we've seen join, support, and get excited about Redwood. We were really intentional with the kind of culture that we wanted to seed that community with, and we've just watched that really propagate. That's what's mind blowing to me, how much the community is going to grow in the next year.

So not just these types of relationships, but also the community at large. I'm really excited about that. I'm also a little nervous because when communities scale, things can get a little awkward and don't always go well. I really want to make that not be the case. We're going to put time and resources in, and we'll keep doing this kind of stuff together as a group. But to make sure that the community experience continues to accelerate as well.

[00:38:29] I'm really excited about that. And then I think the third thing is we are just now starting to see people that came into the community with Redwood who were solo developers, experiencing development in community. Say I developed this by myself, but I couldn't have done it without the people that surrounded me. I collaborated with the community.

And then there's startups coming out that are now getting funded, and I've seen that happen three times with Redwood. That's going to be awesome because that's going to feed back on the system. Those people get excited about Redwood. They start hiring people in the community. Those people in the community get excited, and that's going to happen right across this ecosystem in FSJam.

And that's where we're going to start to see things really take off as the things that these frameworks start to give context to for people to collaborate and the things the startups they produce as those things start to contribute back to the frameworks themselves, both people and time. And hey, we should be doing this over here.

That's going to be really exciting. That'll feel like New Frontier all over again. Those are my things. Thank you for letting me run with that for a little while.

00:39:32 - Christopher Burns

One thing we haven't spoken about is React. React is such a big part of all three of these apps, but it's not necessarily a big part of FSJam if we talk about the core principles. So maybe in 2021 we will see alternatives to React. So maybe an FSJam framework with Vue or Svelte.

Anthony's nodding, I got that right. Those technologies I don't keep up with much, but I hear Vue 3 is going to be really big. Maybe we'll see additions to FSJam next year.

00:40:09 - Chris Ball

I mean, I would agree with everything. I feel like this year has been the year of this is an idea. These are some potential ways to go about it. Here are some things that we feel like will stick, but we need to try them all out first. We've kind of gotten through the we're trying them out sort of phase. There's a lot more to do.

So I think it's really about just kind of consolidating and collaborating. And there's going to be different viewpoints to each sort of thing. But I think that there are a lot of areas of overlap. I just feel like the ecosystem in general should grow. And maybe part of that story is additional languages. It's not a huge lift for someone to take Nuxt and build on top of that, in the same way that some of us have chosen to do with Next. That brings a whole slew of additional people.

I think the point David made about startup success stories, it's huge when there's a startup that people like their product, they say, wow, this thing is like really nice. And how did you all move so quickly? And just them hiring internally? There's a lot of kind of buzz that just happens naturally. I totally agree. That's going to be a big area too. The more that we can say people are building on this successful thing, this isn't just like try it out for fun, but you can use it in production.

00:41:12 - Brandon Bayer

So going into 2021 with Blitz will also be focused on getting to 1.0 here within a few months. Throughout the rest of the year, there's a ton of user experience, developer experience things that we can improve with Blitz. What's there is still just a small part of what we want to get to. It can be so much more. It's already good, but it can still be so much better.

Something else I will be focused on throughout the year is mobile app support. What we want to have is first class integration with Blitz and mobile apps, so that you get the same zero API experience. Like you don't have to have a REST or GraphQL API, but you also have an app. And so it's like one massive monolith with your web app, your mobile app, and your Blitz back end.

And then also the community, same as you mentioned with Redwood. We'll be continuing to focus on the community with Blitz. We're already seeing people hiring Blitz developers. So I'm sure that's going to increase and accelerate. So that's cool. So Blitz is really good for boot camps and students because it simplifies the architecture and so there's less things to learn. It's easy for them to build things. So we're already seeing a lot of students using Blitz to do projects in school. I think that'll continue. And I would love to see bootcamps start to entertain Blitz too.

00:42:28 - Anthony Campolo

Oh man, all of you guys said things that I've been saying for so long. It is so great to kind of get the validation for using these tools for teaching, using Nuxt to build a full-stack Vue thing. We're creating these communities that are enabling everyone to not only build things, but also get jobs and get paid.

I'm really looking forward to all of that, and I'm looking forward to V1 and getting to actually say these things are here, like they're ready to go. This isn't just a thing that we're thinking about that's going to be cool one day. This is a thing now, today. That's what I'm really looking forward to, and I'm looking forward to getting a job in 2021. So anyone who wants to hop on this rocket, hiring me would be a good way to do it.

00:43:16 - David Price

Well, yeah, that would be. This needs to be sustainable. Tom talks a lot about long-term maintainability. This also needs to become sustainable for everyone involved with it. So I hope that becomes true in 2021. That is not an easy thing in open source at all, and definitely not a problem that's been solved.

The Redwood circumstances are much more similar to what's happened with a company sponsoring a project, more where React is coming out. So that's different. But hats off. I know the challenges. And Brandon especially, you're literally bootstrapping a thing. Not only are you bootstrapping, but it's open source. So it's free to the world. But hats off, I'm excited.

So I'm saying this right now because anyone listening to this podcast for all these frameworks, but for Blitz.js especially, there are ways you can support the project financially. If you want to see open source survive and thrive, the model of that hasn't been figured out yet, so just give them money. Don't worry about the complexity. Just say I want more open source like this in the world. So just give them your money. That's the best way you can support it right now.

And there's a lot of ways to do that for Blitz and Chris, I don't know as much. I know that Echo Bind is a consultancy, but I'm sure there's other ways people could support your project as well. So hire Echo Bind. We want this technology to go forward. Using it is one thing, but there are a lot of ways to contribute to it. And cold hard cash, it turns out, is very effective.

00:44:34 - Brandon Bayer

Yeah. Thank you for that. We keep having more and more sponsors coming on board. So Fauna is a sponsor. Render is a sponsor. As people are having production apps, production Blitz apps running, they're starting to come in and sponsor like $100 a month or even more. That's super encouraging too.

So as we get more people running production apps, they'll be coming back. There's at least one company that they have a vision of hiring one or more developers to work on Blitz. So like somebody, some other company is paying them to work on Blitz. And I think that's a bit similar to how Ember works, perhaps, maybe Rails too.

00:45:12 - David Price

We were thinking of doing a marketplace kind of forum category, but Anthony and Chris, there you go: the FSJam hiring board. Jobs board. Yeah, so fun. Brandon, hire Chris Ball's consultancy. You need to hire Anthony. He's looking for a job. I need to fund Chris because Chris has Everfund, which is a phenomenal product that they've just got out the door.

So you support the FSJam, and yeah, jobs board. Brandon, that'd be, I'm thinking the same. I want to see the community get hired as well.

00:45:40 - Anthony Campolo

Yeah. We talked about this on the Blitz episode, how Blitz has started to do job board type stuff. You have like a jobs category in your Slack. You guys have a couple different ways to kind of get job information out there. Yeah, I think every framework should start doing that.

00:45:54 - Christopher Burns

I think my final point: the commercial side of these frameworks is yet to be built. People tinker with them first and then they build with them in their companies. What I would love to see when the framework shows off, here's some of the people using it. It's not just here's your generic logo of Google, Booking, and whoever else. It's the small companies where that exposure can really make a difference.

To round this up, we will go around and say where we can be contacted personally or through the framework. Both is fine. On Twitter I am Burned Chris.

00:46:35 - Anthony Campolo

And you can find me at AJC Webdev on Twitter or Dev.to or GitHub.

00:46:42 - David Price

David Price, because there's thousands of me and I am neither the popular nor the rich and famous ones. You can find me at The David Price on the internet. Twitter's a great way to get ahold of me, DMs, or even better, find me on the Redwood forums or the Redwood Discord chat. We'd love to help you get plugged into the Redwood community. Any way I can.

00:47:01 - Chris Ball

Similar to David, there are a lot of people with my name. I am [unclear: cball_] on Twitter. Also, feel free to hit me up or hit any of us up on the team at Echo Bind.

00:47:11 - Brandon Bayer

I am [unclear: flybayer] on Twitter. You can check out Blitz.js.com and join the Slack community there.

00:47:19 - Christopher Burns

Thanks for your time. This was so exciting and I was so looking forward to this.

00:47:24 - Brandon Bayer

Merry Christmas.

00:47:25 - David Price

Merry Christmas, happy holidays.

00:47:26 - Unidentified speaker

We'll see you guys in 2021.

00:47:27 - Chris Ball

Yeah. See you, family.

00:47:29 - Christopher Burns

Thank you.

00:47:31 - David Price

Yeah.

00:48:02 - Christopher Burns

Speak to you soon. And let's hope 2021 is a boom, a bang, a bang.