Birth of Prettier

https://blog.vjeux.com/2025/javascript/birth-of-prettier.html

by garretruh • 10 months ago

77 56 10 months ago

blog.vjeux.com

When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting.

I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on all of the files, setting up CI/CD rules to enforce it, and teaching everybody how to set up format-on-save in their editors. Some people whined about it ("I don't like the way it does curly braces! Waaah!") but I was persistent and unwavering.

All these years later, I'm elated that whenever I join a new company - engineering orgs almost always have all of this already set up, not just with JS/TS but almost every language out there. It makes getting up to speed on the actual content of the code so much faster.

If I join your engineering org and you aren't using enforced, automatic, opinionated formatting on every single line of code that gets written that's a huge smell.

DanielHB3• 10 months ago

One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases.

I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because they statically enforce code-style.

It has become standard feature in most languages stacks these days because of Prettier and gofmt.

whstl3• 10 months ago

+1.

I'm a huge fan of custom linter rules.

Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things.

This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter.

I hate that a lot of people read the assertion that "PR reviews are a form of creating an internal coding culture" and become human linters, only nit picking PRs for the power trip. This is not only annoying but also makes people ignore the more important parts of the review.

I even made it a rule in every team I managed: if something is bothering you constantly in PRs and it can be replaced by a custom linter rule, let it go and write a linter rule for that later. I only met two people in my career who opposed this, and that was 100% because it made their nit-picking redundant.

throw45524947• 10 months ago

I've recently worked for a company that had no linter and no formatter. It was Java backend, but we have those tools too :) My first PR received 70 comments, 98% was nit-picking. Things like "Rename `MyDomainEntity source` to `MyDomainEntity myDomainEntity`" (it was a MapStruct mapper). I was also asked to remove a simple parent class that I used (in tests!) to reduce duplicated code, something like `MyNewFeatureBaseTest`, because Create, Get, Update, Patch, Delete test classes where sharing some functionalitites.

They fired me during the trial period after this PR.

Before this experience I was also "let's follow conventions even if they are bad", but now that I saw this argument applied so blindly against me, where I wasn't even allowed to use a common class to avoid duplicated code, I don't know, it just feels wrong.

3 weeks later and I'm still unsure if I was really wrong or just being gaslighted. I get conventions like "we split tests in create, get, etc. classes" or "the type of the incoming payload must be called `SomeEntityInput` and the output must be called `SomeEntityOutput`", but 70 comments? And you want me to duplicate code because that's what you did until now, "because conventions"?

normie3000• 10 months ago

format-on-save

A dystopian feature!

whstl3• 10 months ago

I'll do one better: In the recent teams I worked, we even had "organize imports on save".

speed_spread• 10 months ago

Fight the power, setup format on checkout with your own rules.

jjj1232• 10 months ago

I love format on save. I can type (or paste) ignoring whitespace, hit save, and everything pops right into place for me.

Also, stuff not auto formatting is usually immediate feedback that I didn’t match my parenthesis or have some other major syntax error.

CaptainOfCoit• 10 months ago

Sounds similar to my personal history of adopting StandardJS (https://github.com/standard/standard) as soon as it appeared, doing the same at the org I was at the time. Based on memory, seems StandardJS appeared before Prettier in the ecosystem?

It seems weird that StandardJS wasn't mentioned in this article, as surely the author must have known about it before starting Prettier.

Still to this day I just use StandardJS when starting a new project, not even sure what the difference against Prettier is, it's more or less the same as far as I can tell but maybe faster?

nxrabl• 10 months ago

Standard always struck me as kind of scummy - it tries to present itself as something bigger than what it really is, which is a tiny CLI wrapper around one guy’s ESLint config. You have to scroll way down the FAQ section before ESLint even gets mentioned. The author is just squatting on the “standard” namespace and using it to blag his way into relevance. Think how much more good it would do if the sponsors of this project were actually supporting ESLint directly instead of this useless middleware.

dSebastien• 10 months ago

What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom

dleeftink• 10 months ago

Wouldn't that result in having to reorient yourself between the formatted/non-formatted files when comparing commits and messy code that is being worked on? Mind, I do value auto-formatting but wonder about the navigational costs when used this way.

jacknews• 10 months ago

maybe code should be stored with no formatting, only the required whitespace, and the editors/viewers are responsible for applying formatting. Then formatting will never cause confusion in diffs.

nicbou• 10 months ago

The hook is just a safeguard, but ideally your editor should run the same code.

foofoo12• 10 months ago

My love for Prettier went to hate when they started fucking up my parenthesis in calculations. Still an open issue from 2017: https://github.com/prettier/prettier/issues/187

lifestyleguru• 10 months ago

A lot of tools are fucking up the parentheses and apostrophes. Unnecessarily adding, removing, matching, or closing them. In terms of parentheses and apostrophes I know what I'm doing, stop "helping".

maratc• 10 months ago

It's just not a big issue today if you know what you're doing or not, as everyone now seems to care about "consistency" only.

My personal pet peeve is python's formatter named "black" (mentioned in TLA) that converts this:

     important_numbers = {
        "x": 3,
        "y": 42, # Answer to the Ultimate Question!
        "z": 2
    }

into this:

    important_numbers = {"x": 3, "y": 42, "z": 2}  # Answer to the Ultimate Question!

moring• 10 months ago

That Github issue doesn't really stress how serious he problem is. They make it sound like unnecessary parentheses get removed when they should be kept for clarify. What actually happens is that necessary parentheses get removed, altering the meaning of the expression. The example I encountered myself was this or similar to it (can't remember exactly):

