The Fullstack Jamstack Podcast

Episode Description

Anthony Campolo and Christopher Burns launch their podcast by explaining the Jamstack, full stack Jamstack frameworks, and their mission to unite the community.

Episode Summary

In this inaugural episode of the Fullstack Jamstack podcast, hosts Anthony Campolo and Christopher Burns introduce themselves and lay the groundwork for their show by unpacking the concepts behind the Jamstack and its evolution into full stack territory. They begin with the basics—JavaScript, APIs, and markup—before tracing how static site generators and meta frameworks like Gatsby and Next.js emerged as "distributions" of React. The conversation moves into the shift from monolithic applications and traditional server hosting toward decoupled architectures served over CDNs, and how services like Netlify and Vercel accelerated that transition. A significant portion of the discussion centers on Prisma, with Chris drawing on his own experience building full stack applications before dedicated frameworks existed, recounting the sometimes confusing evolution from Prisma one's GraphQL-based server to Prisma two's simplified client. They then examine the emerging full stack Jamstack frameworks—Redwood, Blitz, and Bison—comparing their differing opinions on GraphQL, CSS, and data layers while identifying the shared pattern beneath them. The hosts close by articulating their goal: to foster a community that bridges these frameworks, encourages cross-pollination of ideas, and welcomes contributors from Vue, Svelte, and beyond.

Chapters

00:00:00 - Introducing the Fullstack Jamstack Podcast

Anthony and Christopher open with some lighthearted pre-show banter before formally introducing themselves and the podcast. They pose the foundational questions—who are they, what is Fullstack Jamstack, and why should listeners care—setting the stage for a deep exploration of the topic.

The conversation quickly moves into the meaning of the Jamstack acronym itself. They debate whether the "M" stands for markdown or markup, with Anthony noting that while markup is the official designation, markdown plays a significant role in many Jamstack workflows. Chris shares that his own experience has leaned heavily on headless CMS tools like Contentful and Sanity rather than raw markdown files.

00:03:43 - What Is the Jamstack Architecture?

Christopher frames the Jamstack as an architecture rather than a specific toolset, contrasting it with the monolithic applications of the recent past. Anthony explains the client-server model and how WordPress exemplifies tightly coupled, monolithic design, where the frontend and backend are difficult to separate.

They discuss how the Jamstack philosophy promotes decoupling frontends from backends so developers can mix and match data sources and view layers freely. Chris elaborates on how a universal JavaScript frontend connects to various services—whether third-party SaaS products like Auth0 and Contentful or custom-built serverless functions—to compose a complete application that gets pre-rendered and served from CDNs for fast load times.

00:08:08 - From Create React App to Meta Frameworks

The hosts trace the developer journey from Create React App in 2016 through the rise of what Chris calls "distributions" of React and Anthony calls meta frameworks. They explain how CRA abstracted away Webpack configuration but lacked a full persistence layer, leading developers to host apps on services like AWS EC2 or eventually platforms like Netlify and Vercel.

This evolution gave rise to frameworks like Gatsby and Next.js, which introduced static pre-rendering and rehydration. Anthony extends the meta framework concept beyond React to include Vue-based tools like Nuxt and Gridsome and Svelte-based options like Sapper and Elder, noting that React was always a UI library that naturally invited higher-level abstractions to be built on top of it.

00:13:44 - The Prisma Story: From Version One to Two

Chris draws on his personal history building full stack applications to explain Prisma's role as a key data layer tool. They walk through Prisma one's architecture, which required an always-running dockerized server, and its sometimes confusing relationship with GraphQL—a point the hosts humorously debate in real time while Chris checks his own code.

The discussion clarifies how Prisma one's GraphQL endpoint and Nexus client eventually gave way to Prisma two's simplified stack, which eliminated the intermediary server and allowed direct database communication from serverless functions. They note that Prisma two was ultimately just rebranded as Prisma, reflecting the team's desire to move past versioning confusion and offer a cleaner developer experience.

00:22:10 - The Rise of Full Stack Jamstack Frameworks

With the foundational pieces in place, the conversation turns to the frameworks that define full stack Jamstack: Redwood, Blitz, and Bison. The hosts explain how these meta frameworks bundle React, an API layer, and database connectivity into coherent monorepo solutions that can be deployed to platforms like Netlify in a single step.

