One Year Later

Episode Description

Chris and Anthony celebrate one year of the FSJam podcast by discussing Next.js 12, build tools, edge computing, and the evolving Jamstack identity.

Episode Summary

In this anniversary episode, Chris and Anthony reflect on one year of the FSJam podcast and dive into the major developments shaping the full-stack JavaScript ecosystem. The conversation kicks off with their reactions to Next.js Conf and the release of Next.js 12, particularly its integration of SWC as a Rust-based compiler replacement for Babel — exciting for greenfield projects but limited for brownfield apps relying on tools like Emotion or styled-components. They explore the promise and practicality of ES module URL imports, drawing comparisons to Deno's approach while questioning whether the ecosystem is ready to move beyond package.json. The discussion shifts to React 18 and server-side components, still in alpha but poised to fundamentally change how React apps handle rendering, with Next.js leading adoption. A significant portion covers edge computing, from Vercel's new middleware built on Cloudflare Workers to emerging database-on-the-edge solutions like Planetscale, CockroachDB, and Fly.io, noting that while full edge-stack deployment is technically possible, it still requires significant expertise. They also touch on Blitz.js creator Brandon's new hosting venture Flight Control and close by reflecting on the Jamstack's identity crisis, with Redwood dropping the term in favor of "JS app framework," and Chris predicting a major swing toward server-side rendering in the year ahead.

Chapters

00:00:00 - One Year of FSJam and Next.js Conf Reactions

Chris and Anthony open the episode by celebrating their one-year podcast anniversary, reminiscing about how the show evolved from alternating solo and guest episodes into a guest-heavy format. They share some of their favorite earlier episodes and set up the conversation around revisiting predictions from the previous year.

The discussion quickly turns to Next.js Conf and the release of Next.js 12. Chris shares his surprise that Next.js doubled down on server-side rendering rather than moving toward an islands architecture approach. They note that Next.js has deep SSR roots predating the static generation trend popularized by Gatsby, signaling that the framework is returning to its original strengths while charting a new course forward.

00:03:52 - SWC, Build Tools, and the Brownfield Problem

Anthony and Chris dig into SWC's integration with Next.js 12, discussing the impressive speed gains — up to three times faster refreshes and five times faster builds — while acknowledging the significant caveat that projects using custom Babel presets, styled-components, or Emotion cannot yet take advantage of SWC. Chris argues the tool doesn't feel feature-complete compared to Babel's configurability.

The conversation broadens into the tension between modern build tools and existing codebases. Drawing on their earlier conversation with Fred Schott about Snowpack, they discuss how highly customized projects face real barriers to migration. Chris makes the critical point that the vast majority of production applications are brownfield, and businesses rarely have the financial incentive to rebuild from scratch just for faster build times, no matter how appealing the new tooling is.

00:09:34 - ES Module URL Imports and Dependency Management

Chris raises the topic of URL imports and whether the ecosystem will shift away from traditional NPM-based package management. Anthony draws on Deno's approach to ESM-based imports, noting benefits like cleaner dependency management without lock file complexity, but flagging concerns around offline development and slower internet connections.

They explore the security implications following a recent NPM supply chain attack on the UA Parser package, which affected projects like Redwood and Slinkity. Chris expresses skepticism that URL imports will replace package.json for complex applications, viewing them as better suited for lightweight integrations like embedding third-party SaaS scripts. They also discuss browser caching challenges and the unresolved question of how URL-imported modules interact with production bundling workflows.

00:16:01 - React 18, Server Components, and Suspense

The conversation turns to React 18's upcoming features, including server-side components and Suspense. Anthony explains that the new React documentation focuses on modernizing fundamentals around hooks rather than class components, while server components remain experimental with Next.js leading their adoption among major frameworks.

Chris highlights the chicken-and-egg problem of Next.js 12 promoting server components while React 18 itself is still in alpha, questioning when developers can confidently adopt these features in production. They discuss how server components relate to the islands architecture concept by sending pre-rendered HTML to the client, and Anthony notes that projects like Blitz have been running React's experimental builds for some time. Chris predicts a major cultural shift toward server-side rendering once React 18 officially drops.

00:25:37 - Edge Computing, Middleware, and Databases at the Edge

Chris and Anthony explore Next.js middleware and Vercel Edge functions, both built on Cloudflare Workers. Anthony warns that developers accustomed to Lambda-style serverless functions may face compatibility surprises since the edge runtime doesn't include Node.js, requiring different approaches and abstractions like Luke Edwards' worktop framework.

The discussion expands into the emerging world of edge databases, covering Planetscale, CockroachDB's serverless offering, Fauna, and Fly.io's geo-replicated Postgres approach. Anthony shares the exciting news that Prisma now works in Cloudflare Workers, connecting to MongoDB Atlas — making a full edge-stack deployment technically possible for the first time, though still requiring significant configuration expertise. Chris questions whether a single turnkey edge deployment service will emerge within the next year.

00:34:13 - Flight Control, Hosting Wars, and Framework-Specific Platforms

