Rethinking Bundling Strategies with Tobias Koppers
===

[00:00:00] Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free at LogRocket. com today. My name is Paul, and joined with us we have Tobias Koppers. He is the creator of Webpack and TurboPack.

And he's here to talk to us about why we're going to be rethinking our bundling strategies or why Tobias, you have been ruminating on rethinking bundling strategies. What a privilege it is to have you on. I'm so excited to get into it. And as a user of Webpack myself, as I'm sure a lot of people are very excited to pick your brain about what's going on in the latest and greatest.

Welcome to the show.

Yeah. Thanks for having me. Nice to meet you.

Yeah, it's great to meet you too. So Webpack's been one of those things that I've used. I'm sure listeners, you have all used it throughout your whole development career and to be honest like Tobias You won't see your [00:01:00] name on a billboard necessarily anywhere. So it's or see YouTube videos by the hundred So it's really great to be able to just like maybe zero in and double click on a little bit of some of the intricacies That go into the thing that you built that has helped Thousands if not millions of developers over the years and why you're rethinking things.

Yeah. That's kind of funny thing because yeah, I think it's quite old now. It's 11 years old or so. And it's so well used, So it's hard to make bigger changes in Webpack. So yeah, this is a problem in like making like this kind of architectural changes or like making like stuff changes that have a larger impact on users and would be a large backend change.

So facing this problem while working on Next. js and we want to make some bigger changes. And the problem was like, it was not possible with Webpack. So we. It go the way that we created a new bundle that's inspired by Webpack, but do some stuff differently. And there are a few topics I wanted to change.

And there are probably a lot that come up in the next [00:02:00] time, but. Yeah. And I barely focused on the primary focus was on like the performance topic, which was hard to make major improvements in that pic because it would require to change that big A picture. And it could have done that, but I don't want to like make like a Webpack six, which is a really, or a Backpack 10 or whatever version that is a really big breaking change and breaks like every plugin every year.

User configuration and that stuff, especially when like maybe migrating into a different language from JavaScript to Rust or something that's faster. So yeah, we did go the way to make it like a new tool and with a new name, but this inspired by Webpack and trying to change the architecture and all that stuff behind that.

So TurboPack you're saying was inspired by Webpack and its history.

Yeah it shares a lot of stuff with Webpack. It has like similar output format. It shares stuff, but it also did some stuff differently. So it's it's inspired. It should be [00:03:00] something that is like where you can migrate from Webpack. It's probably won't be like a one to one migration.

It's like something that's different, but it's like similar. And at least it fulfills the same use case that Webpack. .

So before we get into some of the things you're rethinking here and some of the differences between Webpack and TurboPack, just rewinding 12 years or 11 years or whatever it was. What made you wake up and just say, we're gonna try this. I'm gonna try this out. Was it just like frustration or you thought you could like, you had a skill like this so you could do something for the community?

Yeah, it's a funny story because I wasn't into web development at all. did my master thesis at this time. And I'm one of, I just had fun, like writing a web application. And I tried this the first time there was my first web application. And basically I was missing like some kind of tool that does the build stuff.

And I It wasn't into Web at all. So I didn't know about any of these tools like Browserify at that time. So I basically built my own tool. So not from sweat's. More [00:04:00] like I found one of these tools, which was really small one, which is what called Modules Web Make. Nobody used it and now it's not well known.

But anyway I basically proposed to make a change to that and it was like a bigger change. So what I did is I made a prototype, re implementing it from scratch. With this feature, which was code splitting on demand loading at that time and yeah, that prototype then developed into its own bundler.

And I had fun maintaining this open source project. I had fun communicating with other people trying to use it. And yeah, it was more like a hobby project, just implemented, help users with that respond to issues like this open source stuff. And , that was why I created Webpack. It wasn't well known until like.

two years later or so when Pete Hunt from Instagram, like made this bigger talk where like basically promoted Webpack first

time in a conference and , then it was like, had more attraction, but yeah, before that it was just like [00:05:00] a random, like 20 people using it and I had fun developing it.

Yeah, that's the most important part. It was a labor of love. It shows in the impact it had too, so turning to the present day, you're rethinking some things. You already, I mentioned some right when we hopped into the podcast, like a lot of performance related questions and it's hard to make these large architectural changes when so many people there's millions of other developers who depend on it, right?