They compare the frameworks' differing opinions—Redwood's commitment to GraphQL versus Blitz's preference for React Query, varying CSS approaches with Tailwind and Chakra—while identifying shared patterns like Prisma integration and JavaScript-first architecture. Anthony also highlights full stack Jamstack work happening outside React, pointing to a Vue-based project using Gridsome and Strapi, and speculating that Svelte equivalents will emerge soon.

00:29:49 - Building Community and Looking Ahead

Anthony and Chris articulate their vision for the podcast as a unifying force across the full stack Jamstack ecosystem. Rather than championing one framework over another, they aim to bridge the communities around Redwood, Blitz, Bison, and future entrants, encouraging idea-sharing and collaboration toward a common goal.

They close by inviting listener participation through their Twitter account and Discord server, welcoming questions for a Q&A segment and guests of any experience level who want to discuss their work in the space. The hosts emphasize their complementary strengths—Anthony's theoretical knowledge and Chris's practical implementation experience—as a foundation for engaging, accessible conversations in future episodes.

Transcript

00:00:00 - Anthony Campolo

That could be a great question for this episode: What is Fullstack Jamstack?

00:00:04 - Christopher Burns

What? Yeah, exactly.

00:00:06 - Anthony Campolo

And who are we?

00:00:09 - Christopher Burns

Who are we? Those are our two questions. I'm just going to be a bit annoying and ask: What is the point of the podcast? Obviously, to me, it is to teach and inform.

00:00:27 - Anthony Campolo

How do you separate teaching from informing?

00:00:30 - Christopher Burns

That's a good question.

00:00:44 - Anthony Campolo

Hello everyone. This is the Fullstack Jamstack podcast, and we're your hosts, Anthony Campolo.

00:00:51 - Christopher Burns

And Christopher Burns.

00:00:52 - Anthony Campolo

All right, episode zero. So you're probably wondering: Who are we? What is this? Why are you listening to this? We're going to explain. What is Fullstack Jamstack? We're going to talk a lot about what it means to us and our experience with it.

First thing we want to talk about is what's the point of this podcast. What is the point of this podcast to you, Chris?

00:01:12 - Christopher Burns

The point of this podcast is that I believe jam is such a wide range of things. What is jam? JavaScript, APIs, and markdown, markup.

00:01:27 - Anthony Campolo

That's a great question: markdown or markup. I usually hear it's markup when I look it up online. But so much of what I think of as Jamstack actually does involve markdown specifically. For those who don't know, markup would be anything like HTML or any sort of markup language, whereas markdown is a very specific lightweight markup language used in GitHub READMEs and on things like Dev.to. I usually think of markdown as being a really important part of the Jamstack, but I think usually they go with markup.

00:02:04 - Christopher Burns

Well, I've been doing Jamstack websites now for a few years, and I don't think I've ever used markdown. I would go with markup.

00:02:12 - Anthony Campolo

Even in a Gatsby site, you don't use markdown?

00:02:15 - Christopher Burns

Sadly, most times that I've actually built websites with Jam, I've always gone with a third-party CMS source, like Sanity or Contentful or even Netlify CMS.

00:02:26 - Anthony Campolo

Do they have GUI editors that use it?

00:02:28 - Christopher Burns

Yeah, all three of them have GUI editors, especially Contentful. The one that I'm most familiar with is Contentful, the headless CMS. But basically it's really easy to just plug in with Gatsby and get going. But that's not what we're here to talk about.

00:02:42 - Anthony Campolo

Those kinds of CMSes are a big part of the Jamstack.

00:02:44 - Christopher Burns

Well, are we here to talk about jam and jam, or just jam?

00:02:49 - Anthony Campolo

Yeah. Well, I think to talk about jam, people need to know what jam is first. So I think it is important to set that context. We've said that the acronym is JavaScript, APIs, and markup. But it's also worth mentioning that they're trying to phase out the acronym. That's why you now see it as lowercase jam instead of uppercase JAM. The idea is that there's lots of different tools and lots of different languages that do this, not only JavaScript, because this kind of started with things like Jekyll and Hugo, which are Ruby and Go.

