Supper Club × Turborepo with Jared Palmer

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to syntax in this Friday's supper club, the Syntax supper club. It's our new series that we'll be doing on Friday, interviewing some of the coolest people on the web. We have an amazing guest today, Jared Palmer of Turborepo amongst many other things. My name is Scott Cholinski. I'm a developer from Denver, Colorado. With me, as always, is Wes Boss, how's it going, everybody? I'm doing great. Excited to talk about turbo repo a little bit. I had a little call with Jared

Couple weeks ago and just opened my eyes to all the awesome stuff. So I'm excited to share that with everybody else.

Yeah. I think it's gonna be really great because I I definitely playing a little bit more of a, a less informed role. You'll be playing a little bit more of an informed role. And then, of course, Jared is going to be the expert here, so I think it's gonna be really great. About that.

Cool. So let's get Going here, I know Wes has crafted a short list of questions, but, Wes, do you wanna start off with whatever you think is The best question to ask first. Yeah. So, we

talked about mono repos, I don't know, maybe 3 months ago.

It's when I move my course platform over to Monorepo, because I have, like, a back end, and then we have an admin dashboard, board and we have an API, and, like, there's there's a whole parcel thing to to compile all the react and all the CSS and all that stuff and, took a look at Turbo Repo, and we thought, okay. This this looks like a a good approach forward and implemented it.

So excited to have Jared on just to talk about it. So do you wanna give us a quick rundown of what Turborepo is, and then we'll dive into some more bigger questions?

Sure. So, Turborepo is an open source project, part of Vercel.

It's a Build system that abstracts the techniques and complex configuration needed for Most modern TypeScript and JavaScript monorepos into a single cohesive lightweight build system.

So the idea is you give enterprises or even solo developers a world class development experience without this massive maintenance cost, and it uses techniques that We're pioneered by large companies such as Google and Meta, but it makes these techniques available to the masses, and solves the problem with a lot of versatility, getting customers, developers as close to 0 configuration as possible.

And so that's my little

spiel on what is Turbo Rico. So, like, let's answer the question of, of like what it is and what it isn't right off the bat. Because I think people listening right now are being like, okay, like, is it is it a Webpack alternative? Alternative? Is it a NPM alternative? Does it replace parcel?

Yeah. So it does none of those things. Okay. It actually it does none of those things. Tell you the back story. I'll tell you where Turbo fits into your stack. Yeah. So the back story is I have a question in here, sorry, that literally says, how does this fit into my stack? So Yeah. There you go. So so so one of my open source projects is called TSDX.

And this is, If Next.

Js is like a meta framework for building websites, then TSDX would is like a meta framework for TypeScript MPM packages.

It abstract it actually came out of Formic. My my my my forms from the form library, it's sort of like build and roll up setup. Like, it's just a roll up setup, and I was like, wow.

Forex got a great development experience right now. What if I could just have this experience for all my other projects? Yeah.

And so t s d x was born, which is TypeScript and Rollup and Jest and ESLint and all that abstract into a nice CLI. And you go like t s d x create Package and boom, you've got this awesome setup ready to ready to go.

But there was an issue that someone raised for mono repo support.

And initially, this wasn't in scope for TSDX because Formic was just a single React package.

Yeah.

But now it's more than that, and I also started working on other Monterey Pos, mostly powered by Lerna and Yarn Workstations at the time.

And I work been working on couple applications, both closed source and open source too, that Had the same setup, and it just seemed like there was momentum here to kinda figure out what TSDX would feel like for mono repos or at least this architecture. Right? Even if it was a single application, Just having this, like, multipackage development experience seemed like something that made a lot of sense, especially as code bases got larger and larger and More people started working on on these projects. So, that's what Turbo is, is where it started out as. And When I went to go do that, I started looking at Lerna's source code and I started looking at a bunch of alternatives. And I asked myself, well, What's the right way to do this? And I went down this deep, dark rabbit hole of build systems and And learned how the the the biggest code bases on the planet work and how they deploy and how they build and test their code, and it's vastly different is what I found from The way that most front end teams build, test, and ship their code. You you're talking about, like, Google, Netflix, things like that? Yeah. Yeah. Yeah. Exactly. So Google has a tool internally called Blaze, which is, externally, it's open source and called Bazel, but it's a little different. And It helps Google build their multibillion line code base.

Facebook has a similar tool called Buck. They all have great names, Twitter has one called pants,

arguably the best name. Yeah. Money? Yeah. Amazing.

Yeah. I think that team actually split out. So you got Buck, you got basil. You got pants. There's another one called, please. Maybe this is great names. You're one of the highest paid people in the industry.

Yeah. Just like great names.

And and but what what what are these projects doing? So what these projects are doing is they're creating, Get technical for a second. What they're creating is a directed acyclic graph, a DAG, of tasks.

And running those tasks in some dependency first order or commonly called in, like, graph, speak topological order.

Just, like, do the dependencies first. Right? And and they're very good at this. They're like, this is, like, very well understood, And they do this with obscene amounts of speed and complexity.

And basil and buck Really, are very useful for compiled languages, like c plus plus or Java, you know, even Python or Go and really haven't made their way into the front end space for a couple of reasons.

The number one being NPM's a little different and weird compared to other, like, language ecosystems and and such. And JavaScript really has only become a compiled language in like, very recently.

So it's just new. Right? This concept of, you know, compiling TypeScript or even Babble and stuff too. Yeah. Plain JS. Right? This is new. So, all of a sudden, you have these forces at at play here. And because of how the JavaScript ecosystem has evolved with workspaces, These tools, like, don't exactly work that great. They work. If someone's gonna, you know, listen on and go, oh, there is Bazel rules Node. Js, and, yes, it's possible. Yeah. It is. But you also need to configure Bazel with Skylark, which is a subset of Python. Fun fun times. Oh my gosh. Yeah. The average dev Just doesn't have this covered, in my opinion.

Compared to the flexibility and ease of the rest of the front end stack, this part of it isn't has evolved, if that makes sense.

