995: Next.js Vendor Lock-in No More

In this episode, Scott and Wes sit down with Tim Neutkens and Jimmi Lai from the Next.js team to dig into the new Adapters API, what it takes to run Next.js across platforms like Cloudflare and Netlify, and how caching and infrastructure choices affect performance. They also go deep on TurboPack’s internals, why Next.js doesn’t run on Vite, and the evolution of bundling in the framework. Show Notes 00:00 Welcome to Syntax! 01:14 Introduction to Next.js and the Adapter Platform Next.js Across Platforms 02:23 The Adapters API: Features and Community Needs 04:46 Building and Testing the Adapters API 07:37 Infrastructure Requirements for Next.js Apps 11:38 Caching Strategies and Performance Optimization 13:29 The Role of Cache Components in Next.js 17:21 First Steps of Optimizations. 19:48 Blessed Adapters and Community Contributions 22:56 Future Directions and Runtime Support 25:05 Challenges with Different Runtimes and Debugging 26:45 Webpack vs. TurboPack: The Evolution of Next.js 29:45 Why Not Run on Vite? 32:47 Navigating Bundler Challenges 36:59 Building TurboPack: Lessons Learned 41:42 Incremental Compilation and Performance Episode with ByteDance’s Zack Jackson 43:50 Framework Comparisons and Performance Metrics 46:42 Exploring Future Directions for TurboPack 49:44 TurboPack’s Integration and API Development 52:50 Standardization in Bundler Tools 56:52 TurboPack’s Adoption and User Experience 57:49 Sick Picks + Shameless Plugs Sick Picks Tim: Acquired Podcast Jimmy: Hydrangea Coffee Shameless Plugs Jimmy: nextjs-across-platforms Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today, we have Tim and Jimmy on today. Tim is the, of course, the lead dev of NextJS, and Jimmy is the head of NextJS. And they're here to talk to us today about some cool stuff that they're rolling out around their adapters platform, which is going to allow you to host NextJS on different providers like Cloudflare and Netlify, as well as like different runtimes as well. Meaning like if you want to use Node or Bun or whatever, you can do that. Conversation takes a little bit to get warmed up, but trust me, it's going to be worth it because these are some super smart guys and I actually really enjoyed this conversation. We talked about caching, NextJS performance. We talked about turbopack and all the turbopack internals and

• 0:41Wes Bos?

  the whole process of building that. We, of course, asked them, "Why don't you just use VIT?" Like everybody else is asking, and they had a really interesting answer to that as well, which is, "Maybe, maybe one day." And infrastructure, just like in general, like NextJS, of course, is code, but it's also, if you want it to run like Vercel, it requires a whole bunch of infrastructure. So we kind of go through that as well. Let's get into it.

• 1:14Wes Bos?

  So, the other day, you guys launched, what, the adapter platform? Tell us about what that is.

• 1:20Speaker 01

  Yeah, so we launched adapters like API as like stable, which has been like a long time coming, as you said. We've been working on it for close to a year at this point. And so the idea, right, is that we kind of, NextJS by itself, you know, runs super well with like sort of Next Art, you know, like on the simple sort of like VPS, you can sort of like tap into like all capacities of Next. But when it comes to kind of scaling it, it's always been maybe slightly, slightly more difficult, just because like NextJS capacities, like the features like caching and ISAR just

• 2:00Speaker 01

  requires like, you know, synchronization across like, you know, multiple nodes if you need it. So, or with your CDN if you require it. And we basically introduced a layer so that you can

• 2:14Speaker 01

  Tap into this and have somewhat of a stable contract so that you can easily adapt it wherever you want to host it. Like the Adapter's API is useful for yourself if you're just hosting just across like five simple servers, you might not even want like a VPN, sorry, like a CDN or something. But it's also useful if you're someone like CloudFair or Netlify and you're hosting Next尚 in a specific way with serverless NMDs and you want potentially to host your middleware in a different way. And so, yeah, we created that API as a need to answer the needs of the community.

• 2:54Speaker 01

  We also created an ecosystem working group, which is basically composed of us and partners across Google, Netlify, CloudFair. We used to have AWS in the group, but they dropped that at some point. But the idea is that we, since a lot of the Next尚's features require that level of, you know, a certain level of infrastructure work to make it work on scale, we're basically creating groups so we can share ideas in advance, collect their feedbacks and kind of, you know, make sure that they don't dislike supporting Next尚 on their own platform.

• 3:31Wes Bos?

  Yeah.

• 3:31Scott Tolinski?

  Yeah. So you've mentioned that you've been working on this for quite a while now. So I take it then that this wasn't a knee jerk reaction to the slot fork, right?

• 3:44Speaker 01

  Yeah, not really, no. If you look back, we published RFC a year ago and maybe we, I don't, the timeline is quite fuzzy to me at this point too because it's been so long, but we had started engaging with Netlify and CloudFair and the OpenX guys even a few months before that. So. Not really, no.

• 4:07Speaker 03

  Yeah.

• 4:07Speaker 01

  Can't say it hasn't like, um, slope fork term.

• 4:11Speaker 03

  Yeah.

• 4:11Speaker 01

  I think one of the main points there, right, is that like, um, the main reason why CloudFair did this is that they kinda like wanted to avoid like, you know, some sort of vendor login and they wanted to make it like somewhat easier to support some version of NextX on CloudFair.

• 4:27Speaker 01

  And so we did want to show to the community that we also, well, we had so had been cooking on this. It's a great timeline though, because we internally, this matchup with like our testing or on testing, we were like, the reason why it wasn't stable is just that we wanted all of our own websites to be working on this Adapters API first before, before we published it. Yeah.

• 4:47Speaker 03

  Yeah. So we've been dogfooting it for, uh, for quite some time, like outside of, um, like this release, right? Like this release is marking it stable, but, uh, we, we introduced, uh, I think it was beta in, uh, at Nexus Call, uh, last year in October. Uh, but the, the reason that we hadn't marked it stable yet is that also we had been dogfooting it on our own application. So like we built the adapter for, for Cell. Uh, and we had been rolling it out to like all, like for Cell's own applications, like similar to how we do it for Nexus's features, like in general. And, uh, and that took some time because like we have a pretty large application and like, uh, we wanted to iron out all the, uh, like issues that we had with this, like, because, because for reference like this, um,

• 5:30Speaker 03

  like think about this like adapter that we had before was already like, uh, it had been battle tested across like, uh, like eight years or so. Like since we introduced like now V2, when we like introduced the serverless functions into Vercel, of that, like this was still the same adapter from back then. So that all the like possible edge cases that, that you could find in like Vercel, like Vercel version of, uh, of Nexus. This new adapter was like from the ground up, built on the Adapters API. Uh, so we're really like dogfooting this like in the same way that like every other platform is, uh, and Okay. And because of that, like we, we had to do like some extra checks to make sure that like we can roll it out to everyone, uh, in, in this way.

