Zack Jackson - ByteDance, rspack, and the Future of Web Development

Whoever builds a compiler that produces the smallest bundle would most likely win the bundler war. Regardless of how developers feel about it or if they say, "Oh, well, they love this ecosystem so much." That doesn't matter if you can produce 50% less [Music] payload. Hello, welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co-host, Justin. Hey,

everyone. Uh we're really excited to have Zach Jackson back on the podcast with us. Uh Zach, you were on it was like episode 30. Uh we're like in the hundreds now, so it's been a while. Uh so excited to have you on. Uh and we know there's a lot that's changed with you. Um so previously you were when we

last talked to you, you were working at Lululemon. Uh and now you're at Bite Dance. Um, and so if anybody wants to go back and check out episode 30, we talked a lot uh about some like really interesting work you're doing at the time and I hope to get some updates on that. But before we dive in, uh would you like to update our listeners uh and kind of tell the new listeners like about yourself and like what are you up to these days? Uh yeah, sure. So um I'm a infro architect at bite dance and what that basically means is that I work on like a lot of our infrastructure tools. So uh obviously the company is really large so there's a a big set of problems that uh is never ending to solve and uh and yeah and so essentially we I think our team we with about 60 members on the infrastructure team and so it's about 60 of us and on infra we pretty much deal with everything from like uh building out custom runtimes to like custom JS runtimes that comes out of our kernel team.

Um, native frameworks and renderers for various things, compilers, obviously, JS frameworks, and then other, you know, things in between like just the tooling to get stuff from A to B. Um, so yeah, so that's a lot of what I do day-to-day, which is essentially what I've just always been doing, but now like at a much bigger scale, which is quite nice. and uh and and then yeah then obviously module federation is still like you know uh very close to my heart and uh luckily I happened to land at the company who happens to be the largest user of it out there so it all worked out well yeah it seems like bite dance has created a lot of different things just from the outside looking in uh there's like a lot of innovation going on and like next generation type tooling so like what for when you first started like what attracted you you to the company and what projects at the company have you gravitated towards? Let's see. Um, okay. So, I guess like a thing that I usually look for at a company is like, you know, I'm always about like impact. I know that's like an overused word these days. Um, but like generally if I have to go somewhere and I'm just pigeonholding to cool well like you'll do. This is kind

of why I got out of product engineering is it was just not high impact enough. And I think after a while depending on it's also very dependent on like the health of the organization how enjoyable it is to work on the product actually becomes. Um, so you know in in in uh some places it's you you're very beholden to changes of like non-technical users which is can be difficult to kind of like you know really get in get things done. So I would say the the main reason what kind of attracted me was just really the size of the issues that they had and the fact that a lot of the problems that they were looking at were really similar to things that uh I had been interested in solving. And you know, I think

ultimately it was kind of like, okay, well, you know, like when I was looking around at the opportunities and then the kind of just the numbers come out of like, hey, well, here's the size of the people that use this stuff and here's like the runway of problems that you can have to solve here. Um, and that really kind of hooked me in the end. But how it kind of started was it turned out Bite Dance had been after me a couple times and I uh just didn't remember um speak apparently had like a call with the previous infert team manager before and I don't know like why I didn't end up going there or what the deal was but uh so what ended up happening on like about a year and a half later or so um how how we actually started like getting involved was I was trying to replace Webpack's ES3 parser with SWC in like a desperate search for, you know, to make it faster. And obviously I knew nothing about Rust at the time. So I'm like, "Hey, how do I get like the Rust back to the JavaScript?" Like, you know, the most basic thing like just how do you like get it back out? Um, and so I'm fumbling through asking around online and somebody uh someone's like, "Hey, yeah, I can I can help you." and

jumps on a call with me. And so we chat for a little bit and he unblocks me and then we're going back and forth over just like as I uncover the problems of why this ultimately is not going to work. Um uh and uh who I ended up speaking to was actually the lead of RSpack and I just didn't know it at the time. So we're

kind of going back and forth and he's watching me like fumble through like failing trying to make Webpack faster with some Rust. Um, and then you know things kind of die down and then maybe like a week or two later he just messages me. He's like, "Hey, I want to show you something." And so I get on a call and they're like, "Surprise, there's this thing we've been working on where we actually ported Webpack into Rust." Which obviously I was very

skeptical about because I've heard this song and dance many a time before. And you know, my general assumption was you can't like you can't really do do it. like for the surface of the API that it gives you, that's just not something that you can create in native because I haven't seen anything done in like, you know, in any of the other native build tools that have like an API on par to something that's just stays in JavaScript. So, you know, he kind of took me through it, showed me actually these are the real loaders and are the real plugins. We didn't just fork this. It doesn't just

look like Webpack. It's actually running their ecosystem without a problem. And I think that was probably the main thing that hooked me into coming in was like, okay, this is real in like for all my involvement in Webpack and like how much I've been like, you know, a fan of it and how it's helped my career obviously when like the Rust Webpack pops up and it's like, okay, well, you know, I feel like this would be real good. And then on top of that, I found out, you know, they use a lot of federation here. So,