And so Google is a team of a 100 that works on on on Blaze.

You just the average team doesn't have this. Now the techniques though, and this is the key part, that they're using are awesome, and the goal of turbo is to bring as many of those techniques To the average solo dev, small team, big team, whatever, to the masses as possible in the, like, fewest lines of code as possible. So designed to be incrementally adopted.

And I can and those techniques, sorry to ramble a bit, are are are Okay. Got it. Biggest one is, remote caching.

And what this does, is Turbo will analyze your code base.

Each and every package .json script in your code base is the atomic unit of Turo, so that's where it really fits into your stack running scripts. That makes sense? Yeah. That was the place we had to get started first. Before we got the t s d x and presets and stuff, we had to get task running, rocking. And so that's what Turbo does. It runs task. It's an orchestrator Mhmm. At the moment. That's what I that's why I called it. At the very basic, if you've ever had

to run 2 npm scripts at the exact Same time? That's hard.

At the very basic, Turbo does an awesome job at doing things in parallel.

Yeah. So so what Turbo does is it creates this direct to a cyclic graph out of which is a fancy term for it understands your dependencies and your tasks, and It runs stuff in order. It can run stuff in parallel. And not only does it run stuff, just run your tasks better, it can remember which tasks you run before.

Mhmm. Key insight. And when it does this, it actually remembers not just the task, but the output of the task. So if you run Next. Js build, you run Next build, outputs to the .next directory. Right? All this, you know, it transpiles your JavaScript, your CSS, it preprocesses all this stuff. Right? It does all this magic.

So Instead of just, like, redoing that every single time when you run next build, what turbo can do is it can say, oh, next build, that out that outputs to the .next directory.

And for this state of the code base, let's mark this with a fingerprint, what we call a hash. Yeah. And then Turbo stores that fingerprint with its outputs and its logs.

And it does and then when you run that task again, instead of you redoing all of the work, Turbo can do the calculations, say, oh, we've been here before. Look. There's a matching fingerprint in our cache.

Cool. Let's move that into the correct position in the .next folder and, like, Either that's it or move on to the next task we have to do in your in your pipeline of of stuff.

And so this technique is very, very powerful Because not only can your cache live on your machine and you can remember the task that you've already done before, but you can go into multiplayer mode And actually sink that cache among your CI and your other teammates.

So if you or your team or your CI has ever executed a task, You can then share the results and skip the amount the agreed computation.

Mhmm. Very, very powerful. So that's, overall, this technique of caching And and incremental task running and scheduling, as we call it, Can save devs roughly 50 to 85% of compute time Oh, wow. Over the course of the month. That's awesome. Yeah. Because, like, even

even my platform.

So we put Turbo Repo on at a very basic level to understand how it works is that, like, If I'm running a build and I didn't change my CSS, but I did change my JavaScript, There's no sense in in rerunning the CSS build as part of my deployment platform or even as part of, like, your development. Like, We've all had that where you have to sort of sit on your hands and wait for,

that initial build to to get going. And in my case, It it just took a couple of minutes off the build, but that was huge for me and That's huge. Right? Difference between 30 second like, deploying I get this we get this lot, like, Well, my my deploys are 5 minutes. Right? And that's great. What if they were 30 seconds? Yeah. Please.

Yeah. That I I would love that. We are when we had a call earlier, we're joking how, like, I used to just our sync everything up and restart the process. And that was What was that? Ten second deploys, you know, and or the FTP drag and drop your file and you refresh the page and That sucker is deployed. And now we're at a spot where, like like like you've obviously talked to people that are in larger companies. Are the deploys like, Can they get into, like, 30 minutes or even more in large, usually? That that that's where I got the idea to start the company of Turbo.

So What I would what happened is I I get these calls and I I found out after I tweeted about it initially, I immediately Got a DM from the team at a very, very, like, tier one tech company, a couple banks, and I kept hearing the same story over and over again. And, Really, that that boils down to sort of 2 use user subsets. Either you've got a team that is working on a design system, and they need A learner replacement, like an orchestration replacement. They just want faster, better design system. They want workflow there. And they're it's likely a smaller it's a team inside of a large of a company. It's 1 monorepo inside of company that maybe has multiple monorepos.

The that that's, like, say, like, some set of the 20, 30% of the user base. Mhmm. The other are peep are folks that are building apps, or, like, CLIs or, like, full full like, full monorepos.

And, those teams find themselves in a very find themselves in a very tough position as they scale to 20, 30, 40 devs and beyond.

And the situation they find themselves in is their deploys start taking longer and longer and longer, and they get to that 30 minute situate like, situation rather quickly. And because of how these incremental tools and the other build tools haven't become popular, They're still on, you know, workspaces, the Yarn, PMPM, Ed PM workspaces, and they're installing all of their dependencies on every single build, And they're running all their tasks on every single build. There's no caching. There's no fingerprinting. There's no remote caching.

They are they're really struggling, and then they're looking at This decision where they either need to adopt one of these tools like Bazel or Buck, which by the way put significant constraints onto your code base, and it's not an easy, Like migration too. It's Mhmm. It's quite difficult, actually, and unique that they're like that. There are Basel Consultancies, by the way, that's sole job is to just, like, help teams move. And even if you do that, by the way, the complexity and maintenance is is is material Mhmm. Because these things are you know, you maybe do things a little bit differently.

So these teams are finding themselves, well, I need to hire these Basel consultants or I need to, like, build this in house. And so there was an opportunity to come to the market with Turbo, which is end to end solution Slap on in, like, a day and give as near to significant value In a very, very, very short amount of time, that would take their bills and and, you know, put them back into the 15 minute range or 10 minute range, which is Toi. Alright. Let's take a quick minute to talk about one of our sponsors today, which is Whiskey Web and Whatnot.

Now Whiskey Web and Whatnot is a it's a different kind of podcast. It's lighter. It's fun, and it gets To showcase some of the more human side of web developers.