• 6:11Speaker 03

  So yeah, like that, that's like why the timeline was also like spread out over a year instead of, uh, like, hey, we have this new thing. Yeah. Cause in, in practice, like if you think about it, this like the Adapters API inside of Nexus itself, like that's not that complicated. It's like a couple of functions that have like a typed contract. I think the real point is like, you now have a integration layer that you don't have to like reverse engineer on any side of things, like not on Versale, not on any other platform. Because like, it's very clear that you could already host like NextJS on Netlify or CloudFlare, or like OpenX on AWS, or things like that. But basically, like this new API makes it a lot easier for these platform teams to just integrate with NextJS directly, instead of

• 6:56Speaker 03

  like having to like find which files need to be included in serverless applications, things like that.

• 7:00Wes Bos?

  Yeah, hack around it. It's like, I was trying OpenX on CloudFlare for quite a while, and I was like digging into it. It's during the early days of the OpenX CloudFlare, so I was doing like bug reports and whatnot. And I was looking into it, and like a lot of it was just like red jackses and taking the bundled output and like uncompiling it. And like, I was like, oh, this really is just a bunch of hacks on the output.

• 7:24Speaker 03

  Yeah, finding the routes, like, everything that NextJS like knows, like basically, like all this like metadata around like what is a route, what is a, like, how does it match, like that kind of thing?

• 7:34Wes Bos?

  Yeah.

• 7:34Speaker 03

  That's not all part of the adapter's API. Yeah.

• 7:37Wes Bos?

  And like, let's talk about like the different pieces to this, because I think one of the hard reasons, one of the reasons why it was historically hard to put NextJS on other platforms is because it kind of blurs the line between like, like this is a Node app, but also there's this, all of this infrastructure that that needs to come along with it. And like, like you said, that that special sauce of why it was so easy on Versale was because like you guys have had your own adapter platform and have have made it like line up with all the the different pieces, right? You got CDN and databases and caching and and all of that type of stuff. If if somebody's like just looking at this right now, like what are the different pieces of infrastructure that are needed for like

• 8:19Wes Bos?

  a NextJS app that uses every single feature under the sun?

• 8:23Speaker 01

  The thing is, something that like I kind of want to try to dispel a little bit is that like, a lot of the, what we're talking about, like the The sort of like complexity that comes with like some of the next just features, those are mostly sort of like additive compared to like the other frameworks. On its own, if you're just like, you know, if you're just looking for a framework that kind of just like, you know, service side renders. And or just like, you know, serves API routes and serves some like cached.

• 8:50Wes Bos?

  Yeah.

• 8:51Speaker 01

  That stuff just kind of works out of the box, right? There's, there's nothing, you don't need like crazy infra or anything. So you just need like a server that can return to your response. Where we go a bit further is when it comes to basically everything caching related. And then we've made kind of updates to our docs to kind of clarify this, but those things are mostly, I'd say, performance optimizations, right? Like partial pre-rendering, which is like one of the features that allows you to kind of serve like a static page and then kind of compose with, with like some dynamic contents.

• 9:22Wes Bos?

  I, I love those. I want those features. Those are great features.

• 9:25Scott Tolinski?

  Yeah, yeah.

• 9:26Speaker 01

  Yeah. And it works with Next Art, right? Like you're, you're, you're going to hit your server, it's going to return like the, without rendering, it's just going to return you the, the static. HTML and then it's going to do like the render, right?

• 9:36Wes Bos?

  Yeah.

• 9:37Speaker 01

  And when it comes to first well, the way we, we kind of optimize for this is that this now, this, this, this CDN, this, sorry, this, this HTML shell can be served from the CDN rather, right? Like closer to the user and then we'll like invoke like server in the background. This is like purely just taking the, the primitives that we've taken, that, that we've put in the framework and then just like optimizing them. But so that, I think that answered your question a little bit, right? Like, um, I think to get like the first cell ish experience, uh, what I would want, what I would recommend. Um, anyone who's like adopting the, or adapters to, to get those features is you want your server close to your database, right? Um, if you're doing like any research, like is the thing that makes sense in general.

• 10:17Speaker 01

  And then you want your static contents always close, as close to the user as possible. And you need something that kind of handles the connection between the two. Um, and it could be like, on clarify, it could be like a, you know, like a worker, right? Um, and that worker would just like. Execute at the edge, return to you the CDN content, the static shell, and then like invoke another worker that is closer to the origin, basically.

• 10:48Speaker 03

  And even for this case, or like if you're talking about PPR, for example, like the this static shell, like even if you serve that from a server that does dynamic rendering, so like if you serve it from NextStart, like it's still a win because the like you still have this like immediate response. The only difference is that it's not, this response is not immediately coming from like a CDN per se, but it's instead like served from your like server that you have hosted.

• 11:18Speaker 03

  And that's the same way if you go to any other platform, it works in the same way. But what you can do like additively to that is like you can make it so that your CDN supports this like new primitive, like PPR for example, and then it can serve that shell from the from the CDN itself while stitching the dynamic render as well.

• 11:38Speaker 01

  There is a, like maybe, yeah, the PPR part is like an optimization. I will say probably like something that I would consider kind of important and that we still want to make improvements on is the cache synchronization story, right? Let's say you're having like five servers are using Next and like you might, you know, you might like start it with like NextStart on all your like instances. If you're like Next just caching, like the pretty powerful thing about it is that like we allow you to kind of invalidate it whenever you want and we do it in the background. And of course, whenever you you call this or like revalidation methods, that

• 12:21Speaker 01

  one thing that is important for your provider or yourself is that like a revalidation is like just to share across all nodes. And so that's, that's one of the things that we want to, we're, we're making better with the Adapters API, but we still, you know, still got some, some work to do, I'd say.

• 12:38Wes Bos?

  Okay. And like when, when someone's like having a cache.

• 12:43Wes Bos?

  Like when like a page or a component is cached. Where is that typically stored? Is that thrown into like a key value to file? Or does it? Does it matter?

• 12:55Speaker 01

  So we have multiple layers of caching. As you, as you might see from the memes about our docs, right? We, I don't know if you have, how familiar you are with like the, or cache components.

• 13:08Wes Bos?

  Oh, yeah. Use cache. I've many times said like, I, I want that in every single thing. Like, one of the reasons I'm such a huge React server component fan is the ability to like fetch and cache and just do everything in the component rather than like a, everybody else is like route layer. Except for Svelte. Svelte is along with asynchronous now.

• 13:30Speaker 01

  Yeah. And see the idea behind use cache and the idea and why we chose like, you know, a very, almost like generic kind of name for cache components. Is that we kind of want you to think about caching at every possible layers. So it starts like purely through the client. So if you use use cache, you can actually add a property that will just say, you know, cache it on the, on the browsers. So that like across my session, the, the page is like stored here and I, and I can configure like how long it should, it should be kept around. Then it can also happen at like runtime, when you server side render your page. Now this cache lives also, can also live while on your, on your server across your request.

• 14:14Speaker 01

  And you can add like a time that you want to keep it around. We can also have this at build time and for static pages where now this, this cache page should live in your CDN too. And so, so there, there are multiple layers to it, but, but, but we think basically it allows you to build like, you know, the sort of most composable kind of app, some, some, some pages, for example, yeah, it's fine if they live on the CDN like, and they're, they're never really sort of like re validate. And if you do so, you're doing it like, you know, kind of random, not randomly, but like occasionally, like a CMS or something. But those things don't matter, right? If you're like a page like. In an app like ChatGPT where you would rather wanna cache on the on the client instead.