you know, there was just like cool, I get to work on the thing I like to work on already just in Rust and faster and less constraints because we would actually own the product. So, you know, it it was just uh that's really kind of what attracted me. Cool. There's really big problems to solve here that usually you can't really get solved unless you just have like unlimited resources to throw at the problem. And that's really really difficult to come by. Um and luckily just because of like how the company is it like because it has so many products and so many different like you know offshoots of various things um a lot of the architecture attempts to be unified. So then that means it's like

okay well you need a tool that's going to be able to do like 200 different you know business cases that are you know vastly different. So just you know it was kind of cool because it wasn't as uh fragmented and disjointed as like you would usually see where things kind of pop up around an organization for hey what works there which I mean you know that's totally fine but I guess like it's one of those things where I think economies of scale really kind of help and I like working in the areas where economy of scale is useful. So there were a lot of things here that just made it a yeah I'd love to come and work here. Big thanks to Work OS for sponsoring this episode of DevTools FM. If you're building a SAS and thinking about moving up market, work OS gives you everything you need to make your app enterprise ready without turning your road map completely upside down. From single sign on and directory sync to audit logs and fine grain authorization, Work OS is packed with the features that companies expect and developers can actually work with. What sets it apart is how modular

and well-designed everything is. You don't have to use everything at once. Just pick what you need and drop it in. The APIs are consistent. The SDKs cover

all major languages. The developer docs are genuinely some of the best out there. And if you're dealing with onboarding flow issues or user management headaches, Work OS has solutions for that, too. A pre-built admin portal, secure credential storage with vault, domain verification, and a whole lot more. It's built to scale with you, whether you're closing out your first enterprise deal or rolling out compliance features before the questions start coming in. So, if that sounds like something you need, check out work OS at work os.com. Let's talk a little bit about

Webpack. Um, so it's like it seems like for a little while, at least in the realm of like Twitter and Blue Sky or whatever that I'm on, like a lot of companies and a lot of people have been talking a lot about VIT and its sort of shape in the ecosystem. And I I know that there are still a ton of companies using Webpack. Uh, and I know some folks in in places that I used to work that are still using Webpack, but like you definitely don't hear as much about it these days. And I'm curious like how do

you think like RSPAC is like changing that? Uh what are you sort of doing fresh and new? And like how does it sort of how do you see it fitting in the the current ecosystem? So I guess um I don't know. I I I personally view them as like two different categories of tool to be honest like and nothing against VIT just in its current form I know that it can do the job for many developers but uh like I don't know I guess like well why doesn't NexJS just use beep then like why does TurboAC exist like not trying to throw shade here and maybe like I just got off a very long flight. So, but you know, if it's the be all and end all, then we should then nobody would be building Turboac next would be using it and blah blah blah. But it's not and that's nothing like I mean nobody uses CRA to build out these crazy type of things and there's various use cases for them. I think Vit really why Vit got so momentously popular, you know, just speculating here is configuring build sucks and nobody cobbled a solution to that together. you

had Webpack which was okay it's all into one but then you also have like you know a PhD degree in configuring Webpack to go along with it. So over time and then and then you know something like ESB build pops up and it's like oh cool here's like you know an API with four hooks and that sounds fantastic because if what you want you know when I think of ES build I always kind of in my head kind of put it as oh I need fancy babel like I need something that mostly just transforms things and kind of puts it in certain places and that's about it like a little bit more than SWC but you know fancy babel transpile things, pack it into simple files and off you go. Um, so so I don't know I kind of see like uh what V had done and we had learned from this as well when we saw what they had done but they got super successful because if you weren't using Webpack then it was like either roll up or ES build or some kind of Frankenstein between the two or whatever and so what V did was say okay well and they introduced this thing of like a build tool. I don't think we had that really

like I don't know I really only use Webpack and go hunting around but we didn't really have something like a a Vit type experience that was just offtheshelf to use where hey here's a React plugin and it's not you like configuring the loaders but there's like middleware on top of the that's instrumenting the tool. I think that really helped a lot in in its popularity because config hell was real and also it was just faster because unbundled you know skips doing a lot of the buildup front and back in the JavaScriptbased tooling world that was a big issue. Now I would say on the flip side though it hasn't been all like sunshine and rainbows from from like um and again I just know from like the research that I do on these bundlers and from like what users tell me. So, I'm mostly just kind

of paritting like the things that I've heard or think they might not be totally accurate or whatever, but um you know, like I think a big one that we can probably all understand is like, okay, well, the development versus production discrepancy. And so, I mean, that's not a super bad problem. It's something you can work around like either way, like it seems to have not impacted the community to a detrimental point. The problem is though is I don't see a lot of people putting like half trillion dollar company and betting it on that consistency being good. And this is something that I would say like Webpack has historically done well. It's had

good artifact integrity. It bundles really small. It supports lots of things. It kind of meets you where you're at. And I think like when you're looking at the tools that you want when you're on the lower end of like the problem surface when you're in the let's say like when you're in the 8020 rule in the 80 you have a lot of options but in the 20 you don't have so many like example okay if you take Nex.js JS.