So one of the things you're rethinking now is leveraging browser cache, right? Am I correct in saying that?

Yeah. There's a few topics like performance is one of them. Like we want to change some long term caching, leveraging browser cache stuff. And we also want to change some architecture regarding client server interaction and that stuff, especially regarding like server components and that kind of new technology stuff. 

I mean, 

Starting just with like performance, right? Cause I'm sure everybody is very interested in this waiting for their. Builds to happen. Browser cache. It can be used in a bunch of different ways. How are you extending the [00:06:00] functionality? Browser cache to speed up TurboPack.

Yeah. So it's like the idea is that so all the bundles basically use bothercache. And that's more like how you structure stuff in a way that you can get the most out of the most benefit out of the bothercache. So the idea is that you basically want to have everything into the bothercache and 

the idea is that you deploy something new, a new version of your application, you change something and then you want, in the best case, that everything you didn't change, you didn't touch, is still in the browser cache and that can be used and the user only need to download basically your changes that you did.

And technically, if you go just unbundled and with. Like raw ESM modules, and you can do something like that because every module is a single request and then you can leverage a cache for all of that. And bundling basically breaks it a little bit because then you put more stuff into one file, then it's basically invited a larger file and you change something and all of this stuff where you [00:07:00] like, want to have like 

content hashes on file names that makes it , more difficult to like leverage about it in the correct way. So if you go with a naive approach . So maybe let me explain that.

The idea is that. You have a lot of like output of your bundle. So basically you start with an HTML file, of course.

And then that references like chunks of basically JavaScript files, CSS files, whatever, and these make maybe one JavaScript file reference another JavaScript file because it's asynchronous loaded on demand. And then maybe that file references. Some images, some font files, and all that stuff.

And basically all your stuff in your application is connected in some kind of way. And the idea here is that to leverage browser cache, , they're basically sweet kind of things you can leverage in the browser. You can't just put a max edge your request and say that this is valid for two hours or for two days or whatever. but in practice, nobody does that for this kind of application, because then you basically chip an important bug fix and you have to wait two days before the [00:08:00] browser cache, because the users pick up the change. So basically once like you deploy something and you basically want next user.

comes to the application instantly sees that change. So you don't do that. So then there are other techniques to do that then to pay the leverage by the cash and one other thing is like e tech caching, which means \ , you sent the first request. So the browser has the first request and the server answered answers with like response, sends you the data and they put all of this e tech header on the response, which, which basically is the hash of the content.

So it's like e tech. A, B, C, D, whatever. And then the next time the browser want to do the same request, it basically sends like a new request, but it's just like, if non match header with the e tech with the previous e tech. So it basically says, I want to resource again, but I have.

Something with this hash in my cash already. And then the server usually says text. Yeah. If it's the same hash, then I just respond to this. Okay. Yeah. Just use the cache and don't censor [00:09:00] the response. And if something is updated, it's just resensitive response. There's a new e tech and that well because then you don't have to download the file again, but you still have to make a request and get a response.

So still you pay the round trip. To the server, but you don't skip on the downloading phase. So that's good. And you can basically use it for every request. It's a universal strategy, so if you use it like a build tool, you basically can do better. So the idea is that.

If you just put a, like catch that for one year header on a resource and make sure this resource never changes, then you can just catch it infinitely. And suppose it doesn't have to do an request at all. It's just can just use it from cash. And there's also a special cash control immutable header for that to make it more efficient, it doesn't make it better.

But to do that, , to make a resource that never changes, you basically like. Kyle, what I said, you can't really do it because you want to fix something, application, do you deploy application, then your source changes. So then basically to, to fix that problem, that's a little trick. And the trick is basically makes it [00:10:00] URL just unique in this kind of sense that you just put a hash of the content into the URL.

But you often see that in resources and in filenames output by bundlers, which just put like in content hash on hash of the content onto the file name. And then it's unique and it basically never changed it because if it would change the hash would change and it's a new URL and then it's not in the so the bundlers basically do that. They put like content hashes on every asset they output. But then the problem is now you have this application with a lot of references between assets. And in practice, this means if you have an image or something that it's referenced in an JavaScript file, which is referenced in an HTML you have to put say URL of the image with the content hash into the JavaScript file.