• 14:58Speaker 01

  Um. One thing I'm really excited about, for example, is that we could, we wanna extend the the use cache or like layers so that we can have also like an offline kinda kinda layer. So right now, like, we can cache it on clients across sessions, but the idea is like, what if we just like also kept it across reloads seamlessly, uh, like, like, and then you would just be able to, um, reload your page while offline, um, and then still have like the data from or something out of the box, right, without having to do like potentially like a, um, a synchronization, um, layer.

• 15:33Wes Bos?

  Oh, that'd be cool. I like that a lot.

• 15:36Speaker 03

  So a lot of the APIs that we're adding are like, like, edited, like, especially with cache components like there's, uh, like many things that we haven't like really talked about, like this offline thing that Jimmy's talking about. Uh, they're like, right now they're building the foundation of, uh, of what this like caching layer will look like. The other thing is like, well, Jimmy said that, um, like, we want you to think about caching in every layer. Uh, the default is actually to, uh, be like as dynamic as possible. So if you use like dynamic APIs, uh, it will basically like it feel like, uh, like how you're you were using like a server props before, things like that. If you use, uh, like date or things like that, things become dynamic still.

• 16:17Speaker 03

  And then you, like, basically the the biggest change from like Nexus thirteen and like the the first like iteration of all this caching APIs that we want you to just like build the app first and then you can start optimizing. Whereas previously, you were already in this like optimized state by default and that was like kind of confusing. So we really want you to like see these APIs like additive, right? Like you, we want to add to use cache instead of like it's cached by default or like you have to reason about that that kind of thing. Uh, and then like when you want to add to use cache, like Jimmy said, you can do it everywhere, uh, in in the sense that like you can add, do it at the page level, you can do it at, uh, the individual function level or at like components even.

• 16:57Speaker 01

  And that's something that was previously like never been possible. Like even in the first version, like we, we like it was either it's fully static or it's fully dynamic. And like it started with the, the setting thing. Uh, and then like everything is cached, but now it's, uh, you have to opt into it and, uh, and it feels nicer in, in that way as well. Like when you're building the app, yeah.

• 17:21Wes Bos?

  And like, say somebody builds out an XJS app, you know, a bunch of pages, a bunch of components, does a whole bunch of stuff. And they say, okay, like I'm, I feel like the app is in a really good spot. Now I either want to move to use, using less resources or, or make the app a little bit faster. Now I'm going to start looking into cache. Like what, what would be your first couple of steps of attacking like the lowest hanging fruit?

• 17:46Speaker 01

  The nice thing about our model is that we kind of, we still try to nurture toward like making the choice as you develop. I think, I think other different frameworks kind of have like this other sort of like less, maybe less opinionated way of developing. You can like sort of like, you can start with like just client side fetching. And, uh, and at some point, yeah, you do need to kind of invest into like, uh, optimizing your app, pulling it potentially into the server or the loader or something. And while we don't cache for you by default anymore, a big part of like the programming model now on cache components is that like you, you'll write your, your code as like intended, but then like next we'll kind of mention like with like a little like nice, um, warning window like, hey,

• 18:29Speaker 01

  either you need to add like a suspense boundary here so that you keep this thing dynamic, or you just cache it now, uh, with like use cache. And then you, you know, it's like a simple drop in directive and you sort of like are set up from the get go already, right? Cause then it allows us to progressively do it. And so, yeah, I think, I think this is kind of like the, the, the nice part of, um, with, that's, that's why I really like next by itself. Right now today, right? If you have like a slow next app, um, the first thing I suggest, right? It's like, you're probably not on cache components just because like it's somewhat, somewhat very recent, like we haven't like put. You know, as much effort as we uh as we could have into the the documentation and experience yet, right?

• 19:13Wes Bos?

  Um.

• 19:13Scott Tolinski?

  Yeah.

• 19:13Speaker 01

  But uh that's the first thing, right? That's that's what ups you into this. Hey, I'm gonna warn you about this little thing. And uh really take it, take it from there. Read the the use case docs, right? Like, no one, no one likes learning, having to learn about like a new directive here and there. And you know, for most people, performance is also somewhat somewhat fine. Uh uh but uh I think, you know, the our idea is just weird. Whenever you're ready, we'll sort of like, we'll be there. Um.

• 19:41Wes Bos?

  Mm hmm.

• 19:41Speaker 01

  Let's say.

• 19:42Wes Bos?

  Waiting for us? That's that's great, Jimmy. That's great. I like that.

• 19:48Scott Tolinski?

  Yeah, I'm I'm curious uh about with with your whole adapter pattern. Um is there like a minimum subset of features that adapters need to support before considering? Like before considered to be like a blessed adapter by the next team?

• 20:03Speaker 01

  Yeah, it's a great question. Not really. So so the the idea is that um I don't like, I don't wanna get keep necessarily on like whatever you like, you know, someone's platform is supporting or not. Sometimes like the thing with like PPR is that like, it does require like a little bit of wiring if you want to do this at scale. And there's no right and wrong here. It's more like just like uh the users kind of should make their own choice. But one thing we do require um as part of like the adapters. Uh working group, if they wanna be blessed, is that they should just run our test suite. So we've made some work to make this available for um everyone. In theory, you just like need, you know,

• 20:41Speaker 01

  you just plug in your API keys and like just like the the pipeline on like how to just deploy it with like uh a few scripts here and there. And then you can just use our test suite in the same way Vannex has used it. And um and just basically assess how good your platform is at supporting next. Uh and even then, it doesn't really cover like, um it it's not very like opinionated about like whether or not you're running PPR from a CDN or not. Uh we don't really sort of check for performance expectations here rather than just like. You load the page and it's just working as intended. It's not, but maybe it could be taking 20 seconds. I don't, I don't really care about this, as long as the test pass.

• 21:21Speaker 03

  And the other thing is like, we're also not specifically gatekeeping on a amount of test passing. So what we did is we, we, we give you the test suite. The only thing we ask, so there's two sets of adapters. I like, there's adapters that anyone could build. And there's the, the ones that are like part of the docs that we explicitly mentioned. And then we also published the results from the test suite for. Yeah. So this doesn't mean that you have to say like build a, an adapter for, for like any platform that doesn't pass like every single test. But it will split out by, like in the test suite, like we, we keep track of like which feature, like which tests relates to which feature.

• 22:03Speaker 03

  And then we publish like this adapter supports all features like for PPR, for example, or like it doesn't have like some other feature. And then it will, like, then you can choose for yourself, like if, if you want to use the adapter or not.

• 22:20Wes Bos?

  Okay.

• 22:20Speaker 03

  So that's like basically like how we set it up. Like everyone in the, in the working group is already working towards like they either published a adapter already, or they are working on an adapter. Cause they want to roll it out gradually as well. And, and that set of adapters will be part of the, this, this set that we're going to call out in, in the docs. And if there's like other platforms that want to do the same, like we have like a clear set of like, this is what you have to do to set up a test suite. And how you can like get your adapter part of this list as well.