Now this is one of my favorite things about certain types of podcast where you get to know the people, You get to understand them as human beings rather than just people smashing their fingers on a keyboard. Not to mention, there is whiskey And whatnot as well. So it's not just web and and whatnot. It's not just whiskey and web. It's whiskey, web, and whatnot.

Past guests include a Tom Preston Warner, Kenzie Dodds, Charlie Gerard, and, of course, the West Boss. Hey. What we gotta get me on there. I got a Whiskey Web and whatnot. Hit me up. Right? On Whiskey Web and whatnot, they discuss all sorts of things from everything from Next. Js and TypeScript to Chuck's past life as a blackjack dealer, Cincinnati chili, and the best Casseroles and, of course, whiskey. So check it out at whiskeywebandwhatnot.fm, or go ahead and just look for it in your Podcast player, it will be there. We'll also have a link in the show notes, so check it out. Whiskey web and whatnot.

Thanks so much for sponsoring this episode. Let's talk a little bit about, like, Actual real world usage adding into a project that exists. I mean, let's say you do have a, a package that There are a monorepo that's currently using workspaces, any of the flavors of workspaces, so to say. What what's The cost of adding turbo repo to something like that, not like monetary cost, obviously, but

time cost. What what are what are we looking at to add this to a project that's already Utilizing some kind of workspace. Depending it really will depend on the workspace setup, but it's possible that it would be in less time that it took you to ask the question.

But nice. Love to hear that. So so but but I will say that's it will work that way to get peak 8 will that cut your, You know, builds by 85% over the course of the month.

My guess is probably you'll need to do a little bit of of movement of things. Mostly, Turbo likes it To get those high cash hit rates that I just described or that are that result in faster and faster incremental builds, you want to Move things into packages, and you want to move dependencies kind of out of the root Or I shouldn't say out of the root. You just wanna make sure that things are well defined and and and encapsulated in packages. And, also, note that just because you have more packages, doesn't mean that your Hashing is going to be the silver bullet.

The shape of your dependency graph actually does matter.

So if you have a All of the all of these, packages I'll I'll give an example like this. Pretend you have, like, a monolithic Node. Js app, like classic Templates handlebars. Right? And you split that into 2 Node JS apps, and they always build together. Every single time you make you change 1, you always have to build the other. Splitting them didn't do anything to your build time. Right? It may it may it may solve organizational issues, which are valid and absolutely need to happen, but it was not gonna make your build time any faster. Right? So the same is true, you know, with that. Just because you split things into packages doesn't mean it's gonna Faster, especially if they all culminate in 1 final build.

So there's still benefits to turbo though around, like, orchestration and standardization that that may that may be worthwhile, but if we're talking about Pure build speed alone.

You you do need to have, like, a graph that has sort of that that will benefit from caching. Right. So oftentimes, that means the graph has, like, different leafs.

Yeah. And it's not you got This doesn't rely on this one. Everything relies on each other. Right. And so if it's just a straight line where everything does rely on each other, yes, it could help. Right? You just start later down in that line, but it really shines where you've got this, like, oh, I've got The doc site, I mean, like, Wes, in your in in your app where it's, like, we've got the admin panel. Right? And we when we don't touch the admin panel, we do not need to deploy and redeploy the admin now we're touching. Right? Like, it doesn't make any sense. So that's where it really can shine, where you have multiple sort of projects in one In in in 1 repo. And in that's in that case, we're talking like a day, a day and a half. But you can literally start using, turbo on one task in your Monorepo? Like, just get lint going or type checking going in minutes in minutes.

Yeah. My config is, Oh, 40, 50 lines.

And you simply just and at least in my case, I'm just telling it what the tasks are. Dev, build, Start test, Lynn. And then you say which one depends on which. So, like, my start depends on build.

That's beautiful because you can just run turbo start, and it knows that it has to run the build first. So you don't have to, like, orchestrate it. It orchestrates it for you. But then you also tell it what your inputs and outputs are. So, like, my inputs are my React components and my my CSS files, and my outputs are The next directory, a disk directory from my parcel builds.

And that's what I thought was really cool is that, like, I didn't have to, like, I didn't have to find a plug in for turbo.

I just told it which are the folders that come in and which are the folders that come out. And like like you said, there's some magic in it where it will fingerprint it and figure out what it needs to rerun. Right?

Yeah. Exactly. The, inputs are a new a new addition that we just added, which actually really helped because if you change, like, the readmead or something, you don't or even just You don't change a test. Why are you gonna run tests, sir? Yeah. Only if you change them, it's, like, source code related. And even,

you even told me that you can rely On environmental variables changing as well, which is pretty nifty.

Yep. Yep. Sounds like super helpful. API key changes in your environmental variable. Your code didn't Change, but the environmental variables did. So you would obviously have to rerun it because that's being in lined in, like, a template or something like that. Yeah.

Exactly. So if in the case where a lot of these modern meta frameworks, like Next. Js, for example, will inline your Yeah. Environment variables that start with next underscore public underscore.

Yep. And so you need to be careful in this situation because with Turbo, you wanna because of the way that caching works, you wanna keep your builds pure.

And what I mean by pure is the inputs yield consistent and outputs.

So for the same state of the code base, you get the same output. So just like a pure function in JavaScript. Right? Yeah. Exact exactly the same kind of no side effects. But let's be careful what is a side effect. So that being said, like, if you think about a static site with static site generation, that's actually a side effect. Right. Because depending on when you run if if okay. If you're pulling from, like, Contentful or, like, one of these, headless CMSs And you're generating static content depending on when you run that build for the same state of the code base could yield different outputs. So SSG from external CMS is actually an impure bill that's impossible to cash.

I mean, you could try to do some hacks and stuff where, But there is something data fetching that's happening that is a side effect, and so it's not cash flow. But assuming your builds are pure, The only thing you need to then care about is are you inlining environment variables, and that would make them impure. So the way you handle that is by declaring them as dependencies in turbo.

And turbo is like makes that pretty straightforward.