Because it's referenced from there and you have to put URL of the JavaScript file into the HTML file because it's referenced there. So basically you have to embed the hashes of the referenced assets in the importing modules, importing assets. And that leads to [00:11:00] the issue that if you just do it the way I described, then you basically, if you change your image, that will change the content hash of the image.

Which is embedded into the JavaScript file, which means the JavaScript file, all the changes. And then this is embedded into maybe the next JavaScript file, and it's all the changes. It's basically this bubbling effect where , one change bubbles up the application and invalidates half of your application just because you changed one image or one font or whatever.

And that's usually not something you want. Do you want to like, do something better? And Webpack also does. Something better. It's Bailey instead of putting like having a lot of JavaScript assets that are referencing each other, that a webpack puts like all the content hashes of all the files of other JavaScript files, but got chunks in the back and it puts everything into a manifest.

File, which contains all the content hashes, although it's also in the same time, the Webpack runtime. So Webpack runtime basically embeds the manifest of that fixes this problem in [00:12:00] the kind of sense that now, because. JavaScript files or chunks doesn't like reference each other directly anymore.

They don't have to embed the content hash of the reference files. Every content hash is embedded to the manifest. So once you change something, it's basically bubbles only to the manifest and the manifest handle change and manifests really small. It doesn't really matter that changes, but all the other AVAs files can stay cash because it didn't change, because they don't embed the hash and that works well.

if I could jump in, Tobias, just for a second and make sure I have the right understanding about what you're talking about right here. So in the naive approach, you described how you can use, but you can just cache, but then you want to hash the content. So you have the content hash as well as with the tag.

So then. This way you could have like infinite caching theoretically, but then you have the problem of you bubble up changes so frequently with small Adjustments that you end up like almost with a useless architecture sometimes

Yeah, I, I would say [00:13:00] it, it's working well if you don't update the applications that often, so if you only deploy it once a week or something. It's fun. It's works is caching works. If user comes like multiple times a week, then they have the cached and it's only affecting you.

So it's like a kind of Luxus problem where you just have like, caching works and both. It doesn't have to do request, but the problem is only if you update your application and that's. Something I want to optimize it like basic webpack optimizes 

and so when webpack does this you have this manifest level in between just the broad content and in the hashtags That get produced. Did you have like a larger question to yourself about What level of detail this manifest sits at.

yeah. So in webpack, it sits at like chunks level. So only all the JavaScript files and all the stylesheets are in this manifest and only like these that are on demand on it. So initial chunks don't need to be in the manifest because we never reference them anyway. And we basically [00:14:00] don't do it for like assets, like images and fonts, and just accept that one level of bubbling in this case, because I think it doesn't really matter that much.

And , it's been a trade off. So you could blow up your manifest. If you put like all the images into the manifest tool, then the manifest will be large, but the chances like don't have that much bubbling, or if you just put the references of the test of. Images into chunks and you have the one level of bubbling extra, you invalidate your JavaScript chunk that is reverences , the image, but yeah, the manifest is smaller.

And yeah, the manifest is a cost you have to consider. Do you always have to load it up front? Do you have to load all the hashes up front? Yeah, so it's a trade off. And I think it works fine because. I think 90 percent of your application is like, say I was kept five. So it's a code of your application and yeah.

Images don't change that often. It's often if you change the image, you often also change like your component or something like that, or [00:15:00] if you're trying to fund, so yeah, it works. Maybe we could make it like. Experiment with that, but yeah, I don't really mind. It's not that important. 

and the chunks that you talk about, the delineation of where these chunks happen in Webpack, is it just arbitrary? Is it by size? Is it by file?

Yeah. So the splitting off, depending on another topic where like how you split up those modules into chunks. And that's also contributing to long term questions because take an example, you have like your application code and you have some vendor code, like React or Dom or something like that.

And you can consider it like your application code. And in most cases, the application code changes really often because you work on the application, it's changed really often and your vendor code changes really like infrequently that like rarely update your dependencies. And at least most of the people that would yeah.

