Supper Club × NX Monorepos with Victor Savkin

I sure hope you're hungry.

Who? I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Talinsky and Wes Bos attempt to use human language to converse with and pick the brains of other developers.

One's way smarter than these guys. I thought there was gonna be food.

So buckle up and grab that o handle because this ride is going to get wild.

This is the Syntax Supper Club.

Welcome to the Super Syntax Supper Club.

This is the 1st episode that we have of our Our new Friday episode, which is we're gonna be having, guests on and interview, chitchat, shooting the shoot, whatever.

We call it supper club because it's kinda just, I don't know. I've had many good dinners with other developers and just just talk about whatever and you learn a lot. Today's episode is Sponsored by 2 brand new sponsors. Can you believe it? 2 brand new. We've got Whiskey, Web, and Whatnot. They are a lighthearted podcast That, samples whiskey and talks to some developers have been on it myself. And Strapi, Strapi is A tool for building REST and GraphQL APIs, to power your content applications. They're a CMS. It's wicked. I've used it myself. We'll talk about both of these companies Partway through the episode, today with us, we have Victor Safkin, from NX Dev Tools and A few other things. I'll let him kinda introduce himself. But I don't know. A couple of months ago, we or a couple weeks ago, we had a show on mono repos Where Scott and I are are fairly new to monorepos, and we're talking about tooling and stuff like that. And, Pretty much everybody's like, you gotta check out NX. You gotta check out NX. And, like, we're we're we looked it over briefly in the show, but We didn't really have a good idea of, like, like, where does this fit in the whole monorepo. So with that, we'll just have him on, to talk about, NX, but also just, like, monorepos and encoding in general.

So let's get on into it. Victor, thank you so much for coming on. Thanks for having me. Hi, everyone. Hey. Yeah. I'm always happy to talk about molar ripples. Yeah. Molar ripples is the subject that I've been talking about for so many years. So at this point, I'm like, you know, you can wake me up in the middle of the night, and I will tell you something about more.

Oh, good. Because, I'll get your personal number. If I have any any issues, I'll call you in the middle of the night. Yeah.

Why don't you give us a intro, who you are, where you're from, What's your what's your background is in and kinda what you're focusing on right now? Okay. Sounds good. Yeah. So so my name is Victor, and,

I've been programming for a very long time, you know, 20 years, and, I used to be at Google on Angular core team. Right? The Angular bit is relevant. What's relevant is the Google bit because that's where I've experienced, like, mona repos done differently. Right? So And, for the last 5 years, I've been leading a project, called Next, which is basically, sort of tools for like a build system built for mona repos. We will talk about what monorepos are, etcetera. Right? But the post is built for monorepos.

That partially is part to what we saw, at Google, right, with the same sort of kinda sentiment, but done in a way that is usable outside. Because there are build systems built At Google, you know, used by Google successfully, and they kinda struggle to get adoption outside because, you know, it's very hard to build something for 1 company and then Let it be used. You know? It happens, but it's not very often. I so we try to take some of the ideas and and and and make them sort of palatable, you know, Usable by the broader community.

Interesting. Cool. Well, we've got lots of, lots of questions around monorepos and and the tools and whatnot. So, I didn't realize that you had had worked from for Google before then. I'm always curious about about that type of thing. We had After we talked about the build systems and whatnot, we had a couple of people from Google, send me DMs and and whatnot and, Just to talk about, like like, what it is that they actually use internally. What what was that thing built in? Okay. So the, internally,

I mean, there are a lot of, like, a family of 2 for any large tech company. Right? They often build ever since sort of, Not from scratch from scratch, but, you know, they have their own custom stack because they need to so unique. Right? And, also, some of the tech companies tend to be ahead of the like, they are ahead of the industry, right, I'd say 5 or 10 years. Right? So they cannot use what the industry offers because they like, the industry doesn't offer anything. Right? At least that scales to the degree. Right? So, one of the tool that they used which is, I think a fantastic tool, it's called Blaze, and outside Google is called Basil. It it's the same same kinda idea, which is a build system They can use to, to build anything really. And the idea that you would describe your computation as, like, this graph of tasks, you know, And Bezos slash Blaze would figure out how to run them across many machines such that, you know, you could scale horizontally. Right? Run very big things in there. Right? While presumed in the the the ergonomics of it running locally, somewhat. Not perfectly, but, you know, actually well enough. And for it to work, well, it had to be accompanied by other tools around. Because, obviously, if you run, like, 1010,000 projects in your, you know, CI run, you cannot just show the logs in the text like the you know, that's that's not going to work. So you have to, like, a custom for everything. A custom stack for reviewing PRs or change that. Right? A custom tool for just viewing the logs because there is so much, you know, so much log and stuff. Right? But Bazel slash Blaze is what folks right now who do certain things. If you look at Joy development, you like Android core, I think right now you have to use Bazel to So there are certain things where you can sort of see it. At the front end person, you don't see it as much unless you are, you know, in a, like work at Uber or something. I do like in a few companies that do use it. Right? So so I like it. I actually think that Basil Blades had a few very good ideas. It's just, Anyway, we can talk about the trade offs. I think it's a good thing people that on the team, they are brilliant people. It's just very hard for people outside of Google to adopt, Unless they have an engineering team who is like, we are 100 people who are just going to make it work in this company, right, by applying all the effort. Right? And if they made it work, then okay, great things come out of it.

But not every company can do that. Right? And, so we we in many ways, I inspired by Bezos like Blaze. Right? Because you did a lot of things in a very interesting way that Nothing else at that point did as well. Right? But, you know, we made, we sort of basically look at trade offs and decided to not go Maybe Google scale? Like, a slightly smaller scale, but make it usable by, like,

thing that the you know, Google, I mean, has had that reputation even before monorepos became trendy for normal people. The Google monorepo was always In the day.

Yeah. So it's it's fitting that, you know, people with a background and that kind of thing would build a a tool like Next Or and and not that next, NX. Yeah. Yeah. It's it's, it's one of those things where,

unless you actually using it day to day, it's kinda hard to It was a few, like, one of the early one. Now it's lesser because more now it's become more of a thing. Less you you don't hear as much negativity, like direct negativity. Oh, it's complete not working in the garbage or whatever. You don't see parental responsibilities for an app lover. Right? More folks right now are like, oh, I'm I'm interested to see what it can offer. Right? Etcetera.

Right? And but early on, like, when we started 5 years ago, most folks who would use the word monetary point in a JavaScript space outside of Google, Uber, and Facebook or whatever, right, Would always mean, oh, it's like lawn slash yarn workspaces thing. Alright? And it's such it's no. It doesn't wrong with them. They're fine. They're Absolutely fine ways of doing things, but they are so different from what, say, Google or Facebook or Uber mean by monorepos. Like, they're almost nothing in common Apart from there are more than 1 thing in a repo. Okay? Yeah. Like but by this definition, you know, okay, so many things are more than the repos. Right? So the Google and Facebook and others mean, like, a much more concrete way of developing, right, than we can talk about it today, right, Which, has some trade offs, but gives you a lot in return. Right? Learning and Yarnowsmith has a very different way of developing, and they don't offer as much, but they don't ask as much as well. Right? So they Mhmm. Like, kinda they appear there. They kinda do a few useful things. Very cool. Right? But they don't give you as much in return. So if you use something like, you know, or, you know, similar kind of approach.