Well, Nex.js can't just use ES build or just use V. Like, I mean, maybe if you rewrote it from scratch, you could get all the things in there, but they could do that easier with just like Turboac or Webpack to kind of do the roll, but these are also some of the more sophisticated like build meats out there where they're doing a lot more crazy stuff. So, you know, I think there's

just kind of a difference between the target markets of what we're looking at. There's, you know, like I would usually say that probably these are an acquired taste, but our target market is obviously everybody. We'd love for you to use the tools, but our our focus primarily is like the focus we have here at home, which is okay, you've got a 400 billion dollar business and everybody uses the things and it needs to scale and like your compute costs are like, you know, it's at the point where you, you know, you're looking at engineering is cheaper than compute. So CI taking long and chewing up boxes, the amount of manpower to just write a new compiler is cheaper than living with the boxes taking 40 minutes. And if you can do that plus artifact integrity, all the other things that you want, we were just in a position of why not go and do it. So you know, ultimately I think the two will live side by side. What I think really needs

to happen though is like with roll down. So that's kind of what I'm excited to see like what's going to happen there is cuz I think a lot of the problems in VIT it's also kind of unfair to say oh well you know I see some users use it as a scapegoat oh well you know it doesn't do this that or the other thing and yeah sure but they like they have a thing that they're working on to bring out it's just not out yet which um you know again we'll see what happens when it comes out um but I think when we're in that space what we've also noticed that was interesting is that V seems to be like looking at the bundled mode for apps. So instead of doing the bundle and dev like it's always done, they're looking at adopting some kind of like proprietary Webpackesque chunking format and some kind of runtime for it. And I think that that's a really good move because at the end of the day I think like the whole idea of unbundled ESM I think everybody has tried it for a while and it you know it kind of works but there's there's like problems with it that aren't necessarily on paper problems like uh doing everything unbundled. It's technically going to work really well on your machine in incognito mode, but go get the user machine with like the six Chrome extensions and the Bing search bar. Like

you remember the old IE where you'd have like that many toolbars like you know imagine a browser that's got like that like your average Chrome like laden extension laden browser and then if you have to download like you know 4,000 little modules it's not your network isn't the problem. it's all the junk that's sitting on the client device that you can't benchmark against that like brings it down in the real world. Um, so you know, so I think it's I think a lot of these things seem to be going in the right direction of hey, we tried various things. We think a bundled mode

would be good and the reason that we can do a lot of this stuff is like we have faster tools so they can do more work. like cool, we can bundle it all really quickly and make it, you know, more or less as fast as like unbundled just because like Rust would enable speed where oh, if it takes like, you know, 300 milliseconds to start up, we don't really care at that point. Like it's beyond the point of caring. So, I'm also excited for us to get that because it seems like everybody in the bundling space is kind of getting to the point where speed isn't going to be like this thing that, you know, the bundle of wars are fought over, which I feel for like the past 2 years that's a lot of what it's been. Oh, well, you know, which one's faster or so on and so forth. But

now it seems we're talking about like, oh, well, this one did it in 1 second and this one did it in 600 milliseconds. And it's like, okay, sure, that's still maybe, you know, two times faster or whatnot. But then when you look at the demo app and it's building like you know 15,000 modules or something you're like okay well realistically yeah so there could be a scaling issue but if you can build I don't know like we have one here that's like I think 50,000 modules it's like okay if I can build a product app with 50,000 modules and I can build it in 20 seconds then you know that's probably the slowest build RSpec has on the market and that seems more than acceptable to us coming from, you know, that taking like over an hour or more to build. So, I think as well just like the focus is going to start to shift as we all get the tools where it's fast and where it's like, okay, well, a little f like when you're doing HMR, if it takes 100 milliseconds versus like 85 milliseconds, nobody cares at that point. It doesn't take 15 seconds to see the update. So, I I'm hoping that the speed war kind of changes. But then

again, I don't know what the next thing will be that the bumblers are kind of, you know, vying for. Um anyway, long-winded response, but that's just kind of how I see things. I think there's a place in the market for two and or or more. And at the same time,

like now it's more become like, well, what ecosystem do you want to buy into? Like which one has the parts you want? Vit has a big community, a big type of ecosystem, and lots of people like using that. But there's also people who, you know, enjoy the Webpack type ecosystem, but usually because of like, oh well, they're very familiar with loaders or there's certain APIs that let them do certain things that are just easier to get done in there or, you know, whatever other reason, just that's their flavor of the month. Then it's kind of nice to say, okay, well, this becomes more of a preference choice than not like a, oh, you know, well, like what's the real big difference here? But I think what we'll just see is there's going to be just like you have React and you have Angular and you have Vue, you're probably going to have like cool, they're all going to more or less do the same jobs that 80% of the users need. And then it's really just what do you like using to do that job or what does it integrate with that you might also want? A lot to dig into there. Uh so uh one of the original goals of RSpack was kind of just to be this drop in replacement for Webpack and to like completely support the API. Uh that that

works in the beginning, but as you said, new things are going to be unlocked. So like what what has RS pack like worked towards that's kind of like innovations on top of Webpack rather than just like matching the old API? Okay, so I guess to go back a little bit as well for some context on why we went this route. So we didn't just like go let's port Webpack and that was the plan. That was the last thing that we did. So we have like pages and pages of documents. Um I think uh there was something crazy. I think like