So if you consider that's also something that does, so it basically splits. Your modules into two groups by default, like application [00:16:00] code and vendor, vendor, vendor code. And consider this as say, basically change independent of each other in this kind of sense. And if you know that something changes independent of each other, like application code, vendor code, then you can go on and basically put like application code in a different file than a vendor code.

And that. It's a pretty easy technique to do, and it works pretty well because your vendor code, if it doesn't change, you don't have this chunk changing and your application could often change. So this is often changing, but it doesn't affect the vendor code. And yeah, the, basically the problem I talked before that we put multiple modules into one chunk.

And then if one of these modules changes, we have, of course we have to like, we emit the chunks or the chunk changes. So we can't catch all the other modules. So you don't want to. Put modules together in a chunk that change different, change like. They basically don't want to like have , often changing modules in the change chunk with rarely changing modules because then like once the often changing module changes, [00:17:00] you also invalidate like all the less frequently changing.

Yeah. So that's, it's a pretty easy thing and vendor and app splitting works well, and you can go even further. If you have a lot of vendor modules, maybe you split by one package name or something. That's also something that's. Done. And yeah, there's a lot of heuristic you can use there. And we also, we consider some of them to do like, for DopeX.

So, the default is only split application and vendor code and don't do any special heuristic on vendor codes. And for DopeX, we also split by package name. And then . If the chunk is still too large, we split it up by like folder structure and that stuff.

So because folder structure often like, have similar caching heuristics and changing heuristics. so a lot of things you can do and often people configure Webpack also in a way that maybe you speak up by package name or something like that. Or you can also put like customer holistic in your application.

But, something is of value changing. In example, next year does it, it basically also puts like a framework code, so everything next [00:18:00] test related into separate chunk. So it's like basically next, next shares code, application code other vendor code, and that. Yeah, it helps. 

So I feel like we've gotten a really good groundwork for. All of the engineering lift that, or just the sense of scale that goes into like the decisions that you're making to bias. Like we have chunking, we have caching. It was interesting to learn a little bit about how the primitives of Webpack work, especially for me, like never having dug into what's going on behind the scenes.

So that, that was really great to hear. But this podcast is all about. What's new on your mind, right? What's coming and the new improvements that we're going to be talking about. So we're going to get into that and you specifically brought up Next. js. Curious to hear how the recent developments with RSCs, the page delineations, and how that's playing into bundling things up more efficiently.

Before we hop into that, I just want to remind our listeners that this podcast is brought to you by LogRocket. So for your web application, no matter how big or how small, if you want to spend less time debugging, And more [00:19:00] time just building, bundling, shipping, getting into your customers. You should check out log rocket because it helps you find and surface issues.

You just didn't notice you can use features to surface trends that might've slipped past you. You have heat maps and all other sorts of goodies to figure out what your users are doing and what your client server interactions are doing behind the scenes. So head over to lock rocket.

com today and check it out for free. So moving into the now in the future, Tobias and honestly, like the past year or so of what's been brewing, You're making some improvements to the way you're thinking about bundling things. One of the things that I just want to hop out the gate and begin our conversation with is the per page manifest.

And that's one thing, one reason why I asked about the manifest prior is I wasn't really familiar about how you place things in the manifest, what layer you put it at. Can you talk to me a little bit about what a per page manifest means, why it's a big deal, and why it makes changes?

Yeah. So that's barely back to the long term caching. topic. And yeah, so I, basically explained it's a, what Webpack does, it put everything in a manifest. But the problem [00:20:00] is like, if you have a multi page application , like an extra application that you have made multiple entry points to application, you enter whatever on sales or on contact or on dashboard or whatever, and then.

You also have the ability to navigate between pages within a client side navigation. So they want to have this single page application feel if you entered one page and then navigate to another page, then it's just a client side transition. And so with this in mind, you basically, if you want to do that with Webpack, you basically have to build like all the endpoints.

In Webpack into a single compilation. And all the means like, because you have this busy client side transition thing between pages, make sure that all of these pages are using a single one time because every module is basically a single one time module at one time. So it's like basically.

In the Webpack world, it's like a single runtime for the whole application with multiple entry points. And that also means that you have a single manifest because it's a single runtime. And [00:21:00] as I told you that, like the manifest is embedded into the runtime or rather the runtime time. So that's basically a single runtime for all the pages in the application.