(a || b) && c --> a || b && c

which then gets interpreted as

a || (b && c)

Guillaume86• 10 months ago

They would obviously fix it pretty quick if you reported something like that, the still open github issue is about pure styling/readability issue...

rendall2• 10 months ago

One interesting side effect is that I changed the most number of lines of code company wide that year and got my name on the "blame" for most of the JavaScript files that existed at that time. So over the years I kept getting random people or scripts pinging me about code I had no idea about!

Not sure who needs to hear this, but in case anyone runs into this problem, you can create a list of commit hashes that `git blame` will ignore. Commit all of your formatting changes in one push and then put its hash in the ignore file.

https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

This feature was created as a direct response to automated formatters like Prettier!

zbycz• 10 months ago

Wow! Definitely will use, when enforcing new eslint rules. Thanks for sharing this, i just love git :)

rendall2• 10 months ago

github uses it too

https://docs.github.com/en/repositories/working-with-files/u...

harimau7776• 10 months ago

I strongly dislike and disagree with Prettier.

From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read.

From a social standpoint, I think that by labeling things "bikeshedding", Prettier represents a toxic approach to team dynamics. Just because something isn't important to you doesn't mean that it's not essential to someone else.

IMHO, Prettier was a massive setback for the JavaScript community.

CodingJeebus• 10 months ago

The challenge is that it’s easy to find fundamental disagreements on a team on how a codebase should be styled, especially when the language itself doesn’t provide much guidance on styling convention. When that happens, it’s easy for a debate around styling to go on without ever finding consensus.

I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettier really help with that.

harimau7776• 10 months ago

I can see how that would be a challenge. I think the key may be to focus on identifying which things are just a given developer's preference and which are essential to their productivity. Like you said, I'm more than happy to adopt a style that isn't my personal taste. The problem comes when the style prevents me from doing my job.

cheema332• 10 months ago

I strongly dislike and disagree with Prettier.

Have you ever worked in a large team where everybody has their own idea on how code should be formatted? If not, then I can understand your position.

Do you get to review PRs where formatting changes make majority of the changes? Because some people don't use code formatters, others do but use different rules from each other. You may call this freedom, others may call it hell.

harimau7776• 10 months ago

I'm not opposed to establishing a coding style and using a linter to enforce it.

I'm opposed to doing that without getting buy in from the team. IMHO it's important to figure out whats important to the different developers on your team and finding a set of rules that works for them; as opposed to just adopting something that makes some people happy and tanks other people's productivity.

mpalmer• 10 months ago

Just because something isn't important to you doesn't mean that it's not essential to someone else.

The problem with this as an argument is that its opposite is equally valid.

Team dynamics are definitionally not about the concerns of the individual. The team is not helped by one person's insistence on handcrafted whitespace.

jotaen• 10 months ago

In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read.

Prettier allows configuring the indentation style (tabs/spaces) and indentation size, see https://prettier.io/docs/configuration#editorconfig.

Aldipower• 10 months ago

Someone remembers 'perltidy'? :-) Was this the birth of code formatters?

eps• 10 months ago

Never heard of it.

Apparently it's "an opnionated code formatter" - https://prettier.io

ieie3366• 10 months ago

Looking back at it, just crazy how much effort and man-hours went to manually editing whitespace and arguing/nitpicking about it. This is something that should have been automated by the 90s.

hownowbrowncow• 10 months ago

Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout.

One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.

NoSalt• 10 months ago

The formatting "standard" simply boils down to who the biggest fish in the small pond happens to be at the current location in time and space.

andrewmcwatters• 10 months ago

Je n'ai jamais vu un jeu de mots comme celui-ci où « i » a été remplacé par un « j » pour créer l'expression « vieux jeux ». C'est créatif.

Birth of Prettier

Related Stories