00:03:19 - Christopher Burns

And wait until we get to Rusty Jam.

00:03:21 - Anthony Campolo

For, like, Rust the language?

00:03:23 - Christopher Burns

Yeah, I've not touched Rust, but I know there are tons of people that build JavaScript tools in Rust. I don't even know how you would do that.

00:03:31 - Anthony Campolo

Yeah, Rust is really fascinating. I've read the first chapter of the Rust Hello World book, which is really fantastic. I highly recommend it. We'll put that in the show notes, but we're definitely not here to talk about Rust.

00:03:43 - Christopher Burns

No, but what is jam? Jam is an architecture. And what does that mean? For a while in computing, in web development, we would run servers, monolithic applications.

00:03:59 - Anthony Campolo

So the server is the other half of the client-server model. If I'm the client, I'm a person on my phone trying to find my thing online, and to get that information, I'm hitting a server.

00:04:11 - Christopher Burns

Most typically this would be WordPress. If we talk about back in the day, five years ago, that was the case.

00:04:18 - Anthony Campolo

In my day.

00:04:19 - Christopher Burns

Back in the day, five years ago.

00:04:21 - Anthony Campolo

WordPress being an example of a monolithic application.

00:04:24 - Christopher Burns

I truly don't know what monolithic even means. I don't want to be that guy, but there are just too many terms sometimes.

00:04:30 - Anthony Campolo

This is great, though, because monolithic has to do with full stack. I think it's a thing that full stack applications have kind of been saddled with as an insult, being like, "Oh, this is too monolithic. We need to break up the monolith." I think the idea of the monolith is when your full application is tightly coupled, in the sense that you have your database backend where the data is actually being persisted, and then you have your front end, your views, which is whatever visual thing is happening. And if those two things can't be easily separated from each other, then it's a monolith.

And so the Jamstack is the idea of having your backends and your front ends be highly decoupled, because then you can make your front end look however you want, and you can easily plug it into different backends to get the data. And then you're not locked into either one specific data source or one specific view layer.

00:05:24 - Christopher Burns

To add on that, with jam we have a universal front end, normally in JavaScript, as the J stands for. And then what we follow with that is services. A service can be anything that provides interactivity when the website loads, or works at build time to help build the content into a static website.

If we talk about those services, they either go one of two ways. You have software as a service where they encapsulate a function for a specific purpose, such as a service for logging in your user, like Auth0 or Magic Links or Netlify. Then you will have a content management system that will be fetching the data of what to import onto the web page, such as Contentful or Sanity, or even WordPress these days.

And then you have the other side. You have services that are basically paid companies giving you functionality, and your Jamstack frontend builds it all together into either an application, a static website like a blog, or the other side that's a fully built service by yourself.

00:06:39 - Christopher Burns

So that is functions that you build yourself that feed into your front end.

As this has been built out, we have seen the market move and change and be created quite fast for what we believe is this brand new area of jam. Anthony was the first one to even think about it, but I was the first one to coin it to a certain extent. Think about it.

00:07:04 - Anthony Campolo

I don't think either of us are the first ones. I think that Redwood was calling themselves Full Stack Jamstack before either of us thought of it.

00:07:10 - Christopher Burns

What I meant was I was trying to go on to explain what FSJam is. I was talking about it.

00:07:15 - Anthony Campolo

About full stack React before I was really thinking about full stack Jamstack. And that's kind of what led me into thinking about full stack Jamstack, because the idea of full stack React was something that was really relevant to me as a boot camp student learning React. You learn it in a very decoupled way, like you learn it just by itself, which is great. It makes sense pedagogically and from a curriculum standpoint, but eventually you have to actually build something with it. Eventually you have to connect it to all this other stuff to get it to do anything useful.

And so that's why the idea of full stack React was something that I was thinking about a lot. And there's a really great podcast interview between Michael Chan and Adam Wathan where they talk about this. It's called "React Is Not a Rails Competitor." As I was reading about that and becoming interested in that, things like Redwood and Blitz and now Bison started coming out, and we're specifically using the term full stack Jamstack and building with React.

