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

$20k bounty was claimed

prettier.io

Post reply on HN
Print view View original

131–140 of 345 posts

Re: $20k bounty was claimed

#131

Post by shepherdjerred »

harimau777 wrote: post #61
xdennis wrote: post #24

Earlier quoted context omitted.

> I find Prettier to be way too heavy handed But that's the purpose of such tools: to stop endless debates about style.

The problem is that style matters and therefore those debates matter. Just because something isn't important to the developers that made Prettier doesn't mean that it's not important to the productivity of other developers.

The reality is that as long as your style is consistent, very few people actually care what that style is.

I can imagine smaller teams/single individuals being very picky about how their code looks and there is nothing wrong with that. Once you have larger teams that becomes a waste of time since you'll likely have much larger problems to solve.

Re: $20k bounty was claimed

#132

Post by nicoburns »

atom_arranger wrote: post #62
pigeonhole123 wrote: post #30

Earlier quoted context omitted.

Prettier is very opinionated about line length which gofmt isn't. That's the only complaint I have and it's bad enough I just refuse to use it. Add one character to a line and enjoy a ten-line diff. Edit: See a contrived example of something gofmt doesn't touch (the behavior I want): https://go.dev/play/p/cKMKnFwT8tq

What should Prettier should do in this case? I think we can all agree there should be a line length limit, it has to enforce it eventually. You could say “it’s just a couple more characters” until the line is 200 characters long. Semantic diff is maybe the solution.

It should put more weight on the length that the author has original authored it as. So between "always break" and "always expand" there should be an area of "leave it however it already is".

Re: $20k bounty was claimed

#133

Post by nicoburns »

meowtimemania wrote: post #18
nicoburns wrote: post #10

Speed is always welcome, but I just wish prettier was a little less opinionated. Specifically around line length, it will just not leave my formatting alone. I find prettier formatted code much less readable than unformatted code, and this isn't a problem I have with other code formatters like rustfmt.

Do you have any examples where prettier code is much less readable? I haven't really ran into that issue and have been very happy with prettier.

A good example from further down the comment section:

Prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this:

    const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`;
prettier would fix it to

    const foo = 
      `aaaaaaaaaaaaaaa${
        bbbbbbbbbbbbb
       }ccccccccccccccc${
        ddddddddddd
       }`;
Which is not only much harder to read in it's own right, but now takes up 6 lines instead of one!

Re: $20k bounty was claimed

#134

Post by wg0 »

> Consider donating if you or your company are using Prettier and it has been helpful to you.

Wondering what company would NOT be using prettier. Not many.

Some arguing that Prettier isn't foundational piece of software, I'd consider automated consistent readability enhancements as foundational though.

Re: $20k bounty was claimed

#136

Post by hu3 »

yawboakye wrote: post #102
ljm wrote: post #55

Earlier quoted context omitted.

Prettier’s biggest win is that it automates 99% of style complaints away and practically eliminates most classes of nitpicking. But, as well as the issue with line noise, it also encourages patterns that I think detract from code comprehension. It favours expressions over statements and even now, it’s not easy to set a breakpoint in the middle of one, so you end up rewriting into statements just so you can step throu…

does it? prettier is extremely configurable, unlike gofmt. so deferring to the authority of prettier is essentially deferring to the authority of the prettier.yml config. not that i have a problem with that _per se_, i’d expect the author(s) to take responsibility and appreciate that they’re defining/imposing their own taste(s).

> prettier is extremely configurable

That's the opposite of what they claim: https://prettier.io/docs/en/option-philosophy

Re: $20k bounty was claimed

#137

Post by j1elo »

nicoburns wrote: post #111
j1elo wrote: post #63

Earlier quoted context omitted.

I'd rather have a strict line length limit, than having my coworker creating objects in lines 150 or 180 chars long. So we'd end up discussing what is the best choice. I bet I'd also end up discussing those things with Anthony Fu. If the limit is 80, then the limit is 80 , not 81. Come Prettier. No more discussions. I definitely buy the tiny amount of "noise" it brings, in exchange for freeing me from an immense amou…

> If the limit is 80, then the limit is 80, not 81. I agree with that. But the limit should be 120 or 160, not 80 (and my formatter should allow me to set a wider limit like that without making all my lines extra-wide - I want to be able to put things on one line where appropriate and not where it's not). > I definitely buy the tiny amount of "noise" it brings Tiny? It makes a lot of my code 3-5x as long. And often b…

Like I mentioned to the sibling parent, 100 is an OK middle ground. 120, or more, is too long already, and 160 is waaaay beyond what I'd consider acceptable. No way you can fit 2 side-by-side editor panes with those line lengths, unless you use a tiny sized font.

I get it, 160 looks OK and fits into a 4K display without any other windows open. I believe working with dual panes is more productive, so I'll always stand behind shorter line lengths that allow for it.

Even Rust, a modern language that is usually said to collect the best learnings from the industry, thankfully chose a conservative and sensible 100 chars limit by default.

Re: $20k bounty was claimed

#138

Post by hoherd »

ipaddr wrote: post #112
j1elo wrote: post #63

Earlier quoted context omitted.

I'd rather have a strict line length limit, than having my coworker creating objects in lines 150 or 180 chars long. So we'd end up discussing what is the best choice. I bet I'd also end up discussing those things with Anthony Fu. If the limit is 80, then the limit is 80 , not 81. Come Prettier. No more discussions. I definitely buy the tiny amount of "noise" it brings, in exchange for freeing me from an immense amou…

80 character limit? Are we trying to relive the late 80s. Soon we'll move back to 40 characters. Screens can support higher resolutions now limiting lines to 80 so developers can turn their brains off seems silly. Turn your brain on and learn to filter the noise of 100 characters.

These are web developers. Of course they're going to try to force content into a narrow width view and not let you choose to have a wider view even if it makes perfectly valid sense for the given content. These are usability problems that people aren't allowed to make their own decisions about because the UI designer knows the only right answer. "It makes the content more readable" and all that. /s

Re: $20k bounty was claimed

#139

Post by laurent123456 »

warp wrote: post #78
pigeonhole123 wrote: post #30

Earlier quoted context omitted.

Prettier is very opinionated about line length which gofmt isn't. That's the only complaint I have and it's bad enough I just refuse to use it. Add one character to a line and enjoy a ten-line diff. Edit: See a contrived example of something gofmt doesn't touch (the behavior I want): https://go.dev/play/p/cKMKnFwT8tq

Couldn't you just set the "printWidth" in .prettierrc.json to something super long?

In that case prettier will put the code you formatted over multiple lines into one giant line spanning multiple screens. This is especially relevant for method chaining.

Re: $20k bounty was claimed

#140

Post by wentin »

dewey wrote: post #8

> One question you are probably wondering is why would the Prettier team fund another project!? In practice, Prettier has been the dominant code formatter for JavaScript and as a result of a lack of competition, there has been little incentive to push on performance and fix various edge cases. I was indeed wondering that but the answer doesn't really answer the question for me. Why not set a bounty to improve Prettie…

> Why not set a bounty to improve Prettier instead of building a competing project just to increase the motivation to improve Prettier?

There are three reasons, I think:

1. Writing a rust compiler is separate from prettier project because of its nature. Prettier is not written in Rust, and Rust has proven to be a robust option to write a formatter, so the goal really is to write a formatter in Rust itself, and it can't be replaced with improving prettier within its current codebase

2. Asking someone to write a Prettier-branded and owned Rust compiler for $20k is not enticing enough. It is essentially equivalent to contracting someone to write some code for Prettier, with an open bid. It would cost a lot more to hire someone to write these code. Great programmer who has the skill to answer this bounty get paid at least $200 an hour (extremely conservative estimate), $20k is enough for 100 hours of work for one person, not enough to finish the project. But getting rewarded for $20k for stuff you write and will own is enticing!

3. Good ecosystem going forward. If prettier owns the winner project, prettier is responsible to maintaining and improving it. The good that the bounty did ends when the project is handed over. Prettier team get burdened with a project that they didn't write themselves, and the original team (the best people for the job) is not incentivized to keep maintaining it. There is no ongoing competition to keep this field active.

Post reply on HN