If you can even roll roll your own using bash, whatever. Right? To say, oh, I would like to have a 100 packages built with this. Well, you're going to be in trouble. Alright? That thing is not going to work, as well at some point, not because necessarily it will be slow. It will be. Right? But all also other things like you're like, woah. Now it's a mess. Look. Oh, yeah. Like, when Google built it, it's not like you have just 1 giant folder whenever you can import everything else. No. That's not the case. There are rules in place to make sure that the monopoly is not complete chaos. Right? Yeah. So, Like, it it's those type of things where you experience it firsthand. You, like, see what maybe is important, which is very hard to convey sometimes to someone who is new to it because A lot of things that are important aren't important to day 1. And, like, on day 1, you're like, okay. It's like if you look at TypeScript on day 1, you're like Yeah. Yeah.

Yeah. That's hustle. Like, I have to type this stuff, like, to compile it in a way. I can just run this file anywhere. Like, how much nicer this is? No context is required for compilation. Why would ever use this, you know, Like nuisance. Right? But then once you're, like, a year in, you're like, holy like, that is fantastic. Right? So useful for large for large system. Right? So it's one of those things where Anyone who tried it, they know that certain things will be very important 3 months, in 6 months, in 2 years, and and it's kinda hard to convince people that it would be the case. Right? Yeah. Yeah. It is. It I mean, TypeScript is the perfect

analogous for that because, I mean, it is. You you're solving a problem that the user doesn't have, so then the user says, there's no problem.

Yeah. Yeah. Exactly. It's it's it's a bit of a with at least you can say, well, you used, you know, someone who used, let's say, Java, s t Sharp. You're like, Remember the tooling, refactoring that works there? We work here as well. They're like, okay. Let's go. Right? So some folks cannot tie. But more than a person is so not used really. Like, they were very new to not just front end space, even another like, if you look at the back end space and stuff, it's usually done in a very rudimentary way. Right? So it's very hard to explain. Oh, by the way, it is going to be good. They're like, I don't think it is. Right? I I was told, you know, for 10 years that splitting things to small units is good. Right? And you're like, yeah. Yeah. You are splitting things in the smaller units with monorepos. In the most smaller units, they're just in the same repo. And, you know, things like that where,

so a lot of communication breakdown happening there. I I have a question about the the repo part of it because, like, Scott and I are are fairly small, fish. And we got a couple people on our dev team, and we see the value of of a monorepo. But You seem to have, like, experience with the total opposite side, which is these these massive companies. Google and Facebook and, GM and things like that.

Like, what do these companies use for version control? Do they literally have every project in the same repo? Do they use Git? Okay. That's a good question. So let me first say that there is, like, a range or, like,

a of projects. Right? And most folks Who, this is not to say that folks aren't, you know, clueless when they say but most folks are, like, from even from, like, large enterprises that come in And like, oh, but I'm pretty sure once we do monorepo, like, the whole like, nothing will work. Git will not work. Git actually Scale is pretty well to fairly sizable for most of it. Like, for, like if you look at the the range, right, I would say, like, 99.9% of repos Work just fine with Git and Versus code and everything. And they're just in this, you know, range where, yes, you have, let's say, you know, 30 mediums line of code for like, you have large systems in there, but they can all fit and Git won't struggle at all. Right? And there are ways for To scale Git, right, Microsoft has GBFS, which is a Git virtual file system where you can kinda check out the Uber massive repo because Microsoft use Git, to develop its massive Uber projects. Right? That doesn't work well with regular game. It is the the virtual file system for, I think, Windows and Mac and stuff that, you can Kinda cloned the repo, but not really. That kinda works. Right? So but believe me, like, 99% of of of people who think they have massive ripples, They aren't in that category of math. They are just big in practice for most teams, which is totally fine. Right? So not everyone has 20,000 developers contributing to the same like, That's totally fine, though. They are in a bracket where regular git works. Right? Companies like, Microsoft, in this case, have their own custom sort of, you know, git I don't know. Not git back end, but, you know, Whatever. Pre present your git front end while the the way of manipulating files is different. Google has their own custom solution from scratch, you know, Because, obviously, you cannot check out a report that massive, anywhere. Right? So, so so I would say that for most folks who are skeptical. Okay. You can look at Google and say, oh, you know, that is not going to work ever. You know, that is scary.

But, really, you are not in that, you know, you're not going to be in that business. Right? If you're a bank or, like, if you're, like, a a company and you have, I don't know. You you have a good engineering team. Right? You can have a few mono repos. A few mono repos sounds weird, but a few repos that, you know, we have multiple projects in them. And each of them will easily fit in a normal Git repo. You can easily open it in your web store or whatever. Right? So it will work. It's still a bill big repo. Right? It's just that it's big and there is, like, enormously crazy scary big. And I it's like it's it's like when you move houses, you can have you can talk about Oh, how like, what truck to use? Big truck, even bigger truck. Okay. That is, you know, that more most companies are in that space. Google is a space of, like, giant contain like, you know, shipping containers, you know, like giant ships. Right? So it it's just whatever they care about doesn't apply to Pretty much anyone. And I pretty much anyone.

So I'm actually again saying that Google's type of tool should work for you. Right? Because, Really, you're not Google, and you shouldn't be. If you're a bank, you you know, you you're just structured differently. That is totally fine.

You can borrow some ideas and say, oh, let me figure out if I can use some ideas wisely at a smaller scale. Because when you go to a smaller scale, There are certain trade offs that work differently for you, so you can actually have a much nicer dev experience for you at that smaller scale than Googlers have for their own apps at the larger scale. Right? Mhmm.

Oh, that makes sense. Cool. What is NX? I think we'll get into the the questions of, like like, what does it do? Does it replace this thing in relation to, but, like, give us your your elevator pitch of what it is. Yeah. No. It's a it's a good question. So,

it's basically, like, an an extensive build system. Right? And it really does 2 main things. Right? 1, they are connected, but it can be explained in this. One, it does the monorepo bit. Alright? And we can talk about what it means. Essentially, when I say it doesn't monorepo bit is I mean is that you can put a bunch of packages, modules, right, in your repo. Alright? And the next would understand the relationships between them. Alright? So basically, it would create like a a graph. Like, it knows what depends on what, in what way, etcetera. Right? And it knows it automatically because Anix analyzes your source code to figure out how relationship like like, if your app imports a lib, it just knows that it it important. So it knows that there is a relationship between them, That, you know, the app required that lip. You know? If you went to enter, try to get the app, same kind of stuff. It automatically looks at your source code and a smart way to make it faster than that. But anyhow, so it does it. It create this view of your workspace. Right? That's one thing it can do. And the second thing, it knows what you can do to things in your workspace.

