Next.js Post Conf Recap

Episode Description

JavaScript Jam discusses the Next.js 13 conference announcements, community reactions to React-Vercel ties, and new features like TurboPack and React Server Components.

Episode Summary

This JavaScript Jam Live episode centers on the Next.js Conf and the release of Next.js 13, featuring Jeff Escalante, engineering manager for the Next.js team at Vercel. The conversation opens with community drama sparked by a comment that "Next.js 13 is the real React 18 release," reflecting broader concerns about the tight relationship between Vercel and the React core team. Panelists like Theo and Anthony Campolo argue the concern is misplaced, noting that open source participation is available to any framework willing to engage. The discussion then shifts to the actual announcements: the new App Directory with nested layouts and React Server Components (in beta), TurboPack as a Rust-based Webpack successor (in alpha), an improved image component, a new font loading system, and Satori — a WASM-powered tool for generating social share images on edge functions. Brad shares his early migration experience, and Jeff explains how React Server Components fundamentally change the mental model by defaulting components to server-rendered and requiring developers to explicitly mark interactive pieces. The episode also tackles whether Jamstack is dead, with Jeff arguing that purely static approaches don't scale for growing companies and that smart caching abstractions are the future. Throughout, concerns about Vercel consolidating too much JavaScript talent are addressed candidly.

Chapters

00:00:00 - Introduction and Next.js Conference Drama

The episode opens with Scott welcoming listeners to JavaScript Jam Live and introducing the day's topic: a post-mortem on the Next.js Conf. Theo, who attended in person and live-tweeted the event, joins the stage early and sets the scene for the controversy that erupted on Twitter.

The central drama stems from a Q&A comment suggesting that Next.js 13 represents the true React 18 release, implying that React's newest features only become meaningful through a server-aware framework like Next. Theo explains that the tight collaboration between the React core team and Vercel made other framework communities uneasy, raising fears of centralization. Anthony Campolo pushes back, arguing that frameworks like Hydrogen actively engaged with React Server Components while others waited for an invitation rather than stepping forward.

00:05:06 - Community Reactions and Open Source Governance

The panel explores whether the backlash was really about a single comment or a longer-simmering tension in the React ecosystem. Anthony draws on his experience with Redwood to argue that any framework could have integrated React Server Components but many simply chose not to. Andre compares the situation to early enterprise reluctance around React itself when it was seen as a Facebook-controlled project.

Ishan broadens the discussion by referencing State of JS surveys showing Next.js as the dominant meta-framework, drawing an analogy to browser market share and standards adoption. The group acknowledges that while the fears aren't baseless, the open source nature of the work means participation is available to anyone willing to contribute, and the anger may say more about the community's expectations than about Vercel's intentions.

00:12:03 - Early Migration Experiences and DX Improvements

With Jeff Escalante not yet on stage, Brad shares his hands-on experience upgrading a dashboard side project to Next.js 13. He describes a smooth migration for the image and link components using code mods, though TurboPack proved incompatible with a third-party library. The group discusses how the new image component's automatic dimension detection echoes ideas from AMP, and how Next.js's expanded tooling scope lets it solve problems like layout shift more elegantly.

Ishan highlights the font loading improvements and references a tweet questioning whether the "zero layout shift" claim is overstated, since size-adjust CSS can only approximate glyph matching. Brad notes the new font import API looks promising but he hasn't tested it yet. The conversation touches on TurboPack's claimed performance gains over both Webpack and Vite, acknowledging it's still early-stage alpha.

00:17:18 - Brad's Dashboard Use Case and the Layouts RFC

Brad describes his project StatusPilot, a landing page plus dashboard app that maps perfectly onto the new App Directory and nested layouts system. The classic dashboard pattern of a persistent sidebar, top bar, and swappable content area is exactly the use case the Layouts RFC was designed to address, and the group connects the dots on how this has evolved over the past year.

Ishan explains that building dashboard-style apps where some components persist across navigation was always awkward in React, and the new layouts system finally provides first-class support. The discussion reinforces that the App Directory migration is opt-in and page-by-page, lowering the risk for developers who want to adopt incrementally rather than rewriting their entire application at once.

00:23:16 - Jeff Escalante Joins and Highlights of Next.js 13

Jeff Escalante, engineering manager for the Next.js team at Vercel, joins the stage and lays out the three categories of the Next.js 13 release: the App Directory with React Server Components (beta), TurboPack as a Rust-based Webpack successor (alpha), and several DX improvements including the new image component, font loading, and an OG image generation tool. He emphasizes that the App Directory is still beta and welcomes community feedback.