And that's an issue because then you have to like these hundreds of pages. And then all these pages, like important. Yeah, I was confined to those images and whatever, and like for all these pages, all the on demand audits stuff, or all the, like the JavaScript stuff by the embeds a content hash into this single manifesto, which has a lot of issues.

One thing is it blows up manifest because it gets larger and larger when your application grows, which is not something you usually want. it also has a problem. Like baby, if you change. Something one image in one page basically bubbles, like it basically changes the manifest and that basically all the bubbles up to all the HTML files.

So basically all the HTML files, which embed basically embeds the manifest change because you did one change to one page. And that's something it's kind of [00:22:00] working. It works. And it doesn't have that bad of a performance because HTML often is not cached anyway, so it's fine, but I wanted to change that photo back.

So I wanted to have like more a pair page. I want to have every page isolated and changes. And then basically it's an obvious change. If you, by the way, I explained all these things. So basically instead of having this global manifest. I just made it like a pair page manifest and that basically fixes the issue that it's bubbling all the changes to all the HTML files.

You have to change a little bit, a few things, like the one time I have to like, you have to be able to not multiple one times and merge it together and merge the manifest together. But these are only small technical changes. If you like, it's basically more like an architectural change to make it work.

So , it's more of like an architectural change, like you said, and it's in the way you load it. Because when I hear per page manifest, I'm thinking like, okay, there's like another derivative layer of like serialization going on behind the scenes. But you're saying it's not that extreme.

It's more just, 

It, [00:23:00] if you start from scratch, it's basically you don't have to do anything special to do that. Put it like just made it this way, but you basically can't change that because it would break like applications because , it's not considered the architecture. It's just everything is embedded since it's manifest and you can easily change that in backpack.

But you can easily change that or rewrite that if you write a new bundle. So that's what we did.

Always like you do something different, but then new challenges come up and there's new problems to face and which you didn't have to face before. Like now we have to, this problem of merging manifest and merging one time and that stuff. Yeah, it's fun. But a little kind of cool to face new problems.

I mean, mErging manifest and combining these runtimes of the, like, operational islands. I don't want to use that term too much because it's used a lot in web dev, but you have these separate runtimes with all their per page manifest for the client side. bubble that you're in and then you merge them together.

It makes me think of a bit of tree shaking [00:24:00] because tree shaking kind of plays into maybe you have some things here and you don't need them there. So I'm curious about how tree shaking has played a role in the new bundler that you've created.

Yeah. Yeah. Tweeting is another big topic in this kind of thing and it's I really didn't like how tree shaking works in Webpack because when Webpack started, we didn't have any ECMAScript module stuff. We only had CommonJS. We had RequireJS. So it's, everything was like, you export an object and then it's fine.

, you don't have to care about like individual exports. So like now, five years after Webpack. It was created like the ECMAScript modules were developed by a suspect. And that basically everyone is using that now. And ECMAScript module has a special thing that you have individual exports that are like spotted on its own and you can have a random input statement and that kind of stuff.

And that enables something which basically rolled up really focused on. Where you can just like, if you only import like export a from a module, then we don't want to like, maybe[00:25:00] skip all the other exports of that module and that stuff and stuff. And in the way it's implemented in Webpack, it's basically like after we created like the module graph and figured out like all the modules your application uses, we basically go through the graph, check all the imports and check.

Like for every module, we basically check which imports are used. And then we take note of that. And basically all the unused export, we can just omit them at code generation time. So we can just omit them and that kind of works. But it has a few small downsides. One is like performance. So now we basically create the module graph beforehand, do everything without tree shaking, then tree shaking is like a separate step afterwards.

So it works. It doesn't affect runtime performance, but it really affects like the performance at build time. So you have to. Build all this unnecessary modules that may or not be used at all, because it would be tree shaped after like a step afterwards. So I wanted to change that. And in TurboPack, we basically do tree shaking, doing module graph [00:26:00] building.

And so we can just like skip modules, like why buildings and what about, but because we do the pre shaking ourselves, the export stuff, why do my buildings and what the graph. So it's that's a change you can do when we write that stuff. And another thing is that.

the way tree shaking works is basically it takes notes of all the exports used per module, but it also means if page a uses export one of a module and page B uses export two of a module, then the whole thing figures out that export one and two are used of this module and data modules generated with export one and two, and maybe three is omitted, but one or two is generated.

