Learning `just`: A Practical Task Runner

Nyakio Muriuki J — Thu, 03 Sep 2026 13:30:33 +0000

I've been learning just recently.

I came across it while setting up a Python project and looking for a simple way to collect all the commands I use during development.

This started with something I got used to in Elixir.

One of the things I really like about Elixir projects is that you can put the common development tasks behind simple commands/aliases:

mix format
mix test
mix ci

You don't have to remember every command that runs underneath. The project gives you a small set of commands and you use those.

I wanted something similar for a Python project.

For example, instead of remembering all the different checks I need to run, I wanted to be able to do this:

just ci

and let the project take care of the rest.

My first thought was Make

Make was the obvious choice.

I've used Make a lot, and it works. It's installed almost everywhere, most developers have seen a Makefile before, and there is a huge amount of existing knowledge around it.

So I started there.

The setup was pretty small:

format:
    uv run ruff format --check .

lint:
    uv run ruff check .

typecheck:
    uv run mypy src/

test:
    uv run pytest --cov=src --cov-report=term-missing

ci: format lint typecheck test

That gave me exactly what I wanted.

I could run:

make format
make lint
make typecheck
make test
make ci

Nothing complicated.

But while doing this, I kept seeing just mentioned in newer projects.

That made me curious.

Not because I thought Make was bad. I still use it a lot, and I have no problem reaching for it.

I just wondered what just was doing differently.

Was it basically Make with different syntax? Was it easier to use? Did it solve some of the small annoyances that come with Make?

So I decided to rebuild the same thing in just and see.

The `just` version

The nice thing was that I didn't have to change any of the actual commands.

I just changed the wrapper around them:

format:
    uv run ruff format --check .

lint:
    uv run ruff check .

typecheck:
    uv run mypy src/

test:
    uv run pytest --cov=src --cov-report=term-missing

ci: format lint typecheck test

That's pretty much the whole file.

Now I can run:

just format
just lint
just typecheck
just test

Or everything with:

just ci

The ci recipe depends on the other four recipes, so just ci runs them in order and stops when one fails.

For what I was trying to do, it felt very familiar.

And that was probably the first thing I noticed. I didn't really have to learn a new way of thinking about the problem.

A few things I liked about `just`

The basic syntax is very similar to Make.

You have a recipe, optional dependencies, and then the commands to run:

recipe_name: dependency1 dependency2
    command to run

But there are a few differences that make sense when you're using it mainly as a task runner.

No `.PHONY`

With Make, you often have something like:

.PHONY: format lint typecheck test ci

That's because Make is also a build system and cares about files and timestamps.

For these development commands, I don't really need that behaviour.

just doesn't use file timestamps to decide whether a recipe needs to run, so there is no .PHONY declaration to maintain.

No tab problem

Then there is the classic Make issue where a command needs to be indented with a tab.

I've definitely lost time to that one.

With just, you don't have that same tab requirement. You use normal indentation.

It might seem like a small thing, but I like small improvements in tools I use.

`just --list`

This was another nice surprise.

You can run:

just --list

and get a list of the recipes available in the project.

You can add comments above recipes too:

# Format check
format:
    uv run ruff format --check .

# Run tests
test:
    uv run pytest --cov=src --cov-report=term-missing

Those comments can then show up when listing the recipes.

You can also make just itself show the list:

default:
    @just --list

So a developer can clone the project and run:

just

to see what is available.

I like that because the task runner becomes a small piece of documentation.

But is `just` actually better than Make?

I'm not sure that's the right question.

Make is still a great choice in plenty of situations.

If I'm working on a project that already has a Makefile, I'm not going to suggest replacing it with just just because just is newer.

And if I'm writing something that needs to work in an environment where Make is already installed, that is a pretty good reason to use Make.

The thing I found interesting about just is that it feels more focused on the thing I was actually trying to do.

I wasn't building anything based on file timestamps.

I just wanted names for common commands and a way to combine them.

For that use case, just is pretty nice.

But it also comes with a trade-off. Unlike Make, you probably have to install it first.

So the comparison for me looks something like this:

	Make	just
Already installed	Often	Usually not
Task runner	Yes	Yes
Build system	Yes	No
`.PHONY`	Often needed	Not needed
Tab requirement	Yes	No
Task listing	DIY	Built in
Cross-platform	Possible	Designed for it

Neither one wins across the board.

Make has ubiquity.

just has a nice developer experience.

Which one makes more sense depends on the project.

There are other options too

Once I started looking into this, I found quite a few other tools doing roughly the same thing.

Task (go-task) was one I came across. It uses a YAML Taskfile.yml and has some useful features around variables and templating.

For Python, poethepoet was another interesting option. It lets you put tasks in pyproject.toml, which can be nice if you don't want another configuration file.

And if you're working in Node, npm scripts already give you a similar setup through package.json.

They all solve a similar problem.

You have a bunch of commands that developers need to run, and you give those commands names so people don't have to remember all the details.

The differences are mostly around syntax, ecosystem, and how much functionality you want.

So, am I switching to `just`?

For everything? No.

I'm still going to use Make.

If I open a project and there is a Makefile, I'll use it. If I'm working on infrastructure where Make is already expected, I'll probably use it there too.

But for projects I start myself, I can see myself reaching for just.

The thing I liked most was how little there was to learn.

My existing commands stayed exactly the same. I just put a small, readable interface around them.

That brought me back to why I started looking at this in the first place.

In Elixir, I'm used to having commands like:

mix ci

that give the project a simple interface for common development tasks.

With Python, I found myself wanting the same thing.

Make was one way to do it.

just is another.

I'm glad I spent the time learning it. Not because it replaced Make, but because now I know another tool that fits this particular problem really well.

And sometimes that's enough of a reason to try something new.

DEV Community: Nyakio Muriuki J

Learning `just`: A Practical Task Runner

My first thought was Make

The just version

A few things I liked about just

No .PHONY