Chris asks about Brandon Bayer's new hosting venture, Flight Control, built specifically for full-stack JavaScript frameworks like Blitz.js. Anthony connects this to their earlier roundtable discussion about the shortcomings of existing hosting providers for apps that don't fit neatly into traditional monolithic or decoupled Jamstack deployment models.

They discuss the broader trend of frameworks building dedicated hosting platforms, pointing to Gatsby Cloud as a precedent and noting how Netlify and Vercel continue to compete on features. Chris recalls Jason Lengstorf's philosophy that Netlify should build anything, contrasting it with the approach of optimizing hosting for specific framework needs. Both hosts express excitement about Flight Control's potential while acknowledging it remains in very early stages.

00:37:34 - The Jamstack Identity Crisis and Predictions for Year Two

The episode's final segment tackles the evolving meaning of "Jamstack" and "full-stack Jamstack." Anthony reveals that RedwoodJS dropped the Jamstack label from its website, rebranding as "the JS app framework" to avoid confusion about the framework's capabilities. Chris jokes that it should be the "TS app framework" given TypeScript support, and they debate whether the M in JAM still means markdown or has evolved into something else entirely.

Chris closes with a bold prediction that server-side rendering will become the dominant trend once React 18 launches, reversing the client-rendering wave. Both hosts reflect on lessons learned over the past year, express interest in exploring technologies beyond the React ecosystem like Nuxt 3 and Rust's role in JavaScript tooling, and invite new guests of all backgrounds to join the show in its second year.

Transcript

00:00:00 - Christopher Burns

Just like the old times, before we had any guests and people probably just wanted to listen to us. Welcome, everyone, to a very special episode of the FSJam podcast. We are recording this on Wednesday, the 27th of October. It has been one year since we recorded our first episode saying, "What is FSJam?" So much has changed in the last year.

It's just me with Anthony, and we're just going to talk about what we've loved about the past, what we're seeing, what's happening right now, where it could potentially go in the next year, and things we're excited for. So let's get to it.

00:00:45 - Anthony Campolo

Yeah, I think this is going to be fun. A little piece of FSJam trivia is we had actually planned on doing every other episode with a guest, and then just doing episodes with us to talk about what we were doing in our lives and what we thought was interesting. But the podcast just took off, and we found so many people to bring on that we ended up chucking that plan out the window, as you would say.

We just kept talking to people, but I really enjoyed our conversations. I think some of our earlier episodes, like episodes five and nine, especially with just the two of us, are two of my favorite episodes that I've done, and I've listened to them quite a few times. We'll probably revisit a little bit of the predictions we had last year because I think that's pretty interesting.

Then we'll also just talk about where we've gone over this year. And I think that the ecosystem itself is in such an interesting place. And I know that you want to talk a little bit about Next.js Conf, which is funny because you talked about Next.js Conf on episode one as well.

[00:01:48] So what did you think of Next.js Conf?

00:01:50 - Christopher Burns

I only watched the keynote, so I didn't watch any of the other speakers. I'm due to catch up on them because that was last night my time, and I had to wake up and do a day of work. What I thought of the keynote is Next is heading in a really interesting direction, very different from where I would have thought they would be heading.

I thought that they would head more in the direction of the islands mentality, splitting React out as much as possible so you only need React where possible. I thought they were going to do that on a bigger scale, but nope, it seems like they're going to stick with their roots and go more down the SSR route: server-side render everything. We tend to forget that Next is quite old, and it started as SSR. It started as a server-side rendered version and only added static building when Gatsby came along. It's really interesting.

What's my opinion? It's going to be an exciting year for sure.

00:02:49 - Anthony Campolo

Yeah, and I think with Next.js you could already do partial hydration with some kind of manual effort. So I would imagine that's probably why they haven't really dug into it and made it a key feature yet. But I do agree that at some point they'll probably have to, just because Astro has made it such a big part of the conversation.

But one of the big things that did happen was SWC, and we talked about SWC with Aldo, actually. I've been really curious to see how this is going to go, because it's a very new project that has potentially a lot of bugs in it. But when you have a company like Vercel throwing all these resources at it, then they can squash a lot of those bugs, I would imagine. I think that's going to be really great for the whole ecosystem, because I know a lot of projects are looking at SWC. Peter on Redwood really wants to use it, but the edge stuff is cool because Cloudflare is another big one that we've talked about, especially Cloudflare Workers.

[00:03:52] And the benefits you can get by having your JavaScript logic on the edge and able to execute there. And so they released these edge workers. I'm not sure exactly what they're called, but I know they're built on Cloudflare Workers.

00:04:07 - Christopher Burns

I believe they're literally just called middleware: Next.js middleware. They actually had two names for it, a Vercel name, I think it was like Vercel Edge, and Next.js middleware, I think, were the two names off the top of my head.

This is really interesting because we're diving deep into two big areas. I really want to talk about computation on the edge and compilers and dev tools. I think we should talk more deeply about SWC first, because that's the really interesting one.