• 22:57Wes Bos?

  And this is not just for like different hosting providers as well. It's, it's also for, for different runtimes as well, right? Like there's a, already a Bun adapter, which will then allow you to kick out, like obviously work with Buns in. I think it uses Bun's internal server, has a Bun SQLite database for caching, things like that. So this is not just like. Different, like only to run on Netlify or whatever, but it's also like if you're, if you literally have like a Bun server sitting in your closet, you can use this.

• 23:28Speaker 03

  Yeah, yeah. And so that's one case. The one that is really interesting to me as well is the Kubernetes one that Google is running on. Basically, that would allow you to scale the Nexus server as is using Kubernetes. We built together with Jared from Bun, this like Bun adapter, also to prove out like that you can use the adapter's API like for something different and just like a specific platform per se.

• 23:56Wes Bos?

  Yeah.

• 23:57Speaker 03

  Yeah, I'm curious to see what like people built using this because like you can do like more, like I saw someone tried to use the adapter's API like right after it came out to like create like single, like single file executables that boot up the server and things like that.

• 24:13Speaker 01

  Part of like why I was pretty excited about like pushing for the adapter's API is that we kind of want to give you almost like full control over like everything Nexus can do and then what it allows you to do like. So that at first, you know, that that is targeted toward like platforms. But one of the things, for example, that we are planning on working on next with the Cloudflare folks is yeah, going deeper into the runtime story. Right now, it works currently mostly for build. But when you're working on like something like, well, with worker D, for example, there's a bunch of APIs that are not necessarily available from like based on Beta Node, right? And so we wanna, I think VEIT has done something similar with

• 24:56Speaker 01

  their environment API. We kind of want to do same thing, right? Allow you to have in dev as close of an experience as possible as what you're gonna get when you deploy it.

• 25:05Wes Bos?

  So that's planned because that was my next question of like, like one of the hugest pain in the butt with Cloudflare is that like, if you are running Node locally and then you deploy the thing to Cloudflare, there's always this pain in the ass little things that come up. And and the solution to that is like debugging it sucks because you gotta like sit there, commit, deploy, wait for the thing to build, you know? And they've solved a lot of that by Allowing you to run like worker D locally, um, which means you can hit those issues right away before you deploy the thing. But you're saying so that eventually will come to this where you can use it different runtimes in dev as well.

• 25:41Speaker 01

  Yeah, that's the idea, right? Because as a, as a user, I also, I also hate this, right? Like, um, like what we're striving really hard within actually experiences that like, um, dev start and when you push it on Bursell is, you know, behaves exactly the, the, the same, like debugging capacities are same and like, like, I just, I just kind of want to push that forward, um, and, and like, is what we're selling, you know, with, with Naxx by itself is not like, I'm not, I'm not married to the idea of like node, I'm not married to like, uh, worker D or like Bun as a runtime itself. Like what we're selling is APIs, just, just nicely.

• 26:19Wes Bos?

  Yeah.

• 26:19Speaker 01

  Than APIs and like, if, like, hopefully we don't like, like, we don't, like, a lot of the stuff we do, uh, obviously is very targeted towards node. Um, uh, just because that's the main default, but like if it came a point where like Bun becomes like, you know, the, the natural like, uh, the, the natural like platform to, to which to build on now JavaScript apps, then I would want to, I would want next to support that.

• 26:43Wes Bos?

  Yeah.

• 26:43Speaker 01

  As well, right?

• 26:45Wes Bos?

  Does that mean you have to have all of turbopack running on these other runtimes as well?

• 26:50Speaker 01

  Hmm. I think not. Uh, depends on like, uh, there, there might be some, some limitations there, um, right? In, in terms of like, obviously, if you run like on a, on a crazy OS that just doesn't support like, uh, like our build of like turbopack, then, then, then we do, we do still kind of need, um, some things. Uh, but turbopack also turbopack is mostly written in, in Rust.

• 27:14Wes Bos?

  Oh, yeah. So it doesn't matter, right?

• 27:16Speaker 03

  Yeah. Yeah. So turbopack like itself is, uh, you, you can see that it's like a separate binary that we're running and we're compiling it to every, like mostly supported like OS basically, right? So if you're using like a convoluted OS, then like that, that might be a problem, but like for, uh, like, like every like majorly used operating system. So like we're only talking operating system, right? Like runtime, like, for example, like Bun, uh, like you can, you can use Bun for, for next dev, uh, today, because you replace it with no, uh, with node, um, and that knows how to. Run this, like it has the Node.js APIs to like interface with Napi. So we can just like run everything as it is. If that needed something slightly different or anything like that, we could still run it.

• 28:01Speaker 03

  That's not a, not an issue. But yeah, next, like next to itself, it's all mostly TypeScript, some JavaScript. And then the, the bundle is basically a hundred percent rest at this point.

• 28:14Speaker 01

  But yeah, to be clear, we do rely on like pretty sort of load-bearing APIs to like async local storage. For example, and those things were potentially either like they're like, you know, supported pretty well, or they might not be supported fully sometimes. And so in those cases, like that's where we need to do some work to either like try to abstract away some of our usage so that like then a platform could then plug in their equivalent or something.

• 28:43Wes Bos?

  Okay, I see.

• 28:44Speaker 01

  Yeah, that's, I think, you know, as we work with like Cloudflare on, on supporting it, supporting cache components better, I think we'll obviously run into sort of like that kind of issues. Yeah.

• 28:56Wes Bos?

  Oh, yeah. Yeah, there was one weird thing with Cloudflare, like their implementation of async local storage doesn't, I'm just looking it up, enter with you can't use or something weird where you can't like bootstrap something with an existing object, which is kind of a bummer. But like, that's also not really next. It is next problem, but also like that's, that's more of a Cloudflare problem, you know, if they don't support those APIs.

• 29:21Speaker 01

  Yeah. Yeah, the idea is that we make, you know, as much as possible as we can on our end. But in the end, like it's still up to the platform to, you know, choose to invest into making the work. They, they control the runtime, right? So they really can also do some work in advance here.

• 29:38Speaker 03

  It's similar across frameworks as well because like if other frameworks use a sync local storage, say you run into the same problem, right?

• 29:45Wes Bos?

  Um, one question everybody has, and I'm sure you're sick of hearing this right now. So feel free to punch me, but everybody's like, what is it? Noakes just run on Veet.

• 29:57Wes Bos?

  Do you have any response to that? Because like I know making Turbo pack was was a huge feat and I know it's edge cases all the way down. And it's a very frustrating. I'm sure people think you can just boop, boop, boop, add Veet to it. But like, what are your opinions on that or your responses to that?

• 30:14Speaker 03

  If you're not watching, I just set up straighter.

• 30:19Speaker 03

  Yeah, so we started building through back. I can't remember which year it's been some time. The reason we started building it is like for context, like we were using Webpack before, like most other frameworks at the time. And basically Webpack, it has some limitations. The main thing that the main limitation it has is that it's single threaded. So it runs in, it's mostly JavaScript, not JavaScript. It has a very extensive plugin API, but really the biggest like problem that we ran into as applications kept scaling. So like the, like, think about it this way, like if like Wes or Scott starts building a new application today,