Mhmm. And then it can use that in its fingerprint calculation to make sure that for For the same set of environment variables, you're only gonna ship the same set of environment variables and and and encode.

So this works with Like, this doesn't replace how you define what your workspaces are, does it? Like, I'm using it with PNPM, and I'm still using PNPM workspaces.

You can use a yarn, NPM. Right? Like, you you've figured out how to make it work with all 3 of those.

Correct. Yeah. So Turbo is not trying to reinvent that part of the wheel, if that makes sense. I I've all about from from my experience with Formic, I'm all about building tools that can be incrementally adopted, and I think that's very react y. Right? React was always this incrementally adoptable thing, and I think that's super important for adoption.

And so, yeah, Turbo just works with all work spaces.

And soon, very soon, I'll even non work spaces.

Oh, cool. Just regular projects. Yeah. Awesome. And the the sharing of the cash. So how do how do you do that? Is that is that why Vercel, like, We would deem in this a Versal bought turbo. Right? And and now you've got you were saying earlier, you've got a huge team and you're working on all kinds of crazy ideas. So Yeah. You would you would need an external service to share that. Right? Yeah. So the the the

so the cache lives locally on your machine, in a folder, And the cache is content addressable, and so that means that it can it's basically hash based. And so the you can use a service that Vercel provides, called remote caching, to host that cache to you and your team and stuff.

And you you know, there are some open source community caches, but it's super easy to just server sales cache is is super easy to use. You just, it's also the default in Turborepo.

So if you run MPX turbo log in and You have a Vercel account or if you don't have a Vercel account, you can sign up for 1 right there. You're, like, 3 clicks away from getting remote caching set up, And then you can run MDX Turbo link to link it to your correct account, on Vercel, and then immediately, you have this, like, drop box almost for your for your

For your cash. Your cash. And the rest of your team can benefit from that. So, like, what I'm just trying to think of, like, like, what kinds of things are probably cash. Like, tests, Obviously, like, CSS generation, JavaScript.

But, like, is could could you could you do anything, like images, videos?

Yeah. Anything. Anything that you're supposed to do. Yeah? Yeah. Yeah. I mean, why not? The the the sort of trick to it is Logs are treated like logs or you could rewrite logs to disk to to the file system. And so even if there's no other any other file system artifact, I'll call it, that's emitted from a task. Yeah.

Turbo doesn't even know or care about the difference, so it just will catch the logs.

Actually, there's 1 team that saves, like, days. No. They've saved they've saved over 60 days. A team of 10 saved over 60 days of Tight trip, tight checking time in the month of March.

Oh my gosh.

That's insane.

And because I knew this because they're they're we, like, look at, Median log size, and our median log size was, like, 3 bytes because it was, like, type check it was, like, just 2 lines of of type check of the tag, whatever it says when types are just type checking. You can do type checking. You can do video images. You could do, ML models. You can do video encoding.

Man. You know, what whatever you want if as long as you're here, keep them pure and agree to the rules.

You can even use Turbo with, infrastructure as code providers.

So you can use Turbo with, like, the AWS CDK Or, oh, I guess, Terraform or even, like, Terraform or Pulumi to What's that? That's So you could, like, incrementally if you, like, Basically, you could deploy your AWS infrastructure incrementally only if it's changed.

Oh, infrastructure. Yeah. Yeah. Yeah. Like, you You have a config file

that defines what your infrastructure is. Correct. And and that changes that. Only redo that. Yeah. Re reapply it or whatever it is. Actually, that's one that's one of the first use cases. It was, somebody from AWS, Michael Edelman, actually started doing that, and it was super I did not intend Turbo to be incremental infrastructure as code Yeah. Coordination orchestration tool, but lo and behold,

That's what that those sneezes are there. I think I I need to get this set up. Like, have you have you talked to the folks from Gatsby All about their, like, Gatsby images ever? Because then, like, that was a huge pain point of mine where, like, the Gatsby Would they would cache the images, but, like, when you had to, like, redo it or if I had them on my computer, but then I deployed to Netlify, There's no shared cash there, so there I would have to sometimes wait, like, 25 minutes to regen all the images on my site. Have you talked to them at all about that, or that's just, like,

Just generally something that they could use No. Yeah. I mean, that's the benefit of, like, remote caching ideally solves that part of it, but even but sub but sub process, caching and stuff like that. We are working with the Next. Js and Svelte teams because they're at Vercel Yeah. On these kinds of things.

Very, very, very, we're working with the Next. Js and sell teams on on this kind of stuff. How do we share caches both in, You know, for Bill, but also maybe even for dev. And, like, how does that how does that how does that work, right, with all these with all these processing and stuff. But, yeah, it would be cool to one of the ideas would be, like, Okay. If you are image processing locally, like, do you really need to rerun that? So one one thing I I'm wondering here, so I have a PNPM monorepo

That's several salt kit packages.

Right? Anytime we we make any sort of library, internal, external, we make it into its own salt kit package. But the the pain in the workflow right now comes from if I'm working in a package, I want my root repo to Either wait for that package to complete before recompiling or what's happening right now is everything fights for a little bit, and then you hit a couple refreshes, and eventually, it's fine If you're rebuilding the package and you're running the main site. So, theoretically, is this something that Turborepo would step in to help orchestrate to say, alright. You package, Then you go. You package, then you go. Or can it not get in the way of even, like, re re rerunning compiles or anything like that? Or Is this a is this is this essentially a feature that Turborepo, would be able to step in and assist with? Eventually, yes.

I can tell you their pain points that now that exist with, like, locking and stuff that will make that a little bit more annoying than it than it should be. Turbo, To be fair, it was really designed for CI at first. I was really in addition to the TSX story, I was also very frustrated with waiting for some Fargate deploys That I could not. And when you deploy to Fargate, AWS's container service just takes, like, minutes, and there's nothing you can do about it. And I was very frustrated that So Turbo was very much designed to, like, make sure that didn't have to deploy to Fargate, when I made a change. And so it was super CI focused, and I wasn't really focused Too much on local dev, but that being said, it is something we are really going to be looking at this summer. And so Making a local dev experience awesome,