Over the last year, as you've seen, we've had this renaissance of build tools. SWC has now been integrated directly into Next.js with Next.js 12. The biggest caveat of SWC right now is if you use something like Emotion or styled-components, something that requires a slightly custom Babel preset, SWC is currently not supported. If you use just PostCSS, then SWC is supported. It's that thing of if you've got a Next project and you have a customized Babel config, then probably SWC is not going to work out of the box. They have already stated they are working on it, and they're going to be working more on support for styled-components and Emotion and Relay, but it currently isn't.

[00:05:26] Is that a big thing? A big bummer, I think. So I think they probably should have waited until they had that support to really give it that kick, to say we support everything, because to me it doesn't feel feature-complete like Babel. If you're getting me, because we all talk about Babel and like, oh, it's so slow, and all these new tools that are coming out are so fast and amazing, but most of them you can't configure like you can Babel. And I think that's what they're missing.

And as soon as they have that support, I think that's when they can truly say, now chuck out your Babel. Now completely replace it. And what they're saying is it's up to three times faster refreshes and five times faster builds, with the caveat that if you use Emotion or styled-components, you still can't use it yet. So it's a bit of yes, amazing, can't wait to use it, and a bit of a bummer at the same time, I think.

00:06:23 - Anthony Campolo

Yeah, and this came up with Fred Schott when we were talking about Snowpack. He was saying how the more you have customized your own thing, the harder it's going to be to migrate to a new toolset in general. And he was talking more about Webpack configs. But it's the same thing with Babel, in the sense that these tools were originally created to be highly configurable and highly customizable, and to let you write your JavaScript essentially however you want it, both in the syntax and in how you structure your project.

But there's a lot of cost that came with that because you end up with your own weird, bespoke, custom project that maybe no one else can understand or can't necessarily integrate with anyone else's tooling. So I think that having these tools push developers in the direction of less customization and less configurability is a good thing. But then people who have these highly customized setups just aren't going to migrate. They're just going to stay where they are. So it's a bit of a catch-22 for greenfield projects.

[00:07:27] These new tools like SWC and Esbuild, they're incredible. But for brownfield projects, it's going to be a lot harder to see where this is going to go.

00:07:36 - Christopher Burns

And I think that's something we tend to forget about: far, far, far more apps are brownfield at this point than greenfield. Not many companies can just spin up a brand-new Next project and start going. Not many companies have time to start rebuilding their dashboard completely from scratch. It technically never makes sense in terms of money to rebuild something from scratch. If you're thinking about a business, why would I rebuild it when what we've got is fine? Yeah, but it builds five times faster. Does it make five times more money? No. Then it's never going to be worth it in terms of brownfield.

So it's that thing of yes, so much of what Next is doing is you just upgrade and now it works great. But it will be you just upgrade and now it works when it actually works with all the packages you're used to. Because the last time I checked, styled-components and Emotion were very big projects that a lot of big companies use and a lot of apps use already.

00:08:37 - Anthony Campolo

Yeah, and that's why I think it will probably just be a matter of time, because it's going to be like, how motivated are you to get your thing to work with the new stuff? Something else that's worth mentioning is that this was actually the second major project that has moved to SWC. Parcel is another one that is using it as well. So I think as more projects start using these newer build tools, different ones will figure out different parts as we go.

This is one of the reasons actually I really enjoy being a dev advocate. Almost everything I build is like a greenfield project, because I'm always just kind of starting from scratch and building up sample projects and stuff like that. So it's been great to have an excuse to play with these different tools, and I've gotten a lot of mileage out of just building lots and lots of small sample applications that use lots and lots of different combinations of these new pieces of tech.

00:09:34 - Christopher Burns

I guess the next thing about build tools that I'm really interested in hearing your opinion on is ES module support and URL imports. ES module support is obviously one of the things that we can just get off the table because it's coming. It's here. We all know. What about it? The URL imports, do you think this is going to take off and we're going to start just URL importing our packages? Or do you think we're still going to go the classic method of installing through NPM and going that way?

00:10:01 - Anthony Campolo

It's a really great question. This is one where following Deno for a long time has given me some good perspective on this conversation, because Deno has been doing the same thing. They build entirely on ESM modules, and they have the same idea where their whole standard library is on deno.land, and then you import all of your things from deno.land and you can specify the version.

And so I think the versioning is where this becomes really interesting, because it makes it a lot easier for your project to not get lost in this whole crazy lockfile, package-lock.json kind of mess that you get with NPM, and so it makes your dependencies a little more comprehensible. But there are going to be issues just with people who have slower web connections and need to have the stuff downloaded and on their computer. So I think if they can still find a way where you can build a project locally off of these URLs, then that'll be a good stopgap. But actually the real big difference, I think, potentially could just be security, because you have to be able to verify that this code you're getting is the code you're actually getting.