Right? For example, if you have an app, you can say, oh, you can build it or you can test it, right, or you can lint it. So, by but you can look at your NPM's case, but you can also use, like, a next plug ins to to convey more information. But anyhoo, so it looks and say, oh, you can build this app. Well, the app is going to create files in that folder, for example, it knows. Right? Yeah. We it has these 2 parts. It knows basically a set of verbs, Like, what you can do to different parts of your workspace. Right? And it knows how different parts relate to each other. Right? And because it knows these 2 things, right, And it noted again automatically, whatever. It can now do interesting things with your workplace. For example, you can say, oh, if I build the same like this app, if I build it again, if I if I, you know, build it already in the past, right, don't build it. Just you replay the output. Show me the terminal output as before, and it would do, I think the best job among the tools to capture it good as is because it's very hard preserving colors and everything. So it looks as if it was printed right now by the computation And put all the files where the files belong. Right? I'll see the computation happen right now. It can do this thing because it knows how different parts relate. If anything you have depends on changes, It would know. So it it would not in yes to recompute the app, things like that. Right? The second part it can do is to say, well, because I know how different parts relate to each other, right, I can run this computation, this build. Let's say you have 20 apps and a 100 lips, and the audio punch on crazy ways. Right? Instead of running on 1 machine, you can just say around on 20 machines.

Right? And it would know that, oh, I need to build those things first. It will start doing those things. Then once they build it, you know, different agents would pick up different parts of the work. So from your point of view, you're just running 1 command on 1 machine. Your terminal output all appears on 1 machine. All files appears on 1 machine, but the computation happen on 20 Right. Mhmm.

Like, behind the scenes. Right? So you have the dev experience of 1 machine, execution, right, a kinda naive CI. This next CI usually looks very naive. Like, just a chunk of, like, Builds test lanes, and somehow it just fast in regards to the size of the repo. So that's the 2nd part that can do more on the repo wise. Right? And I think the 2nd part of this, you know, on the scaling part is what I think is it's it's hard to do. Google obviously does it because otherwise, but that's the part where, when folks reach a certain scale, they see the magic. Because distributing things actually is very hard. Right? If especially when it comes to things where there are differences between them. Right? Oh, I need to build the 5 loops to build that other loop that then enable me to do those apps, Which then I can use to run into and test against them. Right? There is, like, different things that depend on each other's interesting ways, which mean that you cannot just say Run 5 things here and 5 things here because agents in CI have to share files, swap files, you know, to do all the things such as they have the right things in place before they run a particular Part of this computation. Right? It can do that. Right? So there is not basically you have a transparent. I put it in quotes because, you know, you still know distribution happens. Right? But By and large, you don't have to care about distribution. You just if you want it to be fast, you just put more agents and things get fast until a certain point. Right? That's one part. The second part of the next is sort of the the CLI DX part. It's saying that for any large org, if you are, I don't know a retailer. Right? The big retailer, and you have a 1,000 developers contributing to the same repo.

If you can make you can make it fast, let's say, is on the next, but the 2nd part I need to, make workable, right, is that it's just maintainable. Right? The maintenance part people often neglect because fast, we kinda have intuitive thing about, Well, I know what fast is. I generate many projects. It should be kinda kinda fast. Right? Most people understand what fast means or scaling means. Mhmm. The maintainability is harder because we were like, well, I built in this like, I built in this 1 app on the repo. It's maintainable. So what's the problem? Right? And so and there is to say that, well, if you have this giant system, right, or multiple apps Built by different teams. For it to be maintainable, you have to have some consistency. Right? You need to ensure that things don't import each other in crazy way that, you know, That if you're building a private leap for yourself, in in the same way that a a Bob from overseas is not going to port into it. Right? And now It depends on your lip and, you know, it's no longer private. Right? So things like that, for example, right, have to be put in place. Right? Code generation, code augmentation, being able to migrate things, like, let's say if you're using Next 11, you're going to Next 12 or something. Right? With Next, you can just say go to 12. And then next, we'll look at dependency that you have, you know, update your package to JSON, and update your source code to work with 12. Just look and say, what do I need to update in your repo such that it works with 12? Right? Because, again, if you're a big retailer, a big bank, or whatever, right, it's very hard to go from version to version. If you have this massive system, you're always stuck behind. So This is not fast. Right? This is something that folks don't see right away.

But, like, a year in, you're like, okay. That actually maybe is even more important than being fast. Right? Because I can kinda put together fast bit ad hoc. Most organizations say we kinda teach it together in some other way. Right? And it's reasonably fast.

The maintenance is where they trip over. Like, a year in, it's like if you don't have good stuff in place, you're in a mess. Right? And then you're saying that more than people say disaster because, Well, yeah, you have to have something that, you know, helps you keep up to date, ensures that things are well maintained, that things are consistent,

Blah blah blah blah. Right? Things like that. Okay. So what's the how does NX help you with that? Like, let's say, There's a major version of Next. Js and React have come out.

Like, what what does NX do, Like, as a developer, okay, I I need to upgrade this thing.

Some so I would have to, like, go through all of my projects that touch upon that and make Sure that is all updated. What what does NX do for me there that's so helpful? Yeah. Yeah. No. It's it's it's actually a like, I know it it will sound kinda simple, but I'll explain it. But then I will give you an example where it actually like, how it works in practice with, like, a a real word example. Right? The way it works is that if you are moving, say, from, I don't know. Next, you know, a to b. And and and there are other things where that can come along and make it a mess. Right? Okay. Next by itself is not it's actually fairly straightforward, Because it's I think every single library is usually not that hard to move. The problems usually arise when you have things like, let's say, Cypress and Storybook. Right? The 2 separate tools That can be used together. Right? Yeah. So when you when you move to to to latest of both, latest of they're not synchronizing with each other. Right? So, like, you need to make sure that the combo works, And and that's where the more sort of gnarly cases, occur. Right? But the way it will work is that when you run a next migrate and you can provide the name of what you want to go to, Let's say, if you just say next migrate latest, the next command is going to look at every everything you use in your package is adjacent. It will fetch metadata, right, About things like Next, just whatever you're using there. Right? You'll get this metadata, and I'll be like, okay. You're going from 11 to 12 of Next. Usually, like, the way it works is that we provide this, Like, like, an X plug ins, which is basically a tiny wrapper around the tool to make this happen. Right? To fetch this kind of data and to say, oh, you're going from machine a to b, of, like, 11 to 12 next and, like, 4 to 5 of Cyprus and they're like, that what you want to do. You want to go to, like, to. Right? It would reconcile it and it would say, oh, there are 2 things I need to do. I need to update your packet versions, your node modules, package the JSON with the versions, you know, that, not just the plug ins, but everything that so it's consistent. I'd say, like, Cyprus will go to this, storybook will go to that, next will go to this. Right? And then it would Collect the serve recipes, and I will talk about it in just a second. And I'll just say it'll create a file called migrations, which is basically it's going to list recipes to update automatically Your workspace to work against the new versions of not modulars. Right? So it will do that and then, it will run the PM install to install the new versions and it would run the recipes To update your workspace to, like, update the config files, to update the source files, such that it work with a new thing. Right? So let's say, I don't know. Like Cypress changed something the in the how they write the specs. Right? It would update the version like, oh, that's not compatible. It's going to run that thing. We'll we'll find all the specs you have in your workspace And would rewrite them, right, to work with a new version of Cyprus, right, for you automatically. Alright? So the way for this to work well, you need to be able to to do large scale file transformations.