is something that is 1000% on the road map. I I noticed that, like, Just about a lot of the things you make comes from personal needs, and I think that's, like, a a big interesting aspect of all of the things you're making. Right? Whether it's TSDX came came out of the fact that Formic, had built this, you know, this structure, essentially, to To be very organized in its process. And then, that leads to essentially where you're at now. Is that always something that has been prominent in your career or These types of projects you choose, is it usually just solving your own problems?

Yeah. I mean, I think combined also with, Understanding and being able to recognize that relationship oh, this is a problem I have, but my guess is it's also a problem for a lot of other people because if I'm having it, then I guess people are happy, and that part is not that that part takes, like I mean, I now now I'm a little bit more experienced. I've done it a couple more times. But, yeah, it's all been even Formic was, We were working on a large dashboard, at my agency that I used to run, and we were the problem there was we were pretty sure that Well, we weren't 1, we weren't using Redux, so Redux form was out of the question.

And then we looked at all these, like, schema based form Libraries that existed in it too, that that didn't seem we had just so much complexity didn't make sense. So it seemed like, you know, and So, yeah, I'd say mostly out of my own like, scratching my own itch has been always, like, very useful. I think also, though, now with these prop with this problem stays at least.

There's also an aspect of it of just seeing,

where there's an acute pain point in the community. And I think that It's both my itch, but then also, I guess, everybody else's itch. That makes sense. Totally. And I it it's funny because I end up having so many of the same Problems as you've come across here. I've I've made a a Svelte form library for myself. At one point, I was working on a task orchestrator that I was calling Avalanche, oddly enough. But I did so with just, like, total dumb guy's viewpoint on it because I was just like, oh, I need to run this script in this cup. Just, You know, sync up a bunch of node scripts to try to solve these problems.

So it's it's funny that they you seem to have a good eye for Identifying what these issues are that you would imagine that everyone else is

having as well. Thank you. Yeah. I I think it's just a little bit of, like, of I'm extremely impatient, and so it's like and I just think things should be more magical and amazing. And if you If you just ask yourself, why isn't why do I have to do all this? Anybody in your day today? Why do why do I have to do this? Why why doesn't this just work? Why does this work well?

Yeah. How many

yeah. How many, like, products come back to somebody just ranting on Twitter being like, is is this it? Is this honestly it? Is this as good as it gets? Because this is garbage, and this is terrible. Like, this is garbage. And then I will say another thing too is that

saving the like, Save developers 30 minutes a day, and you will have a very, very successful thing. Whatever that thing is, if you save or really not just developers, Save anybody 30 minutes a day or Yeah. With TXDX, it's, like, saves you an afternoon of config. Yeah. Yeah. You could use Rollup, you could do it yourself, and you could, like, go search For the 5, 6 config blog post of TypeScript and Jest and ESLint. Right? But or you could run t s t x create, and you'd be done. Right? Yeah.

It's that. It's that. That is the nature of everything I try to do, which is or you could just you, you know, import formic and not have to deal with Orchestrating validation on every keystroke properly. Right? Or right. That's that's that's that's the so I like to say, like, remember as kids, you'd say you'd see, the you get toys and they'd be, like, battery pack included, and those are the best. Right. How annoying was it when you got the toy and the battery pack was not included and you didn't have batteries in the house? This was this is catastrophic at that point. I like that. Yeah. It's hard. Hard.

And so, like, whenever so ship stuff with a battery pack included, and people will love you for it.

And so that's that's more of my philosophy. It doesn't mean that, like, you need blow make this thing, like, bloated and do everything,

but it does mean that, like, there's a certain level of working out of the box. There's an elegance to it that I think people miss out on or, like, just like a they they think it works, and then that's good enough that it works. But without looking at it, how how much more simple could this process be for the user? What what can we abstract or what can we hide away

while still making the product not suffer for that. I think it's often ignored. I had that experience both with PNPM and with Turbo Because I didn't change any of my tools.

I guess, I I stopped using npm and I started using p n p m, but I didn't really have to change a whole lot Or adopt or change out anything. And it was just like I just added it on top and things got magically better. So It's a great great experience. Thank you. I I I I

this came also from I guess my question is, this came from a lot of my agency days. So I used to run a dev shop. And Yeah. I've seen so many we used to talk about whether something was a problem or a new problem or a solution.

And what I mean by that is, are you inventing a new problem or are you actually providing a a solution to something? Right. So if you had this big migration, Wes, to x y z tool, that's actually a new problem.

Yeah. That seems like it will help, but it's it's new problem entirely versus A smooth import process to switch over to PMPM and then one command to import, and you're done. And now you've got a new that's a solution my mind. So I often think about, are you creating a new problem or actually offering a solution? And the goal is to always actually offer a solution, and 9 times out of 10, that involves Some sort of migration and adoption plan that is incremental that can be done on someone's own schedule and doesn't require a whole sprint planning. Right. Like, it'd be a very different story if, Wes, if you were like, well, you know what? I'm gonna spend 2 weeks adopting and refactoring my code base to do this to use this thing that's gonna save me 5th you know, 50%, 50, 85%. Yeah. You know, you're not gonna do that. You're not gonna do that. Right? That'd be outrageous. It'd have to be so much worse than it is, like right? Or the the value would have to be that much higher, right, versus like, oh, I can just, like, move my lint command? Sweet.

Take 15 minutes. Let's do that.

So that that that's my that's my sort of take on on on,

You know, building things for adoption and and building things that for myself too. It's like and also it doesn't have to be a solution. It has to be a solution. So this is a a new part of this new kind of thing that we're doing, right, with this whole syntax of our club. And and what we've decided to do Is formulate a group of questions that are just going to be the same every episode, But I think kind of interesting questions here. So we're gonna ask you several kind of rapid fire questions. We don't have to take too long on these, But, I think they're gonna be somewhat interesting for our listeners. Wes, do you wanna start with the first one?