[00:11:19] And there's a really interesting, very bizarre security incident that just happened a couple of days ago on NPM. There was this package called UA Parser, I think is what it was. This guy's NPM account actually got hijacked, like someone hacked into his account and then put malicious crypto-mining stuff into a package and then pushed that out. And it's a dependency in Redwood and in Slinkity, both of the projects I work on. So this came up in both projects. So there's open-source supply chain issues that come along with this too. So it's a huge, interesting problem. And I think in general it's going to be the direction a lot of projects are going to go. But I don't know if we'll ever see a huge, widespread ecosystem migration to this being the way to do things. I think the jury's still out on whether that's going to happen or not.

00:12:12 - Christopher Burns

I think personally it's a cool fad, if that makes sense, a cool one-off thing that I'm going to do for one package. Like, I need to install Intercom onto my website. Sure, I'll just pull in the URL. Because we're so used to embedding a URL into the header of their script, I can see that working. But having a whole dashboard and then just importing it in as you need it, to me, it then gets to that point of, well, how do you keep it all up to date? What tool are you going to use? Because we're so used to going through our package.json and just clicking update. When it's all spread through your code, it's no longer easy to know. How do you then know when a new version is ready?

So I think it's a bit of an interesting one. A lot of plug-and-play SaaS companies fall into this area. I've been working in this area myself now with EverFi, and we've been building a vanilla JavaScript plugin to easily integrate into other websites.

[00:13:16] One of the big things I've noticed is so many companies will just say, put this URL into your headers. A lot of times I've noticed companies aren't versioning and controlling the script, so that script will just be the latest version. But what happens if you want to push a breaking change, or the code changes, or you want to deprecate something? Well, that latest script is now pushed out. And then you look at someone like Stripe that has so many versions of their script in one script, and then you define which version of the script you want. It's a really interesting space, and I think where it will be simplest and where we'll see URL imports work will be for fads, one-off things, plug-and-play. But as soon as something's needed far more times than that, I think, yeah, package.json will stay around. I think it will stay, and that's me being honest, because it just doesn't make sense to me.

[00:14:14] If I'm going to import something, why should I import it twice, that same URL twice, when it could just be in your package? But I think the big thing that I'm wondering, that you probably know the answer to, is about bundling. When you're importing a URL and it gets bundled, you're not actually bundling that ESM script into your bundle, are you? It's when the website loads, it says, okay, now go to Skypack or jsDelivr and find that module and then run it, isn't it?

00:14:44 - Anthony Campolo

I think that is probably how it works. I think it is going to depend on how you configure your project, because we did talk about this also with Fred. He was saying the problem is if you're trying to get the most optimized production bundle, then you don't want to be making these different calls. And part of this dream was that people would then have these packages cached. So if you have jQuery on a million websites, then once you've hit one, then it'll be cached and you'll have it, and you can just go to other places and already have it. But in practice that's never really happened. So if we can get to a point where we can actually cache these modules in people's browsers, then we may get to a point where we don't need to also bundle them. But I think right now you still just need to bundle it all to get it all together and have it all be in one place. Because otherwise you're going to be making all these network calls, and it's just going to be a huge problem for people who have slower internet connections.

[00:15:51] So I'm not really sure what the bundling story is with this. And I would also guess it's just going to depend on what tool you're using, because people now have all these different bundlers that they're using.

00:16:01 - Christopher Burns

So Next.js generates a next dot lock file. So I think it keeps track of everything in there and caches it locally. I think it's a really interesting thing. Should your browser have cached versions of the top 100 scripts? Potentially, because we did with jQuery. I think it's that thing again: should Tailwind be built into every browser so the browser just knows? You can see a reason why the answer should be yes, but at the same time, why should it? Why should the browser now have the top 100 JavaScript packages bundled with it? I think the answer's still out on that one. Will it succeed, or will it be this kind of fad as like, yeah, you can import it from URLs, but we don't tend to?

I think the final thing I wanted to talk about from the Next conference is the server-side rendering of React components and React 18. I'm really early on this. I've not done much reading of React 18. I've not even read the new documentation that is currently in beta for React.

[00:17:07] And I bet you've done both. And I bet you even know a lot about Suspense. I really want to know your thoughts and opinions about this.

00:17:13 - Anthony Campolo

I know a little bit about it. I haven't read the new React docs yet, actually, but the new React docs, as far as I understand, are more about explaining core React fundamentals in a more updated way because the old docs that have still been up have been using class components and haven't really used hooks in the more modern ways that we write React. So I think that's the idea with the new docs.

In terms of the server-side components, though, we actually talked about this on episode nine. It had just dropped and no one really knew anything about it. Here we are, like a year later, and still no one really knows anything about it because it's so new. But I think that people are going to be more excited about it as it gets actually built into frameworks. And so with Next, Next is becoming kind of the first major React framework to incorporate server-side components. And it makes sense that it would be them because they really pioneered a lot of this work in terms of server-side rendering and just connecting the front end and the back end in a more coherent way.

00:18:28 - Christopher Burns

I feel like it's the chicken-and-the-egg scenario when it comes to React. Next.js just had their latest conference and goes, "Everybody, Next.js 12 is out and it's got server-side components in," and we go, okay, exciting. Then they go, "Now install React Alpha and React DOM Alpha," and you go, oh, but do I really want to install alpha versions of React? The answer is probably not.