Right? Like, so next comes with a virtual file system and a set of utilities that help you write those A large scale file transformations and a composable.

And, I think it's relatively easy just to you know? Oh. Is that that's like code mods? Yeah. It it it's similar in spirit. Right? So that you you can think of it as, like, on steroids in that, now that you you have them, you can compose them in very like, in lots of interesting ways. Right? And, it allows you to, like, dry around them. For example, to say, oh, let me see what will happen if I run this transformation. Like, you're like, oh, I can see. Right? It's going to change this. This is not right. So so this, it allows those to compose side effects and and interesting. But anyhoo, so it does this. Right? And as a result, you are able to move your workspace in a mostly automatic way. Not sometimes things occur ways like, Okay. The tools just cannot fix it everything for you because some APIs are just unfixable. Okay? So Yeah. But if you kinda lean on what we offer On the plugins, we try to, for example, with Cypress, we shield you for somewhat by having, like, a anti corruption layer saying, well, if you use invoke us by this function, We'll make sure you'll never be broken kind of stuff. Alright? And as a result, we, kinda I don't I don't know. 95% of the things are handled automatically. The 5% is like the manual way, like, We tried, you know, but it's just, you know, it's good. Like, we don't control those tools, so we cannot ensure they always work. Right? I'll give you one example for when TSLint and the SLint, The thing happened, but just got deprecated. Right? A lot of companies still use just like, you have a 10,000,000 lines of code, Linde by just like It's a trouble because now it's a dead project. Right? So you cannot be using it. Right? And, so we wrote a set of migrations to map against different, Like, map test link rules for your test link rules, basically Okay. Automatically. Right? So in this case, you would run those. We would look at your test link configs, and we would generate Similar. Yes. Link conflicts. Right in that as close as possible, such as what you need is actually the same. And they moved to your sling, And it kinda almost worked. So, like, there are few corner cases where you had to be like, okay. There is a lint error now because, you know, it's it's a different tools. Right? But even that relatively, like, it's kinda extreme case, and the tools are different. Right? They're not the same. It's not like more information a to b.

Most folks we work with because we also consult large companies. Right? We're able to move, like, within days. Like, On Monday, you're used to, like, for your giant workspace on Wednesday, and everywhere. Right? So that's an example where if you didn't have it, those companies would have been forever stuck with.

It's just because of, like, who is going to pay? What business is going to be like? You need to spend 3 months right now moving your lead files. Right? Yeah. Right. And then we're like, okay. It's not happening. No. So Things like that is what I think is, like, again, it's hard to explain if they want because you're like, yeah, I will figure it out. You know? Why do I care? 2 years in, you're like, Webpack 4 to 5 is a, you know, it's a hassle. Right? But it's not hassle if you go buy an act. It just again, 95% automatic. There might be some edge cases in that. Alright? But by and large, it kinda works. Right? So it's it's hard to appreciate unless you were, like, A giant project and you're like, okay. You know, we're always behind. The business keeps, you know, hitting us with a stick that we, you know, need to ship new features. It helps you to kinda completely get rid of this part and say, you know, how about some tool will move my make like, my stack basically, right, Forward for me, mostly automatically. And it was, like, a few minor many interventions in there. To me, that sounds really nice as someone who has written

Tons of find and replaces in my life, which is like the sort of the poor man's code mod.

I think it's nice because it's not just like doing a final replace or regex on it, but it also knows about your code base. Right?

Yeah.

Yep. Alright. Let's talk about one of our sponsors, Whiskey Web and Whatnot.

It's a podcast about web development, but also whiskey And I'm I'm assuming whatnot. I've been on it myself. I I did a little bit more whatnot than whiskey and web, but, it's pretty interesting. So They are more than a typical dev podcast. They're better than this one.

They show a lighter, more human side of developers. I I literally was talking about tractors for probably 10 minutes on it.

Past guests include Tom Preston Warner, Kenzie Dodds, Charlie, Gerard, and, of course, myself. I've been on it. I sampled some whiskey myself on it. They've discussed everything from Next. Js and TypeScript to Chuck's Past life as a Blackjack dealer, Cincinnati chili and casseroles, and, of course, whiskey. So pretty cool dev podcast. You can check it On whatever podcast player you're using or WhiskeyWeb and whatnot dotfm, thank you, www,

for sponsoring. So okay. So, a lot of times now, developers, they have their, like, Parade of of tools that we're using. Right? We we have whether it's Parcel or Veed or Webpack or any of these. And and so one of the big confusions I know for some people is they see NX as a build tool or a monorepo tool or something like that where How does it how does it fit into the puzzle of let's say, I already have services that are using Parcel or using Veed or whatever. How does it How does it work with those tools, or does it work with those tools, and how does that puzzle fit together? It's a good question. So I think there are 2 parts to a and actually, the next core. An x core is basically a a generic task orchestrator,

right, in that it can run processes across machines and cache files, But what those processes do, it cares not about. Right? So Okay. Like, you can run, like, Java, Bash, you know You know, TSC, SW, whatever you you want to do. Right? It just doesn't matter because it's generic task. That part is completely technology agnostic. Right? Like, some of the parts that we'll be able to do it in Kotlin, for the back end. Obviously, the next stuff is good in test. It's sort of different. It works the same way. It just doesn't matter. Right? So That part, throw anything in there, works. The 2nd part, which is, well, to that part is is the sort of the fast scaling part. Right? Works same way caching works together. The 2nd part where it's technology specific, which is with Next, you can write what we call it on Next plug in. The the word parking is, but is it, like really, what I'm talking about is just an ability, to write, like, a custom 2 2 custom things, really. A custom, executor and executor is basically like a types in PM script. Think about executor to an RPM script as typescript to JavaScript. Right. That same idea, you can run a thing. But, actually, there's a PM script that can, provide metadata.

Right? That's all your Versus code integration works, etcetera. Right? And it allows you to express long running processes better. It's more compostable. So NPM scripts aren't compostable really well because it just processes. Status code is the only thing you can put there. Right? So that's one thing. So you just say, oh, if I write this, right, for example, if I have an executor wrapping, I don't know, TSC or SWC. Right? So what will happen is that then my Versus code can give me hints about which flags they can pass, blah blah blah, and things like that. Right? And the 2nd part you can, write plug ins for is a generator which is like that. The migration thing I talked about is a virtual file system and everything is cool. The same stuff just for for migrations but for creating new artifacts. Right? You can right click on a folder and say, I want a Next JS page in here, and it will tell you, okay, customize a few And as you're customizing the Versus code, it will show you the preview of what would be generated if you choose to commit to it and say, oh, that looks good. Commit to it, etcetera. So those are 2 parts. Right? So Let's say a new technology comes up. Let's say I put my own bundler because bundler is a hard writer like Victor bundler. Right? And, like yeah. So I can use it without any plug ins at all. Just well, I could just invoke Victor bundler in NPM script. Right? Or like it will work. Right? No extra metadata, of course. Right? But the caching will work. The bundler would work in a way it works with anything. It works with.