00:08:08 - Anthony Campolo

When we say full stack, what does that mean?

00:08:11 - Christopher Burns

First, before we say what does that mean, it's to say, what has it come from? Simply put, everybody takes React and the concepts of JavaScript in different ways, in different speeds, in different directions. When you first start learning React, your first thing to do is to do Create React App. Well, it started before Create React App, but that's how a lot of people started.

00:08:32 - Anthony Campolo

It came out around 2016. They wanted to take the configuration away, so they didn't want to mess around with the Webpack stuff. It was meant to abstract away the initial configuration setup, but it wasn't meant to provide a full solution with a persistence layer.

00:08:48 - Christopher Burns

Exactly. In 2016, in early Jamstack, what people did was create their React apps and then host them themselves in multiple different environments, such as things like EC2s if you would have to host it yourself.

00:09:01 - Anthony Campolo

EC2 being a main server that you rent from AWS, Amazon Web Services. If you want to just spin up a basic server running Linux or some flavor of it, you get an EC2. And then there are similar versions of this for GCP and Azure, or even like DigitalOcean or Linode. And people are using services like Netlify, Vercel. People still also host on the layer one, but I find that a lot of people have started moving to these other services, and this is where I start to think of it becoming like the Jamstack and not just hosting a static file, once these kinds of services started coming out.

00:09:40 - Christopher Burns

And this is where it moves on to how the Jamstack started when we originally got Create React App. Then people found out that while the configuration was great, it wasn't enough. I like to call them distributions of React, distros. So if you think of Linux, I always think of them as distros, because if you think about how Linux works, Linux runs under every single distribution, and that is Ubuntu or Mint. Linux runs under all of them. With React and Jam, a lot of them run React as the base layer, such as Gatsby and Next.js. These were the first, I would say, prominent ones after Hugo.

00:10:19 - Anthony Campolo

Yeah. So what you call a distro is what I, and I think a lot of people, are calling meta frameworks, which is a framework that's built on top of another framework or a library. I don't want to get into the library versus framework argument when we're getting into the meta stuff too. So I just abstract all that away and say, if you're building on top of React, you're a meta framework. This would be, for React, Next, Gatsby; for Vue, it'd be Gridsome or Nuxt; and then for Svelte it would be Sapper or Elder. I've been calling them meta frameworks. I know some other people use that terminology. I think I've heard other people call them distributions too.

Yeah, I think it's a really interesting idea. React was always saying we're a JavaScript library for UI, and it wasn't meant to be this full solution. So it's natural that we would build these layers of abstraction on top of it.

00:11:09 - Christopher Burns

And with things like Gatsby and Next came the concept—well, it obviously came before—of statically hosting the file with pre-rendered content that would then be rehydrated after page loads with more JavaScript.

00:11:27 - Anthony Campolo

You could then distribute it across a geographic region. You could have those static files hosted on many servers around the world. Then, for someone like yourself across the pond, you wouldn't have to hit Virginia every time you want to get your data.

00:11:42 - Christopher Burns

By hosting the HTML on a CDN, the code is always at the edge of the network. Load times are brought way down. That's really how jam started, and what we see jam being now is this very much an amalgamator, an amalgamation of all of these services and all of these systems and functions built into one pretty package. That's the end product.

00:12:09 - Anthony Campolo

Ideally, that's what we're trying to get to.

00:12:12 - Christopher Burns

As it started to grow, people started really saying, cool, it's great. I could connect to these five services to build my blog, but what happens if I want to build something a bit more complex, like a dashboard, a SaaS application?

00:12:26 - Anthony Campolo

What if you want Twitter for pets?

00:12:27 - Christopher Burns

I need to build my own functions, my own data, my own magic. And that's where FS comes in. And what we think full stack jam is, is all the benefits of jam built with your own technology and magic, calling your own functions. What else?

00:12:47 - Anthony Campolo

So when I think of full stack Jamstack, I think of your whole application being coherent. It doesn't necessarily have to be a monorepo, but the idea is that your whole project is coherent, in the sense that it's not this super distributed thing where you're hitting all these different services and you have to figure out, you know, like, where should I be doing logging? Where should I be looking for a stack trace?