And then it's this thing of Next.js has said we work closely with Facebook. Okay, so when is React 18 going to drop? Is it going to be next week or is it going to be six months' time? We currently do not know when all these things, like Suspense, are really close. We currently don't know yet how close they are. As in, when can I start using it today without an alpha tag? Without a beta tag? With just a release tag?

React server components do talk about the islands mentality of having only the bits needed and being reactive. What I understand is that if a server-side component is just going to render HTML, it's going to then just send that rendered HTML to the client.

[00:19:46] So it won't need to do any compiling of that or DOM tree manipulation. It would just say, okay, here's the five div tags that you need. Is that what you're kind of getting out of it as well? Because that's what I kind of see it all leading to.

00:20:00 - Anthony Campolo

Yeah, it's a way to get as much of your components compiled ahead of time. And it's a technique that's going to be complementary to server-side rendering. And so it's going to be like you build as much as you can and then send it over and then stream JavaScript to partially hydrate it. So it's going to be a huge sea change in how this stuff works. And it's going to be kind of a conundrum for most frameworks to figure out how to incorporate.

I remember at the time when it came out, Aldo was super fired up about it, and he was like, they finally figured it out, and how this has been an idea he'd been thinking about forever. And so I think that it's going to be like a low-level implementation detail that a lot of React developers are probably not going to have to think about too much unless they're the main architect on their project and have to think about holistically migrating the entire thing while it's still on an alpha tag.

[00:21:02] Though, people have been using the experimental build of React for a very long time. I know Blitz has been using it for the entire time it has existed because it uses all these kind of features, so I think they're probably farther along than most people would think. And I built a very small, simple project with React 18 back when it kind of got announced. And so I think that if this stuff is interesting to you, you should just try it and see what happens. See if your application breaks. See what the migration actually looks like. Just get your hands on it, and then you'll start to see how far along it actually is and whether it's suitable or not for your use case.

00:21:44 - Christopher Burns

This is the thing we're all talking about: React 18. It looks like there's not going to be any more surprises, as in fundamental shifts. The last fundamental shift in React was the hook structure. Are you still using class components? What are you, 2015? We use hooks today.

And I think the really interesting thing to look at next is how Next.js just says, oh, just say [unclear] server or [unclear] client. And if it's [unclear] server then it will be server-side rendered. If it's [unclear] client, it'll be client. But where do you make that distinction? Who's making that distinction? What's the best distinction? Surely React should work this out as like, this has reactivity, this should be done on the server, this should be done on the client by default.

Instead of just having to say this is client and this is server. If you say this is client, this is server, and you say, well, server stuff gets server-side rendered, why wouldn't everything just be server?

[00:22:44] Why not have everything server? It's like, well, you might want some stuff to be client-side rendered. What, like, you know, just server-side render everything? I'm really excited to see how it plays out. My last big question with React 18: do you think it's going to be out by the time 2022 comes around, or do you think it's going to be first half of 2022?

00:23:05 - Anthony Campolo

At this point, I would imagine there's not going to be anything major dropping before the year is out. I think usually people kind of aim for things to happen before the holiday season. So unless they plan on actually releasing the entire thing, I would be surprised to see any more major news.

But it is worth pointing out now that there's a working group, and this is something that didn't exist last year when we were talking about this. They've actually gotten other React community members, people like Michael Chan and Mark Erickson, both of whom have been on this podcast. They're both in the working group. And so I think that's going to be really good in terms of having other people testing stuff out and, more importantly, looking at the API and helping communicate these ideas, because you have people who are content creators now who are involved, people who write lots of docs. Mark is just like a doc-writing machine. So I'm going to be taking the lead, I think, from the people in the working group who I trust and respect.

[00:24:09] And when they start saying, hey, this is ready to go, is when I'll probably start saying, hey, this is ready to go. But until we start getting those signals from the working group, I will continue to say that this is an alpha feature that is only for people who want to live on the cutting edge.

00:24:26 - Christopher Burns

Oh yeah, and in terms of Suspense and everything, I've literally done zero research into Suspense past looking at it as one code snippet and going, is this just async/await for React components? And the answer is yeah, it's just async/await for React components.

00:24:44 - Anthony Campolo

Yeah, it's a way to lazy load. It's a way to split up your code, a way to make sure that you don't have a million flashing spinners when you don't really need them. So it's hopefully going to be a small code change, because the way they described it is you just kind of create these Suspense tags and put them around the things that you want to make async.

And this is downstream of concurrent mode, which was making React concurrent. So this is why you hear people talk about concurrent mode and Suspense kind of together but also separately. So the groundwork has been laid for these things over many, many years. So it seems like we're getting closer to it really being a real thing. But it's become like a running joke in React now that people have been waiting forever for this. So it's kind of hard to say if we're actually there yet or if we're still another year or two away.

00:25:37 - Christopher Burns