people who people from bite dance have worked on every Rust bundler except Turboac as far as I'm aware. So most of them that are on the market like in some way, shape or form, some origin story can be traced back to that person's time working here. So there's just a ton of knowledge in building these rust bundlers and like you know like 60% of them came from people who had started working on those here maybe left and took it further whatever but like there was a lot of like catalisms here around bundler research and doing this. Um so the the big thing that we have discovered is writing a bundler is actually not as hard as it sounds. The real problem is the API design and how that ends up biting you down the road.

So when we started we actually were like okay well the first version of RSpack actually was ES build and we rewrote ES build and so at a for time we were thinking of calling it go pack and it was going to be written in go. The problem with Go that we found is it doesn't do well with bindings to JS with like very complicated bindings mostly like you have a garbage collected language to a garbage collected language and and that doesn't play so nicely. So then we kind of looked, okay, let's look into the rest side of it, moving ES build into Rust and let's just fix some of the problems ES build has because it was almost, you know, good enough for what we needed. Um, at the time we were just building our links apps with it. So

we needed a it was originally called Speedy. So we needed a a speedy solution for link and that was hey ES build can almost do the job there but if we could just fix these issues perfect. What we ended up finding though is like there were bigger challenges in like ESB build for example like if trying to fix the code splitting so that it chunks the code better or HMR there's like architectural challenges that make that not just easy to add like the dev just doesn't want it in there but it seems to be like well you know there's fundamentally it's a little bit trickier to try and do that. Um, so we kind of

ran into this wall a couple times where it's like, oh well, let's try and create something new. And then it's like, okay, well then there's the explosion of whatifs that come in that haven't necessarily been thought through and it's uncharted territory and so on. So we had two main issues. One, we had a lot of things using Webpack. Um, we were also investigating VIT at the time because Vit was getting popular and we were like, hey, maybe we could switch over to that. Um, and and you know, maybe that could work. And so then one of our info teams

ended up building I don't know if you guys know farm.fe. Have you heard of that bundler? I think I might have been on the page before. Yeah, farm.fe. So So anyway, so farm actually started out as ploy. So our infert team was split into two sections. One one half of the infert

team was building RSpack. The other half the infert team was building ploy. We reorged folded the compiler teams together to reduce redundancy. And then

the I think the the main guy behind ploy left the company and released farm which was like heavily which is essentially like from all the work that they had done at deploy packaged up and put it out there. And from what I understand of ploy was the idea was to have like almost a ve type compatible API just very quick and solve the problems that we were impacted by that there was no roll out at this point. So this was the way that you know they were going out to solve it. So we wrote like you know I think maybe five bundlers in total like getting through to this point. The reason we ended up on Webpack is um again design issues. Oh we can extend it

here and there but then like there's all the unknowns and race conditions coming in which essentially just makes the risk too high to look at. So what we thought is okay well probably the easiest solution would actually be to take something tried and tested that we know is guaranteed to work for all the business cases and that was Webpack which is a lot more complicated but the nice thing with Webpack is it's also got over 10 years of testing behind it and so you know it's pretty solid to start with that. So if we could port Webpack into Rust and say we have a foundation that we know has 10 years of like here's all the things it all works it's all very well tested then we could start to enhance and iterate on it knowing that we actually have a stable replica of a powerful bundler to begin with which is a lot less complicated than trying to design one that could be that or more in the future. So, so 2024 was largely get par, get stability with the APIs. Like a

lot of it was speed doesn't matter. It's about artifact quality and making sure we have like a one to one or you know make sure it works safely like make it safe and then make it fast essentially. Um so in 2025 now we're looking at speed opportunities. So I would say like

things that we've been we've been considering as like you know time is going to involve on um so there's there's a bunch of a bunch of like various things but we're we're quite interested in a lot of what the turbo pack team has been cooking up and so we've had a lot of those plans in our plan since like mid 2024. So things like remote caching, function level caching, cache, you know, cache that you can share between different uh developers. Um that's something we're very interested in. I think we already have like function level code splitting as well. So you can move single functions out of chunks. Um which these aren't,

you know, super like most people don't really care about those type of like minutia, but basically it means you can make like a lot more fine grained implementation. uh a lot better code splitting, tree shaking, stuff like that. Um a another big area though that we want to look into that I think we've already started the work but is going to be into a uh into a what is it uh into a unified build graph. So essentially saying I want to build to an edge worker, a native device, a node server and the browser and I want to do it all from a single build and then I want certain imports in that build to remain under certain boundaries. So um you know

like building the whole a module graph that could control potentially three to four layers of your deploy stack but as a but it's understood as a single system to the runtime. So this is something turbopac has also been working on. So I what I would say probably is a lot of the future things that we would consider is going to be we started with aligning to Webpack, we have a stable core then now looking at things like what Turbo is doing. How can those be incorporated because we think a lot of those problems again are things that kind of align with the problems that we would like to see solved. Some other areas though like you