What computer

And keyboard do you use? I use a MacBook Air M1 maxed out, and I use the Apple Keyboard for full the full size keyboard. I've tried the whole I went down the rabbit hole during the pandemic of mechanical keyboards. Me too. Like, I got I got, like, super into I got, like, super into it, and I still, like,

think it's great. And then Like this 1?

Yeah. I used that one.

And I, like, really wanted to get, like, a Rama Works keyboard and, like, do it and do the whole thing. And then the reality is that I type faster on the Apple keyboard. I do do do do do.

And as much as I think it's awesome and they're Super stylish, and I see them all, and I want all these cool stuff. Like, I'm was materially less effective With my MX cherry. I tried browns. I tried blues.

I I I did it all. For me, it's the tech. And so what I really It's the tall He's like, I need Yes. Yes. Yes. I need I need I need low profile. Like, I'm not gonna move my fingers that much. I'm just not I don't know why, but, and I tried the Keychron, like, low profile one, which is like the but even that, like, I didn't want to admit it. I was in denial. I was like, no. This is better. This has gotta be better. This smells like it's gotta be I was, like, in the aisle, and then, like Look at it. It's hard to beat. I had I had right. I had I had some blues, the MX Blues, which are, like, really loud, And I have to switch keyboards for my turbo, like, demos, but I was getting, like, pitches and stuff because the the the blues were loud and then when I was recording podcasts, same thing, and, like, I switched back and I just, like, forgot and then realized, like, wow, like, I actually just like the Apple one better. So I really wish. So my goal my my my my wish is that, like, I could tweak my Apple an ounce to be a little cooler, but

I don't know. Yeah. That's great. Yeah. In the same way.

Alright. Next question here.

What kind of phone do you use? IPhone.

I have the Max.

Beautiful. I think I I have to say wait wait wait wait wait. I actually will say, I I have that for my personal phone and my work phone, I have the mini, The the little the little one because I carry 2 phones.

And, the work phone is the mini. I like it. It's it's, like, It's good. It's some some apps are, like, a little too small, but it's it's okay.

It's a good second, though. For someone who's never had a job, I'll ask, Why to carry 2 phones? So you can turn 1 off when you're sick of it? Or

legal reasons around the acquisition, but, basically, I keep my the devices that are Vercel or Vercel's devices are separate from Oh, okay. My my other other stuff that I work on.

Oh, okay.

That makes sense. It's because you if you come up with the the next $1,000,000 idea and you did it on Vercel's phone, then Then they own it or something like that?

Something like that, but, like, more nuanced and, like, probably first of all, Guillermo would probably invest in it if I did, so, like, there's that. But Yeah. Exactly.

But yeah. That's good. There's there's that. Cool. Yeah. So it's also nice to be able to leave your work And not have it be 247. I will say that is also amazing. Just be, like, I'm going, you know,

on a trip. And That sounds like it would be great. Yeah. It's pretty nice.

Yeah. Good. Good. That's a great great answer.

Text editor theme and font.

Versus Code, Operator mono, SSM.

And recently, I was on well, I was on on Oceanic Next for many years As a theme, I'm now on GitHub dark, dim back background.

Maybe I just have a regular, actually. I like to get up dark. It just makes sense. Yeah. I I I can't I don't know. There there but I, like, I have this interesting relationship with themes. I don't know about you, but, like, oh, like, I I say I've learned some of those themes. Like, When I write certain languages, it has to be a certain theme. Mhmm. I don't know how guys have that. Like, when I write Java or Kotlin, like, it I actually have, like, IntelliJ White. I don't know why Is it really? In my mind. Like no. And and also but if I write, like, JavaScript TypeScript Go, it's I don't know. I get used to it, like, in my mind, like, there's a separate separate there's separate universe. I can't, like, think about Kotlin in Versus Code, though. I have to be intelligent.

So what what do you write in Kotlin? Like, are you talking to 2 guys? Used to do stuff. Yeah. Yeah. Like, what kinds of stuff?

Actually used to write a bunch of back end work in Kotlin.

Kotlin's great. It's like a super supercharged TypeScript if you, like, Interesting. Kevin. Like, worth yeah. Java is, like, low key awesome.

Yeah. That's that's my hottest take, and everyone's gonna be like, oh, my gosh. Java was like springs.

So, like, Java there's flavors of this. So Java was, like, spring and it was bloated and all the classic stuff. Right? But Colin and I don't know if you've seen DropWizard. DropWizard is amazing, like, collection of libraries, back allies, and

it's great. It's great. It's great. Super super super powered stuff there. Yeah. Last time I wrote Java, it was A very long time ago doing Android work, and, I did not know what I was doing. So it's Colin seems like the kind of thing I would love to give a chance now. It's it's cool.

It's cool. It's underrated. I'd say it's underrated.

I'm not I'm not advocating, oh, Jared's at Java's amazing. Everything in Java. No. I'm just like, it's it's not as bad as a resized it is.

And turbo repos is written in what TypeScript?

In Go, actually.

Really? Oh, wow. Yeah. So turbo is written in that on that native run. So turbo CLI is written in Go. There are, like, create turbos in TypeScript. But Okay.

Yeah. Turbos in Go. It's distributed as an NPM package even though it's written in Golang, The same way that you spilled is written in Go and distributed as an NPM package. Mhmm.

Oh, cool. And So how how are you able to distribute Go without, like me having Go installed on my computer? Do you ship it as, like, a executable, or how does that work? Yeah. There there's

binaries that we build per operating system and architecture.

And then the turbo package itself It's actually a sort of a shell package, and what it does is it's responsible it has the operating system packages that are operating in architecture specific packages of which they're, like, 12 or something and has those optional dependencies.

And on most platforms, it will Just recognizes optional dependency and install the correct operating system specific version of turbo.

But on platforms that don't or, package managers plus platform combos that don't support optional dependencies properly.