But the problem is like. Technically we don't need export two in page A and we don't need to export one in page B, but the algorithm has just figured out like both of them are used. And because we only generate for technical reasons because at one, time we only like basically deduplicate that module.

So we only use, you must make sure that this module is only used once because it might have stayed or something. But the [00:27:00] identity of functions is not the same. So we have to generate like one kind of code. What the code we have to generate the code in one shape for the whole application. And that kind of is sad because now we have like problem again, where like any arbitrary page affects, like maybe your homepage, which is affected by like the admin side of the thing.

So we want to avoid that. And it's complicated to avoid that. And I tried a little bit to in Webpack to avoid that. And if you like have, separate, like empty points that are completely separated, then you can avoid it. But if you have empty points that want to import each other, like in a way, we do client side transitions to the same page.

Then, yeah, it's busy doesn't work. So we figured out that we need something more involved in TokPak to fix that. And now in TokPak, we do a really complicated transformation. So instead of having like modules, a smallest unit of things that are put into chunks, we, we basically split up the [00:28:00] module into fragments

so we split the module with import one, two, and three into like smaller fragments, like module, fragment one, module, fragment two, and that stuff. So basically for every export, we create like a small fragment. And then , instead of making a module graph, basically make a module fragment graph where we only reference like single exports at all.

And then we can basically put like fragments into chunks. And then we can basically split up the module into, in fragment and then put like fragment one into page A and fragment two into page B. And then basically it solves the of having the module being like one identity of the module, but it also takes a few changes because then what's this shared state in modules do it basically have to create the newest fragment just for the shared state and reference the shared state fragment from both pages and that stuff.

A little bit more involved but that's the idea to split up modules in fragments and then place [00:29:00] fragments into chunks. And that fixes the problem of having this kind of global effects between pages and it's basically the same idea of isolating pages and making pages isolated to like don't affect other stuff., 

Did the fragmentation of a module as an example, affect the way you think about hot module reload?

Yeah, that's the kind of funny thing, because HMR, it's in the old world with Webpack, we had to disable most of the tree shaking for development because the problem is like, if you have like tree shakings, that basically means you change one module, maybe the module that imports another module, and if you change the imports, then This can trigger like bubble and effect to another module.

So basically you change them, you maybe from one module you import. Now you change a module and that now imports more to export two of a module. And in the old tree shaking of Webpack world, that basically means you change module. A, and that would affect module B because then [00:30:00] new exports have to be generated or omitted from that module.

And that kind of bad for HMR, for module replacement, because every module that has changed, like doing compilation from compilation one to compilation two, that is basically sent to the client and basically updated on client side at one time. And that means this module is invalidated at one time with.

Bubble up changes to the next except bond. We may be refreshing like a component, or maybe you're also lose state in that module because it's reloaded or refreshed the module and that kind of bad. In this kind of sense, because of that tree shaking was combined with teaching it would like this kind of behavior where you'd like to change something and something unexpected.

Had happened somewhere else in the application and break something which really unexpected. So we tried to make it that if you change one module that should only affect that model, at least in development, it should only affect that module and isolate everything to like this model so that.

Once you do a change, you [00:31:00] don't want this to touch any other module and have this global effects on application sync. And that's not only good for HMR, it's also good for incremental builds, because then if you have your changes localized to one module your changes only affect that module, you only have to rebuild that module and don't have to re code generate other modules.

And for this fragmentation thing, all the works will vary with this new approach because now you've fragmented stuff and you, because you've fragmented that, and then you like not changing modules because you're basically only adding and removing whole modules. Or fragments that auto fixes the problem that if you change one module that affects the other module because that doesn't happen anymore because now you only import add or remove other fragments, but you don't change fragments and changing of fragments is a problem that because changing a fragment would trigger an HMR thing and invalidation for that code and Yeah.

Basically fragmentation also solves that HMR problem with [00:32:00] tree shaking. So hopefully in future we can use tree shaking for development or tool. And yeah, that might have this performance or had this like similarity of development and production builds and that kind of thing.