know it's kind of an interesting one is like there's still a lot of room in tree shaking and dead code elimination. Like my personal opinion has always been whoever made the whoever builds a compiler that produces the smallest bundle would most likely win like the bundler war because regardless of how developers feel about it or if they say oh well they love this ecosystem so much that doesn't matter if you can produce 50% less payload to the end user like the user wins and if you can serve them twice the light the lighthouse score like the business will override any engineering just because of like the depending on the industry but you know that's what I would say if you can produce a smaller artifact all the other points are moot like everybody's going to go for smallest thing to ship to user best experience at least that's how I kind of think about it um but but tree faking and dead code elimination is really tricky however most modern bundlers still leave about 40 to 50% dead code even after optimizing so that's how much still could be done um and So, one thing we've been looking at as well, we've been working, I think, with Katie Y on some of this too, but looking at how could we use tree dead code elimination and tree shaking by using the TypeScript syntax to help inform the bundler what's going on. So, usually when you build things, how it works is uh you take your TypeScript code, convert it into JavaScript, pass it to the parser, the parser reads it, and does whatever. So you lose a whole bunch of things like oh well if there were private you know if this class is private you could check well is that method actually used in the implementation if not we know that outside you can't use it because it's marked as private so it's safe to tree shake if we don't find any inner graph linkages so there I think there's a ton of information like that that we could extract which would really help with like how we how a bundler can understand the app using like a better syntax or you know a more informative syntax Um, some other things that I know we've been playing around with was we had the idea of um of being able to use hot reloading to redeploy production. So, HMR was designed for production use and nobody really did that. So, something that

we've been looking into, well, is imagine if you need to perform like certain hot fixes instead of having to redeploy the entire codebase, what if you could just push the hot update chunk into an existing app. So if you just needed to add the patch and the patch was only one kilobyte, you're essentially just pushing an extra KB into the existing app and all your users could get it, you know, and you could hot reload them, not not preserve state in the browser, but you could effectively do things like that where your deployments just become hot reloads to um to the to the pipeline. So, you know, those are probably some of the more interesting areas. Then I know we

we're also getting into like stuff with AI and other things like that. So what I kind of see is potentially some somewhere down the line where these things kind of like mash into something like combined where you essentially have like a environment that's then customuilt and then potentially we could bolt on some kind of like a jing system to it and we have a doc site system that's designed to be parsed by like a indexer for like you know a question and answer bot and you would be able to have a code sandbox because we have like uh yeah like essentially you know we could we have enough of the loose parts where we could probably do some more interesting things like that. I'm personally quite interested to see I know we started on it but like MCP for example hooking up our our build doctor RS doctor to MCP servers and now your AI would be able to understand what's going on in the build and what if that could go a bit further and you had like some knowledge graph so like the compiler helps serve here's the application here's how it's working and potentially kind of you know starting to utilize the bundler almost like as a language server of sorts. um to find context and understand relationships without like manually splitting chunks and doing things like that. I think a lot of problems that you have in like AI and in like rag is very much the same thing as bundler. It's just you're serving a

different type of module back which is like a text chunk versus a script chunk. Um, but yeah, so you know, there's some kind of interesting things that I could see floating around here, but I think in general, a lot of it's going to be on how do we make it, you know, faster. Like I think the mainly the big things right now are speed, um, improving the the unified graph structure because that would open up doors like RSD and other areas like that. And so something we've

also been kind of considering is you know what if what if like something like RSV wasn't bound to React but what if there was like a bundler level protocol of some kind that fits within you know that kind of paradigm because if you have like a unified graph and you can build the server build the edge build the browser and the build is aware of every like where every part is going to be going but also the runtime is aware of it as well. So the runtime could know that hey this is a server module per se. But what if you could kind of bake that into well this is just how like importing certain code works rather than like oh well here's React server components and you have to pass it props but you I mean theoretically you could do the same thing where you say hey here's bindings to a function that you get on your end and those bindings are going to translate into like you know a network related call or a call to a worker and then get decoded on the other end. um you know kind of using the similar kind of principle as uh as like what RSC would do. Um, so and I think particularly for something like links that would probably be very useful because we already have this use main thread and like using the background thread you do parallel like multi-threaded processing on there and so being able to do that more sophisticated without needing to uh kind of glue certain parts together I think you know would be quite interesting. I

think this is where it would be nice to say, oh well links already uses this thing where it's kind of like RSC but it's built into like links itself. Now what if like the bundler itself had like universal way to handle this problem of like here communicate with resources that might not be here but to you they feel like they are. This episode is sponsored by Mailch and email platform that developers love. Go for high deliverability, industry best analytics and live 247 support. You can get 20% off for all plans with the promo code devtools. Check out the details in the description [Music] below. Yeah, Lynx is lynx is such an

interesting project and I think the thinking about the the bundling scenarios there is like really interesting. Um, this is something that we want to talk more about in a second, but before we move on to that, I would like to ask you a little bit about like y'all just recently announced uh a next RSpec uh module and like kind of moving into the next.js ecosystem, starting to support that. Um, and this seems like sort of like an alternative. So, if like your team's not using Turboac or not ready for TurboAC, like you have this alternative. Can you talk a little bit