Get ready for React 20 concurrency mode. Well, we'll see. I think the last big thing I want to talk about, obviously, from Next.js Conf is Next.js middleware. The reason I want to put this more separately is that I feel like this falls more into the core area. I think the CDN area, in terms of the landscape, we thought was fully defined to a certain extent. You know, Netlify has pushed and pushed and pushed us so far. But to me right now, I think we're only just beginning.

I still think that Vercel and Netlify have so much scope that they can expand into in terms of databases, in terms of more logic. And I think middleware from Next.js land and edge functions from Netlify... I'm really interested to see how each one is going to play out because they're not compatible, to what I understand. They're completely unique to each deployment target. Will one be better than the other? Will you be able to do the same things on both? I don't know. This is currently brand-new knowledge of how Next is going to do these things.

[00:26:49] I've played around with a few of the demos, and it's allowing you to do things like put a password in front of your Next website, or try and detect a bot, or run logic closer to the edge. This is super exciting, and I think it's potentially what serverless functions wanted to be, that they kind of just missed the mark on, in my eyes. Will middleware turn into serverless functions, or will it be what serverless functions wanted to be? The jury's still out.

00:27:18 - Anthony Campolo

And this is why I've been so interested in Cloudflare Workers for this whole year, because, as you say, the CDN has become a big thing. But the CDN traditionally, for things like Netlify and Vercel, has been for our static content, and then there's still been those Lambda functions or serverless functions that have been on their own server somewhere out there in the world. And so you still get cold-start issues and you still get latency depending on where you are on the globe.

So getting those two things to kind of merge with each other, the serverless functions and the CDNs, that's been the thing. And the issue has been compatibility. And if you're using Cloudflare Workers, then you can't run the same things you would just run in a Lambda function because you're no longer using Node. And so this is something that I think is going to bite a lot of people as they start using Vercel Edge, because Vercel Edge is built on Cloudflare Workers. So you're going to have the same issue where people are going to be writing code, thinking, oh, this is kind of just like a Lambda, right?

[00:28:23] And so they end up writing code like it's Lambda, but then it doesn't work because it doesn't actually have Node in it. They may be able to work that out if they just implement their own Express-like abstraction, which is what a lot of people are doing. There's worktop, a Cloudflare Workers framework from Luke Edwards that gives you a very nice kind of Express-like syntax.

And so I think we're going to see a lot of innovation there over the next year. And you have other ones that are building on Wasm or even Deno, because Matt Billman talked about this on one of his podcasts when Edge Functions first came out, that they're actually building on Deno, I'm pretty sure. And so that's really weird and unique also. And most people have no idea what the difference between Deno and Node is and what it would mean to write for one or the other. So it's definitely going to be one that I'm going to be watching and keeping a close eye on, because it's something I've been very interested in.

[00:29:24] And I'm glad that Vercel is continuing to push in this direction.

00:29:27 - Christopher Burns

That was it. So there's two things. There's Next.js middleware, and that's what is specific to Next.js. And then there are edge functions by Vercel. They kind of just shoved it together in the presentation. But the edge functions by Vercel are framework-agnostic, so they could be used on something like Redwood or Gatsby or something else.

Will it have many uses currently? They've got quite a few uses out of the box, from A/B testing to basic auth to bot detection, geolocation, JWT authentication. I think the biggest thing that will really be the big test is, can I move that server functionality that connects to my database closer to the edge, as in edge functions using something like Prisma? The answer is, as you said, maybe we're getting there, but the answer is currently no.

And I think this is a really interesting point to just sideline on. Isn't it PlanetScale that says like a database on a CDN, or something along those lines?

00:30:40 - Anthony Campolo

So you got PlanetScale, and you also have CockroachDB, which just released their serverless offering as well. And they're a multi-region Postgres sharded database that gives you like this whole global database type thing. And if you've ever heard us talk about Fauna, this is one of the things that Fauna had going for it as well.

So yeah, getting the database on the edge is going to be kind of the next big thing. And there's actually two things I want to get into here that are super interesting because we've had Fly on. Their episode hasn't aired yet, but that's going to be a really good one, because Fly is also pushing this idea of what if we just basically make everything a CDN, just have absolutely everything geo-replicated, and you can do that with Postgres containers and you end up with your database all over the place.

And then the really interesting thing that happened is Prisma now actually works in Cloudflare Workers. This has been one of the really huge, long-standing things that has kept Redwood from going all in on something like Cloudflare Workers, is that Prisma just hasn't worked.

[00:31:53] Like you couldn't run Prisma Client on Cloudflare Workers until like a week ago. And so they now actually have docs. And you can do this and you connect to MongoDB Atlas, which is their kind of serverless database offering as well. So as of today, you actually can run almost everything on the edge all the way down to the database. It takes a ton of configuration and a lot of knowledge about these specific, specialized services, but it actually is possible now in a way that it really wasn't a year ago.

So I think this is super exciting. And for people who want to have a true application that can scale like this, this is going to be the way to go. Kent C. Dodds made a big splash with his new blog, and he built it on Fly and did something similar to this. So I think we're going to see a lot more people start to build applications this way and start to show the benefit you can get from it.

00:32:51 - Christopher Burns