Exactly. Right? So our next quarter in this case would be in that kind of bracket. Right? It it will distribute, like, the the, process of transit banner can be distributed, etcetera. So it will do general stuff. However, if I release a new version of Vector Bundler With the break and change, it won't know about the break and change because, you know, from the point of view of one x, it's just a black box. You're like, you're running a process in there. It doesn't know how the process configured, what it does, Right? Yeah. So, in this case, it will like, if you want to aid that and say, oh, I would like to have a few generators to generate different versions of the conflict for Victor Panner. Right? Or have, like, perhaps, like, shield it a bit against black changes. Okay. You can write a plug into it, but it's an optional step. Right? It's something other tools you don't offer. So in this case, the NX Core would be more comparable. So if you compare, say, a Turbo and an X. Right? You'll see NX Core and Turbo are more, Like, feature wise, similar ish. Right? Whereas plug ins just extra. You don't have to use them at all. Right? They're really truly optional. Next bite of the single package you can add and you get the core. The plug ins, though, don't replace your stuff. You could you it's it's not the right way to think about it. They kinda, If you have a plug in for Next. Js, they kinda wrap Next. Js to provide a few affordances, like migrations, some generators Okay. And a few affordances for dealing of Yeah. Right? For example, most JavaScript tools like Next. Js CLI on Next. Js CLI. Right? So there are some problems With putting the monorepo because if your app depends on the, say, a library of shared components, which you want to build. Right? Then, like, so how do I import it? You actually need to override the import you import from the place where the library is compiled to. So you don't import from the source. Right? So things like that. That that rewrite cannot happen in package adjacent. Most folks put it in package adjacent, but it sucks. Okay? Because it breaks the refactoring in the Versus Code. So, actually, your Versus Code should point to source. Right? But when you build, you want to say, hey. Wait a second. Actually, that import goes over here. Right? So things like that was plug in to to make some things that are specific, which folks at NEC at the Purcell, I mean, until recently, I didn't care about very much. So The experience is kinda, you know, has troubles. Right? It does that, but it's truly optional. So if you really want to throw an exit at any project, you can do it. It It will work with any with any yarn workspaces. You know, just run the command. It just works, but you won't get magical migrations as a result because, obviously, magical migrations kinda require you to To tell us that I'm using the like, remix for something. Yeah. Right? And remix yeah. Something like that. So it's basically optional things That most smaller teams may not care about very much, but larger teams do care because for them, the cost of those migrations and stuff. Right? That's where, You know, they can save a lot of time. Right?

Okay. So that that makes sense to me. So it doesn't necessarily replace Any of the existing tooling that you have.

So, like, if I'm using Vite or Parcel or like, as my other question is, Like, Babble, TSC for TypeScript, SWC with TypeScript.

Those things are still happening on the hood. You guys are Are you guys are building your own typescript compiler or something like that? Yeah. So that's actually an important thing that I want to point out. In general, I'm I have a suspicious when I see A full stack closed too. Right? There are some smart people working, so I don't wanna mention them, not to be like but when I see, like, we are going to implement the whole stack from scratch in a given Language is like, okay. That's cool in principle. When I look at the in history of the industry, those tools don't usually work out. Right? Like, the tools that work out, right, you know, are tools that say, we're going to do some things well, and you can just put whatever you want in this plug in that we offer. Right? So I think that in the long run, those tools tend to work, kind of survive more because, really, the industry moves so fast. Right? While you're already right, you never seen the one thing that you think can show up. Right? And you're like, okay. So what do I do now? Right? So we really believe that we do some things really well, which is we do the start task orchestration distribution Really well. Right? Better than anyone else outside of Google. Right? But, you know, and we do well this, you know, Providing the wrappers around existing tools. Right? Okay. It's very easy to do. It takes, like, a day to ride. We have your custom, like, their guides. It's not hard to do. And then you have nice. You have code experience, generators work beautifully, migrations work. We are not interested in building the bundler or or the compiler or anything like that Because folks who worked on, you know, SWC, SWC, OTSC, are like they should be doing the comp comp compilation bit. Yeah. The experts in that, good for them. Right? So we just want to use it Well,

Sajid fits nicely with the rest of the stuff. Right? And that also probably helps your adoption because nobody wants to rip out their tools That they've Yeah. Yeah. Exactly. Spent a month

creating or or getting perfect there. Yeah. It's very hard to like, people don't realize how hard it is to to get the The experts, like, for example, the TSC and SWC is a good example. TSC like, SWC is a good fantastic compiler. We have support. We actually have a converter from TSC to SWC. You can just try it in the hole, becomes the WBC. But the type check is actually the hardest bit. Alright? And the type checker is still done by TST, do it by the team at Microsoft. Right? Because the type checker is very hard to write. The compiler is easy to write. The type checker is or, like, not easy, but easy, yeah, than the comparing type checker, which is super hard to write. Right? So, like, I'm in no way it would be my nightmare to think that I have to implement the type checker, right, that that, Microsoft team is working on. Because, a, it's close to impossible to do this very hard, But, b, we will always be behind. Right? Because, you know, new version of task is the reason why we like me to it's a headache. I I'm not interested in it. Like,

That's my nightmare. Yeah. No. No. We just want to do what we want to do is to say, we can wrap it, and we can distribute across machines. Here you go. Alright? Let's take a quick break and talk about one of our brand new sponsors, and that is Strapi. Strapi is an open source headless CMS. It's a 100% JavaScript. They give you a GraphQL API. They give you a REST API if you want that. I've personally used it myself. I've built a couple of applications in it, and it is awesome.

You can pretty much make it do whatever you want. It's got authentication and rolls baked right in. That's some of the hardest stuff, of building it, you takes all the heavy lifting out of building a back end API. So if you wanna build the back end API for your, I don't know. Your iPhone app or for your web app or for literally anything, Strapi is gonna be the CMS for you. They have a huge marketplace of plug ins, to extend your content workflow, and integrate with the Strapi app. That's the back end that you can log in to and start editing all of your Content. It's pretty sweet. So check it out on your next, your next project that you're gonna be building. I want you to give it a try at strappy, s t r a p i.i0forward/demo.

That's gonna give you a demo of it. Yeah. At the very least, just go check out strappy.i0.

Their Freaking website is sick just like the scrolling and the I can't even explain how awesome As I need you to go to Strapi.io and and check this out.

If you are missing a content workflow, you go to market.strapi.io, and you can see Some of the awesome plugins that they offer, SEO plugins, configuration sync, CKE editor, Email designer Gatsby preview. So if you're building a Gatsby website, you can integrate this and get that live preview. You name it. I'm just scrolling forever, and the list of plugins never ends. So check it out, strappy. Io.

You can go to forward slash demo, And you can also go to their YouTube channel as well. They've got lots of videos in there. Thank you, Strapi, for sponsoring. I wanna talk a little bit more about the, caching and Skipping builds of things because, like, that that's a big one is that you make a change to something, You git commit. You automatically deploy it. And sometimes you're sitting on your hands for 10 minutes before that changes is deployed. So, like, what are some examples of, monorepos that, a, need to be like like, you can speed up The deployment or the build or whatever, and b, like like, why would you need to split something amongst Twenty computers for a build. Like like, what are people doing besides linting and and bundling? Like, What are bigger things that people doing where you're like, oh, we're saving minutes here. You know? Yeah. Yeah. No. That's a good question. Yeah. It's a so,