Jeff goes deeper on TurboPack, noting it was built by Tobias Koppers (Webpack's creator) and a team of Rust specialists, with incremental builds as its core architecture principle. He stresses that early benchmarks are promising but it has a long road before it can replace Webpack in production apps. The new image component leans on native browser features like lazy loading rather than custom polyfills, and the font component aims to eliminate the recurring headache of font-loading best practices.

00:33:33 - Satori and OG Image Generation

Anthony asks Jeff to expand on the new social share image generation tool, which Jeff credits largely to Shu Ding. The previous approach embedded Puppeteer in a Lambda function to screenshot rendered markup, but Puppeteer's size caused cold start delays and bumped against serverless function size limits. The new approach uses Satori, an open source library that converts markup to SVG, then converts the SVG to PNG using WASM libraries.

Because the process avoids heavy Node runtime dependencies, it can run on edge functions for near-instant image generation. Jeff notes that Satori doesn't support every CSS property a browser would, so developers should consult its documentation for edge cases. However, Vercel is already using it for their own conference tickets and blog post images. The group agrees this represents a major paradigm shift from the Puppeteer-based hack that had become common in the ecosystem.

00:38:18 - Jamstack Is Dead and the Future of Caching

Jeff and Ishan revisit their long-running friendly debate about whether Jamstack is dead. Jeff argues from experience at Hashicorp that purely static sites don't scale beyond a certain company growth point, because personalization, authentication, and performance optimization eventually demand dynamic server rendering. He points out that for large companies, shaving fractions of a second off render times is worth millions of dollars.

Ishan largely agrees but frames the evolution differently, quoting T.S. Eliot about returning to where you started with new understanding. He suggests the industry has come full circle from static to dynamic back to smart caching. Jeff agrees that caching is the right abstraction but notes its complexity, arguing that Next.js aims to hide that complexity by letting developers declare their data-fetching intentions while the framework handles deployment and caching decisions behind the scenes. Ishan adds that the key insight is giving front-end developers direct control over caching decisions rather than leaving it to infrastructure teams.

00:46:23 - Concerns About Vercel's Talent Consolidation

Eric voices concern not about nefarious intent but about the natural consequences of one company accumulating so much JavaScript ecosystem talent. Jeff responds candidly that Vercel's intentions are purely about building great tools, and that everything including TurboPack is and will remain open source. Eric presses that good intentions don't prevent monopolistic outcomes, and Evan Yu's response about Vite benchmarks suggests competition is already feeling the pressure.

Anthony offers a balanced perspective from the Redwood ecosystem, noting that Redwood went through a similar tight coupling with Netlify before expanding to seven deployment platforms. He argues that using Next.js as a test bed is legitimate as long as the tools are genuinely opened up afterward. Ishan reframes Eric's concern as a governance question, asking whether a foundation model might better serve a framework with Next.js's market influence. The exchange ends cordially with Jeff emphasizing his openness to feedback and DMs.

00:59:49 - React Server Components Explained and Closing

Jeff and Ishan break down React Server Components for the audience. Jeff explains that the current model sends both static HTML and full source code to the browser, which must rebuild the page to figure out where interactivity is needed. With server components, developers explicitly mark only the interactive pieces as client components, dramatically reducing hydration time. Ishan illustrates this with a DocuSign analogy where only the signature button needs browser interactivity.

Jeff highlights the mental model challenges ahead, using the example of two client components needing shared state when their parent is a server component that can't hold state. He compares the transition to React Hooks, noting it's opt-in and pages-directory code isn't going away. The episode closes with Jeff encouraging community feedback, Scott reminding listeners to follow speakers, and a warm send-off as the panel wraps up the hour-long discussion.

Transcript

00:00:42 - Scott Steinlage

Welcome, welcome, everybody. Hopefully you can hear me just fine. Welcome, welcome.

00:00:52 - Ishan Anand

Yes, we can hear you.

00:00:54 - Scott Steinlage

Awesome.

00:00:54 - Ishan Anand

Sorry, I might be on mute for the first few minutes. I need to transition rooms.

00:00:59 - Scott Steinlage

Sure.

00:00:59 - Ishan Anand

But kick us off there.

00:01:01 - Scott Steinlage

Yep, about to do so. No problem. All right, thank you all so much for joining us today. Welcome to JavaScript Jam Live. We do this every Wednesday at 12pm Pacific Standard Time. Super exciting. We will be having a special guest here today, Jeff Escalante from Brazil, and he's gonna be talking about Next.js with us. What happened, what didn't happen, all the cool stuff that we want to hear and talk about. He should be joining us here soon, and we'll bring him on up. Looks like we got some awesome people here in the audience. We got Theo. Long time no see. Anthony, long time no see. Yes. Brad, our dear friend Bro Nifty, aka Boo Nifty. Watch out, yo. Nice, man. Matt, yeah. So glad.

00:02:12 - Ishan Anand

And Theo was actually a speaker at Next Conf?

00:02:15 - Scott Steinlage

He sure was. I think he's a speaker at every conference.

00:02:20 - Ishan Anand

He was a speaker for the Composability Summit as well.

00:02:23 - Scott Steinlage

Yeah, yeah, yeah, for sure. All the invites. All right, I guess we'll bring you up. Absolutely. There we go.

00:02:41 - Theo

Wanted to give you guys your well-deserved credit for being the first people to invite me to speak at something. So yeah.

00:02:48 - Ishan Anand

I take that as an honor, so thank you. Were you there in person for the conference?

00:02:55 - Theo

Not only was I there in person, I was live-tweeting it. That caused half the drama on Twitter.

00:03:00 - Ishan Anand

Oh, which part was the drama? I've been looking through a bunch of threads. I saw your thread about what they didn't announce. I think it was TypeScript and Create React App. But what was the drama you're referring to?

00:03:16 - Theo

One of the speakers during the Q&A section said something along the lines of, "Next.js 13 is the real React 18 release." And that wasn't taken super well by the community.

00:03:26 - Ishan Anand

Oh, I did hear that in the Q&A session. But tell me more. Why? I know why they said that. Maybe we should, for the audience, set the context for what they meant by that and then tell me what the community reaction was to that.

00:03:48 - Theo

Sorry, I was misclicking buttons in my DMs. God, I've really lost my voice, man. The best I can explain it is that, for the changes in the new version of React to really be valuable, you need to be able to run it in a server runtime that's aware of React and its needs. Next.js is one of the most prolific ways to run React on your servers. And React Server Components need a runtime like that to be useful and used in the first place. We haven't really gotten to see a lot of the benefits of the new server component architecture because we haven't had a major framework that's consuming it. And the close relationship between Next, Vercel, and the React core team has allowed them to really take advantage of these new features and show them off properly for the first time.

00:04:40 - Ishan Anand

Yeah, I was actually making that point to one of my coworkers. I'm actually at an offsite right now, and I was like, you realize most of the things we're talking about with React Server Components were released a year ago, but no, two years ago.

00:04:56 - Jeff Escalante

Since December 2020.

00:04:58 - Ishan Anand

Thank you. Thank you for the correction.

00:05:00 - Anthony Campolo

Yeah, I remember the day it came out.

00:05:06 - Ishan Anand

Yeah. So can you name names? Was it other framework creators feeling left out and that there's like a favorite son here? Could you maybe elaborate a little bit on how it was taken?

00:05:21 - Theo

From what I've seen, there's a lot of general skepticism of a company having such a tight relationship with React when, historically, React's been the modular, "it's just there, do what you want with it" framework. This is a huge shift in how Vercel and the React core team interact with people outside of it, and that change is making people scared. Especially when you look at previous frameworks like Remix, Gatsby, and all these other awesome tools that might not have that same relationship. There's a lot of concern there. I think it's misplaced simply because so much of the React core team works at Vercel, and the parts that don't are very grateful for Vercel for pushing these things forward. There's a great thread by Dan Abramov about a lot of this and how excited he is by it. Funny enough, I actually chatted with him right after that conference, right after that Q&A, because we wanted to chat about it. And generally speaking, I think there's a lot of fear because there are a lot of things that can be perceived as centralization.

00:06:24 - Theo

But what I'm seeing is less centralization, more progress.

00:06:28 - Ishan Anand

Is it centralization? Oh, go ahead.

00:06:30 - Anthony Campolo

I was just saying I think this was a PR kind of snafu more than anything. I think the way it came out, people didn't like it. But I'm someone who is on a React meta-framework team, on the Redwood team, so I actually can speak to how other frameworks may or may not have perceived this. And I don't think they did anything wrong at all. I think all this is very, very misplaced anger. And the way I say it is, if you want to be involved, get involved. This stuff is still open source. There's nothing stopping any framework from integrating this stuff and working on it. People just didn't. And now they're complaining that they weren't involved in the process.

00:07:09 - Scott Steinlage

Yeah, absolutely. I mean, we have the CTO of Vercel in here with us right now. I didn't know if you wanted to touch on anything, but I invited him to speak up here if he wants to participate. More than happy to hear from him.

00:07:26 - Theo

on a billion things, so I'm going to switch down to listener for a bit. I might pop back up if something triggers me enough.

00:07:33 - Ishan Anand

The one thing I'll say on this topic is it's interesting. It was set off by a single comment, and I agree with Anthony's take. It's open source. If you want to get involved, get involved. I'll just say this is supposed to be a podcast about technology, less about politics, but it is a human endeavor, and it feels like the comment was the straw that broke the camel's back. Am I wrong that this sentiment might have been building before, and that simply was the dam breaking? And that's why there was a reaction. It wasn't about a single comment. It's more about something that maybe has been ongoing. Or is that not a good...

00:08:13 - Anthony Campolo

It's the "let them eat cake" of the JavaScript world. Let them eat cake.

00:08:20 - Ishan Anand

I mean, well, Anthony, since you've been on Redwood, do you feel like that's accurate to say it was more than just a straight comment? It might be a reflection of the relationships that each of the frameworks have with, say, the React core team.

00:08:35 - Anthony Campolo

Yeah, I mean, it's complicated, and I understand why people feel this way. But going back to the first thing I said, I think that if React frameworks want to get more involved, they need to get involved. If anyone on Redwood complained that we weren't involved, I would say that's ridiculous, because we didn't even make an attempt to integrate React Server Components. That's on us, to not bring ourselves to the table. Hydrogen is an example of a React framework that said, "Hey, we want to integrate this. We want to be involved." They gave a lot of notes, and they were able to help shape what React Server Components became. And they're not Next and they're not Vercel, so it is possible. But I think frameworks were kind of waiting for the invitation when they should have just put themselves forward saying, "Hey, we want to be involved."

00:09:31 - Scott Steinlage

Absolutely. I think. Ishan.

00:09:34 - Ishan Anand

Yeah, sorry, I was fiddling with my buttons.

00:09:36 - Scott Steinlage

No worries.

00:09:37 - Ishan Anand

We got Andre coming up here.

00:09:38 - Scott Steinlage

Yeah, I know. Don't worry about the request, bro. I hit them every time, I think.

00:09:43 - Ishan Anand

I think I have like a hundred percent failure rate for that, and then you

00:09:46 - Scott Steinlage

usually end up muting everybody.

00:09:48 - Ishan Anand

Then I mute everybody, you know, once bitten, twice shy. But yeah, Andre, go ahead.

00:09:55 - Andre

Hey guys, I just wanted to say this kind of reminds me of the relationship that a lot of larger enterprises had with adopting React early on, where there was fear because it was a framework coming out of then-Facebook, where the reality is it is open. And though the announcement yesterday may have set off some strong emotions, everybody can choose to get involved. And if we choose not to as a community, that's on us a little bit more, just the same as it was with enterprise adoption versus Angular six or seven years ago now. This kind of feels like the same argument, but in a different community.

00:10:47 - Ishan Anand

It's an interesting analogy. And this may be dangerous, but in some sense I have to agree with the comment. When you look at the State of JS reports, when you look at the Stack Overflow survey, in terms of adoption, it is probably the most popular meta-framework. I guess the analogy would be it's like back in the old days when IE had the most browser share. I guess now it's Chrome, right? And one of the browsers suddenly adopts a new standard and supports it, then people feel like it's really arrived. So I don't think I would have been taken aback by that statement. But I can certainly understand those folks in the community who were, and what sentiments might have led to it. And I see Malta in the audience. He had a really great thread. I was actually going to tweet it out and quote it and say, if you read one thread about what was released at Next.js Conf, read his. It was a really good thread. It'd be great to get you up here.

00:12:03 - Ishan Anand

And I think. Scott, is Jeff supposed to be joining us?

00:12:09 - Scott Steinlage

I mean, he's definitely supposed to be joining us. I messaged him. I haven't seen anything yet, but. Okay.

00:12:16 - Anthony Campolo

Yeah.

00:12:17 - Ishan Anand

Okay, well, let's move on to talk about what was actually announced. And I'd love to hear from the audience. What announcements got you the most excited? What did you think wasn't that great, or what did you have concerns about? They're introducing, I guess it depends what the antecedent for the pronoun "they" is, whether it's the React team or the Next team, this new paradigm, React Server Components, a new way of looking at data fetching. Feel free to raise your hand. JavaScript Jam is, as we like to say, an open mic for JavaScript and web development, so feel free to raise your hand. We'll bring you up to the stage. But I'd really like to hear from the audience what their thoughts were on what was announced yesterday. What were the high points or maybe the low points? And Anthony, if anything jumped out at you.

00:13:14 - Anthony Campolo

Yeah, I didn't actually watch any of the conference itself. I've been kind of busy with my own stuff, but I've just been watching all the fallout online.

00:13:25 - Ishan Anand

Well, you know, I went through Hacker News and I went through Twitter, went through a bunch of threads collecting some reactions. The first immediate reaction that jumped out to me... oh, we've got somebody coming up.

00:13:40 - Scott Steinlage

Yeah, Brad. What's up, Brad?

00:13:46 - Ishan Anand

Hey, Brad. Hey, guys.

00:13:51 - Brad

Don't know if my connection's too good. If I'm a bit choppy, let me know and I'll switch to mobile later.

00:13:58 - Scott Steinlage

Sounds good, but no.

00:13:59 - Brad

Yeah, I was just gonna chime in there on interesting points from the conference. I followed along as well as I could, jumping across the stage from the main keynote. I went ahead and already updated to Next.js 13 to give it a try. Couldn't unfortunately try Turbopack because some library I'm using seemed to conflict with something. But other than that, I've already migrated over to the new image component, which I'd been putting off using because of the structure where you had to provide all the sizing and stuff, and it didn't fit with the couple of little icons and assets I had across a landing page. But it's been quite a smooth update, and all seems to be working well minus this issue with Turbopack. But no, yeah, I was interested to try out the new layouts as well. That's something I've been following along with, so that's the next thing on my to-do list.

00:15:08 - Ishan Anand

Yeah. So let's talk about the migration process. One of the smart things both the React team did when they did React Server Components, and I guess Concurrent Mode, is that it was opt-in, and Next.js followed that lead, that a lot of the new features are opt-in. You used to put, or you can still put, all your code in the pages directory. There's a new directory called the App Directory where you put basically your new pages that follow the new default paradigms that are now going to be entirely server-rendered as React Server Components. When you say you upgraded, did you just upgrade the version number in package.json, run some codemods, and do it, or have you actually started looking toward moving things from pages?

00:16:02 - Brad

No, that's the next thing on the list. I was planning on getting rid of some plugins. I was still using this Next Image Optimize plugin that I've been using for a while. I had a task to deprecate this, and it was literally while I was watching the conference I was like, I'll do it all in one and move to the new image component while doing so, obviously updating links as well, which had some small issues there because of styled-components and the as prop and some stuff like that. But basically, for those who don't know, the Link component in Next.js, you no longer pass it an anchor as a child. There's a prop for backwards compatibility and there's codemods for all this, but I did it manually. There's only a couple of anchors across the site that aren't using a shared component. But no, next thing is definitely going over to the App Directory and seeing how I can benefit from that. Because in this structure I've got a dashboard, basically, where I've already got some layouts, but I'm not using the new layout structure. So I've got to move that around a bit.

00:17:18 - Brad

But definitely going to give it a try in the coming days.

00:17:22 - Ishan Anand

Got it. So I was just about to ask you about your use case. Your use case is like a dashboard, is that correct?

00:17:28 - Brad

Correct.

00:17:29 - Ishan Anand

Yeah, it's a little side project I'm working on.

00:17:31 - Brad

StatusPilot app. I don't have a link in my bio or anything.

00:17:37 - Ishan Anand

Yeah.

00:17:37 - Brad

And it's a landing page plus dashboard app sort of thing.

00:17:46 - Ishan Anand

Okay, very cool. So it's basically what the new Layouts RFC and app dir were really built for.

00:17:53 - Brad

Exactly. Literally left side navigation, a top area that's shared and then the typical sort of right side content area, which is what each page is going to be filling.

00:18:10 - Ishan Anand

Yeah. So that's actually been, you know, we can gradually connect the dots over the last year. For the audience, it was easy to build, say, something like an e-commerce site in React, but if you're trying to build a dashboard where parts of the page don't change as you navigate around, but other subcomponents in the page do, it was a little harder. They created the Layouts RFC, which they teased about earlier. Now we're starting to see the benefits and the instantiation of it now in Next 13, so that's really exciting. Okay, that's really cool. Then I also noticed the Link tag not needing an anchor component. I was like, oh, I felt like it's about time. Then when it came to the image component forcing you, it's forcing you to do a couple things. It's forcing you to add an alt tag now, and it's forcing you to add height and width. And I remember looking at that, and my immediate thought was, AMP, the framework, was right. And I honestly have to say, I know I say this every fourth episode, but I really feel like AMP was the most misunderstood framework out there.

00:19:27 - Ishan Anand

The success of AMP is that all of its ideas just end up inside other frameworks. And because it's no longer labeled AMP, people don't have a negative reaction to it. So I thought that was a really nice change, especially for reducing layout shifts. I thought that was a really good, positive move that struck me.

00:19:48 - Brad

Yeah.

00:19:48 - Ishan Anand

To add on to that, if I can.

00:19:50 - Brad

Ishan, yeah, go ahead. With the image component, if I heard correctly, you said width and height are required, but especially...

00:20:00 - Scott Steinlage

Well,

00:20:03 - Brad

Certainly for local assets that you import and then pass into the source as an imported module, those ones you don't have to give a width and height to anymore, which I really liked because I have some widths and heights set responsively in some styled-components, and I didn't feel like moving it around into using the attributes on the old image component. Now you seem to get some of that out of the box. That's how I've understood it anyway.

00:20:35 - Ishan Anand

Yeah, no, not required.

00:20:36 - Brad

At least all I got was source and alt are required from using it.

00:20:40 - Ishan Anand

Yeah. My understanding is it's going to pull that in for you. Right?

00:20:44 - Brad

Yeah.

00:20:45 - Ishan Anand

Which is actually a really valuable lesson when you think about the scope boundaries you look at on the job to be done. AMP didn't necessarily come with the tooling to the extent that Next.js incorporates, well, no longer Webpack, now Turbopack or whatever, when it says we're going to take the whole build step. AMP couldn't have come in and said that. It was more like React. But now, when you look at the job to be done and you put a requirement like that on people, you can say, well, let me let the tooling solve part of this to make it easier and less onerous for developers. So I think that's actually a really valuable lesson, that when you expand the boundaries of the job to be done, you can actually start coming at a problem in a way that makes everyone happy. So that's a good callout. Yeah, I maybe misstated that one a little bit. Were there any other things that jumped out at you?

00:21:47 - Brad

The fonts import as well looks, I must say... I mean, fonts is already, especially using Google Fonts, not really even a problem anymore. The layout shift from fonts is barely noticeable. I've got some, let's say, good defaults. I think I'm using Inter as well, which is quite similar, at least on macOS, to the system UI font. I've matched up the widths and the letter spacings a little bit to match it as much as possible. But just as an easier solution, instead of having that huge chunk of however many lines of CSS in my app...

00:22:31 - Anthony Campolo

Too.

00:22:34 - Brad

Just having that direct import from, was it like font/google, and then you do a named import for the font you want. But I didn't try it out. Well, I went to try it out and I had other priorities, so I was like, well, I'll check it out later. Because I didn't see too clearly how I could define the weights that I wanted to import. But I didn't go digging too much. I was looking literally on the blog release. I think it was in the notes there.

00:23:01 - Ishan Anand

Yeah, obviously.

00:23:03 - Brad

As well as all this, the big news, like the server components and using Turbopack under the hood and all that stuff. Looking forward to those things for sure.

00:23:16 - Ishan Anand

Yeah. So let's talk a bit on fonts. There was a tweet from Andy Ingram. It was posted yesterday at 6:18, and he mentioned the font thing, and it was the one part where I felt like maybe there's a bit of overselling. And he said, quote, "It seems disingenuous to claim zero layout shift with the new font stuff on the basis of just using size adjust. You can claim reduced, but each glyph sizes differently. It may turn out to be a distinction that doesn't make a difference. Maybe it gets you 90% of the problem, maybe it gets only 20% of the problem. We'll see what happens." I was wondering if you've played with that, but it sounds like you haven't had a chance to dig in. So I was really curious what your experience has been on that. And then the other one that I was curious about was Turbopack. So one of the quotes, and this was from the Hacker News thread, when people saw Turbopack, there were a lot of comments like this one, and it was, quote, "It's getting really interesting and tiresome at the same time with the JavaScript ecosystem and how quickly things change."

00:24:23 - Ishan Anand

But Turbopack brings two orders of magnitude speed improvement over Webpack. They quoted numbers that are an order of magnitude faster than Vite for bundling all your code together. So I was curious if you've noticed that. But again, I think you said that Turbopack wasn't compatible, and they acknowledged during the Q&A that it was still in alpha stages.

00:24:48 - Brad

Yeah, I literally just got a plain Rust error, and I had to set some flags to see the logs, and it was some incompatibility. I've got this React typewriter library, this UI library that types out some text that you pass to it, and you can delete it, write to it, and all that sort of stuff. And something in there isn't compatible, the way it's exporting the ES module, I think it was. I can't remember now, but yeah. And I was like, it's not super important for me to try it out. I wish I could have, but I can wait. Usually I've always been like that with Next.js, staying on a previous version or something from when I first started the project. And I've done the minor upgrades but not done a full-blown one. And I went to version 12, I don't know, six months ago or something, and it just happened. I was watching the conference when they said it's out, you can try it. And I was like, hey, why don't I give it a try? I was looking to get rid of this image plugin I had, and it all seemed to work.

00:25:54 - Brad

I've stuck with it, but I've yet to try Turbopack.

00:25:59 - Ishan Anand

Yeah, let us know in a future session.

00:26:01 - Scott Steinlage

It will do.

00:26:02 - Brad

Yeah, I'll keep you updated, but it

00:26:04 - Ishan Anand

looks like we've got Jeff. Hey Jeff, welcome back to JavaScript Jam. I know you were on the podcast a while ago. I've got a couple questions for you. Maybe, Scott, you just do the midpoint station break and then we'll...

00:26:21 - Scott Steinlage

Absolutely planning on doing that.

00:26:23 - Ishan Anand

Let's do that and then turn over to Jeff.

00:26:25 - Scott Steinlage

Sounds great. All right, thank you so much for joining us, Jeff. All right, welcome, guys. If you haven't been here before, this is JavaScript Jam Live. We do this every Wednesday at 12pm Pacific Standard Time, and we have awesome people like Jeff in the house right now who's about to give us some more information and awesome stuff to talk about with this Next.js post-conference recap here. So really excited to hear from him. Yeah, remember, if you're a beginner at this or you've been doing this for a long time, developing that is, we'd love to hear from everybody. Okay? This is going to be an open mic type of atmosphere here. Okay? Feel free to come up on the stage, ask questions, participate, share your opinions. We'd love to hear it all. In fact, that's where we get the most value, when you guys are participating. Everybody else gets the most value from it too. By the way, if you get value from someone on stage here, please click on their face and follow them.

00:27:14 - Jeff Escalante

Why?

00:27:14 - Scott Steinlage

Because you're probably going to get value from them in other places, so be sure to do that. Also, we have launched our newsletter, and if you don't want to miss out on the latest on tech and everything that's happening in the development and JavaScript world, feel free to get yourself on there. Just click on our image, go to our Twitter profile, and it's right there. All right, thank you so much, Ishan.

00:27:38 - Ishan Anand

Okay, Jeff, why don't we start with you just introducing yourself and your background, and then talk about what you thought were the highlights for you at the Next.js conference announcements.

00:27:51 - Jeff Escalante

Hey, sure. I hope you can all hear me all right. I kind of lost my voice from yelling all day long and talking to people at the event here in San Francisco, which was really a blast. But I'm the engineering manager for the Next.js team over at Vercel, and super happy to see how everything went down. Really proud of the team. They did a ton of really, really hard work for this release. So thrilled to be here. And yeah, your other question was one of the highlights of the conf, right?

00:28:31 - Ishan Anand

Yeah,

00:28:35 - Jeff Escalante

Mostly the same context here. Yeah, good, go ahead.

00:28:39 - Ishan Anand

I was going to say we should let people know that prior to being at Vercel, you were at HashiCorp, but you were using Next.js for the documentation system. So you also come at it as a user and not just somebody on the inside. I think that's important to highlight. So maybe put yourself in both mindsets, both from inside the belly of the beast and also as a user, what you think are the most important highlights that would have made you super excited when you were at Hashi, so to speak.

00:29:08 - Jeff Escalante

Yeah, good call. So the general highlights, in case anyone didn't catch the event itself, were obviously the release of Next 13. We typically do a major release of Next.js at our annual conference, and this year was no different. And the big features of this release, there were kind of three categories of features in general. The first one was the App Directory, which is a pretty substantial change, an entirely new router that supports nested layouts and React Server Components. And there's quite a lot of new patterns that we're going to have to learn and figure out over this period. It's worth noting that the App Directory release was a beta, so we're still kind of expecting that there's going to be some bugs and things that we're going to have to work through and feedback that we're going to get from the community. But that's what a beta is, so feel free to test it out and give us some feedback. There's a lot more docs on this. If you go to nextjs.org/13, you can find all the information about the release, because I know I'm being kind of brief in this summary.

00:30:27 - Jeff Escalante

Second big-ticket announcement was the announcement of Turbopack, which is a Rust-based kind of successor to Webpack that's been worked on by Tobias, the author of Webpack, and a really great team that we've assembled here of platform-focused Rust developers. So that one is also even earlier stage. It's an alpha. It's still got a long way to go before we can actually replace Webpack in a substantial app. But it's been pretty exciting so far to see it taking shape. The initial benchmarks have been really strong, and the performance has been really good. It's really focused on incremental builds at its very, very core. That's kind of the core architecture principle of it. So we're excited about that. We'd love to get some feedback, and we'll kind of see that come along further over the coming months. And then the last category was some more DX-focused enhancements to Next itself. There's a new image component that makes some nice improvements to performance. It kind of drops some of the things that we were polyfilling before in favor of just falling back directly to platform features like lazy loading, which are better supported now.

00:31:52 - Jeff Escalante

And we also have a new Next font component that will allow you to quickly and easily load up fonts. As we all probably know, if we've done any web development here, which I assume most of you have, loading fonts is this thing that's always changing. And every time I go and work on a website and load fonts, I'm Googling, what's the current best-practice way to load a font? And so hopefully this kind of just makes that go away. We're just going to make sure that this is always using the current best-practice way to load a font so that you don't have to think about that and look it up. And additionally, there's a really cool feature where we will go to the fallback font and automatically make adjustments to the sizing of the fallback font so that the character size matches the custom font as closely as possible. I'm sure we've all seen websites where they have the fallback font, and then it loads the custom font and replaces the fallback with a custom font.

00:32:53 - Jeff Escalante

But then it causes all the text to shift and the layout to shift, which is really frustrating. So that will reduce this as much as possible for you automatically, which is really nice. And then we also released effectively an image generator tool that allows you to serialize markup into an image. The primary use case we're imagining for this is social share images. If you have to dynamically generate a social share, this will let you sort of just drop a page into whatever app you want to use. The image generation library is open source, and it's available for use with any host.

00:33:33 - Anthony Campolo

That's a killer feature, if you can talk more about that, because social images are a huge pain in the butt. Having it built in is awesome. Can you talk more about that?

00:33:43 - Jeff Escalante

Yeah, yeah, happy to. I mean, all credit goes to, well, actually there's a bunch of people working on this, but the one kind of leading out the project was Shu Ding. If anyone is not following this man already, he's truly a visionary developer who put together this concept of being able to do it. Originally, we had this library, I think it was like Vercel OG Image or something like that, that would embed Puppeteer into a Lambda function. And you could put in some markup and it would run Puppeteer to generate a copy of the page and then take a screenshot of it and dump out that screenshot as an image, which is pretty good. The problem is Puppeteer is huge. And that means that your loading was really slow because it got loaded into a Lambda function. You had a cold start, your cold start was even longer because the amount of code that needed to be loaded was really large. And also, Lambdas have a size limit. And the Puppeteer image started to exceed that size limit. So we had these issues with this library where we had to use an older version of Chrome, Chrome's rendering engine effectively, in order to render the image, because if we upgraded to newer versions, it was over the...

00:35:04 - Jeff Escalante

The size limit for serverless functions. And so we knew we needed something better because it was starting to diverge more and more from what you would see if you ran that same thing in your actual browser. And so the way that this works is, there's a library called Satori, which you can find on GitHub, and it's open source, that effectively takes markup and serializes it into an SVG. And then it does this using WASM libraries, and then it takes the SVG and turns that into a PNG using more WASM libraries. And what's cool about this is, since it doesn't heavily leverage node runtime stuff, and since it uses WASM libraries, you can run this on an Edge Function. And so what we recommend doing is just taking the library and having it run straight off of an Edge Function where it doesn't need to fetch data, so it can run actually on the edge. You don't need to regionalize it. I might be going way too deep into the weeds here.

00:36:14 - Anthony Campolo

No, this is great because I've heard other people... the first thing you described, about the Puppeteer hack in a serverless function, you can find a dozen blog posts telling you how to do this. It's this common thing people have done. I've never done it myself because it always seemed ridiculous, but it makes sense that you would have kind of taken that approach to its logical conclusion and been like, we need a paradigm shift. And so WASM on the edge is a paradigm shift. And it's just, it's very cool.

00:36:42 - Jeff Escalante

And the performance metrics we're seeing from this are crazy. It's effectively instant that you can generate them, whereas before there was kind of a decent wait. So we're really excited about this and excited to see how people use it.

00:36:53 - Ishan Anand

So just so I understand, it's replacing the job of Puppeteer by running some stuff in WASM, but that stuff in WASM is basically... or am I misunderstanding?

00:37:02 - Jeff Escalante

It's turning the markup into SVG and then it turns SVG into an image so it skips the whole browser rendering piece. As crazy as that sounds.

00:37:14 - Ishan Anand

Does it still have... oh, I don't want to rabbit-hole too much. But now I've got lots of questions, like, does it have to build a render tree, right? And all the other parts that go into it. But I agree with Anthony. I mean, that's a huge, huge efficiency gain.

00:37:28 - Jeff Escalante

It doesn't support everything. It's not unlimited. There's a certain set of properties that it supports. It's not like you can just take any page that would render in a browser, drop it in here, and it's guaranteed to come out one-to-one. But you can go look at the docs for Satori, and it will kind of break that down a little bit.

00:37:44 - Ishan Anand

Got it. That's exactly where I was going to get to like what are the edge cases? So that's a good answer.

00:37:49 - Jeff Escalante

There are edge cases for sure, and you should read the docs beforehand. But we've kind of covered enough of them that we feel like you can generally do what you need to do with share images. For the conf ticket images, and we're using it on our own website for blog posts and everything, it does a pretty good job. You can get custom fonts in there, you can drop images in there and place them, you can style them. But yeah, if you go to the docs, it kind of explains what the edge cases are, and we're working on filling in more of those over time as well.

00:38:18 - Ishan Anand

Maybe I just want to browse the web in that engine.

00:38:21 - Jeff Escalante

I think that would probably. I don't know if that would work out, but, you know, I'd be curious.

00:38:28 - Ishan Anand

I would be on that experiment, I agree. You mentioned the other day, last week, I had a Twitter thread and you responded a little tongue-in-cheek and you said Jamstack is dead. The slogan for the conference was dynamic without limits. You mentioned React Server Components, which I think plays a big role in this. But do you want to elaborate on what you meant when you said Jamstack is dead? And I had a different take on it. I'd like to hear.

00:39:02 - Jeff Escalante

Yeah, that's been a friendly debate.

00:39:05 - Ishan Anand

Yes.

00:39:07 - Jeff Escalante

In a friendly manner for probably literally years at this point, yes. So there's a history here if you want to go back down the podcast archives between the two of us. But generally, I guess my perspective, and this is kind of informed by my work here and also informed by the journey I went through at my last job at HashiCorp, where I was kind of there from startup through IPO phase, and got this really unique opportunity to experience a really fast, aggressive period of scaling for a company. Where I'm coming from with this standpoint is just that, to be very straight with it, I just don't think static scales. At a certain point, you can get by for a certain period of time with static, but after a certain point it just doesn't do the trick for you as a company after a certain growth point. Because it makes sense for you to invest in dynamically rendered pages for a variety of reasons, whether that's you adding some sort of login to your page, whether it's you personalizing some of your marketing so that it's more effective.

00:40:25 - Jeff Escalante

There are certain things that, when you're a small organization, it doesn't make sense to invest in because the scale that you're operating on would make the cost of doing it higher than the payoff. But as you scale up, that calculation changes. An example I give for this a lot is, for big companies like Amazon or Walmart or Target, shaving a tenth of a second off the average render time for one of their pages is literally worth millions of dollars. So they'll hire a team of three full-time senior developers, and it would be totally a great move to do so, if possible, just to tackle that problem. Whereas a startup, that would be so foolish that you'd probably go out of business because it just doesn't make sense at that scale. And so based on my own experiences and the experiences of folks that I've talked to, it just feels like investing too heavily in static is going to lead you into a situation where you get stuck at some point in your company's growth curve.

00:41:31 - Jeff Escalante

And you don't want to put yourself in that position. You want to put yourself in a position where, as you grow, your tools can continue to scale with you into what your needs are going to be at a larger scale. And the traditional model of Jamstack, I mean, we've talked a lot about the fact that the definition of the word Jamstack is something that's continuously changed. But the original definition, which is kind of how I think of it, was that Jamstack is all about a static site that can be hosted statically. It can be built entirely at build time. You don't have servers generating pages on demand as users access them, and then any kind of dynamic capabilities that you need, you just do using client-side JavaScript. And I don't think that approach actually works for larger companies. And we've seen that in the fact that it literally doesn't...

00:42:24 - Ishan Anand

Let me push on that. I actually agree more with you than I disagree. I think this is why the definition of Jamstack has continued to evolve over the last couple of years. It's interesting that the way Next.js historically tried to bridge this divide was we had these alternative rendering patterns, ISR and ISG. Now in Next 13, it seems like you're going back to regular caching. I had this quote that I often mention, which is that T.S. Eliot quote that's like, "At the end of our searching, we'll come back to where we were and know it for the first time." It kind of feels like that's what's happened here. At the end of the day, rather than static, what you should just do is stick a cache in front of it, and then whatever gets used the most should be cached the most, generally.

00:43:22 - Jeff Escalante

Yeah.

00:43:23 - Ishan Anand

Good.

00:43:24 - Jeff Escalante

I mean, I think I agree with you on this in general as well. I think the problem with this typically is that, as we all know as people who work in computer science, dealing with caching is very difficult, one of the most difficult things to deal with. So if you can use a tool or service or some combination of both of them, whatever it ends up being, certainly not trying to sell anything here, but if someone can build something that gives you that capability but takes away the difficulty and complexity of the caching needs for you, it ends up being viable to run things that way even when you're at a small scale and you don't have the resources to invest in trying to figure out how to deal with complex caches. And so that's kind of, I feel like, generally the gist of what we're going for with Next.js. We're trying to make it fast enough and easy enough to deal with for you that you don't have to really worry about whether it's static or dynamic, the way that it's being rendered off the same server.

00:44:32 - Jeff Escalante

And then the reality behind the scenes is that we kind of render most things off the server, unless you have a page that genuinely doesn't have any need for server rendering, and then it will just get automatically optimized into static, taking that decision away from you and just being like, write your app the way that you want your app to be written. When you're fetching data, tell us as part of your data fetch how you want the data fetching to work. Do you want it to be refetched every time every user goes to the page? Imagine your Twitter feed. That's probably not cached, because every time you visit the page it needs to update because you want to see the latest tweets. But there are plenty of other situations, like maybe some content from your marketing CMS, that you really don't need to go back and fetch every time. And so changing the interface and the semantics for folks so that they can just be clear when they are fetching data about what their intention is for how they want that data to be fetched can kind of put a separate interface over the top.

00:45:32 - Jeff Escalante

That's understandable and that you can deal with. And then under the covers, we'll just figure out how this needs to be like deployed in order to work the way you want it to work.

00:45:40 - Ishan Anand

Yeah, let me... we've got two folks coming up on the stage. I just want to rephrase, I think, what you said slightly differently, which is, I think the challenge we've had with caching is that the cache was really not under the control of the developer. The person who can make the judgment call you just described, to know the main Twitter feed page shouldn't be cached but your profile page is fine, is the developer writing the code. And in a large enterprise, historically, that developer hasn't really had access to the CDN control panel or control over the VCL code, and so they've been very disassociated from it. And when you expose it up to the front-end developer, then you get the real power.

00:46:22 - Jeff Escalante

Absolutely.

00:46:23 - Ishan Anand

Yeah. So I don't know, Bro Nifty or Boo Nifty for the season, or Eric, which of you is first up? I'll ask you to use the honor system.

00:46:32 - Bro Nifty

You want to go first, Eric?

00:46:34 - Jeff Escalante

Not really.

00:46:35 - Eric

I just wanted to have the button to participate when I wanted to, but so far I've watched almost none of the Next Con. I've just been watching the shadows on the cave wall of Twitter about what's happening, but it all sounds really exciting. I guess if you squeeze me for an opinion, I'm concerned about the monopoly of JavaScript power. I feel like Vercel is buying all the talent, and I think it's going to be hard to compete with them, but that's my only concern.

00:47:34 - Ishan Anand

So you actually mentioned that at the beginning. Sorry, I think I cut you off. Go ahead.

00:47:41 - Jeff Escalante

No, no, no.

00:47:42 - Eric

Like, I saw a four-tweet thread from Evan Yu that was basically like, yeah, it's faster than Vite, but under certain circumstances, and we're also competing in this area. But anyway, no, continue.

00:47:59 - Ishan Anand

Well, so that's interesting. I mean, obviously it always depends on how you're going to measure the optimization. I'm sure there are points at which Vite scales, but I think your bigger point is that it's not about features or performance. It's a political one, and it seems there are rumblings about that. I don't know if Jeff is the right person to address it. It is an open source framework, but I don't know. Jeff, do you want to respond to that?

00:48:29 - Jeff Escalante

I've been kind of responding to threads along this line sort of all morning. You know, I think that, at least, I haven't been at Vercel for a super long time. I've been here for less than a year, but it's been great, my time being here. I feel like everybody is super nice, super friendly, super positive, and optimistic. And what we're trying to do is just make really great tooling. I think you could trust me on this, but there's absolutely no devious, monopolistic intention here, or anybody trying to...

00:49:09 - Eric

No, no, no, not on purpose. Not on purpose. I think that's the thing that naturally happens. And, you know, I consider myself a friend of Guillermo's, but yeah, I think that...

00:49:28 - Ishan Anand

in,

00:49:28 - Eric

In their best intent, sometimes with the best intentions they end up, I don't know, breaking the most eggs, or some metaphor.

00:49:37 - Jeff Escalante

Yeah, I mean, I'll be very transparent with this. I really think it's just people selling FUD. I'm not gonna lie. I am super happy to talk, to work with, to collaborate with anybody on any of this stuff. I'm super happy to connect anyone with any of our staff. I'm super happy to talk about what we're working on and what we're thinking about. There's not really anything that we're trying to box people out of. We just want websites to be fast and great and awesome, and we're just trying to build good tools for people to do that, and that's it. And we're trying to hire the best people we can, like any company would.

00:50:18 - Eric

And yes, I agree. I understand.

00:50:22 - Jeff Escalante

We're not locking people in or anything like that at all. All of the core libraries here are open source. We're open sourcing everything that we've got. Webpack is open source. It always will be. It's not attached to Next.js. It can be used for anything. It always will be. It's the same story with Turbopack. It's the same story with everything. We want to be... we want...

00:50:42 - Eric

Well, hold on, hold on.

00:50:44 - Jeff Escalante

Because we're the best option, not because we're the only option or because we've locked you into anything.

00:50:49 - Eric

It's not quite the same story. It's going to work first with Next and then with other platforms with TurboPack. Yeah, I mean, everything.

00:50:59 - Jeff Escalante

Yes, that's true. It's just our test bed. But we're super alpha. And I've talked about this a lot, very specifically with the team, because there are a lot of people internally who have this concern of, like, this is not going to be the Next.js bundler. This is going to be the bundler that's available for everyone to use.

00:51:16 - Anthony Campolo

It's just.

00:51:16 - Jeff Escalante

Just that Next.js is our test bed, kind of in a similar way to how it is with React and Facebook. Facebook is a great test bed for React. It's a huge, exceedingly complicated app that they can kind of prove it out against. But it's not like you can only use React with Facebook. You can use React for anything. So we're really not intending it to be locked into Next.js. It's just how we're developing it in its early stages.

00:51:44 - Eric

Yes, I. I agree that there is no intention, but sometimes things happen.

00:51:52 - Jeff Escalante

I'm working my absolute hardest to make sure that they don't happen in that way. And if anyone has any feedback for us, my DMs are open.

00:52:00 - Eric

Thank you. Thank you. Thank you for that.

00:52:03 - Ishan Anand

So I think we've triggered Theo and Anthony. And Theo, I think you've got a stream you're launching in seven minutes, if I'm not mistaken. So I'm gonna let you go first. I'm actually a hard stop at one, but I'll let you go first over Anthony. Go ahead.

00:52:19 - Theo

Yeah, I'll be super quick. I appreciate the acknowledgement of that. Yeah, I'll be live in a few minutes. I'll probably be like 15 minutes late to my OBS being a shitter anyway. I wanted to quickly double down on everything Jeff is saying, both as a person who's been in his DMs for a while now complaining about things and seeing how quickly they get fixed, but also because I am obviously a big Vercel fanboy, arguably even more so than a Next fanboy at this point, where I use the hell out of Vercel's infrastructure deployments, et cetera. And funny enough, Next is one of the worst runtimes to play with the edge stuff on Vercel right now. It's just unstable and unreliable. And I love using edge on Vercel. I use it through Astro and through SvelteKit, because those are the libraries and the frameworks that have the best support for it right now. Not only is Vercel not just doing things that only help Next, they're giving access to things early that actually make Next a worse bet. One of the biggest reasons I won't be using Next for some projects in the near future is because Vercel has made innovations outside of the Next ecosystem and given them to us before Next is ready for them.

00:53:25 - Theo

So for everyone like, "Oh, this is something Next gets first,"

00:53:28 - Theo

[unclear]

00:53:28 - Theo

"Oh, this is something Next gets last."

00:53:31 - Jeff Escalante

Yeah. I think the Build Output API is a really great example. That may be not a super well-known Vercel project, but one of my little passion projects, because it was one of the first things I was assigned to work on when I joined. But if you haven't checked it out, I definitely recommend looking up Vercel Build Output API. It's effectively a file-system spec for just being able to deploy whatever you want to the platform. We had a lot of people that were like, "Only when you support this certain framework can we deploy it easily to Vercel." And I was like, yeah, that's very valid feedback. So we kind of opened it up, and now you can just take whatever you want. It can be no framework, it can be an existing framework, and you can just use it. Just say, mark this as I want to deploy it as serverless. Mark this as I want to deploy it as Edge Function. Mark this as you want to deploy it as effectively an ISR primitive where it puts out a static file, but then also in parallel deploys a serverless function that handles the revalidate timer.

00:54:30 - Jeff Escalante

So like we're really just trying to make tools that are useful to people and open them up for like whatever use they want to have.

00:54:38 - Ishan Anand

So Anthony, did you want to talk on this topic or something else?

00:54:42 - Anthony Campolo

Yeah, I'll be brief. Because I'm someone who I think can have somewhat of a neutral opinion in this matter, because I'm someone who's been very heavy in the Netlify ecosystem my entire career. And Redwood at a point in time was exactly where Next and Vercel kind of were, in the sense that they built around each other. Redwood, for a certain point in time, was made to work with Netlify. And so I do agree with people who have a fear here that the two are going to mold each other, because to a certain extent they will. That's not necessarily a bad thing, though, because as we've seen now, Redwood works on seven different deployment platforms. So as they're saying, it's a test bed, it's a way for them to figure out what works and then you can kind of spread it out. So I think that when they say that, they're being legitimate, and we'll only really be able to see that in time, but doing it open source is all you can really do. I don't think there's much more we can ask beyond just saying, all right, acknowledge that there's pitfalls here, but if you do this right, this can still work out for everyone.

00:55:44 - Anthony Campolo

So I think that the fears are justified, but I also want to support Vercel and that I don't think they're doing anything wrong right now.

00:55:51 - Ishan Anand

Maybe to rephrase Eric's point a different way, when I heard Eric, it didn't sound like he thought there was anything nefarious or a conspiracy. In fact, he said he was friends with everyone and he felt like they all had the best intentions. I think the question might be better stated: what is the right governance model for a framework that has so much heft in the market? So would something like a foundation, for example, make more sense? Or a DAO? Yes, maybe. Right, Eric? Is that a better way to phrase it? Your concerns are, I don't want to say theoretical or hypothetical, but we have seen situations in the past where something that was loved by the community got acquired by somebody else, who then uses it in a way that's different from the original owners.

00:56:47 - Eric

What I'm seeing is a consolidation of talent in the space to a company. And companies, by definition, have a motive to their shareholders in a way that, as much as you want to say, you know, open source, open source, open source, it's still... And again, it's not like I would have the DOJ come in and break up Vercel. No, that's...

00:57:18 - Jeff Escalante

That's.

00:57:19 - Eric

That's silly. But what I'm seeing is a consolidation of talent in the space that I know and love. And a lot of the talent previously has been unpaid open source labor. And I'm so happy that those people are finally getting some padding in their bank account, but I feel uneasy having so much water in that one... I don't know how best to say it.

00:57:58 - Jeff Escalante

Yeah, well, you know, we are hiring. There's one way to solve this problem, Eric.

00:58:09 - Scott Steinlage

Just jump in the water. That's the problem.

00:58:12 - Eric

Hey, I went through the Vercel hiring thing a couple years ago, and we agreed that at the time I was not a good fit, but, you know, whatever.

00:58:25 - Jeff Escalante

Sounds like it might be time for another round.

00:58:27 - Eric

Yeah.

00:58:30 - Ishan Anand

Yeah.

00:58:32 - Eric

By all the naysayers, right?

00:58:34 - Ishan Anand

Yeah.

00:58:35 - Jeff Escalante

I mean, I'll say that it was a big pull for me. Seeing all the super talented people that were working there, being able to work with those people is just incredible. Like you're saying, I've really never seen such a concentration of talent, at least in the space that I follow in the industry. And it's really cool, at least from the inside perspective. It's just amazing to be able to see those people sitting in a room and collaborating on a project together. We had an offsite for the Next.js team in Portugal a couple months ago, and at some point I was just sitting there thinking, this is just insane. There's no way that you could ever find this group of people together in the same physical space unless something like this happened. There were just people flying in from everywhere, you know. And it just got me thinking about remote work in general. It's just wild, the ways that this has allowed the geographical distribution of niche specialists to actually be able to work together on projects and be employed for it.

00:59:49 - Jeff Escalante

I don't know if this is a silly reflection, but for me I was like, I've never seen anything like this happen, and it's just so cool.

00:59:58 - Bro Nifty

That is wonderful. If I can just get this in real quick here before you have to leave and everybody has to leave. Ishan, for Jeff, we're all piling on. It's Jeff time. Thanks, Jeff, for joining us today. I was curious about the implementation detail real quick. Did you use something like Browsercloud, or perhaps create your own custom serverless function? Because I worked with scraping in Next, taking some cues from Mohul Mohan, really super, super smart guy. He showed me how to do some stuff in there, screenshotting and whatnot. I needed to do a little bit more heavy-duty stuff, get access to the file system and stuff like that, so I had to go into Docker and use a custom container. But something like Browsercloud, I've heard good things about that. Have you ever used that for scraping, or what? Just out of curiosity, at a super high level, what did you guys do for your HTML?

01:01:10 - Bro Nifty

Sorry, this hearkens back to way before we got off this topic, but for creating the OG image, I believe, is the process to do the social share.

01:01:20 - Jeff Escalante

Oh, yes. Are you talking about the original version or the new version that we released recently?

01:01:26 - Bro Nifty

Oh, I don't know. I heard something about a scraper and so that's what made me think about it.

01:01:31 - Jeff Escalante

Yeah, I don't think we were really scraping anything. What I had mentioned before is just, effectively, in order to generate an image on demand, you would take some markup and just run an instance of Puppeteer, pass the markup into it, and then screenshot it, and that would be the image. That was our previous best option for generating social sharing on demand. But we've released something new that works in an entirely different way now, and it's much quicker. So that one's kind of going away anyway.

01:02:04 - Bro Nifty

Okay, so Puppeteer. Yeah, Puppeteer is for the scraping. Yeah. Okay, so you were running Puppeteer in like a...

01:02:10 - Jeff Escalante

It was in a lambda.

01:02:12 - Bro Nifty

In a lambda. Okay.

01:02:13 - Jeff Escalante

Yeah, exactly.

01:02:15 - Ishan Anand

Okay, thanks.

01:02:18 - Jeff Escalante

Yeah, you got it.

01:02:21 - Ishan Anand

So just a time check here. We're right at one, which is our normal ending time and what we'd asked from you, Jeff. I don't know if you have a hard stop. I actually am supposed to be. And Theo, I think, has to hop in.

01:02:38 - Jeff Escalante

You are correct.

01:02:39 - Theo

OBS crashed five times, but I think I found the plugin that was causing it, so hopefully it won't crash again.

01:02:45 - Ishan Anand

Okay, good luck.

01:02:52 - Jeff Escalante

You know...

01:02:52 - Ishan Anand

You went over the highlights, and you said React Server Components, and then you talked about Turbopack, and then some DX improvements. And the way I like to break that down is that the first one's going to make your site faster for your users. The second one is going to make your building of your site faster for you as the developer. The third is actually going to make both lives easier. On that first one, the React Server Components, it's going to make your site's users happier, the site faster for them. But you dropped this maybe-understatement, which is we're going to have to learn some new paradigms. There's things like with streaming. If you're streaming the data and you stream out the output and you say it's a 200 request, which means it was a success, and then you later determine while you're doing the fetching that you find there's an error, how do you signal that? There's all sorts of stuff in there. What are your thoughts on how long it's going to take the ecosystem to adapt to the new paradigm? And what do you think are probably the biggest gotchas people are going to encounter, trip over, when they try it out?

01:03:53 - Jeff Escalante

This is a good question. I'll give you my best take. I mean, I think some of it we're gonna find out here as people start testing things out. But this definitely is a really big change. I think that it is important to note, and I go into some of these scary-sounding things as a caveat, that the existing pages directory that doesn't use React Server Components is not going away. So it's not like you have to migrate. And on top of that, you can do it one page at a time, so you don't have to stall out your whole development team to migrate everything. This is kind of like a React Hooks type transition, where it's a really big change to the mental model. Some people will be unhappy about it, but overall we feel like this is the right direction and most people are satisfied with it, and you can use it for new things. You don't have to go back and refactor everything. Class components aren't going away. It's kind of that same type of vibe with this change. But in the same way, when Hooks came out, there was a lot of, like, we have to reconsider our patterns of how we do architecture now.

01:05:09 - Jeff Escalante

And I think it's going to happen the same way with React Server Components because they're just so different than the way it works now. And I mean, for anyone that hasn't looked into React Server Components, it might be worth doing a quick breakdown of what the difference is with them. Maybe you want to go on a tangent right

01:05:29 - Ishan Anand

there and do that for the audience, or I can jump in and give a take and see if you want to correct me. Either way, I think you're right. We actually should spell it out for the audience.

01:05:36 - Jeff Escalante

Yeah, I'm happy to. Right now, the way that React works is that you put content on the page. Some of the content requires interactivity on the browser side, some of it doesn't. So for example, you might have some paragraphs and some text and some images on your page that could render on the server, and it doesn't really need the browser to do anything else or touch it or parse it in any way. But then underneath those paragraphs of text you might have a button where you do actually need the browser to connect a click handler to it, because you can't send a click handler over the server, right? It's just static HTML. And so in the current model, you just build the whole page, and React will take the whole page and kind of... when you're server-rendering, you send a copy of the statically built page that's not interactive in any way. And then you send a copy of the source code that was used to build that page. And the browser effectively runs the source code to create a second copy of the page.

01:06:39 - Jeff Escalante

And then it does this, quote-unquote, virtual DOM diff of the two different pages, and it figures out where it needs to inject interactivity into the page. And with Server Components, the control goes back into your hands over that. So instead of you just doing the whole page and then React has to figure out what parts need interactivity and what parts don't need interactivity, now you mark the parts that need interactivity as needing interactivity. And the default is that it would not need interactivity. And this way you can get a much quicker result because React doesn't have to waste time looking through all of this content that doesn't actually need to be hydrated. And I'm sure we've all run into pages where you load the page and you click on something and it doesn't do anything, but then after a second or two it actually does do something. This is the hydration process. It dumps out the static HTML, and then the browser goes to work trying to figure out where it needs to add interactivity. And so that process should get faster when you have only marked small sections that need interactivity as needing interactivity in the first place.

01:07:53 - Jeff Escalante

Can I jump in with an example?

01:07:56 - Ishan Anand

Yeah, yeah, yeah. That might make it a little concrete. I thought that was a good explanation. But just to make it a little concrete, imagine a DocuSign page, right, where somebody sends you that link, you click on it, you read a giant contract. The only thing you need to do is one button at the bottom, which is to do the signature that says, "I agree." In the traditional React model, when you send that, even if it's server-side rendered, React has to, inside the browser, run all the code to build the entire document, including the contract and the button, even though the thing that's interactive is the button at the bottom. With React Server Components, it can send the entire document and it says, you know what, I don't have to rebuild the DOM tree for the document. I just need to do it for that button that you're going to click to say, "I agree." Just to make it a little concrete, but sorry, keep going.

01:08:42 - Jeff Escalante

No, that's great, thank you. I think that's really helpful. But generally, that changes the way that you need to think about how you put things together, and it adds an extra thing that you need to think about that you didn't need to think about before. The benefit is that if you do think about it, then you can get your page to be more performant. The downside is it's another thing that you have to think about that you didn't have to think about before. Now, you can just mark everything as a client component and it would work the same as before. But what's the point of doing that? You probably want to get something out of this if you're going to do the migration. And so I'm expecting people to start looking into how they can split up existing pages into chunks that they are going to have be server components and chunks that they're going to have be client components, client components being the ones that hydrate and require interactivity. But what's interesting is, when I started testing this out myself, I almost instantly ran into an example of something that dramatically confused me, which was if I had a server component that contained two different client components, let's say a page with a bunch of text on it, and it had two buttons that had counters on them.

01:10:03 - Jeff Escalante

And I wanted both of those buttons to share the same state. Today in React, what you would do is just put it in the parent component, put the state in the parent component, and then pass it to both children, and then you're good, because then they share the same state. But if your parent component is a server component, it can't have state because it doesn't hydrate, it doesn't run at all in the browser. So now you're like, okay, well, what am I going to do?

01:10:27 - Scott Steinlage

Right?

01:10:28 - Jeff Escalante

How do I share state between these two components? Because the parent is no longer something that I need to be a client component. Can I get away with this? I mean, there's going to be a lot more examples like that, but I think that's just one quick, easy-to-comprehend example of how there will be new architecture patterns that evolve, and there'll be new ways that you have to think about how you put your apps together, because this is a different programming model for React entirely.

01:10:58 - Ishan Anand

I actually have to jump. I think Scott's going to be able to stay on. I'm getting pulled into something else. But I just want to say two things. I agree with what you're saying. I think it's hugely important. It's probably going to be, for most people, worth learning the new paradigms because of the benefits to performance. And Jeff, thanks for joining and taking all the questions. I look forward to having you again on JavaScript Jam. Jeff, thank you.

01:11:22 - Jeff Escalante

Thanks for having me, man.

01:11:24 - Scott Steinlage

Absolutely. Thank you so much, man. I appreciate it. We all appreciate it. I'm sure there are so many people here that appreciate it. By the way, with that being said, if you haven't already clicked on Jeff's face there and followed him on Twitter, and if you're not already, I'm sure you are, but if you aren't, do that because I promise you, you're going to get a ton of value from this guy. I mean, just hearing our conversation today, I'm really excited for the future things that he's in charge of and pulling together.

01:11:53 - Jeff Escalante

So thanks, I appreciate it. And really, I'm super, super open to feedback. It's really, really important to us to make sure that we're building this for web developers to use, and so that it's something that they like and it's useful to them. So getting feedback from the community is super, super important for us. And I'm always open to take feedback from anyone, and that's literally my job, to figure out what we should be working on. And so it's very, very valuable for me to hear it. So if you've got thoughts and stuff, please feel free to reach out.

01:12:26 - Scott Steinlage

Absolutely, absolutely. There you go. Reach out in the DMs. You heard Theo earlier today on the call here. Theo was saying how he's been going back and forth over DMs with Jeff and how things change rather quickly with those issues or complaints or whatever it might be.

01:12:43 - Jeff Escalante

I can't guarantee it for everyone.

01:12:45 - Scott Steinlage

Well, sure, absolutely. But you know, Theo's got the pull, I guess, right?

01:12:49 - Jeff Escalante

If I hear the feedback, I'll make sure that it is like, I will make very, very sure that it's something that we're thinking about and talking about.

01:12:56 - Scott Steinlage

Absolutely, absolutely. It'll be top of mind, I'm sure. Well, fantastic. I know we've had some more people join the room here. Jeff, I don't know how much time you have left here. I don't want to continue to scoop that away from you. If you have to go, please feel free. But if you want to stay, I'd be more than happy to maybe put it out there if anybody has any other questions or anything. I don't know, let me know. What do you think, Jeff? One more? One more. All right. Anybody have one more good question? We have one more spot to come on up here and ask your dire question to Jeff.

01:13:35 - Bro Nifty

Jeff, I got a quick question for you. On the RSC, or the RFC for React Server Components, like 188, I believe it was, the way that Dan and his coworker had it wired up, it looked like it was wired up in Webpack and it was directly serving a server-side kind of deal. And then in the recent RFC with the use hook, which looked to me like an extension of RFC 188, the React Server Component and what you described, where, you know, how do you manage the state if it's on the server side versus can you put it in a parent component and then share. What it looked like to me was that the React Server Component is fetching the data on the server side and passing it into the child component as a prop. Then the child's just rendering it with that use hook, similar to if you had a TanStack Query or a Redux and it's making the fetch somewhere and then you use the hook to bring it into the component.

01:14:44 - Bro Nifty

You're not actually fetching in the component.

01:14:46 - Jeff Escalante

Yeah, totally. You can do that. And that is what we recommend doing generally, using Server Components for data fetching. The only caveat there is that it needs to be serializable, whatever you pass between a Server Component and a Client Component. So for passing in data, you're probably fine because presumably your data is serializable because it came over HTML in the first place. But when you're talking about the example I mentioned earlier, like sharing state or sharing a context provider that contains functions, you're going to run into an issue passing over that boundary because the boundary from server to client just has to be serializable, because you're moving over HTTP, if that makes sense.

01:15:34 - Scott Steinlage

Awesome. Go ahead. Okay, cool. Brad, I know you got your hand up there, man, and I know I have one more question, but I think you had raised it as soon as Bro Nifty started talking.

01:15:48 - Ishan Anand

Yeah, no worries.

01:15:49 - Brad

No worries. There'll be another time.

01:15:51 - Scott Steinlage

Okay, cool. All right, man. Well, thank you so, so much, Jeff. Thank you from everybody in this room. Can I get some love for Jeff here, man? Can I get some love? Some 100s, some hearts? Yeah. Put your hands together. Absolutely. Cool. I hope everybody had a great time at the Next.js Conf. I'm sure it was fantastic. It looked like there were some pretty cool things going on there. Wish I could have been there in person. Maybe next time. Love it. Absolutely. Absolutely. Don't forget, follow Jeff and anybody else that came up here on stage and you feel like you got value from them, follow them too. And hey, you know what? Give JavaScript Jam a follow too, if you don't want to miss out on the latest and greatest things in the web dev and JavaScript world. We love covering it all and hanging out with all those folks, including you. So don't forget to follow us. And don't forget, next Wednesday we'll be here again, 12:00pm Pacific Standard Time. We love y'all. Thank you so much for joining us.

01:16:53 - Jeff Escalante

Yeah, thanks for having me. This is great.

01:16:56 - Scott Steinlage

Thank you, Jeff. Appreciate it, man. Yeah, thank you. This is awesome. Hey, thank you all so much. Appreciate y'all. We'll see you in the next one. Peace.