All of your stuff is in one single place. You can think about your front end view, you have some sort of controller layer, and then you have some sort of database kind of model. It doesn't have to necessarily be MVC, but I think having those different pieces all together in a way that's fairly coherent is, for me, what is really important here.

Having to learn all these different technologies is already challenging enough that if you don't actually understand how to integrate them and what your data flow is, your problems compound so much faster.

00:13:44 - Christopher Burns

Very much so, but I think it's really worth talking about the key pillar of FSJam: Prisma two and ORMs. I could give some really good context here.

00:13:54 - Anthony Campolo

Yeah. So let's talk about that. We've been talking about having your front end and your back end connected in a way that makes sense. You don't want it to be monolithic. You still want to be able to separate the two pieces, but you want to have them integrated in a way that makes sense.

And I think part of how you accomplish this is by having a really good tool to mediate between the two layers. There's a couple terms we're going to throw at you. ORM is object-relational mapper. Prisma does not define itself as an ORM. It defines itself as a query builder. A query builder is like an ORM, but it's slightly lower level, so it's closer to the database. It's closer to the metal in general. Query builders are tools that we use to mediate between our front end and our back end, and Prisma two is one of the few consistent components of all three of the frameworks that we're going to be talking about a lot.

00:14:46 - Christopher Burns

I think it starts with Prisma one.

00:14:48 - Anthony Campolo

Great. Let's talk about Prisma one and Prisma two. Most people probably don't know.

00:14:53 - Christopher Burns

Prisma one is the original version of Prisma. It used to just be called Prisma.

00:14:59 - Anthony Campolo

Actually, you know, the original version of Prisma was GraphQL.

00:15:02 - Christopher Burns

GraphQL. Yeah. GraphQL. But okay, I have a lot of history with Prisma, one that I can obviously talk about, but that involves talking about how I built an FSJam before FSJam.

00:15:14 - Anthony Campolo

Give as much context as you need. I think that's actually a great thing to talk about, the fact that this is a term that's being put on a thing that describes something you've already been doing.

00:15:22 - Christopher Burns

Yeah. Prisma one came around, and the real use case of it was that you could easily write to a database using a common interface, such as a JavaScript library. You would put all the things you need into a query and bish bash bosh, it would be in your database five seconds later.

There were a lot of drawbacks to Prisma one versus Prisma two. For example, with Prisma one, you had to have an always-running server. Normally in a dockerized system, your application, while it could be compiled down to JavaScript using something like Gatsby, would be communicating with an always-online server, and that always-online server was communicating with the database.

00:16:05 - Anthony Campolo

What does that have to do with GraphQL?

00:16:07 - Christopher Burns

What does this have to do with GraphQL? They didn't use GraphQL for Prisma one. Technically you don't need GraphQL for Prisma two.

00:16:12 - Anthony Campolo

Well, I thought they did use GraphQL for Prisma one, and then they stopped using GraphQL for Prisma two. And that's why there's all this confusion about whether Prisma is GraphQL or not.

00:16:20 - Christopher Burns

You know what? I'm going to have to check my repository base now in Prisma, because I'm not sure.

00:16:24 - Anthony Campolo

What you were describing for Prisma one, I've heard that exact same description. It's a GraphQL server. The server you were talking about was a GraphQL server.

00:16:33 - Christopher Burns

It is, it is. No, it isn't. It is, it isn't. I think the ORM was in GraphQL. No, because it did REST. Let me just check my API.

00:16:43 - Anthony Campolo

You can do REST with GraphQL. You build a GraphQL layer on top of your REST endpoint so that you just have that one kind of god API endpoint, and then you're just hitting that and sending the queries.

00:16:54 - Christopher Burns

So what you're talking about is actually Nexus, which was built in GraphQL.

00:16:59 - Anthony Campolo

I think Prisma one essentially kind of forked into different projects. So they took the GraphQL part out of it, and that's what now is Nexus. Based on the research I've done into this, that seems to be what happened.

00:17:09 - Christopher Burns

Okay, okay, I'm just looking at my code, and no, Prisma one in essence didn't use GraphQL. It was just interesting. Just like Prisma two, it's an npm library that you obviously import and you build and then import in.

