Should you replace prettier? Maybe

Bassel Al-Sayed — Thu, 22 May 2025 09:12:29 +0000

For years, I've been prettier's biggest fan... Introducing it to every codebase at a new role, instantly adding it to any new repository, installing additional plugins such as tailwind or xml and of course, ensuring the "Format on save" option is switched on.

But recently while building algovi I encountered some turbulence for the first time with my first love of formatting.

The source of this frustration? Multiple operators.

Consider the following:

const result = a + b * c - d / e;

To understand it, you need to recall operator precedence.

Perhaps most developers would prefer:

const result = (a + (b * c)) - (d / e);

Is it uglier? Depends who's answering. However, most of us would agree it's more readable.

Alas, when it comes time to format, the parentheses are nowhere to be found.

This example may be trivial, but it's easy to see how this problem can get worse.

The solution?

I don't have a good one...yet.

My first thought was to use no-mixed-operators, which can be setup to enforce parentheses on any operator you like.

However, after setting it up. I noticed my prettier eslint rule was still complaining (yes I did make sure the rule sat after my prettier rules). After some digging I found this comically long issue where some developers resolved to stop using prettier entirely.

Why?

The only way to get prettier to play nice with this rule is extraction:

const mult = b * c;
const div = d / e;
const result = a + mult - div;

It's not terrible. Potentially it's actually preferable for longer equations. For my use cases though, it breaks the flow of the equation. Sometimes, wrapping segments in parentheses communicates intent without polluting the namespace with throwaway variables.

Potential solutions

The only realistic solutions for my use case I found are to replace prettier for js/ts altogether, leaving it to format css, markdown etc. which I'm not eager to do.

@stylistic/eslint can be configured to pretty much replicate prettier's behaviour, but I'm an all or nothing guy. If I'm going to add an extensive plugin I'd like to use it properly, replacing my react and typescript rules with it as they recommend. I will probably get round to this when I have the time, updating my core eslint config

biome is a replacement for both ESlint and prettier. It's a pretty cool project but I've already spent considerable time setting up my ESlint so this is not a realistic option.

In defence of prettier

If you have a more complex equation:

const result = a + b * c ** d / e - f % g << h & i | j && k || l;

Prettier will format it closer to what I am suggesting above:

const result =
      (((a + (b * c ** d) / e - (f % g)) << h) & i) | (j && k) || l;

This is a case for extraction though. Because similarly to ternaries, there are diminishing marginal returns on parenthesis.

Closing thoughts

Prettier has been an essential tool for me for years.

However, this experience has brought me to the conclusion that code formatters should aid readability, not rigidly enforce minimalism at the cost of comprehension. Until Prettier allows an option to respect extra parentheses for clarity, we are stuck choosing between formatter compliance and readable math. Does a formatter deserve to have this much power?

Rediscovering React: Visualise algorithms in the browser!

Bassel Al-Sayed — Wed, 21 May 2025 10:58:31 +0000

Recently, I took on a side project that’s been both a technical refresher and a creative outlet: a pathfinding visualizer built with React.

The motivation was simple. I missed building things for the sake of building. Recently in my career, I’ve been more focused on svelte and flutter and I wanted to reconnect with my react foundation. With no time pressure or stakeholder demands, I gave myself the space to explore, iterate, and have fun.

The project itself is a visual tool that lets users see how different pathfinding algorithms work in real time. Think Dijkstra’s, A* etc.

It was a great way to sharpen my JavaScript fundamentals, play with some awesome libraries, revisit hook abstraction and folder architecture, and even brush up on algorithmic thinking.

More than just a technical exercise, this project reminded me why I love software development and particularly frontend: the immediate feedback of building, breaking, and fixing —and the satisfaction of watching an idea come to life on screen.

If you’re curious, you can check it out or have a look at the code here