I'm never writing another Makefile ever again

If there's one thing us software developers are really good at, it's taking something built for one specific purpose and coercing it to perform tasks it was never intended for. Famous examples of this phenomenon include running JavaScript on the server thanks to Node.js or running web apps on the desktop thanks to Electron. Whilst I have opinions on both of these, perhaps the biggest coercion that I often perform when it comes to my own projects is when it comes to make. Originally, Make was designed as a build tool for the C programming language. However, over the years, it's been adapted by developers to be used more as a task runner. For example, in my projects, I often define a make file with recipes for common project actions such as make build to compile my project, make dev to run it in development mode, and make test to execute my test cases. The benefit of doing this is that it provides a way to simplify any complex commands whilst also providing a common interface across different projects, no matter the underlying language or tooling. Unfortunately, I've been recently running into issues when it comes to using Make with the current project that I'm working on, which is a video editor written in Rust. Whilst make works for the more simple recipes that I've set up, the more that I try to push it, the more it starts to show its constraints, as well as the fact that it's kind of outdated. For starters, I always get caught out by the fact that it requires tabs, not spaces, which means every time I make an edit to my make file, it ends up broken. Additionally, because make is intended to make things, then it often expects to produce a file. And because a lot of my targets don't, then I often need to use the dot phony declaration in order to make it work with non-producing tasks. If that wasn't bad enough by itself, however, one thing that absolutely bothers me is that it completely sucks whenever I need to perform string handling or when I need to provide variables, be it through the environment or just through plain arguments. Perhaps the biggest friction that I'm finding, however, is that it has no native cross-platform support, which given that my project supports Windows, Mac OS, and Linux means that in order to have a single make release command, I have to do some Uname magic. So, I just end up setting one up for each respective target. Now, to be fair, whilst none of these are complete blockers, all of these points of friction make working with make feel rather unenjoyable. And given the fact we're in 2026, it just makes the entire tool set feel rather archaic. So I decided to take a look at finding a better solution, one that would be much better suited to the era of application development. As it turns out, I not only found one that solves all of the issues that I have with make and make files, but it also brings a number of other features that one would expect for a modern software development tool. This tool is just and it's so good at being a taskr runner that I don't think I'll be writing make files ever again except maybe in a couple of situations. Not only does just fix many of the issues that I mentioned when it comes to make and make files such as allowing spaces not needing do phonies and also providing crossplatform support for recipes out of the box. But it also brings a number of other quality of life improvements such as built-in loading without you needing to add it into your project. the ability to pass in arguments to commands uh which yes is just incredibly useful and even better shell integration using flags such as d-list which lists all of the available targets or d-choose which provides an interactive menu you can select from. Therefore in this video let's take a look at how just works and some of the features that I really like by adding just file into the following project which is a simple RS API built using Axom. This is slightly different to my current projects setup where I have more of a mullet stack going on. Uh this is because I have business on the front end i.e. using Rust and party on the back end using TypeScript. Uh which actually brings up a good point. If you yourself are interested in back-end web development using TypeScript or Go and you happen to like playing role- playinging video games, then there's a good chance you're going to be interested in the sponsor of today's video, boot.dev. Boot.dev Dev is an online platform that will teach you the skills to become a back-end web developer using either TypeScript or my personal favorite, Go. Whilst learning languages is important for the modern era of software development, the key benefit of using boot.dev is that they aim to make the learning experience as enjoyable as possible. They achieve this by taking concepts from role- playinging video games, which means that whilst you're learning to code, you'll also be gaining experience points, leveling up, obtaining achievements, and competing for first place on the global leader board. If all of this sounds too good to be true, then fortunately, you don't have to take my word for it, as all of the material on boot.dev is both free to watch and read. However, if you do want to make use of the interactive features such as code challenges, AI assistance with Boots the Magical Wizard Bear, and all of the game-like features that I mentioned before, then you can get 25% off your first purchase by using my coupon code Dream to Code when you check out. That's 25% off either your first month on a monthly subscription or your first year on an annual one, which is a really great deal. Not only that, but if you find the platform just doesn't work for your style of learning, then there's no risk as boot.dev dev offer a no questions asked refund for the first 30 days. So to try everything that boot.dev has to offer then visit using the URL on screen or use the link in the description down below and make sure to use my coupon code dreams a code to get 25% off your first purchase. A big thank you to boot.dev for sponsoring this video. Okay, so now that I've spent time glazing just, let's go ahead and take a look at how it actually works by adding it to a new project. In order to do so, the first thing we're going to need to do is to install it onto our system. You can achieve this through a number of different ways. Either by using your operating systems package manager or through the use of cargo. In my case, because it's looking very much like 2026 is going to be the year of Rust, at least for me, then I'm going to go ahead and install it via cargo using the following command. Once installed, I can then go ahead and create a new file inside of my project root called just file. With the file created, let's begin with a simple yet commonly used command, which by the way is called a recipe when it comes to just and also make. To begin, let's go ahead and define a new recipe called build, which we can do as follows. Here, I'm specifying the name of the recipe called build followed by the command I want it to run. In this case, cargo build. One thing to note is that each recipe in just runs as a shell script uh using sh by default, which means your recipes can have multiple commands and various levels of complexity. Now with our first recipe defined, we can use it like we would do make. However, before doing so, let's quickly run the just--List command. This command lists all of the available recipes inside of a just file, which in our case is just the single build command. Similar to make, just is self-documenting, although it does come with a couple of key improvements. To show what one of these is, let's go ahead and add in another recipe, uh, this time called test, which will run the cargo test command. With both of our recipes now defined, let's go ahead and add in a comment above each one describing what it does, which is done using the following syntax of the pound symbol. Now, when I go ahead and run just--list, you can see it prints out both recipes, each with the documentation we added above. Very cool. The second self-documenting benefit that just file has over make is that it allows you to group recipes together. For example, let's say I have the following just file with recipes to build, test, and release. uh by using the following syntax we can easily group recipes together so that when I run just d-list you can see that each recipe is printed with its respective group improving the overall readability of what recipes are available. Okay, with our recipes defined we can now run them similar to how we would do using make by calling the just command followed by the recipes name. In this case I'm running just build which when I go ahead and execute will call the cargo build command. Of course, if you're not too sure which recipe you want to use, then you can also use the d- choose flag in order to bring up an interactive mode, enabling you to see and cycle through all of the recipes in your Just file. Very cool. In addition to being similar to how make works, just also uses a very similar syntax, but with a couple of key improvements. For starters, there's no need to define a doony attribute when specifying recipes that don't produce files, which is a really welcome improvement because when it comes to most modern use cases, they typically don't. And the second big improvement is that I'm able to use spaces with my just file instead of being constrained to using tabs, which is the case when it comes to make. Despite these syntax improvements and the use of d-list and d-w, there's not really that much difference here when compared to make. So, let's take a look at another feature that just provides one that's actually quite painful to achieve when using the old make command parameters. To show how these work, let's go ahead and add in a new recipe called dev, which will use bacon to start up the development server. If I try and run this, you'll see I encounter the following error. This is because I have multiple binary targets inside of my cargo configuration, the API and a worker. Therefore, for this command to work, we need to specify which one we actually want to execute. Whilst I could just hardcode this value into the dev command as follows, a much more versatile approach is to make use of a parameter uh which will allow us to specify either binary whenever we want to. To do so, all we need to do is specify the parameter name after where we define our recipe as follows. In this case, I've defined a parameter called bin. Now, in order to use the value of this parameter, we can just interpolate it into our command using the following syntax. Now if I go ahead and use the just dev command again, I can pass in the binary I want to run as a positional parameter and it will now work as expected. Very cool. Whilst this is pretty cool, it is a little bit tedious to have to specify the binary every time I want to use the justdev command, especially as most of the time I'm going to want to be running the API instead of the worker. Fortunately, just allows you to define a default value when it comes to parameters, which we can do as follows. Here I've specified it to be API. Now you can see when I run just dev, it automatically runs the API binary without me needing to specify it and I can still easily override this value if I need to. Again, very cool. In addition to this, another valuable parameter I have configured in my own project is when it comes to the test recipe. In this case, I like to define a parameter called filter so that I can constrain the command to execute only a specific test or group of tests rather than the entire suite. By the way, you may have noticed that the API and worker failed to run due to them both missing a database URL environment variable. Whilst this could be solved using an argument, a better approach is to make use of a variable of which just supports in a couple of different ways. For starters, we have local variables which we can define inside of the just file as follows and then reference inside of our recipes. Uh by the way, the at symbol here is used to mark the command as being silent uh meaning that it just won't print it out. Whilst local variables are really useful to prevent magic numbers and magic strings, these variables can't be overridden. Which means if you want a value that can be overridden, you'll instead need to use a parameter or an environment variable. Using an environment variable inside of a just file is incredibly familiar. All we have to do is use the posics syntax as follows. Here you can see I'm referencing the environment variable of user inside the echo command which if I go ahead and call just hello you can see it says hello to the value defined inside of my user environment variable. By using environment variables it means we can easily override this value by setting it as follows and then running the following command again which as you can see now produces a different result. Additionally, we can also define or export environment variables from within our just file, which will make these available to each of our recipes. For example, here I'm exporting the user environment variable from within my just file, which it will then use the value of instead. One thing to note is that any defined or exported environment variables inside of your just file have a higher order of precedence compared to those you pass in. Uh meaning basically you can't override them. In addition to being able to define environment variables, just also has support for loading EMV files, although this isn't enabled by default. In order to do so, we need to add in the following line into our just file. Now, if I go ahead and run my code using the justdev command, you can see it connects to the database URL I've defined inside of myv file in my directory. Very cool. Additionally, you can also override or specify which file you may want to load. For example, if you're using something like next.js, js which comes with av.local local then you can just specify this file using the following line after setting to use. EMV in addition to having the ability to add variables another area that I find to be really powerful when it comes to using just is for defining platform specific recipes. For example, let's say I want to define a recipe for easily opening up the landing page of my new project. Uh when it comes to Mac OS, I can define this using the following recipe calling the open command with the URL that I pass in. If I go ahead and run this, you can see it works as expected. Unfortunately, however, if I try to do this on Linux or Windows, then this recipe will actually fail uh due to the fact that the open command doesn't exist. Whilst I could solve this by making use of aliases inside of my shell configuration, a much better approach is to use the platform attribute to constrain this recipe to Mac OS only. Now, if I go ahead and use the just-list command on Linux, you can see that the recipe is no longer available. However, we don't just have to settle for this. As by using platform attributes, we can specify the same recipe, but with different behavior for each platform. To show how this works, let me go ahead and add one for Linux that uses the XDG open command instead. Now, this recipe is available to us. And this time, it'll work on Linux platforms, uh, provided XDG open is installed. Additionally, we can also define a recipe for Windows that does the same thing as follows using the start command. Platform attributes are incredibly useful when it comes to building a cross-platform project. And in my case, for my editor project, I make use of these with the release recipe so that it will bundle and upload for that specific platform without me needing to do some youname kung fu or passing in the platform as an argument. As you can see, just provides a number of improvements over legacy make files when it comes to running tasks. But this really only touches the surface of what it provides with some other notable features being support for conditionals where you can use if statements to change the behavior based on variables or even the operating system which is really useful if you need to define different flags depending on the context. Uh recipe dependencies which allow you to specify which recipes one depends on. So in this case I have an example set up where running just deploy will automatically run the just test and just build recipes before doing so. Although it is worth noting that unlike make just doesn't support parallel execution of dependencies so they'll run sequentially. And another notable feature is support for private recipes where you can prefix a recipe name with an underscore to hide it from the d-list output. This is great for defining helper recipes that you don't want to clutter your public interface. As you can see, all of this is an improvement to the humble make file. But like everything in life, there are some reasons why you'd still want to use make. For starters, make is ubiquitous. It's available on most Unix systems by default or when you install the build development tool chain whereas just does require an additional step sometimes through the use of cargo. Additionally, as I mentioned before, make can run independent targets in parallel using the -j flag which makes it useful for running concurrent tasks. And perhaps the most major reason as to why you'd want to stick with make is if you're building a C or C++ project. Although in that case, I would probably use something like CMake or even Zeg. But that's just me. Other than that though, when it comes to running tasks in a project, Just is just simply a better tool, and it's quickly become my go-to replacement for Make in all of my current projects, especially whenever I write code in either Rust, TypeScript, or Go. Speaking of which, I want to give a big thank you to boot.dev for sponsoring this video. If you're interested in learning back-end web development in a way that's actually enjoyable and approachable, then make sure to check them out using the link in the description down below and use my coupon code dreams of code to get 25% off your first purchase. Otherwise, I want to give a big thank you to you for watching and I'll see you on the next one.

Except, maybe, if I'm writing C Click this link https://boot.dev/?promo=DREAMSOFCODE and use my code DREAMSOFCODE to get 25% off your first payment for boot.dev. For the longest time, Make has been a staple in my developer toolkit, acting as not only a build tool, but also as a task runner. Whilst there's good reasons to use Make as a build tool, I often find that I run into friction whenever I try to use it as a task runner, especially in 2026. Fortunately, I've found another tool to run tasks in my projects, one that's much better suited to the era of modern development. Links: - Just: https://github.com/casey/just - Rust video Editor: https://getkiru.app - Example Project: https://github.com/dreamsofcode-io/just-demo - Bacon: https://dystroy.org/bacon/ How I edit my videos: https://getkiru.app My Gear: - Camera: https://amzn.to/3E3ORuX - Microphone: https://amzn.to/40wHBPP - Audio Interface: https://amzn.to/4jwbd8o - Headphones: https://amzn.to/4gasmla - Keyboard: ZSA Voyager Join this channel to get access to perks: https://www.youtube.com/channel/UCWQaM7SpSECp9FELz-cHzuQ/join Join Discord: https://discord.com/invite/eMjRTvscyt Join Twitter: https://twitter.com/dreamsofcode_io