about like the work behind that? like how that came about and the the introduction post mentions like some collaboration with Versel on at least like fundamentals is like what does that look like for y'all? Yeah. So, so yeah, I think it kind of I think well I think it kind of all jump started a little bit when when about I don't know like seven or eight months ago when whenever I was in China I uh uh we were kind of looking for hey what should our plan be for like the next year? kind of doing like midyear planning trying to think about like a bit you know midterm what our road mapap's going to be um and so we're all sitting around the table like putting out ideas we had things like RS test which is now kicking off kicked off to like you know RV test but like integrated within like all of our other tools and so we're going through the list of like things we want to add to the ecosystem or change and then you know one and then sarcastically I just threw out RS next and uh I don't think sarcasm translates super well So, um, so yeah. So, so everybody was like, "Oh, okay." You know, that's it would be interesting. And essentially what it

ended up being was like, "Oh, well, you know, we've tested a web RSpack on virtually everything we can find." Like we just clone down repos, see if RSpack can build them. And that's kind of how we've like tested a lot. But the one we

couldn't test was Next cuz like you couldn't just clone it down and and replace Webpack with RS type and you're good to go. Um, so then we decided to try it and so we forked next and you I think it was like we went out like over dinner somewhere. We like went out for an evening and we're like okay let's just mess around a little bit like over a steak and just see you know what we can get it to do. And so you know within a couple hours we got you know pages router working and of course not all the tests were passing but it was like okay I could pick you know a series of random tests and like you know a basic page of router with some CSS and you know a couple other various things would work and that was quite impressive to just see oh wow okay like it is it wasn't that difficult and a lot still doesn't work but the fact that you could get like maybe 40% of of tests passing or you know something like that from just uh like you know quickly trying it out to see you know hey could it actually build this. So ultimately I think like the challenges that we had with that is hey this is really cool and I hyped it up far more than I should have just because I was so excited to see it. Um

but the thing is we didn't have a use case for it. So for maintaining a fork of next is like a tall order. Um but it was really cool to prove that hey the bund like for us it was can the bundler do the job? If it can then like cool. I think we're we're hitting the right track when we can build what because Next is I mean really Next is just the most complex Webpack plugin ever created and that's Nex.js with some server

thrown in there, but it's essentially like you know the goat of build plugin uh out there. So it was the perfect test case. Um so yeah, so anyway, we kind of built that then shelved it for a little while. We a few people after the RS Next thing went out, I think a couple people from Versell kind of reached out. like,

"Hey, what's your plans with this thing?" And we're like, it was just kind of like mostly for testing. Like, we wanted to see if it would work and it did work. So, that was the end of it. Um, and you know, we they would ask like if you know, would you consider upstreaming this because it'd be great to like have, you know, another option? And hey, I think a big challenge Next has is they're not necessarily closed off to like other options being presented. The problem is like people

aren't just on tap who can just you know quickly drop out a new like just you know a brisk replacement of Nex.js's whole build infrastructure with something else. So I don't really think it's been a case of like oh well next is really closed off. It's just well how many groups are out there who are just going to like well one know how to do it or what to do and like two like you know just it's it's complicated to do like so so uh so so yeah when we had something that was partially working we started the conversations with them and you know it kind of like died out and came back and died out and came back a little bit over time. Um, and I think ultimately like what we had found is there would be really nice symbiosis here because regardless of if like there's if turbo competes with RS pack or you know whatever like the problems that RSpack faces that so like a lot of stuff at bite dance is built inhouse and the main reason is because when we run into a problem there's nobody we need to ask from the outside. So, oh, you know, and that can get a little crazy like you let's, you know, build our own JavaScript runtime, but ultimately if the business needs a problem solved, you don't have like there's no no, it's yes, we have everything we need. Um, so, but that

said, there's still open source stuff we depend on. And so, like a really big one for us is SWC. So if and that's one that is hard to get access to because it's largely like time like KDY is like the main guy behind it and if KDY doesn't have capacity to do it we can't like then it doesn't matter how many PRs you send in like you can't like help coordinate with the author and cool how can we like utilize a mix of manpower and what did you want to do here and then like combine to try and like solve some of these issues. So we identified there's lots of like common shared foundations in general that even if there is turbo pack here like if RS pack is currently impacted by an issue in SWC we know Turboac will be as well and beyond like competing in the open source because again like we don't have too much skin in the game in terms of like like you know we don't like we don't need anything from these tools there are side effects of we have our own problems to solve and by solving ours they mostly work for everybody else so here's a copy of Um but so so I think what was interesting is like okay well we one really admire Turbo Pac's work like I still am a big fan of Tobias and think the guy's you know like really next level on bundler design and I think a lot of my teammates would agree that yeah he's you know like the epitome of building bundlers. So the oper so I think it was just like a really good opportunity of well one we do admire the work that they're doing over there um the guy behind it obviously we're very happy with his prior art since we built our version off his like you know design so it seem this would be really help you know essentially how does this become like a rising tide lift all boats we're happy to pass more of next test and try to get this thing into an upstreamable position um if like there's is if we can also have a greater impact that solves some common problems we're having. So,