when you, and just to summarize what we've talked about so far in the new way of doing things, like we have per page manifest, tree shaking and these differences that you noted between development and production so that we can keep the concerns of HMR and development and the smaller bundle size and production in check given these kinds of ideas, would you say in general, you're seeing smaller bundle sizes, like aside from speed, just like the end output size?

Yeah. 

yeah. So technically module fragments helps this bundle size. So it, because you have paired module and fragmentation of stuff, it can help. So I don't think it's met us that much and it doesn't matter for every application and in some edge case, it might affect, have a bigger effect on bundle size because [00:33:00] you benefit from that case.

But I'm not sure if it's like. So comment and I would like minification is more valuable and that's kind of stuff.

And, it has this bundle size a little bit, but , it won't be like a 20 percent boost in bundle size. I think we really need the boundaries of like where we can skip model code and stuff.

And yeah, I don't think it's so big boost on production builds. Yeah, most of the things we did for ToteBag are mostly development related. So like incremental builds, it's mostly like really fast, incremental builds are mostly development thing. And we focused on that and we didn't start with production builds, but.

I like at least for production builds to be really fast and with incremental, we would need something with persistent caching and the stuff. So that's another topic which didn't start on that. But that's maybe something for next year and depending on what this podcast, it's like 2024. So that's something where we [00:34:00] can see bigger boost, both in build time, at least. like, although the long term caching thing, it's really hard to measure the benefit of that because , it only takes effect for like common users can come back after you've deployed a new application, build a new change on.

Yeah, it's hard to measure that. Benefit of that. It's not really something you can just measure by going one time to application. You have to, but maybe you have to measure your cache way to raise you from users, like when you develop your application, like over time. Yeah, I had to see that, but I still think it's valuable to do these changes, even if like it's hardly noticeable.

fOr us and they, at least it's happy measurable. But I think it's pretty cool. 

I mean, there's a bunch of other things we could Get into about how you're rethinking in TurboPack. I definitely wanted to focus on that top layer, which is the per page manifest, and then underneath that the fragments and how you're rethinking some of the chunks and stuff. But we're [00:35:00] running out of time.

We have a couple minutes left. I'm sure there's a lot more that people can explore about the innovations that you and the community are making. You did mention 2024 persistent caching, sO aside from that, If there's something that you're personally, like you're a theoretical guy, Tobias, like , you're designing all these structures and you must get excited about some of these ideas and it's like, wow, we could just do something better.

What in 2024 are you looking at that you are personally like, get your heart rate going a little bit because you're excited to just dig in into the optimizations and in the theory behind it.

Yeah. I'm really like into the, once we have this because like the whole. I can take you off to build around like incremental base. And I really looking forward to like, once we have a system cash and we have incremental builds and that combines well together, and then we have this hopefully super fast production phase and.

That's what my dream or what I'm looking forward to. And yeah, it's still a long way to go, but it's [00:36:00] really, but what I'm into like this kind of, when finally this is I knew architecture comes into like real benefits for the users, the HMR benefits we currently have with Stonepack are really good, but I think it's not that like important if you have two seconds or 100 milliseconds.

That's fine. Nice to have, but I think the production builds are really cool to see. I think that, yeah, I'm looking forward to yeah, I was always kind of two seconds stuff. It's always really cool to see that in action. Yeah, forward to production builds.

That's where the cool stuff is the optimization stuff. And that's, yeah, that's cool.

everybody loves a good production built device, so I'm glad you feel the same way we're on the same team here. If people wanted to. Get the latest about what you particularly personally are focused on Reminiscing about can people find you on Twitter? Mastodon, where do you post?

Yeah. I'm on Twitter on X and yeah, I don't post that much on Twitter. It's more like what I do is like conference talks and you can [00:37:00] see, look at, look them up online and I basically, all my interesting stuff is. 

Yeah, I mean if you google Tobias's name I'm sure you could find a lot and there's good YouTube videos I know you did an interview of Jack Harrington like a couple or five or six months ago Yeah, which was great to see Well, tobias, it's been a pleasure having you on. I wish we had more time to dig into some of the technicals about TurboPak and the great work that you're doing, but in the meantime, until we get to have you on again, thank you for your time coming on and hopefully some people can start to take advantage of these end users can really start to take advantage of the research and work you've been doing

Yeah. Thanks for having me.