
The Next Requirement of FSJam?
Christopher Burns and Anthony Campolo discuss Next.js, its rivalry with Gatsby, and whether full-stack frameworks should build on top of Next or go their own way.
Episode Description
Christopher Burns and Anthony Campolo discuss Next.js, its rivalry with Gatsby, and whether full-stack frameworks should build on top of Next or go their own way.
Episode Summary
In this episode of FSJam, Christopher Burns and Anthony Campolo explore what Next.js is, how it evolved from a server-side rendering framework for React into a more versatile tool, and why its recent Next.js Conf announcements have shifted the landscape. The conversation traces the long-standing comparison between Next.js and Gatsby, noting how the two frameworks gradually absorbed each other's features until the distinction between static generation and server-side rendering blurred. The hosts then turn to the central debate: should full-stack Jamstack frameworks like Blitz and Bison build on top of Next.js to inherit its features automatically, or should they follow Redwood's approach of building everything from scratch for greater control? Chris Ball's conference talk, "Next.js: A Framework for Frameworks," serves as a jumping-off point, with the hosts weighing the jQuery-Backbone cautionary tale against the real productivity gains Next provides. Christopher shares his own experience running a Redwood API alongside a Next.js frontend and feeling envious of Next's performance and image optimization. The episode closes with a look ahead at emerging topics like database tooling, caching, and the Remix framework, plus a preview of their upcoming interview with David Price from Redwood.
Chapters
00:00:00 - Introduction and the Next.js vs Gatsby Rivalry
Christopher and Anthony open with some weather small talk before jumping into the episode's core topic: what Next.js is and why it matters to the full-stack Jamstack world. Anthony defines Next.js as a React framework originally built for server-side rendering that has since expanded its capabilities significantly.
The hosts trace the familiar dilemma developers faced when choosing between Next.js and Gatsby after outgrowing Create React App. The conventional wisdom—Gatsby for static sites and content marketing, Next for dynamic server-rendered apps—started breaking down as each framework adopted the other's strengths. Christopher admits he was a committed Gatsby user largely because of its image processing, but the recent Next.js conference has changed his perspective.
00:05:13 - Next.js Conf Highlights and the Monzo Talk
The conversation shifts to impressions of the recent Next.js Conf. Christopher discusses the challenge of juggling multiple talk tracks and highlights the range from beginner to advanced sessions, many of which focused on when Next.js is the right tool and when it isn't. He singles out the Monzo talk as a standout, which leads to a brief explainer on UK challenger banks.
Anthony and Christopher discuss how Monzo represents the kind of modern, tech-forward company that benefits from frameworks like Next.js. They also touch on the talk's practical message about choosing tools wisely rather than defaulting to a single framework, including the idea of pairing headless WordPress with a Next.js frontend when that better serves the client's needs.
00:08:11 - Framework for Frameworks: The Build-On-Next Debate
The hosts dig into Chris Ball's conference talk arguing that Next.js is the ideal foundation for building other frameworks. Bison and Blitz take this approach, inheriting features like the new image optimization automatically, while Redwood builds its own stack from the ground up. Anthony offers a historical parallel with Backbone.js building on jQuery—something that seemed obvious at the time but aged poorly.
Christopher pushes the conversation toward practical trade-offs, noting that while Next.js gets many things right out of the box, the real value of full-stack frameworks lies in the abstractions they add. The debate centers on control versus convenience: Redwood gains independence but must replicate features Next already ships, while Blitz and Bison move faster but tie their fate to Next's trajectory.
00:14:18 - Real-World Experience and the Ideal Stack
Christopher shares his hands-on experience across Gatsby, Next.js, Redwood, and Blitz, explaining that he built his startup Everfound on Redwood. He praises Redwood's GraphQL API layer but finds the web side lacking compared to what Next.js offers in speed and optimization. His ideal stack, he says, would combine a Redwood API with a Next.js frontend.
Anthony highlights Bison as a project that may offer exactly that blend—Next.js on the web side with a strong GraphQL API. The hosts discuss how Christopher's production setup already bridges Redwood and Next via Apollo, and they consider whether Redwood might eventually offer Next.js as an optional web layer, a question they plan to pose to the Redwood team directly.
00:19:16 - Caching, Remix, and Looking Ahead
The conversation turns to what the next major innovation in full-stack frameworks might be. While Christopher suggests databases, Anthony throws a curveball by pointing to caching, citing the work being done by the Remix framework from Michael Jackson and Ryan Florence. They discuss Remix's paid licensing model and the backstory of how COVID destroyed the React Training business that funded its development.
The hosts wrap up with housekeeping: previewing their upcoming interview with David Price from Redwood, asking listeners for feedback on episode length and format, and noting that the podcast is expanding to more platforms. The episode closes with a lighthearted callback to Christopher's shifting framework loyalties, encapsulating the ever-evolving nature of the JavaScript ecosystem.
Transcript
00:00:00 - Christopher Burns
Okay, what's the best starting word? Good evening. Hey, you listening to me? Okay, we'll go with: hey, you're listening to FSJam with Christopher Burns.
00:00:25 - Anthony Campolo
And Anthony Campolo.
00:00:27 - Christopher Burns
It's a cold day in the UK. How is it in Colorado?
00:00:31 - Anthony Campolo
It was very cold this last weekend, actually. We had some snow, but it's warmed up a little bit now. The snow has melted. I can go outside now, so that's nice.
00:00:40 - Christopher Burns
That's a dream to hear about snow in the UK. We normally get ten centimeters in February.
00:00:49 - Anthony Campolo
Isn't that the perfect amount of snow, though? Do you want more snow than that?
00:00:53 - Christopher Burns
Well, it's disappointing. As a British person, I would say I would always love to open my window and see everything covered in snow. It's just something you don't get in the UK, but I'm sure it comes with all of its problems of not being able to drive or go to the shop, you know, digging out your driveway. But we're here today to talk about what Next.js is and why it could be so important to FSJam.
00:01:28 - Anthony Campolo
Yeah, this is definitely a great conversation because there are a lot of frameworks that are building on top of Next, and other frameworks that are choosing to rebuild some of the same stuff that Next built, but in a slightly different way. And I definitely have a very strong opinion on this. I think that it is definitely maybe a good idea to do one or the other. It's hard to say which, but it's definitely good to do one or the other.
00:01:55 - Christopher Burns
Okay, so I think it's worth explaining what Next.js is first. Really, how would you describe it, Anthony?
00:02:04 - Anthony Campolo
I would describe Next.js as a framework for React that was originally intended for server-side rendering, but has now expanded out to include other things as well.
00:02:20 - Christopher Burns
Yes, I have always seen Next as a competitor to Gatsby. While both of them were doing different things, they're very much head-to-head right now.
And whenever I would go to build a new Jam website, I would always think, is this going to be in Next or is it in Gatsby? Gatsby would always have one magical component, and that was their image processing. That's why I always picked Gatsby.
00:02:56 - Anthony Campolo
I definitely agree that you would frequently hear people ask, what should I use, Gatsby or Next? And their thought process behind that was they would kind of learn some React. They would check out Create React App, which we talked about in our original episode, and they would be like, okay, I want something a little more than this. And then they would hear, okay, there's Gatsby, and then there's Next. And for many, many years, those were kind of like the things to build with for React.
And when I would hear them compared, you would always say Gatsby is more of a static site generator and is better for things like content marketing, landing pages, things like that, whereas Next was for server-side rendering and was better for a more dynamic application, like a shopping cart or something of that manner. So that was kind of like the canned answer you would get from everyone.
And as I was learning these and I was digging into them, I found that this distinction starts to break down when Next starts adding static generation features and Gatsby starts adding server-side rendering features, so the line between these has become blurrier and blurrier over time.
00:04:10 - Christopher Burns
I think it's always two Goliaths. One of them adds a feature, the next one follows it. The next one adds a feature, the other one follows it. And I'm guilty of this myself. A few months ago, if you asked me what I would be using, I'd say Gatsby. I think Gatsby is the best thing ever.
But as we will talk about today, the tables have shifted with the Next conference. So many awesome things have come out of it. And that makes us question, would it be worth it if frameworks adopt Next and then build their magic and abstractions on top of Next?
After building my first Next.js website and also watching the conference, I think Next.js is the next best thing. I'm sure we're going to go into the conference in a minute and how that factors into FSJam.
00:05:13 - Anthony Campolo
We are less than a week away from when it happened. I didn't really watch any of the videos, honestly, because I know that they're all going to be online. There's a lot that I'm really curious to check out. I was just kind of hopping between the booths and doing some Discord.
Yeah, what was your impression of the conference?
00:05:29 - Christopher Burns
I watched a lot of the talks, but one of the things that always nags me with these kinds of conferences is when they're more than two or three tracks. It's like, which one do I watch? Do I watch E or X?
00:05:46 - Anthony Campolo
Watch them all at the same time?
00:05:47 - Christopher Burns
Exactly. I jumped around, and a lot of them were beginner talks, but also advanced talks at the same time, and a lot of them really focused on the principles. Do I need to use Next.js for this, and what does Next.js bring? Because it's okay saying the only tool in my toolbox is Next.js. But as one of the talks was about, you should always learn what the best tool is. If your customers use WordPress, well, you might actually prefer to learn a new skill and turn that WordPress into a Next.js website with headless WordPress.
Yeah, the talks. There were some really good talks. I learned quite a lot. Some of the talks that I want to highlight, I think the Monzo talk was really, really good. And if you didn't know, Monzo is a challenger bank in the UK. Their technology is phenomenal compared to most banks.
00:06:53 - Anthony Campolo
And when you say challenger bank, what does that mean?
00:06:55 - Christopher Burns
Without going too in-depth, Britain, the UK, obviously had their big banks, you know, HSBC, Capital One, the big banks. A few years ago, new legislation was brought out in the UK saying you could fast-track becoming a bank. It would take one year instead of like five years. Those aren't the nailed-down numbers. They're just approximate.
00:07:21 - Anthony Campolo
Yeah, it just means that it's not going to take you a ridiculously long time to get set up and going, so you can have more of a startup kind of mentality, I would imagine.
00:07:29 - Christopher Burns
Exactly. And Monzo just started opening a beta in the US so US users can join, but they are very much known as the trendy, mobile-only bank in the UK.
00:07:46 - Anthony Campolo
For us, that's probably like Robin Hood. They're more like stocks than a bank. But in terms of being like a hip new finance thing, I guess.
00:07:53 - Christopher Burns
Revolut is probably your closest.
00:07:55 - Anthony Campolo
I don't have money, so I don't worry about where to put my money. It's simple.
00:07:59 - Christopher Burns
But the other talk that I'm sure we're going to talk about in a second was with Chris Ball. His talk was about FSJam, and the title was.
00:08:11 - Anthony Campolo
Not anything to do with Bison. He should have put Bison in his title, I thought. I get why he didn't. You know, it was "Next.js: A Framework for Frameworks," I think is what it was.
00:08:20 - Christopher Burns
We'll link his slides in the show notes. Chris Ball will be on the podcast, so make sure you're subscribed. When that interview is released, you'll get to hear it. I already know he's working on some really, really cool things for FSJam.
One of the main subjects that he spoke about was that he believed the Next.js framework was the best way to start another framework. And this brings us to the topic of what is the right path and what do you gain and lose by using quite a big framework as your base.
Bison and Blitz use Next.js, and then they add their own magic and abstractions on top of that, while Redwood decided to go its own way and basically make everything itself. And that's the core talk of this episode, the debate that I'm sure we'll go into in a minute.
To go back to Chris Ball's talk, the main point was that by using Next.js as a base, whenever Next.js adds a major feature, Blitz and Bison already have it.
00:09:40 - Christopher Burns
Such as the image tag. Whenever you create a new application with Blitz or Bison, it will now have automatically optimized images. If you take your own route, like Redwood has, then you have to talk about how do we build an image component, how does that work, and how do we get all the same benefits with as simple an interface as Next?
There's a lot of pros and cons. It's very much what would you like and what would you be willing to sacrifice. And I think that this subject is very opinionated and there is no right answer, but let's debate it.
00:10:33 - Anthony Campolo
Yeah, I agree. I think the answer is a definite maybe. There is really no good answer. I'm glad you brought up this topic because, as we said, this is what Blitz is doing, also building on top of Next. So this has been something I've been thinking about going back to when I was learning Blitz and Redwood, when I first started learning them back in like May.
And the question of, do we want to take all this work that's been done by Next and stand on the shoulders of giants, or do we want to build it out ourselves? And the trade-off is always going to be about control. It's how much control do you really have over your own framework and the pieces that make up that framework? And it's good to have control if you have the skill set to use that control in a way that's going to benefit you in the long run. It really is going to be situational, contextual.
One thing that I would want to point out, though, as kind of a historic case study of a time when it would have seemed really obvious to build on another layer, would have been one of the very first MVC JavaScript frameworks that came out around like 2010, Backbone.js done by Jeremy Ashkenas. And they built on top of jQuery as their base layer, and at the time it was like, why wouldn't you build on top of jQuery? It was the thing everyone was using. It had so much work behind it.
And, you know, today you wouldn't want to use a framework that uses jQuery as its base layer. That would seem like a really bad idea. So something that may seem like a good idea to build on at the time, you have to think about where is this going to be in five years? Do we want to be able to evolve our own base layer over those years, or do we want to really hope that this thing isn't going to become the next jQuery? Or maybe you want to be the next jQuery. jQuery is still used by a lot of people, so who knows.
00:12:22 - Christopher Burns
My thought is that you would be shooting yourself in the foot when you think about what is done right versus what's done wrong. Next.js gets a lot of things right. The biggest thing that makes FSJam what it is is the abstractions and the magic that Blitz, Bison, and Redwood do. You know, they make it easy to build full stack applications.
While you can do that with just Next, you tend to find that there's still a lot of glue that you still have to do, a lot of management, a lot of running certain things. The main question is, do you think Redwood not adopting Next.js for their web side is a crutch? Do you think it would be a crutch or not?
00:13:24 - Anthony Campolo
I think time will tell. Like we said, it's really hard because it's all about the trade-offs you get. It's just going to depend on how each of these projects develops. For me, I think it's great to see these different approaches. That's why I like seeing how these different frameworks solve this problem.
Because ideally you can look at, okay, how is Next doing routing and how is Redwood doing routing, and why is it different? Why did Tom decide to build his own router? Obviously that wasn't something that just came out of nowhere. There was something it was doing that he wanted to be different. And it's really hard if you don't have the technical context to understand why these decisions were made. Getting that context really requires actually building things yourself with these tools.
I think it's just great that, you know, a lot of people are out there experimenting, like people such as yourself, Chris, who are using all these frameworks, you know, like in production.
00:14:18 - Anthony Campolo
What frameworks would you say you've actually used, what you consider in production?
00:14:23 - Christopher Burns
I've used Gatsby, I've used Next.js, I've used Redwood, and I've tested Blitz, but I've not touched Bison yet. I'm very much a developer that asks, what's the use case? Which one suits you best? And I built my startup with Redwood.
And the biggest thing I find right now, and the guys at Redwood are amazing, we're going to talk to them soon, but I think the API side is amazing. It's just what I wanted when it comes to a GraphQL server. But the website is lacking, and they know that. We all know that it's alpha and it's building, and optimizations and fixes come every week.
But when you play with something like Next without Bison or Blitz, it just feels so much faster. And with the optimizations and the new image tag that came out with Next 10, it makes me feel envious. It makes me feel like my ultimate FSJam stack would be a Redwood API with a Next layer and the Redwood magic on top of that.
00:15:52 - Anthony Campolo
And that does exist, doesn't it? Isn't that what Danny demonstrated at our last Redwood meetup?
00:15:57 - Christopher Burns
Well, yes, Danny did demonstrate that. And I've also demonstrated it. The platform that I have built is called Everfound. It is a payment platform for nonprofits, and it has multiple sides. But the main three sides are the API that's in Redwood, the dashboard that's in Redwood, and our payment links. They are in Next.js.
The Next.js application sits on Vercel, and that communicates with our Redwood server through Apollo. And with that, I've seen how beneficial Next.js is when attached to a Redwood server. That's what's left me envious: I've used Next.js with a Redwood API, and then when I go back to Redwood Web, I just feel like it's lacking so much.
Next has already ticked off so many things, and if we had to put a business mind on it, how much development time would it take for Redwood to gain those features? Would it be clearer if they adopted a Next.js side? Next.js could be optional. I'm sure that's an interesting question that we'll ask David.
00:17:26 - Anthony Campolo
This is why I really find Bison to be so interesting, because I think you get a little bit of the best of both worlds between Blitz and Redwood. You get the Next stuff like Blitz has, but you also get all the GraphQL stuff like Redwood has. Because that's what has kept me in Redwood is I really like using GraphQL. And, like you said, having that API is really great.
But if you have also all this other great stuff you get from Next, but you can still have a really powerful API. That's why I've found Bison to be a really fascinating project and worth looking at. So look forward to getting Chris on and talking to him.
00:18:04 - Christopher Burns
I'm really trying to not try Bison because I feel as soon as I try it, I will be like, why did I pick Redwood? But at the time, Redwood was the best option.
00:18:19 - Anthony Campolo
And Bison didn't exist at the time, right? Bison has only been around for what, two months now, I think.
00:18:23 - Christopher Burns
Yeah, it's still a great option. And yes, I put on my hard hat and used something before it's ready. But for me, Redwood was right and I think it would still be right. And I'm still backing Redwood as much as I'm backing Blitz and Bison.
My next question would be: where do you think the next big goal is, and why? Because we know that each framework is still building toward stable 1.0. What will come after? What will be the next big feature? I think that feature may be around databases. What do you think?
00:19:16 - Anthony Campolo
I think databases are definitely somewhere a lot of interesting work is going on. I would throw a curveball there and say, what if the next big thing is caching, like with what Remix is doing?
We haven't talked about Remix at all, which is the new framework by Michael Jackson and Ryan Florence, and they're doing a lot of work on HTTP caching and the whole caching layer, and Redwood is struggling with caching right now. And so it'll be interesting to see how some of that influence starts to leak in.
00:19:45 - Christopher Burns
Yes, I'm really interested in Remix. I understand the pricing structure, but I wish there was a demo or a trial. You know, I'd develop with it for free, but if you want to take it into production, you need to pay, because I think that would be the best of both worlds.
00:20:04 - Anthony Campolo
Yeah, it's hard to say. I can't speak for them. If you've really heard their whole story, like their entire business got wiped out by COVID. So there's a lot of kind of forces that go into the decision they've made behind their pricing structure.
00:20:19 - Christopher Burns
Wasn't a lot of their income from workshops and conferences, right?
00:20:25 - Anthony Campolo
Yeah. So they ran React Training and they would go do workshops. They would teach React. And so all in-person workshops became effectively impossible. You had to essentially do video conferencing, and people won't pay as much for video conferencing. You know, whether that's fair or not or a good decision or not, it's the way it is.
They had a team of people that they were training to take over React Training so that they could work full time on Remix. And then COVID hit and they had to lay off their whole team. And so they spent like a month just working on getting their team jobs. So they made sure that they would be set up.
00:21:00 - Christopher Burns
I'm yet to check it out. I get their newsletter, but I'm quite busy and I can't just keep looking at other frameworks right now.
00:21:12 - Anthony Campolo
Nader Dabit put out a good video and a good article that we'll link to, where he just did a run-through of a first Hello World Remix project. So I think that's the best resource right now for someone who can't afford the license, such as myself.
00:21:26 - Christopher Burns
So as you can probably hear since the first episode, I have got a better mic. And with that, we've been doing a lot of preparation in the background, getting on a lot of guests, but we still want to have these casual chitchats between Anthony and myself. We're working out a schedule. We are unsure right now whether it'll be weekly or biweekly.
We're just taking it in free-flow, finding out what works best for us and what works best around us, because a lot of our conversations will tend to be based on news, what's happening in our development, and our guests' opinions. Our next episode will have David Price.
00:22:18 - Anthony Campolo
The David Price.
00:22:19 - Christopher Burns
You mean it will have the David Price on. And we will be going deep into Redwood and how it's managed, growing, and succeeding in FSJam.
00:22:35 - Anthony Campolo
Yeah, I'm looking forward to talking with David. We'll be talking more about community management type stuff and less like nitty-gritty technical details. And he's been someone who's really helped bring me into the fold and has been so patient and kind in answering my questions and helping me get spun up in the community.
So really happy to have him on and get to talk about the work he does.
00:22:57 - Christopher Burns
It's going to be great. I bought a brand new mic just so David didn't have to hear my terrible mic. That's the end of this quick episode about Next.js.
Do tell us on Twitter or FSJam.org what you would like to see. Would you like to see short, single-topic episodes or longer episodes? We want to hear the feedback.
You can check out our new website. It is FSJam.org. We're currently working on getting the podcast on all platforms. It's currently available through Spotify and, I believe, Google Podcasts, with Apple Podcasts coming in the upcoming weeks. That's it from me.
00:23:48 - Anthony Campolo
Thanks a lot, everyone. Have a good one.
00:24:19 - Christopher Burns
I'll be Gatsby. I think Gatsby is the best thing ever now. I think Next.js is the next best thing.