Live data from Hacker News

$20k bounty was claimed

prettier.io

51–60 of 345 posts

Re: $20k bounty was claimed

#51
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…

Adding to what has been already said, simply the fact of having different people with different perspectives and intentions, can surface new ways of improvement.

https://biomejs.dev/formatter/#differences-with-prettier

Turns out Biome found several pain points that they chose to not follow the same decisions than Prettier, instead diverging from it. This alone could be already a reason why a parallel development is worth it.

Re: $20k bounty was claimed

#52
post #6

That's interesting. I've been using "deno fmt" as of late and it's been fine for me. https://docs.deno.com/runtime/manual/tools/formatter

FWIW it doesn't matter which formatter you choose, so long as everyone working on the project is required to use it.

Re: $20k bounty was claimed

#54

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.

Agreed! I'd go so far as to say that we would be better off if Prettier was never created.

Re: $20k bounty was claimed

#55
post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

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

It will favour deeply nested ternary statements in react so your code reads more like a tree with densely tangled roots.

It will favour shorthand syntax for optionally merging properties into an object, which basically relies on a quirk of the splat operator.

There is fuck all standard library to speak of without pulling in an insane amount of dependencies, but surely stuff like deep merge and compact should be provided out of the box?

Re: $20k bounty was claimed

#56

I'm incredibly excited for this. The Biome team has been remarkably fast on achieving 95% compatibility with Prettier [1]. This will help to bring maximum speed to formatting Javascript thanks to Rust, following the ruff (Python formatter) trend. Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how t…

Do you know the reason for enabling compilation to WASIX?

WASIX will enable to run biome fully sandboxed at close to native speeds.

Imagine you can safely assume that the formatter program will only have access to the directory you provide, and not anything outside of it (not even the network!).

In summary, Wasmer + WASIX is like Docker, but much more lightweight :)

Re: $20k bounty was claimed

#58
post #49
post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

eh -- this is a one-time occurrence with prettier. Subsequent changes are guaranteed to be changes-only since formatting is consistent between authors.

It happens often in JSX, you add one prop, which makes the line longer than the line width, which turns it into a multi line change.

It's annoying, but not a reason to throw the baby out with the bathwater.

Re: $20k bounty was claimed

#59
post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

It's not really an issue if you do a one-time Prettification commit, and then stick to Prettifying automatically thereafter. Then you won't ever see line-width changes mixed in with functional changes.

Isn't this an issue with every linter? At some point you're going to have to decide what to do with old code that doesn't match the new style rules.

Re: $20k bounty was claimed

#60

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.

Prettier often makes code written using sequences of .chaining much more difficult to read by forcing it all to the same line.

For the same reason, it often makes code written using composition more difficult to read since it won't let you decide when to put a sub-call on its own indented line for clarity.

Post reply on HN