00:17:25 - Anthony Campolo

Nothing like schema definition language or anything like that. There's no resolvers.

00:17:29 - Christopher Burns

No. But that's where they built Nexus, I believe, was the name of it. And obviously these tools have been developed further with Prisma two. But basically the whole point of Nexus was: cool, you've built an API with Prisma one, why not also open that to your front end? It's all coming back to me now. Sorry. Yes. Okay, now we got it. Prisma number one, the original communication method was a GraphQL endpoint.

00:18:01 - Anthony Campolo

You don't say.

00:18:02 - Christopher Burns

I know. I just remembered. I'm looking at my code. You have to think this was...

00:18:08 - Anthony Campolo

This is amazing because I had to figure all this out before I even used either Prisma one or Prisma two. When I was learning this, I hadn't used any of these freaking tools. And I was like, okay, so Blitz uses GraphQL, right? Because it uses Prisma. Like, no, Prisma doesn't use GraphQL. What are you talking about?

00:18:25 - Christopher Burns

There were two parts to Prisma. One was the Prisma client, and Prisma Nexus would connect to your GraphQL endpoint of Prisma one. So Prisma one GraphQL endpoint, and then it would build a client that you could interact with in JavaScript.

00:18:45 - Anthony Campolo

That makes perfect sense because that's what we still have now. With Prisma two, you have a JavaScript client that gets created, but that is now abstracted away from GraphQL.

00:18:55 - Christopher Burns

You could have used just the GraphQL endpoint without the Nexus part, but it was basically an open server that you could do whatever you want with. You have to imagine it was a three-hop process. Your front end would jump to your server, your server would jump to Prisma one, and then the Prisma one service would talk to the database, and then all the way back.

With Prisma two, the stack was simplified with no always-running runtime. What does that mean? What actually happens now? You speak to your service or your API. Your API then directly speaks to your database. I do not truly remember how they do this voodoo magic, but it does a lot in the background using their clients.

00:19:41 - Anthony Campolo

That's why you're using it so you don't have to figure that out yourself.

00:19:44 - Christopher Burns

Exactly. Why do I know so much about Prisma one? Prisma one was the base, and with Prisma two, a lot of things were moved around, simplified, and expanded. Prisma two was renamed to Prisma.

00:20:01 - Anthony Campolo

Yeah, they were going to call it two, but then they're like, nah, let's just call it the first thing and then we'll wait it out. Eventually, people will forget that the other thing was a thing, and we'll just have to deal with like a year of everyone being confused.

00:20:12 - Christopher Burns

Yes. So now it's just Prisma because we don't like second versions anymore. So that was one part, but before FSJam and these frameworks that we'll talk about in a minute, you still had to run your own services. How did people do that? Well, the popular method was using Serverless Framework, where you would write your own functions and that would push them to AWS for you.

00:20:35 - Anthony Campolo

Or as far as I know, the Serverless Framework is an abstraction on top of CloudFormation.

00:20:40 - Christopher Burns

Yes, but it also compiles to other providers now. But basically they took the approach of zip it and ship it. They do all the management of uploading it to AWS, getting it running on AWS. You run one command and they give you an endpoint URL and you go. Hooray, I've saved myself X amount of hours.

So in the past we had, say, our front end in Gatsby, or just Create React App that then connected to a serverful or serverless server, and that serverless or serverful server would speak to that Prisma one client and hop back and forth. As you could expect, that required a lot of management, a lot of developer time.

In my case, you were deploying your own functions to AWS, managing a dockerized Prisma container. And also, where is your front end uploaded? For me, it was Netlify and all those technologies. I saw early on and thought this is the future, but I had to basically build my own glue there.

00:21:42 - Christopher Burns

And then Prisma two happened, and that's what we get onto today with FSJam. Prisma two simplified the stack. As we said, you could easily connect and talk to a database with your serverless functions, making it easier for developer experience. What came next was the big point, the explosion it started. Obviously we can't say which one came first, Redwood or Blitz.

00:22:10 - Anthony Campolo

Sure you could.

00:22:11 - Christopher Burns

Well, this is the point. You could say this one was first.

00:22:14 - Anthony Campolo