It will actually run a post install script to detect the correct operating system And architecture, and then it will download it from MPM for you. So

little shady, but it's actually how Versus build works too. They're exactly the Install and distribute exactly the same way. Oh, that's really interesting. I'm glad that we asked that. That's cool. These these questions this is the 2nd time we've done this now, but these questions have always surfaced really neat stuff,

So I like it. What is 1 piece of advice you would have for beginners, people who are just starting out in this industry?

Have a breakable Totally. Nice. Yeah. Love it. So if you're familiar with this concept, when you're learning stuff, especially this All this development development work. And even even as you progress through your career, having a side project that it's a breakable toy that's not crazy ambitious, but is doable and just for you Yeah. Is immensely important for your ongoing development and career trajectory.

The side projects will help you it will expose you to new new new problems that just, You know, reading blog posts and Hacker News and Twitter are just not going to expose you to. And it's those That, will will you be able to augment or enhance what you're doing day to day? It is still important to you know, if you're trying to be a coder to code every day, if you're trying to be a product manager product manage every day or immerse yourself in what you're doing for sure. Mhmm. But especially if you are Looking to either change change careers or switch switch focal points or you wanna change industries or you wanna just level up. Having this breakable toy, Whether that be, like, as simple as a to do list or a task or maybe you share it with your partner or your mom or your what whatever or It's your own little task list or calendar app or again, small scope. Maybe your own CMS or your own course platform or right? What whatever this is. Right? And even if it's been done before, I think that's the other thing. People are trying to, like, re like, create something new. Like, it's okay for these thing for this just to be, like, your flavor of this, And build it with the best tools or or coolest tools or new technology or whatever it is, and then always when you're when you see new technology or in tools or read about something on Twitter or whatever, you now have another lens aside from just, like, work that can get, oh, that's gonna be great for Blank or that could oh, I could use that as a database or I can use that as a logging system or what's that? Right? Or now you have this extra extra and if you have more than 1 breakable toy, even cooler. Right? Yeah. And the point about it being a toy is it should be small enough in scope where if you break it, it shouldn't matter. Like, there shouldn't be, like, massive consequences.

Right. Yeah. And so that's my advice is to is to get a breakable toy. I like that. Breakable toy.

Next 1 we have here. I'm gonna change it a little bit. The question as how do you stay up to date? But I'm going to change it to you can answer that. But I'm more curious, like, how do you know so many languages? You know, like, you use Kotlin, Java.

You wrote it in Go, TypeScript. Like, you're all how do you how do you know so much? Alright. So I'll answer the first one.

How do I stay up to date? I'd say mostly a lot a lot of it is Twitter, but less so than it used to be.

Interesting. GitHub as well, less so than it used to be, but just reading and working and and immersing myself in these problems. I'd say also Get getting involved in the community. So even if that's through Twitter, but then get you're going to meet ups and hosting meet ups, then speaking at meet ups and conferences. And and I know that's been hard with the pandemic, but it is coming back. So just being involved in the community helps you stay up to date, right, I think.

So and then how do I know so much? I don't know if I know anything, to be honest. The more I I don't know if I I don't know I don't know anything. But what I do know is I work with awesome people who know a lot now.

But to that end, running an agency or your dev shop, well, first starting as a freelancer and then, you know, growing that into an agency, yes, those are a lot of stuff. Oh, yeah. You know, so it's a lot of work. And whether that be new projects, old projects, you know, absolute Disasters after disaster, you know, replacing systems.

I used to joke that between me and my my my CTO or Our former CTO, Ian White, who's now the CEO of ChartHop and founder ChartHop, an HR platform, that together we had built, like, a lot of the Internet By the end of, like, our couple years, we had built a Instagram clone or a Pinterest clone. We built, like, a news site. We built a Membership management platform. We before Stripe had billing, like, I had this, like, recurring billing system. We built a recurring billing system. Oh, wow. Yeah. Built, like Like, an entire, like, price product crud situation. We built a dash like, we built so much stuff.

And, yeah, that that and so that that's paid dividends, over the years. And then as we're just, like, trying to teach myself new stuff, again, project driven learning is the best type of learning, especially for self taught developers. You know, having that project and and whatever that

Happens to be, and that's always been my my my sort of,

playing with live ammo, if if you if you will. That's been the way I've learned things the best, rather than go sit down and read a textbook on

x y z x y z thing. That's that's that's not my style. Let's go build it. Yeah. That's great advice. We we always talk about that too. Like, I did freelance for the 1st 6, 7 years of my career, and I I was primarily working with agencies. And I I saw it all, and it it it's crazy. Sometimes people, like, have worked at 1 start up for 5 years, and they're they just you just can't get through to them to understand, like, Why you might wanna do something a certain way? Because they've only approached a problem in in one tech stack. Right? And And being working in agency world, you see literally everything, and you're you're dipping into all kinds of different stacks and problems and whatnot. It's great. I I recommend it. It's tough, but I'm sure you know. It is tough. There are drawbacks, but but it it certainly for an ex I I'd say, like, working in a

Do a stint at, like, a a dev shop is never a bad definitely never a bad move. What about what about y'all? I'm curious. Where where do you stay up to date? I I well, I I started my career at a dev shop as well. So that was, like, big for me was getting to you know, if I wanna now all of a sudden do sass on this project, I can. Whatever. There's a new thing coming out, stylist let me try it on this one let me just give it a try but for me I do I stay up to date a lot on Twitter one thing that I've been using a lot more lately is GitHub's Explorer page or GitHub's own, you know, following. So I follow a bunch of really great devs on On GitHub and, you know, if Jared Palmer's liking or starring something, it pops in my feed, and I can see it. Yeah. Anyone stars. I star a lot. I start a lot. I think between you and Swix and then, Mateo from, Fastify, like, I I get so much out of that.

Just the amount of amount of things that other people are looking at or interested in a little bit. And even if not something that I'm, like, interested in right now. I just kind of goes in a spot in my brain.