• 30:59Speaker 03

  they're probably like pulling in like 10x more code than they were 10 years ago when we started next year. So over time, like basically you started hitting this, uh, this problem of like, there's so much code to compile. Now everything gets slower and slower. There were some takes on how to solve that problem, uh, which included, uh, and then like next itself, also made this, uh, like this problem ish 2x worse by having two compilers. So you're not running one Webpack, you're running two Webpacks, uh, like one Webpack for the browser, like your browser code and one Webpack for your server code. So we're like server set rendering and all of that.

• 31:43Speaker 03

  Like we had to do that because like otherwise you can't, you can't run browser code. That's like bundled for the browser in the server, like your like type of window would be replaced or things like that. You couldn't do as many optimizations, like all of that. So. You were basically like, what Next尚was doing was like, it was like trying to orchestrate multiple instances of Webpack and trying to make sure that they compile at the same time, they finish at the same time, they run in parallel as much as possible. But in practice, you can't really do that because like one might depend on the other. And then when you have server components, now you have this, like it's a scheduling problem, basically, like you have use client and use client could import a use server, like a server action.

• 32:27Speaker 03

  And this like, the first file that you find is a server component. So like that's server code, so that's running in the server compiler. But the moment it finishes compiling, it has found all the, like it collects all the use client and then it injects it into this like second Webpack instance and it's like, hey, you know what, now we're going to compile that. And then when that second instance runs and it finds all the use server, it now has to run the first compiler that we triggered again to then like compile all this new code that we found. And basically like that means that you're going from like server, client, server, client, and it can effectively recursively go through more than that, but we blocked you from doing that.

• 33:12Speaker 03

  In practice, you should be able to do that though. Like you should be able to import more client components that have more server actions and like, and so forth. And this might be like this, the other thing that we want is to have server components that you can like import and render from like using use server, for example, in the future. And like this would basically make that like a compilation problem, right? So like we had this kind of like slowness problem and it only got worse like as we added more like compilation work to it and like this orchestration, basically. So like that was the, like really quick, that was like the problem that we had. Besides like the applications are getting a lot larger and like that also being problem. So.

• 33:56Speaker 01

  You said really quick, but you gave a whole explanation of the server component architecture.

• 34:04Speaker 03

  Yeah, yeah. So, so that's like the problem or like where we came from, right? Uh, I just want to clear that up because like it might sound very simple to say like, oh yeah, just like drop the bundler and do something else. So at that point, like we were like, okay, let's have a look at like where things are at in the overall ecosystem, like what is everyone else doing? And what we find is like effectively every other framework was doing the same thing that we were doing, which is regardless of what vendor you were using, even if you were using more modern ones like, uh, like feet or roll up or like anything else. Uh, effectively they were all like, if you're building a, um, a, a framework that multiple layers, so like server and client or things like that.

• 34:45Speaker 03

  They were all doing this orchestration issue, like they were all compiling like, like you had two V instances instead of two web pack instances or things like that.

• 34:55Wes Bos?

  My personal Waku website, which is React Server Components, I think it has four V instances.

• 35:01Speaker 03

  Yeah, it works in the same, like, like everyone did the same thing. It's like, that makes sense, right? Like if you, uh, like if you're not building the vendor yourself, like you hit this thing where you're like, oh yeah, I need to run multiple of these. Cause like I have multiple output targets or things like that. Uh, when I explained this, like I was only talking about server and browser, but you could also think about like ad runtime or like all these other like output targets, right? Uh, button maybe or things like that. Uh, you would have to like, like basically it goes a problem where you're running like many instances. So, yeah, so we looked at it at the time, which, uh, is multiple years ago now. Before there was like any, like the, the only other, uh, I, I will give credit to Parcel.

• 35:43Speaker 03

  Parcel had this API where they could do server client, server client, server client like that. That was a thing that they already added. You have a web pack application, like your, your like existing Nexus application is like completely geared towards. Like you have all the webpack specific API. So this means like dirname works in a certain way. New URL works in a certain way.

• 36:04Wes Bos?

  Yeah.

• 36:04Speaker 03

  Like import meta works in a certain way, like all of these things.

• 36:07Wes Bos?

  All the resolvers of all the files work the same way.

• 36:10Speaker 03

  Yeah. You've probably hit this thing like in the past for like, like Feed, for example, like they introduced, we're going to use ES modules for everything. So now you're migrating like a, like a app that was built using webpack and you're migrating to Feed. Like you would have the same problem where you had to rewrite some of your code or things like that.

• 36:30Wes Bos?

  Yeah.

• 36:30Speaker 03

  And there were more reasons for this, but like, I feel like the, the problem that we had was like, there's multiple compilers, there's like combat with the, like the previous Nexus apps that we like, and we had millions at the time already, right? So this isn't like a small scale problem. Like we, like if we give you a lot of breaking changes, like now, like millions of people have to do work to actually get to the latest version or like to use this like improvements. There were like no solutions out there at the time. So effectively it was a question of like, do we take existing bundlers and try to cram this like new features into them to make it work in this way?

• 37:10Speaker 03

  And then like work with this, like other bundlers or things like that? Or do we start from, like take everything that we've learned from all these, like the other bundlers? Cause like the, like a lot of the, like say Feed is like built on, like a lot of this like knowledge of like mistakes that were made for webpack, for example, right?

• 37:32Wes Bos?

  Yeah.

• 37:33Speaker 03

  Or things like that. So can we take like all of these learnings from building all these different platforms? And then like a lot of people that, that came into Vercel, like people that came from Svelte and, and all of that. Like take all of this knowledge and then build something new that takes like learnings from, from everything that came before, similar to how most new open source projects are built. So that's like where we started and that's how we started building TurboPack. And then we had this, like, pretty quickly, we had like a fully functional bundler. You take inputs, you create outputs, it runs, transforms, like all of this. That was actually not the hard part, like building a, a, like bundler. Like, we, we know how to do this and

• 38:19Wes Bos?

  Yeah.

• 38:20Speaker 03

  We, we hired all the right people to work on it and we had that pretty quickly. So a, like, create a React app type app was, like, we, we got to that point pretty quickly. The problem was that, and why it took, like, quite some time to, to get, like, fully to, like, 100% of Nexus test passing is that Nexus has a lot of tests, like, like, I think, like, 11,000 to 13,000 tests, if you take, like, both dev and build.

• 38:48Wes Bos?

  Cloudflare knows about those tests, yeah.

• 38:52Speaker 03

  So, like, this test suite is super large, but it tests all edge cases. That includes things that bundlers would usually be testing. So it includes HMR, it includes fast refresh, it includes, like, all of these edge cases, every bundler feature. Because when, like, when I was building Nexus, like, very early on, we were just like, every single edge case that we ran into, like, instead of just, like, upstreaming every, like, test that we have for that, we also added a test, just in general, to make sure that it keeps working in Nexus. Because, like, we were doing this orchestration thing, like I explained.

