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

Prettier 1.0

jlongster.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Prettier 1.0

#41

Post by dguo »

startupdiscuss wrote: post #37

The amazing thing, for me, is: 1. Announced 2 months ago 2. Already adopted by, it seems, every major JS project. ( https://twitter.com/jlongster/status/852532847252566017 ) 3. 7000 stars, 100,000 npm downloads/mo Now some people will say it is a better mousetrap, but even now I can't tell you what the difference is between it and all the other linters. I can tell you that, based on the popularity, I would just defau…

Speaking for myself, I've been waiting for 1.0 before using it, but I've been very excited for this project since its announcement. I've personally experienced how much time can be wasted bikeshedding over stylistic issues. In most cases, just picking a consistent standard is far more important than whatever the choice happens to be. Prettier will make almost all that bikeshedding unnecessary.

Even with ESLint having autofix capabilities, Prettier seems far more comprehensive in that regard. It also isn't doing exactly the same things as linters. They check for programming errors as well, not just stylistic issues. With those linters, you also need to decide how to configure the rules (though picking a preset can make that easier).

I have always loved that Python has an "official" style guide (https://www.python.org/dev/peps/pep-0008/), and gofmt (https://golang.org/cmd/gofmt/) is one of the reasons I want to try out Go, so Prettier is a great development in my opinion. I am optimistic that the community will keep on adopting it, helping make our code more readable and allowing us to focus on actually building libraries, tools, applications, etc. rather than arguing over where we should and shouldn't have spaces in our code.

Edit: my TL;DR answer would be that it's a virtually zero configuration way to guarantee stylistic consistency.

Re: Prettier 1.0

#42

Post by scardine »

antirez wrote: post #38

I'll never understand code formatters. For me the idea of my code passing through a formatter, is like if accidentally I lost part of it: there is a lot of care in the way you write your code, even in the part that the compiler does not care about: spaces. Spaces are the rhythm of the code... not sure why one would write code without rhythm and later add a synthetic one.

That is one of the reasons I'm stuck with Python, I find it pleasant to read (I'm almost as productive as I used to be with Perl but at least I can understand my own scripts 6 months later).

I know, many people can't stand significant white space... The idea sounded weird for me too but after trying it for awhile I was hooked.

Re: Prettier 1.0

#43

Post by jcuanan »

vmasto wrote: post #14

I recall the React team were discussing at what part of the build step they should include Prettier. I believe there was an idea of adding it as a pre-commit hook, a second one as a manual step and another one as a post-commit amend. Have we reached a consensus on that? Not up to date what they went with, what seems to be the best way to do this?

I'm also curious about this. FWIW, I came across this post on adding Prettier as a pre-commit hook that might help others: https://medium.com/@brindelle/format-your-javascript-with-pr...

Re: Prettier 1.0

#44

Post by sergiotapia »

startupdiscuss wrote: post #37

The amazing thing, for me, is: 1. Announced 2 months ago 2. Already adopted by, it seems, every major JS project. ( https://twitter.com/jlongster/status/852532847252566017 ) 3. 7000 stars, 100,000 npm downloads/mo Now some people will say it is a better mousetrap, but even now I can't tell you what the difference is between it and all the other linters. I can tell you that, based on the popularity, I would just defau…

It's really better than a linter because a linter warns you of style errors, but you still need to invest time to fit it.

Whereas this just formats everything for you, set it up on file save and you're done. No more discussions on style and whatnot, your codebase is suddenly uniform.

Go has that with `go fmt` and it's very liberating.

Re: Prettier 1.0

#45

Post by bradfitz »

rattray wrote: post #9

Prettier is a code formatter for JavaScript, like the hugely popular "gofmt". Highlights of the 1.0 announcement: - production-ready (and used, eg; React, Oculus, Cloudflare, etc) - --no-semi option - --use-tabs option - parens that help indicate precedence - many formatting improvements There are a ton of edge cases in this work that really matter (read through the announcement for a few). Speaking as a contributor,…

We had configurability in early versions of gofmt but realized it was a mistake and kinda missed the whole point of having a code formatter, so we removed them.

Re: Prettier 1.0

#46

Post by sergiotapia »

antirez wrote: post #38

I'll never understand code formatters. For me the idea of my code passing through a formatter, is like if accidentally I lost part of it: there is a lot of care in the way you write your code, even in the part that the compiler does not care about: spaces. Spaces are the rhythm of the code... not sure why one would write code without rhythm and later add a synthetic one.

Because your rhythm might be unique or confusing to your team members.

Using a tool like this you all share the same rhythm. No ones feelings get hurt, onboarding is simpler, code is easier to read.

Re: Prettier 1.0

#47

Post by k__ »

Prettier is like rainbow sprinkels on top of my code.

I write vastly different JS as Prettier formats (single quotes, no semicolons, etc.), but after I hit save everything just looks 'normalised'

Re: Prettier 1.0

#48

Post by mrkgnao »

bradfitz wrote: post #45
rattray wrote: post #9

Prettier is a code formatter for JavaScript, like the hugely popular "gofmt". Highlights of the 1.0 announcement: - production-ready (and used, eg; React, Oculus, Cloudflare, etc) - --no-semi option - --use-tabs option - parens that help indicate precedence - many formatting improvements There are a ton of edge cases in this work that really matter (read through the announcement for a few). Speaking as a contributor,…

We had configurability in early versions of gofmt but realized it was a mistake and kinda missed the whole point of having a code formatter, so we removed them.

While I understand the reasons for this (especially with the culture, for lack of a better word, around Go), I feel like this is a step backward in general. The "standard" Haskell formatter, hindent, did something similar. I found the maintainer's behavior admirable -- the style that was agreed on was very different from his own, but it was what he saw after analyzing publicly available code -- but what's the problem with custom formats if they're consistent across a whole codebase?

Re: Prettier 1.0

#49

Post by curun1r »

antirez wrote: post #38

I'll never understand code formatters. For me the idea of my code passing through a formatter, is like if accidentally I lost part of it: there is a lot of care in the way you write your code, even in the part that the compiler does not care about: spaces. Spaces are the rhythm of the code... not sure why one would write code without rhythm and later add a synthetic one.

There's two reasons, to me, why formatters make a lot of sense. First, working in large teams, not everyone will agree on a formatting convention and it's very difficult for people to internalize the convention and stick to it. This leads to, at best, inconsistencies in the code and, at worst, bike shedding discussions on which conventions to use that distract from shipping actual features. When HBO's Silicon Valley had its lead character lose out on a promising relationship because of a spaces vs tabs argument, it hit dangerously close for those of us that have had to endure a months-long meetingfest to arrive at a company standard for code formatting. Once you've been through that hell, you can appreciate the simplicity of just invoking a tool during the build process.

Second, there's what I'd call the "Mark Zuckerberg clothing" reason. When asked why he always wears the same style clothes, he said, "I really want to clear my life to make it so that I have to make as few decisions as possible about anything except how to best serve this community." Similarly, code formatting doesn't deliver value to customers/users. The more you can ignore it, the more you can focus on other things. When I first started using code formatters, they irked me greatly. But once you get used to them as a part of your process and start to feel comfortable reading the code they spit out, they transition to being liberating. The formatting fades into the background and all you see is the logic in the code. And I didn't realize just how much time I was spending getting indentation levels correct and aligning things until I entirely stopped doing those things. Now I write code that looks really ugly until I hit save and then it looks exactly the way that the rest of my code looks.

Post reply on HN