But this is something you just said: tons of configuration and tons of knowledge. In the next year, do you think we'll see, in layman's terms, I can use one service to deploy my DB, my functions, and my React app onto the edge? I personally think the answer is going to be no, but in three years, yes.

00:33:15 - Anthony Campolo

I think you can do it today on just Fly. And so I think if you really learn how their thing works, because part of the thing is you just need a service that already figured out Kubernetes for you. Because I don't know if he's literally running Kubernetes, but they're running something that's very, very Kubernetes. It's really just about these container cluster pod things. I imagine people who are DevOps people, they've known how to do this for a while, I would guess.

And so in terms of making it a turnkey thing that anyone can use, it's going to be how well do you already know one of these services, and how well are these services integrated with your framework? Because Redwood has been working very hard on getting good first-class Fly support. It's going to get to the point where you can just take your Redwood application, run a single command, and then it sets up your Fly thing and just shoves your project up, and that's it. So there will be ways to do it that are going to be fairly simple, but it's just going to depend on what services you want to use and what framework you have.

00:34:13 - Christopher Burns

I'd like to say I remember four years ago when I first looked at, you know, I need to write a server function, an AWS Lambda on the edge, right? And that was four years ago, but we still haven't fully worked it out. But we're getting very close now.

I think the last thing I want to talk about in terms of CDNs and providers is a wild card. And that is, what do you think of what Brandon's doing at Blitz.js with Flight Control? What are your thoughts on it?

00:34:46 - Anthony Campolo

That was awesome. It's super great because, going back to our Round Table episode, we had a long discussion about this, about the problems we were having with the current providers and what it would take to have kind of the ideal deployment and hosting experience for these full-stack applications. And the conclusion that we pretty much all came to is that we need to just make our own. We need to figure out exactly how to optimize for these apps that we're building, because they are slightly different from a traditional monolithic app and a traditional decoupled Jamstack app. It's some weird kind of middle ground between the two.

So it makes sense that there wouldn't be good hosting providers for us, because we're not really doing something that slots into the model for how other people used to do this kind of stuff. So seeing him announce his own hosting provider, Flight Control, it was really exciting, and I'm very happy for him and I'm super stoked. You could pay like $20 to get in on the early group of people who get news and stuff.

[00:35:50] So I'm in there. There's been really no news whatsoever aside from they've had like one hire so far. And so it's still super early days. Like, you can't use it at all yet. But really happy for him. And I hope that we'll get to do something similar with Redwood one day. I think it's definitely in the cards. It's just going to be a question of how motivated we are to actually do it.

But there's so much room in this space because there's just so many problems to fix in DX and working with AWS and that kind of stuff. So whatever he puts together is going to be really awesome, and I think we'll kind of show the way of how we can make a nicer DX experience around deploying these kind of apps.

00:36:36 - Christopher Burns

Yeah, and I think some of that came to my mind is our episode with Jason Lengstorf. He said, no matter what you need to build, Netlify will build it. And I think that's a really good thing that always sits in my head: the end game card that you could say for every single framework is build your own hosting platform for it. So you can really eke out that performance, because that's what we've seen with Gatsby. It's a perfect example of they built out their own cloud with Gatsby 4.0. They're saying it's going to build a lot faster on Gatsby Cloud. You should just use us, but obviously you can still build it wherever.

Exactly the same with Netlify, that a feature they released is kind of dueling with Vercel features now. It's kind of the end game card. I'm really interested in Flight Control. Hopefully we'll have a working alpha by the end of year two of the FSJam, and we'll definitely get him on to talk about that. Something else that I think is really interesting.

[00:37:34] What is FSJam? It's a really interesting question because over the last year I feel that the jam has gone through an identity crisis. I think even it has. Personally, I think we're more at a point where maybe it's just full-stack JavaScript. I don't know, I feel like we go through these cycles of decoupling, to couple, to decouple. What are your thoughts?

00:37:58 - Anthony Campolo

Well, something we should mention is that Redwood is no longer a full-stack Jamstack framework, according to the website. If you now go to RedwoodJS.com, the headline has always been bringing full stack to the Jamstack, and that's really the origins of this podcast, is you and I meeting, working on Redwood and seeing this kind of full-stack Jamstack thing and wanting to take it beyond Redwood.

But Redwood seems to think that it's not really a useful term, and that they felt that it confused people and made them think, okay, this is just like a Jamstack thing, so that means it has all the limitations that the Jamstack has. And the whole point that we've been talking about is that the point of the full-stack Jamstack is to address the issues that Jamstack had. And so that's why we're using the term. But they have now changed to it's the JS app framework. And I was saying how I jokingly troll people by saying that the JS stands for Jamstack, but it doesn't. It stands for JavaScript.

[00:39:00] So it's the JavaScript app framework. They're leaning more heavily into just JavaScript and being something for apps. And I think that's probably the right move in terms of people get apps. I just talk to random people on the street and my mom and stuff; my mom knows what an app is, kind of. And so it's a good term for the types of things you want to build.