• 39:28Wes Bos?

  Yeah.

• 39:29Speaker 03

  And we, you would hit issues with the orchestration itself, which means that it's not a bundler issue, it's actually a Nexus issue. So we already had this, like, very extensive test suite of, like, how a bundler should behave. We basically had to go through and, like, fix every single edge case so that it behaves in the same way or super close to what it was doing before. Including a lot of the behaviors that Webpack has. So an example here is, there's a comment called "webpack ignore true", that you can add into an import, I'm not sure if you've ever seen it. That makes it, like, ignore the import when, when bundling. A lot of NPM packages have that, for example.

• 40:09Speaker 03

  I had never seen it before myself, but as we started building this, like, obviously ran into it, because, like, Turpact would start bundling it, for example. I found out, like, other frameworks also start, or, like, other bundlers also start bundling it. But then in Webpack, it would, like, just ignore it and, like, there would be no confiderer whatsoever. So we have like in Tropac, we have support for like a lot of these like Webpack specific APIs as well. And we make sure that like, for the most part, your application, like you don't have to rewrite like a lot of things to get to this newer version. So that covers this like millions of people case. At the same time, what we've seen like while we were building this, like, like other, like vendors, they kept innovating as well.

• 40:51Speaker 03

  There was a RSPAC that tries to like implement the, the whole like Webpack API interface. Yeah. While giving you this like parallelization and like better, like, like slightly better bundling and like parallelization. And at the same time, also, you saw the V10 build roll down, which is really cool as well, which has like a lot of the, like, it takes a lot of the same learnings that we had for, for Tropac. So like in practice, like the, the way I feel about it today is like that all of these vendors have started to sort of like converge onto a similar type of feature set. And the way they work is actually very

• 41:32Speaker 03

  similar. The only difference is like trade offs that you make around, like caching, like incremental compilation, like things like that. So for, something I didn't talk about for Tropac specifically is like, we went all in on this like incremental compilation architecture. So similar to like Solsa and Rust or things like that, which is like, you can annotate functions that are cached automatically and paralyzed automatically. And this was especially important for us because like we were also seeing, besides this, like the new apps are 10x larger, the existing apps became 10x larger as well. And we want this incremental compilation, like basically you want everything to be incremental compilation. So this means if you're in a build, like the first build,

• 42:16Speaker 03

  like the very first time, might be slow or slower than, than like any other vendor, for example. But after that, we have every single thing that it did cached. And if you make another build, it's a lot faster. So it's, for example, Uh, like if you have an application that's like super large, like hundred thousand plus modules or things like that, and it it might take like a minute to build or something like that. The incremental uh compilation would be a few seconds to get to like this uh the the like the next build after that, basically. And it would be like every build after that is just faster than the very first one. And you like rarely hit the, it's like I'm starting from scratch case.

• 43:00Wes Bos?

  Yeah.

• 43:00Speaker 03

  And similarly, we want that to be the same for development, right? So like if you boot development, you uh make your changes, you do like hundreds of HMRs, you quit the server and then the next day you boot it up again, it should be as fast as uh it was uh like getting a HMR, for example, like a fast refresh.

• 43:18Wes Bos?

  That always drives me nuts when people post like, oh, it took V boot it up in like three milliseconds and the first load of my next app took like 20 seconds or something like like. That always drives me nuts when people don't understand how how that works. Um, like, like my own personal Wiku website takes like 30 seconds before I can actually they even console logged the URL and then after that it's fine, you know? But uh, uh, that always drives me nuts. I'm sure it drives you nuts as well when when people post stuff like that.

• 43:50Speaker 03

  If you compare frameworks, if you're looking at the you boot up and you see a uh URL. So for example, uh, you you boot up uh like any other uh framework and it says uh like local host 3000, right? And then it says like ready in like some time, for example, like uh like 12 milliseconds or 50 milliseconds or something like that. Uh, in Nexus, it would say 500 or like one second or something like that. What we found is uh, or like what I found like looking into this, because I was like confused about uh like this, this like no other work happened. It's just like uh, for us, it was like a timing issue, like we would load the Nexus config, for example, uh, which which might be including like all your uh like like external plugins,

• 44:34Speaker 03

  like Sentry or or things like that. It would be requiring all of those before it actually said like, hey, let's like the server is ready, uh, it took this much milliseconds. Uh, so recently we uh, we optimized that by first logging out all of this, like the the server is ready type uh uh like uh logging and then uh like requiring the config and things like that in in parallel, basically. And we're like some like interesting optimizations of. Yeah, how does like perceived performance is there as well? Yeah.

• 45:07Scott Tolinski?

  Have you considered just faking the numbers?

• 45:10Speaker 03

  Never, no.

• 45:12Wes Bos?

  Volvo.js, I think that was. Yeah.

• 45:17Wes Bos?

  That's great. By the way, I just looked it up and that Webpack magic comments was me. I opened the issue on that. I was running into a weird issue where I had like a dynamic import and in Webpack, when you have dynamic imports, it gets everything, right? And I had like a video in the same folder and it was like loading the entire video and then crashing. That was a weird one. I'm sure you run into all people doing stupid stuff.

• 45:50Speaker 03

  Yeah, and on top of that, there was just like the test suite had a lot of these cases already. It's like, it might be that like Wes from like eight years ago had already reported this issue and like we had a test for it. Right? Like there was a lot of cases like that as well, things that we would have never caught without this test suite.

• 46:05Wes Bos?

  People using it in weird ways.

• 46:06Speaker 01

  There is a bit of pros and cons of like, you know, sort of like maintaining a framework for so long is that like the battle tested sort of features that we have there, in a way, they're like the things that are almost like slowing us down. Because you could start like a new framework today, right? And actually you go to kind of eat and it would look like it works. And then you kind of don't have like the burden of like, sorry, maintaining too much.

• 46:32Speaker 01

  But eventually at scale, like what we what we found over the years is just that there are sort of like many cases that kind of tend to pile up there. And I feel like the big T O D R of like why we have gone for two or back at first is just like, like what's what's really important for our team is that we just keep, you know, shipping as fast as possible. And so, you know, it could be like a symptom, like it could be, I don't know if you heard about the term of like, like sort of like not invented here. Kind of problem where if you go at Google or Meta, you know, they have like every version of like what you use externally, but like built, purpose made for their own system, because it's just actually, if you have the resources,

• 47:17Speaker 01

  it is just always the fastest solution. And kind of like what we were saying earlier, right? It's like next is on its own, somewhat somewhat simple, right? Take our test suite and try to recreate it, some, some parts of it. And, and, and you could get, you know, somewhat, somewhat, somewhat pretty, pretty far uh on, on, on your own, right? And like Tim said, we spent like just an insane amount of time just trying to make sure it wasn't like a breaking change. Uh, now maybe the juicy part, I, I can share here. Yeah. There's um.