Look at their commit history and see which commit is first.

00:22:16 - Christopher Burns

First. But Peter and Tom from Redwood have said they've been working on it for the last two years, and they could have moved it around different repos, removed the git history, restarted it. The concepts have been around, but the biggest thing that came with FSJam is the magical abstraction layer that came above it. They are in the form of meta frameworks, as Anthony likes to call them, such as Redwood and Blitz.

And what they allow you to do is basically abstract multiple things into one framework. React has gone from just being a UI library to being a management tool for a front end, and also integrating a monorepo solution and API. Your functions and your front end would be zipped and shipped to Netlify, and Netlify would build them. And there you go, you have a full application. Your React can speak to your server, and your server speaks to your database, back and forth. This is very much a brand new area, and there's a lot to discuss.

00:23:25 - Christopher Burns

But the biggest point that always will come up, and this is where we talk about the philosophies of FSJam, is that each meta framework will tackle this subject very differently. What we like to think of FSJam is a pattern. And what we mean by pattern is: what tick boxes does each one of these frameworks tick to say, this is an FSJam framework?

I would say the first one would be easy management of an API with a front end, with something like Prisma two. But this is where you say, I don't want to use Prisma two, I want to use Fauna. Technically, Prisma two is not a required bit of technology. Really, it's, I would say, the services connected to the front end, transferring that data between your own API and your own front end. What would you say the next one would be, Anthony?

00:24:17 - Anthony Campolo

For me, it's having some sort of language that both your front end and back end speak. So this may be GraphQL, but it doesn't have to be. It could be just JSON API. Basically, you have a consistent data structure or language that allows your front end and your back end to know what they're speaking. It makes type safety easy and makes querying easy.

I find that a key differentiator between Blitz and Redwood is that Redwood is all in on GraphQL, whereas Blitz draws you away from GraphQL. You can use GraphQL, but the default is really not to. There's not really requirements, I think, so much as preferences. Prisma is not a requirement of FSJam, but it's the preference of these frameworks. And so there are some things they all have a similar preference on, and there are some where they differ. Like they don't all use Apollo; Blitz uses React Query instead of Apollo for their client, I believe, and they don't necessarily agree on CSS.

00:25:18 - Anthony Campolo

Some go heavier into Tailwind, some go into Chakra. I believe Bison uses Chakra. I think Blitz is agnostic to CSS. So is Redwood, but we have a Tailwind generator. So I think Tailwind is the favored choice even though it's not required. I think looking at these different stacks, there's really interesting comparisons to draw between them.

00:25:38 - Christopher Burns

I think the key bit of information to take away from this is that when you say, I want to start learning an FSJam framework, you really got to say, what opinions am I happy with and what opinions am I not happy with? For example, I know I could be building a multi-client service that could have a TV app and a web app. So you would want a unified interface such as GraphQL. So Blitz.js may not be your default choice; maybe Redwood is. But if you want more of a typical monolithic, you would go with something more like Blitz.

But the area is still brand new. I would even say that React is not a requirement, it's more of a preference. We are yet to see FSJam be tackled in Vue or Svelte.

00:26:31 - Anthony Campolo

This is something I'm really interested in: full stack Jamstack stuff that is not in React. I haven't seen the term used very much, but I've definitely seen projects that I would consider FSJam. We'll link to this in the show notes. There's a really great video by a YouTuber, Faraday Academy. Her name is Gwen. She put together a video where it's Gridsome and Strapi. So Gridsome is kind of like a Gatsby for Vue, and then Strapi is like a CMS back end that has a lot of flexibility. She built out a full stack Jamstack application with Strapi and Gridsome. I thought when I saw it, I was like, this is it. This is exactly what we're doing, but in Vue.

Since you look at the timelines of these things, I think Svelte is probably going to be a little bit behind just because it's newer. I imagine that over the next year or two, we're going to start to see these things emerge in Svelte world as well.

00:27:25 - Christopher Burns

I would also say that you could say that you have brownfield FSJam. What is brownfield FSJam? I would define Gatsby as brownfield FSJam.

00:27:38 - Anthony Campolo

Them's fighting words.

00:27:39 - Christopher Burns