I I put out, like, a a link list of, like, five Interesting projects I found over the week each each week on the level up newsletter.

So it's, like, part of my job is to, like, hunt for that kind of stuff. So I'm always kind of Just looking around, I guess. The podcast as well. Like, we we have to do a lot of research.

Like, we did, we did an episode on cloud functions or no. What? But not cloud functions.

Edge. Edge compute. What the hell is edge compute? Alright? And we did a little bit of research for that and Yeah. Figure out what it is and what people use it for, and Twitter is great for that. You can often just dip into Twitter and say, hey. What do you do use this for? You know? Yeah. It's great. The, stars are great. I forgot how much I star stuff also. Like, I do star quite a bit. Yeah. I know.

You wanna grab the last question there, Scott? Yeah. Last question is,

what is one thing that you're excited about in the future

of web dev. Oh, that's a good question.

I'm excited for basically, to not have to think about Config ever again.

Love it.

I'd like to see a world where you just, like, open an editor and write code and deploy code, and You don't need to think about how it all magically gets to the final state.

I think I'm also so that's, like, my my my local dream, and turbo will hopefully get get us there. I'm very excited about React server components. I'm very excited about React to edge, Edge rendering and also the stuff that's coming.

I'm very excited for that, in the in the nearer term.

I'm excited for The even even even tighter feedback loop between local development and preview

and preview URLs and and just tightening of that process, I'm very pumped about. Awesome. I like it. Alright. Is there anything anything else that we didn't mention that you wanna make sure we touch upon, or should we move into the last section here? Do you wanna

go through I don't know. We didn't talk much about the, like, joining Vercel or just, like, life at Vercel. I don't know if that's relevant, but We need to talk about that. Yeah. Let let's tell us about that. How how does that even happen? Like, selling a company, Versa, that sounds pretty cool. Yeah. Does do Vercel want to buy a podcast? Yeah.

Yeah. So the way that all went down was kinda fun. So I was gonna raise a pretty big seed round for Turbo to be an independent company, and Guillermo was going to invest in that as an angel investor, and I'd actually we worked together prior on the React docs.

So Vercel had and and commissioned me and Facebook to kind of, like, in tandem to work on the and prototype the migration of the React js official reactjs.org from Gatsby to next, and I was staffed with that. So the beta.reactjs.org is built on top of some of the initial work that I did. It was completed by, I think, it was this. Labs and but the initial move was was mine, my my work. And I g and I, Guillermo and I worked together on that, and we hit it off immediately.

And so that was just like a cool side project. And then fast forward, like, the following year, and I'm doing raisin cheese, like, And Guillermo was like,

I wanna invest, and they would make sense. And then and then when it came close to closing the round,

Chairman was like, why don't you just build this up for sale? And then they made an offer, and it made sense and, you know, the rest is sort of history there. But it was an interesting process To make that decision versus spinning up a company on my own and and doing that, but I'm very happy with the decision I made. And soon I actually joined before Rich Harris did. Rich Harris joined Purcell a month later, but I was in stealth mode, stealth working at Purcell.

And then Rich joined, and then Seb joined, And now Molt has joined. We got and there are already so many people out there. It's been a wild, yeah, a wild time for,

And for people getting picked up. And Vercel is just out there to solve all of our web development problems. Right? Like, is there other stuff that you can tell us about that is, like, Coming down the pipe from Versal? Any any sneak peeks?

I mean, the the stuff they're doing with Edge is amazing. So I yeah. They are already in beta, but stay stay tuned for that.

And then there's very cool stuff now with racks or components that, it's very, very, very soon. There's also I'll tell you the, Next. Js layout pull, RFC is coming.

So layouts in Next. Js is a is a big pain point. So that's, like, a that's gonna get that's that's getting solved. That was one of my biggest problems with Next. Js overall, so happy to see with that. Yeah. Yeah. Yeah. So that's that that's coming. That's, like, the the thing I can I can share? Wow. That's really cool.

Awesome. Awesome. Well, thank you so much.

The last section of the podcast would do shameless plugs.

So if you have anything you'd like to plug for the audience To go check out, we'd love to hear it.

Sure. So I guess we'll start with Turborepo. So the tool is at turborepo.org@turborepo on Twitter.

I guess, for cell for cell .com, probably the easiest way to deploy a modern front end web web application, whether it be Next. Js, Gatsby, Remix, Cell, Create React app, DocuSaurus, Purcell is the best, in my opinion. I'm very biased.

Yeah. There's a night, like, 2 bait like, I guess, shameless plug picks.

And 3rd pick,

totally out of the blue, would be I just got a new water bottle. Kinda kinda

digging it. Yeah.

Soma.

You seen that? Have you seen these? Soma? No. No? How do you smell the ice?

It's sweet, s o m a, quality. Just it's glass.

It's kinda have this rubbery thing there. It's pretty pretty pretty pretty.

I don't know. I just got it the other day.

Pretty nice. It's a it's a random, like, Relevant podcast. Yeah. Oh, yeah. We we've got the that's a sick pick.

That's I like that a lot. Beautiful. Oh, I'm just on their website. They have, like, a nice kettle.

Like, you can do that like, like, you know, the pour over with the tiny little kettle that people do? Those are great. You're from New York. Right? Yep. Yep. Yeah. I'm sure you you know you've been to some sweet coffee shops then.

Mhmm.

Yeah.

Yeah. Yeah. Yeah. Yeah.

Awesome. Jared, thank you so much for coming on. That was super informational, and I'm sure everyone's gonna love it. I I know I did. Yeah. I'm gonna go out and implement

Turbo repo right now to just give it a try. Give it a whirl. Give it a whirl. See how see how it goes. We're, we're we're we're standing rapidly.

Downloads are through the roof, and hopefully, that's a good indicator of of of adoption and or so. But thanks for having me. I know this is fun. I've been a listener for a long time and We're so glad to to get the call out. Well, thanks, Jared. Alright. Thanks again. I'll talk to you later. Peace. Peace.