• 47:49Speaker 01

  Like, you know, uh, like we're not married to node or Bun or anything like what matters more is the experience that we kind of provide to our users. In the same way, like, for example, we used to ship with like a lint command uh that used to kind of just like bundle yesterday. Cause that was like the, you know, the, the, the industry standard at the time. Yeah. Um, we've kind of reconsidered and like we, now we're just not doing anything, but we might, you know, consider a word where maybe we just run it around like biome or something like this. Yeah. And um, in the same vein, transparently, like every year we ask ourselves, you know, like uh, do we, do we wanna sort of like um, try exploring V?

• 48:30Speaker 01

  Do we wanna sort of continue on triple pack? Now we're working with the RS pack folks, like what's the, what's the best end result, right? For our users and um, the big blocker was really just the amount of work that it would take to kind of make this like a non-breaking change. There was also just the fact that like, there's, there's nothing, I think that like pushes a, a, a bundler as much as like next year's today. Because we, we talked about like, you know, server components, server actions, cache components. Um, like you said, there's like, why could you do some stuff today? But like, I don't think there's quite something uh that is quite, that has to support quite like, uh, you know, as, as many sort of like larger um websites there. Yeah, yeah.

• 49:14Speaker 01

  And so if we wanted to find out, I think we kind of need to spend like a lot of time into exploring this ourselves. And um, and I think the very latest here is just like, maybe in the age of AI, uh, maybe this is like very doable, right? Uh, maybe we can like finally have like an answer to the. Would like next work better on VIT.

• 49:38Speaker 01

  I think it's definitely still like an open question.

• 49:42Wes Bos?

  Oh, cool. That's good. That's good. And is TurboPak part of like the next repo now? Like, are other projects using TurboPak? Or is this just just a next thing now?

• 49:55Speaker 03

  Right now, it's part of the Nexus repository. It is a fully standalone utility. It can run. The only thing is that we don't have added, like, we haven't added a public API for this yet. The reason for that is that we wanted to really prove out that like this bundler has a right to exist, that it can like run on these Nexus applications and that doesn't have like any like bugs on bundling, like MPM packages and things like that. We're past that point at this point. And we do have like a CLI for it now. The only thing is like figuring out like how to, like what the public API looks like. And then especially like, one of the things that's that's missing is like we can run like Webpack loaders, for example, and things like that.

• 50:40Speaker 03

  Like, we don't have a plugin API specifically for TurboPak right now. And that's like what we're currently exploring as well, like what that will look like. Then there shouldn't be a reason that you can't run TurboPak. But right now, the, if you wanted to use it, for example, like there is like another bundler called U2, like U T O O. So U2 is like another like framework slash bundler that's built on top of the TurboPak core. And they, they're using it very successfully. They're conserving back to TurboPak as well, because they're using it in this way. And they're building like pretty like large applications on this.

• 51:24Speaker 03

  And it's, yeah, so like, there's no reason that you shouldn't like that you wouldn't be able to use this as a standalone bundler like in the same way that you would use is build or feed or anything like that. Really, the like, it's on us to add like a public API for this. And really, the only reason that we haven't yet is like, we want to really intentional about like, we want to support that thing if we put it out and and give the right level of support there.

• 51:51Wes Bos?

  Cool. You should make the API just the VD API.

• 51:56Wes Bos?

  Do you want to put your rule on them?

• 51:58Speaker 03

  We've been talking about that as well, because like, feed has a pretty decent API. The only, like, the only thing that we've been like, thinking about there is like, there are some like, fertilization concern as well regarding that. But it should be doable, like, it's not like the individual pieces are very similar. There's also the like, unplug in, like, and just API. That might be good as well, because there, there's a lot of like, plugins that are already written using, using unplug in, which is like, it basically bridges, you can basically think it's unplugging like, open next for like, like, Webpack loaders and plugins, or like, like, similar API.

• 52:45Speaker 03

  Because it bridges like this, like, every adapter to like, one single unified API.

• 52:50Wes Bos?

  Yeah, that would, that'd be interesting. Do you think we'll ever see that, like, you know, like, like, web request and whatever has been fairly standardized across everything? Do you think we'll ever see that for like, bundler tools?

• 53:01Speaker 03

  It kind of depends, because like, the, the bundlers themselves are quite different, but as I just told you, like, they're a lot more aligned at this point in, in the way that they work. I think for like, transforms, for example, like, transforms are a really like, basic, like, source input, some metadata, and then like, return and output. Like, and unplug in like, gives you like, a standardized API for that. Like, having like, one standardized API across like, all bundlers would be possible there. The only question is like, getting it to like, everyone to agree on like, this is the one thing that you should do.

• 53:37Wes Bos?

  That's the hard part, standards.

• 53:40Speaker 01

  Ever heard about web confidence?

• 53:42Wes Bos?

  Yeah, yeah, exactly. Good point.

• 53:46Speaker 03

  So it's really, yeah, it's that. And then plugins is slightly different because like the the way that the vendors work under the hood is like very different. Like, like throwback is nothing like web pack under the hood. Like it's, it works completely different. There's different phases. There's like the way that it works is just completely different. So like for plugins, like for example, you could write a plugin in web pack today that like like reorders chunks or something like that. Like it gets like access to all your modules and you can put the modules in different chunks or create like extra chunks or things like that. Like having a like in in terms of like we want to have like a more intentional API for this. Because otherwise, like, it's very easy to introduce, like, very large slowdowns or like,

• 54:30Speaker 03

  like, single point of failure bottlenecks, basically, where our things get a lot slower. And then, like, naturally, because, like, having a plugin API, it's, it allows everyone to, like, add these plugins, like, it would very quickly become like, everything gets a lot slower for every app or things like that. So we want to be very intentional about, like, what are the APIs? How are they surfaced? Like, similar to, like, we didn't talk about this, but adapters has a specific log line in the the build that will show you how long the adapter took, instead of like, that time being attributed to to Nexus internals or things like that.

• 55:04Wes Bos?

  You got me diving into this U2. It's from Alipay, by the way.

• 55:11Speaker 03

  Thank you. Yeah, I forgot which company built it. Yeah.

• 55:14Wes Bos?

  That's really interesting. That's the whole Chinese JavaScript is like a whole different world, you know? It's crazy. They have some pretty cool tools.

• 55:25Speaker 01

  This is kind of why we had started working with RSPAC last year to, like, and it was like this, we had the same realization, right? They're, they're just kind of introduced us to how, like, how BIDEN is going to compile their own apps internally and

• 55:44Speaker 01

  In some ways, they have the, they might even have like the largest set of like Nexus apps that like the world will never see. I don't know how many engineers that they have over there. They kind of showed us like the other sort of frameworks and it turns out there was like another framework that was also like very much like very similar to Nexus internally. And those companies are so big that they have like, they can have like four web infrastructure teams. It's always really fascinating to see. I wish, I wish we, we shared more there.

• 56:19Wes Bos?

  Yeah, it's, one of the best talks I've, I've had, or I watched was Zack Jackson. He's one of the devs on RSPAC and he works for ByteDance. We had him on, on the podcast as well. And like, man, that was fascinating to just to get a peek into how some of these big companies work and their infrastructure. And I'm sure you guys hear from it as well as like, if you can save them like 1%, that's sometimes just like millions of dollars a year in productivity and in compute and server time, all that stuff.