But I think that Jamstack isn't going anywhere. I think it's going to still be a huge thing in the industry, and so I'm still happy to keep using the term full-stack Jamstack. And now that Redwood has kind of dropped it, it just opens the space up more for other frameworks that are going to be interested in doing this kind of stuff, like Webstone and all these really newer kind of things that no one even knows about yet, but could become a big deal over this year.

00:39:52 - Christopher Burns

Exactly. And I'd like to just say I put on my cynicism glasses and I said it should be the TS app framework because TypeScript is fully supported. So why not just say TypeScript? But all aside, it's really good that they've expanded it because Redwood's doing something, I think, unique where they're trying to, instead of saying to your Gatsby developers, build an app with Redwood, it more feels like they're speaking to Ruby, PHP developers, as in, this is the JavaScript framework you want to build the next thing with. You hear everybody talking about JavaScript, but you've not touched it in ten years. This is the way to do it.

I think there's a lot of merit to them dropping it, and I can't wait to see where it goes. In terms of the term, yeah, I'm super excited. I still think it matters. I still think it's meaningful. I still truly don't know what the M is in JAM. Is it markdown? Is it anything else?

[00:40:50] You decide. MDX now? Haven't we all dropped markdown for MDX? Is it JavaScript, APIs, and MDX? You be the judge.

00:41:01 - Anthony Campolo

I like mash-up: JavaScript and API mash-up. Just mash them together.

00:41:05 - Christopher Burns

Yeah, I can see that working. But it's this thing: they drop the A and the M to lowercase. So now it's just JavaScript, the big thing, and it will always be the big thing.

00:41:14 - Anthony Campolo

Well, that wasn't the idea. The idea of dropping the acronym was not that it's just JavaScript. It was that you drop JavaScript, APIs, and markup altogether because you could build a Jamstack app without JavaScript at all. So that's the idea of them changing the acronym.

00:41:31 - Christopher Burns

But that's the point. But you can't. But you can because, say, Eleventy, but Eleventy is built with Node. So it is JavaScript, but it's not JavaScript in [unclear].

00:41:40 - Anthony Campolo

Yeah, but it's just like Jekyll. Like Jekyll is Ruby and can just spit out HTML. So that's the idea in terms of you don't need JavaScript to do this.

00:41:49 - Christopher Burns

Yeah. It's going to be a super interesting year as to where we're going next. It's a really interesting one. I'm going to put my predictions in: we're going to go full 180 and everyone's going to be like, just server-side render everything. As soon as React 18 comes out and Next has their server-side React components, I think "client render everything" is going to look old. I think we're going to see the complete opposite, where it's going to be, I hate to say, the next Chad thing to do is now everything is server-side rendered. I've got this new tick on my thing saying server-side rendered, supported or whatever. I think that's going to be the next big thing for JavaScript, React specifically.

00:42:41 - Anthony Campolo

All right. Well, this is a really fun conversation. I'm glad we got to do another one with just the two of us. We should try and do these a little more frequently than once a year. But yeah, thanks so much, Chris, for doing this podcast with me, and we've had so many awesome guests and so many great conversations. I'm so excited to see where this all goes. Next year will be continuing to talk to new people and new companies and new projects, but I know we'll also end up talking to a lot of our other guests.

Again, there's quite a few that we've started chatting with to get on a second time, so it's going to be really great just to continue to build these relationships and see where the ecosystem is going and kind of share the knowledge of what we're learning as we go.

00:43:29 - Christopher Burns

What I want to say is, yeah, thanks for doing this podcast with me. But I think thanking each other is a bit like patting each other on the back. I think the biggest thing that I can take away from this whole podcast is that maybe React isn't the only cool thing on the block, and there's a lot of cool things coming up, and I really hope some of them take off and become really big things.

Like over the next year, I want to get a guest Nuxt expert on the podcast because Nuxt 3 looks pretty good. All you got to do is take off those React glasses and say, I'm going to go look at something else, and you realize it's completely different, but they're still having fun.

00:44:09 - Anthony Campolo

Yeah, and that's awesome because Nuxt was one of the things I said I wanted to learn over the course of this year. And actually, I did do a decent chunk of some Nuxt work, and I already have a Nuxt 3 blog post out there that we can link to, so definitely would be very curious to get a Nuxt person on.

00:44:26 - Christopher Burns

Yeah, I guess my biggest thing is that we're always open to more guests, no matter what size you are. If you're a developer working on a side project or a massive company, we're really interested in hearing what you've got to talk about, and it doesn't have to be framework-related as well. We've obviously in this last year started as, oh, we're this full-stack JavaScript thing, but I'm excited to start hearing about Rust. How does Rust come into JavaScript? I would love to get someone on to talk about that. That's completely crazy.

And I don't want to say this, but I want to be that guy who asks the question, why do I need Rust to compile my JavaScript and act like I completely know nothing? Because someone's got to do it. Because why is Rust a thing? I still don't know, and I'm sure we'll find out soon.

00:45:20 - Anthony Campolo

All right, we'll catch you guys next time.

00:45:52 - Christopher Burns

Bye.