Paul: Hi there and welcome to PodRocket. I'm your host, Paul. And today we have Jared Palmer with us. So, Jared is the founder of Turborepo, and a team lead at Vercel. Welcome to the show, Jared. Jared: Hey there, how's it going? Happy to be here. Paul: Awesome. We're happy to have you on today. We're going to be talking about Turborepo, the thing you made, and we're going to be talking in general about monorepos and some of the workspace management and hygiene that we may practice as developers when we're building applications. So you founded Turborepo, created it. When did that happen? How long ago? How long has it been? Jared: I guess it's been about a year and a half or so maybe a little bit longer than that. I was working on another project at the time, and I was really frustrated by how long it was taking to deploy this application that I was building or several applications that I was building on a project. And on top of that, I had an open-source project called TSDX, which is kind of like the create-react-app, but of, instead of it being for like an application it's for a TypeScript package. So if you've got a TypeScript NPM package that you want, if you were to do like TSDX create, it would generate this best practices, boiler plate slash CLI to do build and test and lint. And there's a getup issue raised to have TSDX for monorepos and these two sorts of forces combined into what ultimately became Turbo. And yeah, it's been really fun ever since. Paul: So Turborepo's some tool, some CLI sort of set of packages to create, support, manage monorepos. Is there anything we would tack onto that to...? Jared: Yeah, so I'd say that Turborepo is a monorepo build system and orchestrator. The Genesis of this was I was very frustrated, as I mentioned with my deploy times. And I looked and I was working on a bunch of learner projects learn as another one of these tools. And what I realized was that this was the root of the issue in order to reduce my deployment times. The actually, it wasn't about making things necessarily faster or just making them smarter. And so instead of always, let's say rebuilding the entire code base, or always redeploying something on every single change, the idea of Turbo is to do things more incrementally and only do what's necessary. And I got there by, at first looking at well, hmm, can I like kind of merge TSDX and learn it together. And I was reading, learn a source code and realized that, this may not be the most efficient way of doing this. Jared: I wonder how this actually gets done by the biggest companies in the world, like what are they using? I did some research. I went down this rabbit hole of build systems and learned that the way that Google and Facebook build tests and deploy their code is vastly different from the way we normally do it in the front-end ecosystem. And a lot of the techniques that they are they've pioneered and been using just haven't made their way to the mainstream yet. And so Turbo is an attempt to take a lot of the best practices and ideas of some of these more sophisticated build systems and bring them to the masses. And in that sense, it does three things that are crucially important. Jared: It does caching. So it can remember what it's done before. It can do scheduling. So you can orchestrate the tasks you run in the order in which they run explicitly, and it can do incremental execution. So it can under look at your get history and figure out actually what's changed and what's impacted. So these like three things together can reduce build times by roughly 50 to 85% with really really in Turbo's situation, a very limited amount of configuration. Paul: So, I mean, I first came into this podcast, presenting Turborepos from a monorepo sort of use case scenario and an example here, but realistically like Turborepo is taking best practices about how to arbitrarily build these sorts of projects and improving it from all fronts. It doesn't necessarily have to be monstrous monorepo to see improvements and yield those benefits. Jared: Yeah, exactly. So we do have some constraints on, so right now Turbo works with Yarn Workspaces, PNPM Workspaces, and NPM Workspaces. It doesn't actually install packages. It's just orchestrating your tasks and your package dot JSON scripts far more efficiently than you probably are used to. And this is very powerful because it means it's almost compatible. It's compatible with a vast number of existing code bases. And so it's very easy to incrementally adopt Turborepo. It's actually a design goal versus other sophisticated build systems like Google's and Facebook's, by the way, which are both open-source projects. Google's is called, sorry, Bazel and Facebook's is called Buck. And these build systems are great, especially if you're doing like C++ or Golang or Java or Rust or Python, they're great for these compiled languages, but they're not as awesome for JavaScript and TypeScript. Paul: Why is that? Jared: It has to do with just like some of the quirks in the NPM ecosystem. And on top of that, I'll say just age so and complexity. So JavaScript was a compiled language, I'll say compiled, but like transpiled whatever you want to call it is relatively new, right? It's only a couple years old. That being said, the other thing is that these tools use a config language called Skylark, which is a restricted subset of Python. And so the average JavaScript developer doesn't really know Python or maybe doesn't really know Python. And so, the idea of like configuring what are called build rules, or like these presets for these different build systems in Python, and then also having JavaScript and also having TypeScript, also having your meta-framework or whatever this is, you're just like adding layers and layers of complexity. Jared: And it's just too much, in my opinion. And I've talked to hundreds of companies and even the companies that have went down the Bazel path, they're not necessarily happy with it. On top of that, these systems make constraints on your code base. The biggest one is what is known as like hermiticity. And that is to make sure that builds are reproducible, and they force you to create a... they have a sandbox. And so you must declare like all of your native dependencies and you must sort of change and alter your code base in a way that just doesn't jive with the way that most teams work in the front-end full stack space. Jared: And so these, this combination of like a little bit extra complexity or a lot of extra complexity, and then also the hermiticity constraints and sandboxing constraints just make it like kind of hard to work with. That being said, Bazel is used by very large companies like Etsy and Uber, and some of the biggest, tier-one tech companies. The goal of Turbo is to take a lot of the Bazel ideas and the Buck ideas and like reimagine them to be as close to zero config as possible and be as compatible with as many front-end code bases in full stack code bases as possible. Paul: Right. Because I was going to ask like these build systems, even though they might be great and they really bring you to whatever destination you might want to go eventually, there there's a certain opportunity cost about actually following one of those paradigms or implementing one of those build systems. And it sounds like Turbos really made for everybody. It's made for anybody wanting to improve upon the way they do it. So yeah. So would you, yeah, you would say it takes those, it makes it zero config and it says, listen, that time sync it's gone, you should check this out no matter what, just for your own sake and organization. Jared: Yeah. So even if it's not like, so even if Turbo isn't going to necessarily cut your build times because of the way that your code base is set up, it's not a guarantee, but it's often it will, you'll still benefit from its orchestration layer and the way it can run tasks and collapse waterfalls. So instead of something like Yarn Workspaces or PNPM Workspaces out of the box, when you run like Yarn Workspaces run something, it's going to run that in dependency first order. And- Paul: Which could be a pain. Jared: Well, no, I mean you to right, but there's actually ways if you're going to run two commands and you know you're going to run two commands back to back, like you're going to run test and or build and then test or something like that, right? You're actually kind of wasting some idle CPU time because knowing the dependency graph and knowing you're going to run two commands, you can start testing when it, the dependencies have been built and continue building at the same time. So what Turbo can do is actually run multiple commands at the same time and sort of collapse these waterfalls, which reduces idle CPU time. And that is a small material, but useful boost in overall build time. So it runs this stuff at maximum concurrency on top of that, where Turbo will improve upon just your base workspace is Turbo does caching. Jared: And so if Turbo has run a task before, and by I say task, I mean a package dot JSON script. Turbo can actually remember the outputs of that command. And the way that works is it looks at your source code. It statically analyzes it, looks at your dependency graph, statically analyzes that, and it creates a fingerprint of the state of the code base. And then it records the logs, and it then records the outputs that you've specified for that task. And then it keeps it in its cache. Jared: And whenever it runs a task, it actually checks the cache locally to disk first. And it will look for that fingerprint. And if that fingerprint exists, it actually doesn't even rerun the command, because it knows it's done it before. So what it does is it takes it, the outputs of that, whether those be like CSS or Java or whatever, the outputted files were and the logs, and it moves the output, it files back into the correct position and replays the logs instantaneously. And it does it in a matter of milliseconds. And so you can dramatically reduce your build time, test time, check, time, whatever the tasks are, you're running through this technique. And even cooler than that is this cache doesn't just live on your own machine. It can actually be shared across your entire team and your CI through a technique that Turbo calls remote caching. Paul: So you could really use this to speed up your local development as well. Because I know I'm always hammering make test and all that, right? Jared: Yeah. So Make is cool. Make is actually a great build system. It works a little differently than Turbo. Make looks at the modification time of the specified input files. And if the mod time of the file or folder is the same, it doesn't do anything. Which is- Paul: Interesting. Jared: Yeah. So it's called the dirty bit technique and it works really well. The problem with Make is that it doesn't have a memory. So you can do that once. And it just checks if it's done it before and then it can skip. But if you do something, make a change, do something again, make a change. And you like Apple Z twice, right? You know it'll build it again because it's just looking at the mod time. It's not smarter than that. With Turbo, its memory is unbounded. It can remember everything it's ever done, especially if you've connected to a remote cache, it's almost like a Dropbox for it's cache. And so if you hit Apple Z, Turbo still be instantaneous. And that's really useful because when you talk about sharing and cutting down, build times across machines, whether that be CI or your other teammates, you go into a multiplayer mode, which is far better than single player mode. If that makes sense. Faster with friends as we like to say at Turbo. Paul: Could this reasonably also say improve my build time on a get action? If I had a remote cache and I point there I'm like, all right, just spend 10th of the time building it, because it's only 10% build like changed right? Jared: Yeah. Exactly. That's exactly it. So it could be in, yeah, it could be, get actions could be it on Vercel it could be on AWS could be wherever it could be in a Docker container. And as you know, like Docker doesn't have you, can't like, you're not going to boot this cache the volume there. So I think remote cache can just use the parts of the last Docker build that you can in the current Docker build for given application. So it's a very powerful technique and Turborepo makes it zero config. Paul: Now is this what we would refer to as incremental builds as we have pieces that are built, remembered, and then recalled upon? Jared: Yeah, the term incremental builds, I think is a little bit, it can sort of mean two things. It can either mean this type of caching or it could also mean because you're only going to execute the work that hasn't been done before, or it could also mean that you're looking at the get history, and you're only going to strictly look at the packages or applications that are impacted by a change. So their sort of like build what matters and never recompute work. Those are the two concepts right. So to sort like when you say incrementally, you're like, are you talking about build what matters or are you talking about never recompute work, they're sort of both related and they're both necessary to hit that peak performance. Paul: So you mentioned, Turborepo. It's not just a monorepo save all. It's not Lerna? What do you use? Like besides there being all these additional features, do you think that Turborepo could replace what Lerna is for many teams in terms of repo management and how do they differ on that front, on the repo monitor? Jared: Sure. So Lerna is a... Lerna is probably the first workspace manager. In fact, it influenced the design of the workspaces that you now see in a lot of the package managers, and Lerna was great for large amount of time. It didn't have caching until very maybe recently. I don't know, like some beta maybe I think I've seen some caching stuff done, but Lerna doesn't have caching at the moment in its stable branch. And then... So when you make a change in a Lerna repository and you run, Lerna run build, it's just going to build everything. It doesn't understand like what it's done before. Next, Lerna, however, has other features that Turbo doesn't have. So Lerna can do publishing. So Lerna is oftentimes seen in like a design system or like a framework to do into additionally like version bump and publish packages to NPM. Jared: Now Turbo could do this if we wanted to enter the space and make a solution for that. And we might, but for now we don't because there's actually a lot of other systems that can do publishing and versioning if you need to even do versioning and publishing. And I say that because in certain types of monorepos, you don't even need versions for things. If you are building a bunch of apps and you have some shared packages with these applications and it's kind of self-contained, you don't need versions. You should just keep, your get hash is your version. If that makes sense, everything is atomic. And at latest, if you are publishing stuff to NPM, then yeah, you need version control and need version bumping, sorry, not version control, you need version management. Jared: And the reason that I didn't build this into Turbo is because I actually like an existing solution so much, and the Turbo's fully compatible with it, that it wasn't even worth building. So the solution that I really like is called, is from Atlassian. It's called Changesets. And it's a wonderful versioning tool. And as an OSS maintainer myself, I've used it on multiple projects and Turbo is completely compatible with it. So you can completely replace Lerna with Turbo and Changesets. And I argue, It's a... I think it's a better workflow because you it's actually fully automated. Change sets has a get up action and also a GitHub bot that will automatically set up PRs for you and generate change logs for you and then even publish to NPM for you on merge. So you don't, there's no like it's like designed to be a 100% automated. Jared: So I really like have been sort of leaning towards folks to do that. We might add it to Turbo, but for now we're not, you can also still keep Lerna around by the way and add Turbo to your Lerna monorepo and keep both and use Lerna for publishing and maybe some tasks. And again, Turbo's designed to be incrementally adopted so you can add it to your Lerna monorepo and start moving stuff to Turbo, task by task and then ultimately yeah, keeping Lerna around for publishing. If you want to, if you need to publish and use Turbo for task for like orchestration and task running. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple podcasts so we can continue to bring you conversations with great devs like Evan Hughes and Rich Harris. In return we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Paul: When you talked about moving things from Lerna over to Turbo, what is like the smallest possible way? Like let's say I have an existing project and I wanted to start to introduce the Turborepo paradigm into my workflow. What's the smallest first step I can take to start doing that. But would you say just make a new one? Jared: No. Keep your same setup. So what you'd want to do is look for those uses of like Lerna run, pick one of them, let's say it's Lint and let's say you have like a Lerna run Lint or you have... maybe Lint's not the best because sometimes Lint has run a pre-commit hook, but let's pretend that it's like test right. Lerna, run test. So what you would do is you create a Turbo dot JSON file and you'd add a key for your pipeline, and your pipeline defines something that's nuanced to Turbo that is extends Lerna's functionality or goes beyond what Lerna can do. And you define a Lint key and you define that the task has maybe no dependencies and it would not have any outputs just to logs. And when I say by dependencies, what a pipeline is it's actually a declaration of the relationships between your package dot JSON scripts. Jared: So that's actually like a new dimension. It's not so Turbo can look at the dependency graph like what's in the dependencies and dev dependencies package dot JSON, but then it actually, adds another like dimension to your monorepo. That is the relationship between your package dot JSON scripts. And you define these by convention, if that makes sense. So you can say Lint a package is Lint command. I'm just making this up. Depends on make maybe like depends on its prepare command. Or you could say a packages test command depends on its dependencies, build commands, being done first, which is often the case, right? You want to make sure you only run a test if it's dependencies are built, because it, maybe it uses those dependencies and tests. Conversely, you could say something like a packages test command depends on its dependencies being built and its own build command being first built, being first completed. Jared: So maybe you want to test the build version of something, and you can express that rather easily. The other use case of the pipeline is to define the outputs of a given task by convention. And you'd use that with globs. So for let's just take a Next JS app, for example, you've got a Next JS app and maybe you've got like TypeScript package as well. You could say that, okay my build commands depend on their dependencies, build commands completing, and they're going to either generate outputs to a dot next folder or like a disk folder. And you can just say that. And now Turbo has complete information about running commands in the correct order and potentially running multiple commands at the same time. So, and crossing those boundaries. So instead of what Lerna will do, which, or PNPM or Yarn or NPM will do, which is run stuff just in dependency, first order, now Turbo can actually do better than that because it understands the relationship between these tasks. Jared: So if you want to... It build depends on or if test depends on build and you say Turbo run test, it will note what to build, minute, like what's necessary. If that makes sense. So back to your first question, let's add like how do we add Turbo to an existing Lerna a project. If we were to choose like Lint, we'd say, okay, our pipeline, we have a Lint command in all, in most of our packages, there's no file system outputs to a link command, right? Just going to print to the console and maybe it doesn't depend on anything because you can run ES Lint at any time. And that's it. Now you're in Turbo run Lint and you're good. Jared: And maybe replace wherever you had Lerna run Lint and same go through like Ler... And then you're good. You've adopted Turbo for your Lint command, right? And that's it. So I think that would be like three lines of code four lines of code. And so now what's funny about your link command is I know there's a team that a team of 10 on Vercel that saved over 67 days of type script type checking and ESLint checking in the month of March. Paul: So that's days, times 24 hours' worth of CPU computation. Jared: Correct. Paul: Not cheap. Jared: Well, no. Saving trees as well, right. We're reducing emission CO2 and also like saving energy, right? But yes, like that saves just raw compute time. And so if three lines of code, four lines of code, they save like 67 days of compute time. So, that's what we're talking about when I say like offering the maximum value for like the most minimal amount of work. And that actually was, they actually had a Lerna monorepo. So this is exactly the situation that we just described. Paul: That's a wild saving that's a night and day type of thing. So like what about this parallel execution thing that's going on? How do you do that? How do you orchestrate it? How do you know how much room you have or what technologies do you use to carry out this faster parallelized way of managing things? Jared: Sure. So a lot of it goes into the graph analysis and looking at that pipeline definition, and then fanning that out, given the dependency graph. So there's two graphs that we think about internally and this is in Turbo internals, the end user doesn't care about this, or need to think about it, but there's two graphs. So first we look at the dependency graph and we look at, we read all the package dot JSONs. We look at the internal dependencies and the external dependencies and we make a graph. And what I mean by graph is not like, an X, Y like not like grid, paper, I mean like social network type of graph, like with edges and nodes. And we create this graph and it's directed, and it's actually a cyclic, which means that there's no like cycles. Jared: So if you were to draw arrows between all the points, there'd be no circles. There'd be no loops. So that's called a directed acyclic graph. And this is a very well understood like space and mathematics. And there are a lot of tools to create these graphs and traverse these graphs, and Turbo has its own graph construction, and then traversal system. And Turbo's graph, that's like, so it creates this, what we call the topological graph, which is the dependency graph. And then we also take the pipeline definition, which again describes the relationship between your package dot JSON scripts, very concisely. Jared: And then we take the, that the dependency graph. And then we take this pipeline definition and we create a new graph, which we call the task graph or pipeline. And that graph is contains all of the package dot JSON scripts, and each one of their dependencies on other scripts. So it's more involved than just like going to every package and running build, right? Because build, maybe depend on test or whatever you've described in your pipeline. We now construct this final task graph. Then we will make sure it's like sorted topologically, a dependency first order. And then we walk it and we do that asynchronously, Turbo's written in Golang and we use goroutines to walk at maximum parallelism. And it's very similar to Terraforms like traversal of its graph, if you're familiar with that tool. Paul: Yes. I used to use a good amount of Terraform, it was better the worst, the focus of what I did for a while. So does Terraform also run on Go underneath? I actually, didn't know. Jared: Yeah. Terraforms are in Go as well. Yeah. So it's dag library is similar to Turbo's dag library. There's some slight modifications because, but they're very similar. Paul: Gotcha. So we run on Golang underneath, use Go routines. I mean, those are pretty magical. You got to love how easy they are to kind of wrap your head around and not mess up as long as you do a few things, but compared to other asyncs, those are easier to work with. So now you're at Vercel, you've been acquired by Vercel. Can you tell us a little bit about that because what was Vercel's motivation for really getting involved in Turborepo? Does Vercel like want to play with the other big tech players out there and say like, "We have a really good build system that like, we're working on with the lead developer or was it more of like an internal marrying of projects that's going on." Jared: That's a good question. So the way it went down was I was going to... so Turborepo was closed-source at first and we were offering the command-line interface. You could do download from NPM, but the command-line interface, but it was closed-source and a remote cache service. That would be zero config. So instead of you having basically like that Dropbox, I was mentioning earlier, so you can share your build cache with your friends and teammates and CI. And we had, some grand plans to build some awesome stuff. And I was going to raise a seed round from some venture capitalists and Guillermo the CEO of Vercel has been a mentor mine for many years and he was going to be an angel investor in Turborepo the company. As it came down to finally like close that round, Guillermo and I had a conversation, he was like, why don't you come and build it at Vercel? Jared: And after some rounds of negotiation, we worked it out and then Vercel acquired Turbo and then we incubated it and integrated it into Vercel. And now Vercel has a remote cache that it offers and it's in beta right now, but it's going to be generally available on June 1st. And it is the default now for Turbo. So if you run... if you enable remote caching, which you don't have to enable just as an aside, but if you do enable it to Vercel is the default remote cache provider. You can log into your Vercel account and boom, all of a sudden you have this Dropbox like system for your Turborepo code base. Jared: And then Turborepo internally at Vercel is we use it on a lot of projects. It powers a lot of our monorepos in Vercel. And we're actually probably going to be investing further in Turbo in the sense internally by Berkshire moving to a larger monorepo all in the backbone of Turbo powering that system. And then since then sort of like Vercel's vision with Turbo is that, so Vercel is all about making the web faster, right? And that's one component of it and Next JS and Svelte and all of the technologies and the platform itself, it's open-source, its platform are all about doing that part of that journey, making the web faster is deployment and build. Jared: And so Turbo is, we like to joke it's about making ship happen. Like how do we enhance developer velocity and Guillermo and I agree that when you enhance developer velocity, you enhance creativity and productivity and wonderful things happen and developers make better products. And so Turbo thus aligns like really nicely into the Vercel ecosystem where Next JS or Svelte kit may be the best way of building a website and Turborepo ideally is the best way to build a code base. And so it's just two sides of the same... It's just two different aspects of the same end goal, which is, offer the ultimate developer experience. Paul: Do you think that anybody starting a Next JS project with create-next-app, NPX create-next-app should immediately look at Turborepo? Jared: I think it depends on the project. A lot of solo developers actually do now start their projects monorepo first, if that makes sense, because they know that they may have multiple applications. They know that they may have maybe an iOS app, or an expo app, a react native app. They know that they may have, they may want to separate their like, I don't know their docs from their blog, from their main application. And Next JS is great at that already, by the way, like if you use Vercel, it's very easy to like proxy these things back and forth. But at the same time, maybe you have a CLI as well, like you've got different stuff. So some solo devs go monorepo first personally, I do that on, on almost all my projects now, but if you can stay in a single Next JS app and build your whole application as one Next JS app and you don't need to have a monorepo that's awesome. Jared: Like I don't, I'm not suggesting the complexity if it makes sense, but if you do need to, if you are working on, either you want to get ahead of this or you want to work this way from the beginning and you think that you're going to need this type of multi-application, multi target code base, there's no better way to start than just like create-turbo, NPX create-turbo and Go. And it gives you two Next JS apps by the way out by out of the box and a shared UI kit. So, you can start it in best practices anyways. Yeah. Paul: Our magic command here is NPX create-turbo? Jared: Create dash turbo. Paul: Create dash turbo. All right, everybody, you heard it NPX create dash turbo. That's the new thing to do. So, what do you, what's next? Like, is there anything you're looking at from your chair and thinking, wow, that's a good win. Jared: Yeah. So, we're always working on performance. We're really... Turbo was initially designed for CI/CD environments. And now we're actually refocusing our efforts on local development too. So we're working on a background Daemon. And this background Daemon will sort of boot up when you install Turbo locally and it'll sit in the background and shut itself down. You don't have to worry about it consuming resources, but what its job is to look at the code base and do all the work that Turbo is already doing. But instead of doing it, when you run Turbo thing, Turbo, whatever run build, it's going to run it ahead of time or do as much as it can do ahead of time. So that the next time you run Turbo as much work has already been done before it's even it's even faster. And then also it'll be responsible for managing your cache asynchronously. Jared: So instead of waiting to upload stuff to your remote cache, because we have this other process, the main Turbo CLI can just be like, oh yeah, we're going to go cache these things when you have a moment, but we're going to stop whatever we're doing. When you have a moment, here's go stuff to go upload that stuff and download that stuff to cache. And so there's just like some cache management stuff that we'll be working on that again, it'll just make local development even faster because you're not blocking. It won't have massive changes to the... you're, ultimately if you're just using Turbo and CI or like, it's not going to make a huge difference, but it will make that local development experience a lot, a lot cleaner. Jared: We're also working on presets, which will be like, instead of having to manually configure everything for like Next JS or, TypeScript. And we're just going to have sort of premade presets, that'll be installable and runable so that you just have to do even less configuration and you'll be able to write your own as well. So those are things that'll probably come out this summer or by probably maybe the time this podcast gets published, they'll be out. Some of them will be, but yeah, it's, that's what we're working on in the near term. Paul: One thing that I just love about Vercel in general and it's, I mean, it sounds like your branch right here, Turborepo is really embodying these values is like there being a way to really quickly and automatically get going, but you can always drill down and affect these custom parameters. They just have a very good way of determining this balance for developers. At least I found using their tools, it's like really easy to get up and going. You realize benefits right away. And it sounds like, Turbo's like immediately the same thing. I can really download it and get going. And these performance improvements you're talking about, like the Daemon, we won't even know about it. It'll just be going and then yeah. Jared: You won't even know about it. It'll just happen in the background. It'll be all in the center. Paul: No time, so fast. Jared: Yeah. It'll just be even faster. So, that's our philosophy at Vercel is to give you good defaults, but give you also great escape patches and- Paul: Escape patch, that's a good word. Yeah. Jared: Yeah. You need the escape patches and you definitely, that doesn't mean you can't, you know, shoot yourself in the foot, but ideally the happiest path is good and like useful, right? I mean, I think Next is really good at this where like, I think internally, the team would like to never see Next dot config dot JS, like that shouldn't exist. Like it's almost like a smell when it happens. Like not, it's not, by the way. It's not, but like, it kind of is, it means that our defaults are like not right. If that was like a repeated thing to see, I shouldn't say Next dot config, I would say like, modify web pack stuff in Next dot, you need rewrites and stuff and redirects and all these other things, obviously like you need that and like MSS and stuff like that. Jared: But I'm talking about like, when you augment the internal config of Next, that's kind of a smell. That means that like you've moved. So same thing with Turbo. Like we want to give you the best practices by the default. We want to give you a toy. It's not a toy, but like a kind of like a toy with the battery pack included, like when you were a kid, we want to make sure the battery pack is included. So you can use the thing immediately versus, other frameworks or technologies that are like maybe fully plugin or oriented. And you need to like install these some seven or eight plug-ins to just like do what you want to do. And you need to remember which seven of those were. And maybe, and then every single version of it kind of is different. And you can't really share code because they all have different plug-ins. Like that's not great. Jared: So we're sort of against that at Vercel. So we want to get... Make sure that we give you out of the box, best practices, whatever, with quotes, but best practices and what we determine that. And then also give you an incremental adoption path and migration path to newer and better features. Like for example, Turbo's Daemon, right? That's just going to happen one day, and you're not going to care or know about it, except that Turbo's going to get way faster. Paul: And it'll be really exciting for folks when that happens. It's like, wow, my computer just got upgraded. Jared: Right. Exactly. Paul: Well, Jared we're running up on time here, but as we wrap up, do you have any resources that you'd like to point people to? Like what, what's the Turbo website? Jared: Turborepo.org. Paul: Turborepo.org. Did that have a slash between turbo and repo or is it one word? Jared: No, it's all one word. Paul: One word. Okay. Jared: Turborepo like monorepo but with Turbo. Paul: Gotcha. And any other shoutouts or other links that you'd like to direct people? Jared: Yeah, we're @Turborepo on Twitter, vercel.com. Vercel is a hosting provider. It's the best way to host full stack and front-end web applications, whether it be Next JS, Svelte, Gatsby, Remix, Create React App, Vercel is likely the platform for you. It's got to get like workflow where you make a change and can automatically see the preview of your change on a branch in matter of seconds usually, or however long it takes you to build, hopefully in the case of you're using Turbo like seconds and it's a wonderfully collaborative and amazing platform for developers. So if you're thinking about moving to, or looking at alternative providers to let's say your barebones AWS Setup, I would say that you should have a look at Vercel. That really is the ultimate developer experience. And then Turborepo is a nice compliment to that. If you're looking to build an awesome code base, that's super fast. Turborepo is probably the right place to get started. Paul: Awesome. Well, hopefully some people will get notified about this who have never heard of Turborepo and for anybody who that hasn't checked out Vercel's hosting services. Definitely, if you're looking for an easy way to make mom's website or even a bigger one, like I could... Jared: All big websites too though. Paul: Oh yeah. Even a big one. I can personally attest with. It's a good experience and definitely check it out. Jared: Yeah. Cool. Paul: Well, thank you for coming on the podcast, Jared, and hopefully we'll see you around sometime in the future to learn about the updates and what has happened since for Turborepo. Jared: Thank you so much. If you want to follow me on Twitter, I'm @jaredpalmer everywhere and @Turborepo and @Vercel, if you're interested in following along. But thanks again. I really appreciate it. Paul: Thank you. Kate: Thanks for listening to PodRocket. You can find us @PodRocketPod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.