let me just Explain what, like, what cash means, and then I will talk about, you know, how it fits into the rest of it. Right? The way, I at first, I I called computation memoization.

People are like, okay. That is I I was got that all of negative feedback, because I was like, well because the word cashing implies that implies sometimes that get something that's outdated, Really. Right? So you like to get something from the cache, but, you know, there is a new version, there is expiration. In here, that's not the case. What we're talking about is that if I'm building, say, my Next JS app, you know, what the next the tool like Connect does and there are a few tools that do the same. It will basically say, okay. I know what you're trying to do. I'm going to include certain things into this as and input into this, build. Right? Like, relevant source files. For example, you know, relevant run time variables, What actually you typed into flags, basically. Right? And you can customize them, like, everything that's customizable so you can pass different ones. But then you go, something like that. Right? So now it has this. It then reduces this to a value, to a hash and say, okay. Now I have the string that uniquely identifies this computation. Right? Meaning that once the computation is done, I can associate the terminal output and the files created with that string. Right? Basically. Yeah. I'll put it somewhere either locally or in a, you know, Ask 3 or so, like, some distributed storage. Right? But now I have this. So next time you're running this build, I'm going to create the same, hash, right, and say, okay. Have I seen this before? Because now we have this thing. A locally organ across machines. Usually, you get something from CI. And I'd say say CI build something on Maine. You pulled main in the morning, then, well, obviously, everything should be cashed because CI just did it. Right? And, in this case, what you would do is, like, oh, I've seen the thing. Oh, someone else, computed it before.

You get the, the artifact, you know, from storage, you know, unpack it, put the files where they should be, like, as if they were created right now. Right? And then, you know, print the terminal output in exactly the same fashion. Right? So, like, it looks As if you just run it. Right? Obviously, when I say it looks like there are certain things that that would, like, time stamps would look different. You know? So it's still, like, magically replace.

Like, there are certain things you would see that, okay, We actually tell you, like, in small small bracket that that was from cash. Right? We do actually better than this. So if we know that whatever you're trying to unpack or download It's already in the right place, in the right folders. We cannot treat different, right, and say, okay. Don't do anything in there. Alright? That matters for local development where if you're doing, like, constant builds, There are tools that can watch these folders. You don't want them to be, like, triggered every time the folders have been, you know, removed on the yet even though they are the same. It's just slow to remove on the yet files if you do it In a local watch mode kind of stuff. So that's cash. Right? So when you push your PR to, CI, for example, right, one thing that can next will do, it would, first check, okay, Look at your repo. It will analyze your PR and say, what part of your repo might be affected? What might is important. Right? Theoretically might be the business PR. Like, let's say you have 3 apps, you have a share lead that only affecting 2. You change the share lead. The 3rd app, in this case, won't be to consider, because there is no way that the Share Leap affected 3rd app. Hence, you know, don't worry about it. Let's just look at the Share Leap and the 2 apps. Alright? So now it's going to test LinkedIn build Those 3 things. It might happen that if you, let's say, made a change to, you know, your send a PR, one of the apps build broke or something, as you didn't fix it. So you go and you change it. You you you push a 2nd commit. In this case, the shared loop is exact same, right, than before, than the previous runs with CI. One of the apps is exact same. And so in this case, those will be just retrieved from, from cash because the same property that happened locally. What what applies to this case, you save a computation. Okay? So, that's cash. A natural conclusion like, extension of cash. Right? It may not seem like a natural extension, but it is, is that once you really believe in cash, right, You're saying, why don't I distribute? Because what distribution is essentially is saying that if I run it on 1 agent, I can kinda retrieve from cache on a different agent, replay it. Even if you don't call it caching, it's de facto the same thing we're saying. I can replay the computation that happened on 1 machine On a different machine to enable distribution, the coordination between many many agents. Right? It's like caching can enable distribution, really. Right? Yeah. Yeah. And so so So why do we need both? Right? So like like what? With the point of caching is that you don't wanna compute something you don't need. Just a good thing in general, you know, good for the environment, Good. Fastest CI, etcetera. It's just a a a good thing. Right? And there are some use cases where it really matters, like if you have, say, a system build out of Multiple buildable things. Shared lips, did you ever touch? The shared lips is is changed only by design team or something. Right? Like, why are you rebuilding every time? Just get it from cash magically and, you know, and and, you know, and only do the apps. Things like that. Right? The second, the problem with caching is that It can help you reduce your average, CI time, but not the worst case CI time. On average, you don't reboot everything. You only reboot a fraction of things. So, yes, your average CI time can leave. You have a big rip or can go from, I don't know, 5 hours to 1 hour or to 20 minutes. Alright? The 20 minutes, but the worst like, On average, because you wanna rebuild just small fraction of it. 5 hours are very big. Let's say 3 hours to 10 minutes, so it's a bit more, you know, realistic.

And, But the worst case, CI time can still happen. In my you can change every single line in the repo or, like, reform whatever, pre check, got a plate of sauce. Right? Or, like, or you change Some super duper at the bottom, and it just changes everything. Right? The worst case CI time can happen. Right? So the even if the the worst case CI time happens once a week, If it takes 5 hours, it's unusable. It's just unusable. Right? If you're saying that now you're paranoid about change the. You're like, holy, but I don't touch the because that's how it's going to run till tomorrow. Right? You just cannot Yeah.

It doesn't make sense right now. That because it's gonna take forever. Yeah. Yeah. Exactly. It actually changes your habits in a in a worst kind of way where you're like, oh, I don't wanna touch you. It's too whereas if you're saying that the worst case CI time can be slower than the average one because on average, you're not building the slowest stop maybe maybe, you know, blah blah. But it it still should be reasonable. Alright. Let's say 20 minutes or something like that. Right? Well, the the only way for you to get it to go from 3 hours to 20 minutes is to run it on, I don't know, 10, you know, 15 machines at the same time. Right? Different parts of it. Right? Yeah. And that sort of you have to every large enough monorepo has to do distribution In some fashion, because there is no other way for you to scale. Just the just you'll you you hit a a certain point that no matter how much you optimize this cash and etcetera, You have to distribute. So the choice you only have, you're distributing sort of ad hoc by saying I'm going to run some tests here, some tests there, some builds here. That doesn't really work for large enough people because there are dependency between things. Or you do this, you know, kind of transparent Google style, Pretend it's 1 machine but runs 20 machines kind of thing. Right?

Yeah.

For most Folks who, like, build a like, if you want a in a bank or whatever. I think build some giant bank app. Right? That thing can build just build itself can run for 30 minutes. So you want to split up the bills, you know, try to run the multiple machines. Functional test can run for another couple of hours. Right? So it's, like, you you hit this limit, at an enterprise, right, very quickly.

Partially because, it's kinda hard to Maintain that code base and keep it super fast in CI because, you know, it's just lots of developers doing a lot of interesting things. Right? But apart of it, it's kinda inevitable. A large enough system will, will exceed, 1 machine. Right? It's it's just it it's a given. So the only question you you You're like, at this point, you're faced with to say, well, I need to split it somehow.