it's kind of like, okay, well, we don't really use the next plugin, but it would be really great for RS TAC to be able to prove that it can build that. Obviously, you know, that's a getting a kind of like a, you know, informal blessing, you know, on hey, RSpack's good enough to we'll let it run on here, you know, I think was a big milestone for the project just to hit. But I think as well like you know one of my colleagues had said that like regardless of any competition that might be between the two build tools the fundamental layers are there's so much more value to drive out of working together to fix those even if we are never like even if we're at odds with like the topend build tool like if you know it comes down to like an example was FBD used to have a kernel panic when you would have a chunk over 100 megs. Now, that's probably not a case a lot of people run into, but when you run into it, you know, you're kind of dead in the water. And so, these were kind of things where we' like, okay, well, we'd love to be able to fix this, but we need to kind of be able to collaborate a bit more. And so, I think this just created a really good atmosphere where, yeah, we don't, you know, we're happy to kind of help upstream upstream this back in. I think

it would be great for the project, but we'd also love to like not just, you know, take the RS Next stuff, kind of sync a bunch of manpower into it just to get it onto Nex.js, like you know, again, we don't use it, so there's really not much use for us, but we doesn't mean we wouldn't have loved to see it get in there. And also the way that it's done is really great. But I think I think the the the next RS pack is really just kind of like a nice gateway piece of like cool through this we can now like you know it it's we now are supported next 15.3 and I think like the main thing is but we are going to be working on shared problems that impact us both. So like some big ones already I

would say largely around SWC again. Uh I think since the past few months that we've been like collaborating, we've seen the like performance improve like just various like reliability and performance improvements of SWC like significantly like improve essentially and that's exactly what we want is uh you know if we know how to write the Rust code and you know what you want it done then perfect is there a way that we can kind of work together on some of these things. So really but you know I think that that's That's primarily how it came around is like, hey, would you be could we upstream this? Think it'd be a great like community option. I think like the motivation behind it as well is just you you have a situation where there's everybody who wants to go and use Turboac, but a lot of the people who are on Webpack are usually the big like you know whoever's stuck on a Webpack build is going to be somebody who's worth like a lot of money like companywise because it means that they've created this massive monster and it's not something that you can just rip out in a couple days and pop something new in. So if you're really coupled to these build solutions, I feel like in next it was also challenging because you don't have an option. Turboac gets all

the love. It's it's getting all the speed and Webpack can't get any quicker and so those users just don't get brought along. So it kind of is counterintuitive to versel to like to connect good DX thing that it tries to promote is like hey it's nice to work with but then it's like oh well it's nice to work with only if you're in the club but the webpack can't be fixed so your best move is to move to Webpack and that's not a very nice thing to hear from like someone who relies on it. So, I think this was a really good way where it's like, cool, people who can't migrate yet. Perfect. Hey, and if you prefer the Webpack style convention, like maybe you want federation or things like that, here's a solution that at least now is going to be like fast or comparably fast to what you could you could get. Um, so yeah, you know, I think it really throws a lifeline to anybody who can't move. They can now get

a nice DX improvement. we get a lot more, you know, eyeballs looking at it and obviously we get like the best battle test that we could want, which is against uh next spells. Yeah, it's cool to see more and more like shared foundations popping up between these projects. It uh it just lifts all the projects up. I think I think the the the the big the big thing there is like it's there's it's surprisingly few people who actually like you know that that own a lot of these libraries or something like the the the the group the the clusters of devs are really small. So it's really really helpful when there's an opportunity to like work together because you know there's there's especially in Rust compared to JavaScript it doesn't feel like you have the same like vast JS devs everywhere like when you go to conferences and stuff like that like Rust isn't quite there yet. So I do think it's probably

best for those working in the language to try and work together if you're solving a shared issue because really there's not as much manpower to stretch like you would have on npm. So uh before we wrap up I think we should touch on a new project from bite dance links. Uh it looks like it's a react native uh competitor. I think I saw some CSS in the docs. So could you explain to us what it is and like is it like a native renderer? Is it like a web-based thing? What's going on there? Yeah. So Lynx is quite quite interesting. So So it was so

originally it was built at Bite Dance and then Tik Tok is the one who's essentially the funer and the like main open sourcer of it um currently. Um and I think the reason that we have links is so so I guess one scenario is like remember when Facebook wrote React and what was their first use case? It was the like button. They wanted to swap out a like button in in PHP somewhere. Now I

believe that that is essentially kind of like what how how we like the reason that we use something like links was okay well we have a component that's maybe not worth writing in Swift or C and bringing in React Native is to it is potentially like too much overkill for this thing. So we need a a a lightweight solution that's that's relatively low friction. And then a big thing here is like everything here is web. Like it all

is looks web or is kind of you know how do you make the web type experience show up in things that aren't necessarily normal web. Um because I think in China everything's a lot more client side rendered. So there's a lot more mentality around okay this is like how we kind of work. Um but it also just makes it familiar. So so yeah so link

