Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Birth of Prettier

blog.vjeux.com

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Birth of Prettier

#11

Post by CaptainOfCoit »

TranquilMarmot wrote: post #2

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…

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?

Re: Birth of Prettier

#12

Post by speed_spread »

normie3000 wrote: post #5
TranquilMarmot wrote: post #2

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…

> format-on-save A dystopian feature!

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

Re: Birth of Prettier

#14

Post by lifestyleguru »

foofoo12 wrote: post #13

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

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".

Re: Birth of Prettier

#15

Post by maratc »

lifestyleguru wrote: post #14
foofoo12 wrote: post #13

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

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".

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!

Re: Birth of Prettier

#16

Post by rendall »

> 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!

Re: Birth of Prettier

#17

Post by fenomas »

schwartzworld wrote: post #10
whstl wrote: post #6

Earlier quoted context omitted.

+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…

I often say that “nit” comments on prs are bad. It’s either important enough to make a linter rule, or not important enough to mention.

I wouldn't go that far - to me what's important is that nits must be non-blocking. I.e. the author is free to ignore them if they disagree, and a PR review with only nit comments should be an approval. If those things are true, it's fine to have gray area between what's linted and what's mentioned in PR review.

Re: Birth of Prettier

#18

Post by moring »

foofoo12 wrote: post #13

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

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)

Re: Birth of Prettier

#19

Post by harimau777 »

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.

Post reply on HN