• 56:51Speaker 03

  For sure. There's also something that we didn't, didn't touch on is like this, this whole strategy of like building TurboPack and giving it out to, to everyone using Nexus as the default and like very compatible has actually paid off. Cause like on Nexus 16, there's like 92% of like development sessions are actually using TurboPack.

• 57:15Wes Bos?

  Awesome.

• 57:16Speaker 03

  It's like the, the rest is, is like WebPAC customization basically. Like people that have like customized their WebPAC config and they, they might still be able to use it today. Cause like if you're only using WebPAC loaders, you can already add them to TurboPack and they will just run for, I will not say like every loader runs, but like, like most of this like simple input output transforms, they, they, they work for sure. Yeah.

• 57:38Wes Bos?

  Beautiful.

• 57:40Wes Bos?

  Cool. Anything else we didn't cover before we, I know we're running up on an hour here, but I wanted to make sure if we covered everything you wanted to touch on?

• 57:47Speaker 01

  Yeah, no, I think we're good.

• 57:49Scott Tolinski?

  So now is the part of the show where we get into sick picks. Tim, I know you've been on the show before, so you know what a sick pick is. Jimmy, it's really just anything you're enjoying in life right now. Could be as like a podcast or a YouTube channel or any type of product, a phone charger, Hulu, whatever you want. Yeah.

• 58:12Speaker 01

  I should have asked for sponsors before. I, I really like, I don't know if you guys are like much into like coffee beans or not. I feel like a lot of like engineers are. Overall, but there's this, this shop that's, I think it's based in California. It's called like Adrangia. Their coffee beans are amazing. And if you like, you know, sort of like really, really light, almost like experimental kind of coffee.

• 58:39Wes Bos?

  Yeah.

• 58:40Speaker 01

  Very pretty and recommended.

• 58:43Wes Bos?

  It's like the hydrangea coffee roasters. They're like the flower.

• 58:49Speaker 01

  Yeah.

• 58:49Scott Tolinski?

  Yes.

• 58:50Wes Bos?

  This looks great.

• 58:51Speaker 01

  Beautiful back there.

• 58:52Scott Tolinski?

  Tim, what do you got for us?

• 58:54Speaker 03

  I still remember this section from last time. Last time I called out Apple TV because of sci-fi mostly.

• 59:01Wes Bos?

  Oh, yeah.

• 59:02Speaker 03

  I will, I will call it out again. If you're into sci-fi, Apple TV is such, so good. But that's not the one I want to call out. So I'll do two. So the second one is acquired podcast.

• 59:16Speaker 03

  I think y'all at Century are also sponsoring it because I hear the segment every time. It's this podcast. If you haven't heard about it, it's pretty popular. So you might've heard about it if you're into podcasts, but they do like four hour, five hour to like even longer podcasts. They talk through the history of companies and how they started, where they're at now. Like the whole thing that if you're into any of the history of like Microsoft or Google or like any other company, it's definitely a nice listen. And I usually like put it on when during chores or whatever, and then yeah, time just flies by.

• 1:00:03Speaker 03

  The one that I found super interesting is the interview with Steve Ballmer. Uh, cause like Steve Ballmer has such a like crazy and like I've never like listened to anyone that has that much energy like for like two or two, three hours straight, just like talking about everything. Um.

• 1:00:22Scott Tolinski?

  Yeah, acquired is really good.

• 1:00:23Wes Bos?

  I'm gonna watch this. This looks awesome.

• 1:00:25Scott Tolinski?

  I really liked the Hermes episode and the uh, what was another one? The Costco episode and the Porsche one was really good, Wes, if you haven't listened to that, because Doug Demiro is a guest on it. So.

• 1:00:36Wes Bos?

  Oh, cool. No, I'm definitely gonna check that out. Sick.

• 1:00:39Scott Tolinski?

  Yeah, really good.

• 1:00:40Wes Bos?

  Awesome. Um, Seamus, plugs? Anything you'd like to plug to the audience before we headways?

• 1:00:45Speaker 01

  I kind of would like, uh, for the audience to kind of read the blog post about like that we kind of publish about the adapters. Um, because I feel like a lot of people kind of read those kinds of like, uh, blog posts. Uh, and we put a lot of effort into it, but also I think it's really interesting about like, kind of how we, how we came together, right? Like, because it does sort of like, you know, establish a little timeline about how we work and like, more importantly, I think like kind of the game, the engagements that we're kind of, you know, having with the group, like what are the exact roles that we want to have like around the adapters and like just, just, you know, sort of like how we do kind of care. Uh, like, like actually care about like making Nexus work well everywhere. And, um, yeah, like I think, I think it's a nice blog post.

• 1:01:30Wes Bos?

  Definitely. We'll link it up in the show notes.

• 1:01:33Speaker 03

  Yeah, awesome. Uh, for me, it's an actual 16.2, uh, jokingly called Snow Leopard by a lot of people. Uh, uh, so it's this, uh, new release that we did, uh, two weeks ago. Uh, it includes adapters, uh, but, uh, it includes so much other things like it includes like up to 60% faster rendering, uh, like, uh, this is faster dev starter that we talked about. The server actions are now logged when you call them in development, uh, to make it easier to see what's happening there. Like we, we added so many things into this that we had to write three blog posts to cover it. Uh, so.

• 1:02:14Wes Bos?

  Hydration diff indicator.

• 1:02:17Speaker 03

  Yes, so if you like, we already had hydration diff, but now it includes the text of like what is server and client. But it was good to call it out again because like apparently not everyone had seen it before. It's basically if you have a hydration error, it will show you exactly what was the cause of the hydration error. Or like at least like the place where it happens in your code.

• 1:02:37Wes Bos?

  Yeah.

• 1:02:38Speaker 03

  And then what else? Oh, yeah. So we're doing a lot of research into what do frameworks look like with AI? As it's probably on your mind as well, like you're using like AI agents and like things keep improving quite rapidly. And like, like we built this like first version that was like an Nexus MCP. And now we're also looking at this like agent browser. If you haven't seen that yet, like look up agent browser. It's really interesting as well. And basically like we wrote a separate blog that was called Nexus 16.2 AI Improvement. And that talks about like a bunch of the learnings that we had from like building like frameworks for like AI agents next to humans building on Nexus.

• 1:03:21Speaker 03

  And it includes like one of the learnings is that like if you add an agent to MD that has like a like a small snippet that knows where to look for the docs, that it will suddenly become like significantly better at figuring out like where it had to await your search brands or how to like write an Nexus structure or like some code that it was previously adding use client to, wouldn't add use client to anymore. And we've been doing a lot of research into that, which is super interesting. We should probably talk about it like another time.

• 1:03:53Wes Bos?

  Yeah.

• 1:03:54Speaker 03

  But that's, yeah, that was my shameless blog. Yeah.

• 1:03:57Wes Bos?

  Sick. Awesome. Well, thank you guys both for coming on. Thank you for all your work on Next and I'm pretty excited about this. Appreciate all your time.

• 1:04:05Speaker 01

  Thank you for having us.

• 1:04:06Scott Tolinski?

  Yeah, thank you so much.