Yeah, such as: you could build your own Prisma two serverless infrastructure that is connected to Next or Gatsby, and that's more typical jam with the FSJam added to it. I would call them brownfield FSJam, but we have the greenfield FSJam, the first three, and I'm sure there'll be many more. I'd love to see many more even in Vue. And yes.

00:28:04 - Anthony Campolo

It means slim and slender because everything gets compiled away, so you have a really tiny bundle. That's why it's called Svelte.

00:28:11 - Christopher Burns

I've still not even tried it. I've never tried Vue either. I'm very bad.

00:28:16 - Anthony Campolo

Tunnel vision.

00:28:17 - Christopher Burns

Tunnel vision.

00:28:17 - Anthony Campolo

I mean, you have to specialize. You can't really be an expert in all three. But if you know React really well, you'll pick up Vue in a day. Same with Svelte. Svelte has the most concise syntax. It's really nice and easy to write in, but being newer, there's less things built around it. It's kind of, are you just interested in learning this slightly new paradigm of how to work with components? I think they're super fascinating. I like seeing what's happening in every sphere that's adjacent to the sphere I am in.

00:28:45 - Christopher Burns

Very much back to the point of what FSJam is, the philosophies: we obviously have the first one, a data tool to connect your services to a database. That could be something like Prisma two or Fauna. Then you have your second one compiled down in a monorepo of some sort. All of your code is committed together and in a universal language such as JavaScript. Your third one: bring your own options. What tools do you want to use with that, such as React or Vue or even Svelte?

We're yet to see, and this is very much a podcast where we're trying to grow community around the overhead group of repos, of distributions, where we understand that we want all of these things in an opinionated style. We're here to bridge the gap between the difference of Blitz and Redwood and Bison, because all three of them have the same goal. At the end of the day, it's just a different opinionated version of how you want to achieve that goal.

00:29:49 - Christopher Burns

And we believe they all are tackling the same problem. And that's why we wanted to create this community above it, to say, let's help each of these work together, bridge the gap where we can, and make sure that we are really getting the most out of JavaScript.

00:30:05 - Anthony Campolo

We want to make it a big tent. We want to be as inclusive as possible with other projects and other frameworks, and to get a dialog going and speak between the different communities, to share ideas, to build connections. Because, like Chris said, we're all aiming toward the same goal. We have some different ideas of how to get there, but I think that's what makes for really interesting discussions and what makes us all grow and get better.

00:30:32 - Christopher Burns

There's a lot of things we want to talk about, but one of the sections we want to have in the podcast is question and answer. The questions can be as simple as, what do you think of this? Or explain this, because we're quite knowledgeable in very different areas. Anthony is very knowledgeable in theory, and I'm very knowledgeable in practice.

00:30:56 - Anthony Campolo

I know nothing practical. Can't do anything.

00:30:58 - Christopher Burns

Exactly. You're theory; I'm practical. You know all the magic words, and I know how to implement the magic words. And how should you get those questions to us, you might ask? We would really like your questions to be tweeted to us. The Twitter handle is FSJam Org, so F S J A M O R G. Yeah, just tweet them out. We'll get around to answering them in the episodes.

00:31:27 - Anthony Campolo

We also have a Discord, don't we?

00:31:29 - Christopher Burns

We also do have a Discord. To join our Discord, the link will be in the description, but the code is C7 N Q app as well. So come and join us and let's chat some FSJam.

00:31:44 - Anthony Campolo

Yeah, thank you for listening. We're really looking forward to building out this project. Feel free to send us a message or tweet at us if there's anything you want us to talk about. If you want to come on and talk about what you're doing, we're open to anyone who wants to come on and talk about what they're doing in this space. And I think with that, unless you have anything else, Christopher.

00:32:03 - Christopher Burns

We are really open to guests, no matter how big or small. If you think you could really bring an engaging subject to this podcast, please reach out to us on Twitter. That's everything from me.

00:32:15 - Anthony Campolo

All right. Thanks for listening. We will catch you next time.

00:32:46 - Christopher Burns

Is that okay?

00:32:47 - Anthony Campolo

Dude, that was great. Yeah, that was awesome. I mean, that was great. That was so much fun.