some some things that were okay. So the first thing is so links is actually agnostic. So it's not it's not like React Native but it has React links which is essentially bindings to links that give you JSX and or so I think under the hood it's technically using Pact but essentially you know here's like the lightweight React like bindings to this but you could also do it with speld I think you could do it to Vue as well and then I know I just saw they announced they're working on a vanilla one where hey you don't need any kind of UI framework and you could just use vanillajs. Um, so like is it web kind of, but we there's a custom renderer built into it. So a similar kind of thing where we actually render it down. So things like, you know, I

think you've seen we have like really good performance on the virtual list scrolling or like doing all the weird, you know, carousel things that are easy to do on web but really hard to do in native. Like a lot of that stuff is also kind of baked into it. Um, but yeah, like even when you so when you style CSS, I believe that is converted. Yeah,

that gets converted into like the native equivalent. So it'd be the same as like, you know, I've never used much of React Native, so I don't know much of the the styling semantics of it, but essentially it's saying, okay, read this from your CSS and make that happen and create the the final like rendered element style correctly. We don't support all CSS selectors obviously, but we need to support like a wide range of them. But I think ultimately the the the

thing that we were after was we need a you know a native solution that's fast, that's lightweight that we can sprinkle into views that don't need all the effort or all like the hard work that goes into like making say the mainline experience. So, um, you know, I think like on Tik Tok they were saying like the Tik Tok app is native, but the Tik Tok shop is links or something like that. I'm not sure if it was the shop. Maybe it's the studio. I have to go back and read the blog post. I don't I don't work uh on Tik Tok. I don't work for Tik Toks. I don't actually know. But

essentially, it's this idea of you have things that need to run super super well and you'll write those in native code. And then you have other things that are like it's not you don't need that much out of them where a good kind of native but web feeling solution would be perfect to inject these things like banners or certain pages that are you know out in the flow but maybe your main video scroller keep that and see. Um, so I think that was a lot of like what it was used for, like surgical ways to, you know, make a app, you know, have more features in app without necessarily, um, having to commit to like the whole like a all ornone type of scenario. Um,

so yeah, so I think that was kind of like some of the main reasons that that we that we had done it was it was it was very like tactic like, you know, surgically inside of existing apps. We needed something that worked crossplatform because we have to deal with like a lot more devices as well. So, um, so we wanted, you know, something that truly worked on everything because we have so many like hard part I think, you know, we even have like Pico, which is like VR headsets and stuff like that. So, when you're thinking about I need a crossplatform solution, the potential of the platforms you're up for consideration are beyond just like, oh, well, it needs to work on like a phone and a desktop or something.

Um, so I think that's where a lot of it came in. Now, it is still like in its early days and all of that, but it has been really exciting to see like what they're doing. And I'm, you know, I think they would love to collaborate with like existing community like I'm sure they would love to collaborate with like React Native Group and stuff like that on, you know, similar kind of thing. Hey, is there any kind of shared foundations that could be, you know, could be helpful to lift native app dev in general? But, you know, that's I don't know if you had any other specific questions in there. I kind of got off on a tangent, but you know, that was generally what Lynx was like done brought to do in its current form is like drop in there. What I would love to

see is something like a router. I think that's like a missing part, but I also understand like why it's a missing part cuz we're not like making your your normal like router app where it's hey everything is React Native and it's all expo or whatever. It's more like we have a app that's built for this purpose but this thing doesn't need to be in the same language because it's not as missionrit like the manpower to write it and see isn't necessary. we could do it better if we wrote it in a more web friendly language. And then that's also a lot more portable across a variety of platforms. Cool. Well, it sounds like

you guys are working on just so many different cool things. Like we're out of time now, but uh we didn't even talk about all the different RS family members and all the different like permutations that you guys have come out with. Uh so it's exciting to watch from the outside looking in. Uh and thank you for building all these tools and for coming on. Yeah. Yeah, it was great. It

was great to come on and chat. Yeah, thanks again, Zach, for coming on. Uh, it was awesome last time to talk you to you about all the model module federation work you've been doing and great this time to to catch up on what this the current state of RSpec is. Uh, it's cool that you're breathing new life into the Webpack ecosystem. It's such an

important ecosystem and it's such a broad ecosystem. So, it's great to see. It's something that you you don't want to see die just because like times have changed. And that was a big thing like it would be really nice to just keep it alive because there's so many good things on there. It just needs to run quicker. Um I would say like I know we didn't get to the rstack stuff, but I think like in general what we're just planning to do with our thing with with what we've got is like okay as you can see we're bringing out a lot of pillars of the infrastructure that we would need. You know that we're going to be

bringing out tests. We already brought out library builds like you know unbundled treehakable npm package builds. We have RS build which is the recommended way to use it which is essentially RV if you were to say RS packs the build engine and RS builds the Vit of the world. Um but you know I

think probably a lot of this is going to be how do we fill out that ecosystem to provide kind of because this is from our own internal in unified infrastructure kind of approach for everything. it just makes sense to build like this. But I think also it's something I would greatly appreciate in the in the open source space to say, "Hey, here's like a full suite of tools that I don't have to buy into all or none, but if I do want more, they're happen like you know that it's designed to work together." And I think that's something we still struggle with in like ecosystem is the pieces can be glued together, but it's not necessarily like one

2025-04-24 18:16

Other news