Right? And the question is how. Alright? And then you decide, you know, what strategy we you use. Right? We try to make it as you know, it's still distribution is still there, so you still need to consider something. Right? Yeah. But by and large, right now, you can pass when you create a new workspace, you can pass CI GitHub actions, and we just generate a customer, like, a 20 line workflow without distribution for you, because distribution is really cash is cool.

Distribution is what really matters, really. Because really, cash is just it's just an optimization for distribution. Like, if I had unlimited money, I could just always distribute everything. It would be still pretty damn fast. Right? It's just I would run unnecessarily.

You know? I would pay for much to compute for no reason. Alright.

Really, here, you know, we're trying to minimize your your bill. Alright? And, also, you know, it lowers the average time, average CI time for sure.

Cool. That makes sense? I'm thinking, like yeah. Absolutely. Like, it's kinda interesting. You think, like, oh, yeah. Obviously, the big one is, like, Linting and building, and then then there's tests that can take forever, and you can distribute those out. And, like, do people use For, like, image assets and and video and stuff like that as well where, like, you need to compress or something like that?

So, I actually don't know if folks do it for image assets. So, you know, if you could probably do it. Right? I would give you, like, a realistic example. So think about it. If you have, Like, an app, a shell app built out of 10 more just in more just iteration, like sort of micro front end ish things. And then they depend on, like, say, 5 shared libraries. Right? So you have you need to build the libraries, ideally, in a distributed fashion, so as fast as you can. Build those 10 things. Whatever you can retrieve from cash, And then the show, everything has to be retrieved from cash or built because for the show to appear, all of it has to come together. Alright? And then you have end to end test. Let's say written Cyprus, trying against it. Right? So you basically said, I would like to enter and test my app. That is like, oh, for you to do it, we need to do it with the show. Oh, for that to happen, those 10 things have to be built. Oh, for that to happen, those 5 things have to be built. Right? And that combo by itself, that's, you know, that could be a long time, like hours if you just run on 1 machine. But if you distribute, you can You basically look at the slowest path to the route. Right? They're just saying, well, the slowest path would be, 15 minutes, something like that. And you can realistically go from, like, hours to 15 minutes With relatively little it's it's like, you know, a very strategically placed effort by a smart team of engineers within, like, weeks. Right? Going to, like, 5 minutes CI times that case is very hard because at some point, there are just so many fixed costs in there. Just Yeah.

That is, like, kinda it becomes problematic.

But going to, like, 15 minutes for a massive repo with, like, you know, a 1000 engineers contributing to it is actually realistic. Right? Doing going below, okay, that requires, you know, like, some hard engineering, proper hats, you know, pencils, drawing on papers, you know, Like, property work. Interesting. Yeah. Next thing you know, you're

waiting overnight for a three d image to render. Because I remember I I used to have, like, a background in computer graphics, and that was, like, Very typical to to be like, alright. I'm just gonna set this to render and then come back to it the next day.

So It's so funny that, you know, here we are in the web world where we have all these compilations and code processes now, and then we do we do? We spend so much time waiting for them to finish. So, Yeah. Tools like this. Yeah. It it can do a lot of cool things. Yeah. Because they're like the the question is here is is mainly,

the moment you run end to end test in your report, you're kinda doomed. Right? And And when if you're writing up and doing task, okay, that's, you know, that's hours of compute right there. So, So it's, anyway, it's not as uncommon, this need, especially at, like, an

the through a larger work. Right? I think most teams will hit this limit at some point. Yeah. And and if for those of individual devs out there, again, you you these aren't problems that you have until you have them. And it it does usually take place in larger projects.

And maybe not, like, larger in terms of size, but larger in terms of scope and breadth and and people working on it. Yeah. Cool.

Is there anything else you wanted to mention before we move into the next section of this? I I I would say one thing. Just, is, so we talk about scale. So I don't wanna come across Oh, if you have a small app, you know, go away. Do your own stuff. You know? Yeah. Because, like, it's it's the same with task. With task, it rocks at scale, I think.

But it actually can be useful for, like, a at a small project because of the guidance it gives you. Like, factoring works, etcetera. Right? You know, like, you know, other completion work, things like that. Right? So there is 2nd aspect to TypeScript, which happen to be useful scale, but it's actually useful for no like a new A new like, sort of someone who's learning as well. Right? You need to learn task, but at least when you use a new tool, right, it actually can guide you quite well. Right? And, same Kinda here if you say try to build a React Native app, right, with with an x because we generate so many things with Versus Code support for you that you can just Click through with the file tree and kinda it will put the whole application for you, right, and make it runnable, etcetera.

Sort of The side effect is that it can be easier to, to use something, right, if you are new to that. Right? Because it is less common, like, it's less scary. You don't need to copy and paste samples that don't don't fit exactly right or whatever.

It kinda can scaffold things in a very sophisticated way. So that's a side effect that if you know, like, some new topic, like, if you're trying out, you know, remix or whatever. Right? There are upsides to an egg that have nothing to do with scale. And, like, just side effects of us caring about developer economics, right, and the editor integration, things like that. Right? Awesome. Should we get And to the

the questions we have here, Scott? Yeah. We gotta come up with a cool name for them, but right now, they're just lightning questions.

They'll be Yeah. They'll be some sort of supper club based Name. Come and get it questions. It's so early.

We don't even have a name for it, but we thought we would ask the same set of questions to every guest that comes on.

So we'll we'll sort of just rattle them at you, and you can answer however long you need to. Okay. Okay. Sounds good.

What computer

and keyboard do you use? Okay. So I use, I'm actually on a, like, a MacBook Pro 14, which I like. I I used to go on Linux for years, but honestly, when m one came out, m one is like and then now, you know, the m one max, etcetera.

It's just so good that it's There's some that exists. Yeah. Yeah. And the keyboard is I use HHKB, which is a a like a mechanic I don't know if it's considered mechanical, but it's basically as a very unique switch made by 1 company in Japan.

I like it a lot. I think it's very pleasant to type on. Right? So h h k b.

A c h k b? H h h. Yeah. It's like I think it's like something hacking. Yeah. Yeah. Yeah. Yeah. Oh, okay. People. Yeah. Yeah. Scott will put a link in the show notes for it. That sounds cool. It's very cool. So it's, like, when you look at it, you're like, okay. That looks a bit retro. Right? Yeah. Yeah. Accepted.

It it's good. Right? It's, find a friend with such a keyboard so you can play, like, play with, you know, how it feels. It just feels very different from, let's say, you know, MX, switches and stuff. So Interesting. Yeah. Love the feeling or you don't like? So if you love it, just get it because it's very hard to get the same feeling from Amex, competitors.

Yeah. This looks nice. I'm just looking at this. Cool. What about a phone? A phone. It's just an iPhone, so I'm bored. IPhone.

Yeah. And text editor, theme, and font? Okay. That's a a oh, the text editor, I use 3 text editors depending on on whom I'm Speaking of this Woah. Wow.

So and the reason is that they're they're good at different things. Right? So for any heavy lifting development, I actually use IntelliJ with a solarized, Dark. Right? Because of the extra stuff in Telaj7, that's just very hard to replace.

For small edits, I use a Lunar VIM, which is like a a set of plug ins for Neovim, which is a new version of VM written in Lua.

I like it. So it's like when you jump into, like, a folder and just, Oh, wait a minute. Like, yeah, I can make a change in, like, 5 seconds and jump out and, you know, I need to open anything. Right? It's convenient for that. Who is this? And I use Versus Code for all the demos. People love Versus Code. I also love Versus Code. Versus Code is amazing.

So because most people use Versus Code in a web space at least. Right? So I use all 3. So my muscle memory is a bit kinda clunky, you know, when I speak between them because I like yeah. But it's, I would say most of the time you want more than 1 because It's very hard to beat them at small edits, but I kinda find it's not good enough for for big edits. Yeah. You know? At least for me, maybe I'm not good enough That's so sad. Oh, that's really interesting. Yeah. Next question. If you had to start from scratch right now, what would you choose to learn? I actually don't know. It's a hard question.

On what I wanna do. In general, I find that things that are timeless tend to be like a a dim with example or like bash or something like that. Right? Yeah. You look at it like you're holding. Why would I ever need it? Right? When it's like, but I've, you know, been a a programmer for around For many years, for 20 years. Right? Yeah. And both of them are still around. Yeah. Right. Yeah. Right. Yeah. So, it's like, If I if I if if someone chooses to learn bash right now, I guarantee you, 10 years from now, you will still be using it. And I Mhmm. In terms of practicality, I think GS is is is good. I like JavaScript slash task good because I like the, How versatile it is at everything.

Right? So you'd like pretty much anything you can place. I mean, I'm talking in terms of like writing drivers or something. Right? It just does it really well. Right? And and the tooling finally kinda on par with what, you know, Java and c sharp used to have. Right? Actually, Versus Code right now is Like, basically there. Right? Yeah. So you get fantastic tooling and, you know, it it can do everything. Right? And you have to use it anyway because you cannot get rid of it. Right? Oh, that's true.

But I actually love it. I dodge it.

Yeah. I I I actually do love it. So, people use it like, oh, I I really would wish I use this. No. I actually think the TypeScript is like, I enjoy writing it, and it makes me happy. Yeah. Oh, that's great to hear. What is one piece of advice you have for beginners? This is something we have all the time. We have lots of beginners listen to the podcast, and you've been at it for so so long. You've probably seen everything.

Any advice you have for beginners? Yeah. There is 1 thing that I do, that I know some other folks do. Right? Is that, we shouldn't apply necessarily to beginners. But I think at the beginning, you the impact is much stronger. Right? Yeah. That if I learn something, let's say, in a given week, I've done some interesting thing. Like, I I have a discovery about a particular tool or whatever. Right? I would take, an my notebook. Like, I would show it right now. They are spread. And I would draw a picture. Right? A picture with few words supposed to like a diagram with, like, idea for me, picture would be better.

Pointing out the lesson learned and the the like, the idea would be imagine you read something about virtual machines, and you're like, oh, that's pretty complicated. Not to the beginner because it's, you know, technically stop.

Just draw a stack, put some references, imaginary like, object like like, just basic diagram. Like, that's what I have. Right? And you do that once a week for 50 weeks. Alright? You have something that you discover that week. Any week has interesting stuff. Right? Just find one thing, and then just one thing.

Watch an interesting talk, and then say, okay. I watched this talk. Let me convert the picture. Right? And And at the end of the year, you're gonna have 50 pictures.

Right? And a lot of senior engineers with, like, 20 years of experience Don't have 50 interesting pictures in their hand, so you already be ahead of them. So Wow. It really doesn't take that long if you just say, okay. I need to do like, figure out one novel thing Once a week. Right? Something that really pushed me forward. Like and, like, really in a few years. Because everyone knows those. Like, Some are juniors, like, oh, I have 2 years of experience, and they're, like, super fast, super sharp. Right? Have deep understanding of things. Lack experience, right, but already kinda Can do crazy stuff. Right? You're like, You know?

Because they're more we're paying attention, right, to those type of things. Right? Oh, that's great. I. These questions are awesome, Scott. These we're getting lots of good info.

How do you stay up to date on stuff? Oh, this is a tough one. So I have people who tell me interesting things, because I actually have my Twitter, blocked. I only can write but cannot eat because I find it exhausts me so much. Yeah. Like, wow.

Like so I don't consume many social media. Right? So, usually, I I know enough, super duper smart people who aren't, and they tell me, I read I read this 1 tweet and, like, watch this talk, and I get, like, a feed from, you know, this, not everyone has this luxury, obviously. Right? But, like, I have a good network of people who are, you know, very smart and and and staying up to date, and they help me staple it without my having to pays this for me an enormous cost of being on Twitter because I find that and now on Twitter, it's like, I I get older. Like, I get a 1000 years older. Yeah. Oh, yeah.

Yeah. I totally get that.

Wow. Alright. Last question.

What is one thing you are really excited about In the future of web development. Yeah. I'm I'm actually pretty happy with how it's it's

I think it's one thing I would, like, Maybe I would like to see is, some form of types making into, JS pack. Right? So the, whether it will happen or not, you know, because there are advantages to optional typing the way TypeScript does it, which is it's purely editor informing, but it's not, execution foreman. Right? But, really, if you had a few of those, we perhaps the system could have been faster. When I was at, On angles, there was some poke on the chrome team. They discussed it, etcetera, but it's hard to get it, without, you know, screwing everyone over. So I don't know. So Yeah. That's one thing. Well, because I really believe JS and JS rock. Okay? So people like to say, oh, why don't you build everything in Rust and then plug it into some, like, Foreign language interface or whatever. You could, but there are advantages to just using the same language without having to transition to a different language. Right? Either then, like, I expand the applicability of particular tool to, like, 98% of use cases like that. Right? And, honestly, There are advantages to having, like, a lingua franca, the thing that everyone knows. Right? As we all speak English, right, English is not method language. Right? We can coexist Effectively and, you know, and I have a lot of interesting collaborations as a result. Right? The moment you divide folks, you know, anyway so I I really believe that JS can be the space of this. You know? Everyone speaks at at least to some degree, and it's used for Yeah. You know, when the cooler things can come out as a result. Right? And then They're cool in other amazing, you know, communities, etcetera, right, where they don't have the same property. Right?

Yeah. Yeah. Totally. Alright. Well, last thing we wanna ask you, is there anything you'd like to plug before we send you off on your way? We call it the shameless plug. Yes. Yeah. Yeah. It's, I mean, I've been plugging it the whole time. Right? So,

go and check out NX if you, especially if you're a JavaScript or TypeScript developer, you know.

Even if you don't end up using it, and then it can inform you about some other ways of developing that you can then, you know, try to implement, you know, on your own. Right? So check it out. And, if you have any questions, you know, you can go to our community Slack, ask questions. The core team hands out there all the time. You can even DM me on Twitter. I don't use Twitter, but once a month ago and see if someone send me a message.

So it does happen Very occasionally, and and and I might reply. So Awesome.

Cool. Well, thank you so much for coming on. That was really helpful.

It really gives some insight into tooling around monorepos, and we appreciate your time. Yeah. Thank you, folks. Yeah. Thanks for coming on. Thanks again. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player Or drop a review if you like this show.