Live data from Hacker News

$20k bounty was claimed

prettier.io

81–90 of 345 posts

Re: $20k bounty was claimed

#81
post #68
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"?

Specifically for reviewing a pull request in GitHub, wouldn't the "Hide whitespace" setting reduce some of this noise? I could be mistaken, though, but that's how I interpreted that setting. 0: https://github.blog/2011-10-21-github-secrets/

This is often useful, but JavaScript specifically has the annoying property that newlines can be semantically meaningful.

For example, if someone changes:

    function isUserBanned(username) {
      return db.findUserByName(username)?.banned;
    }
To:

    function isUserBanned(username) {
      return
          db.findUserByName(username)?.banned;
    }
you want to see that diff because the second version always returns undefined. If you ignore whitespace changes entirely, it becomes possible for people to sneak in bugs intentionally or unintentionally.

Re: $20k bounty was claimed

#82

While porting to Rust has been a trend, as Prettier runs on every save, the speed boosts will be significant. I'll be trying out Biome soon. Congrats to the Biome project!

I have never noticed any lag from Prettier running on single files. The perf starts to matter with whole-repo format passes. For interactive use we really should be using long-running, warmed up, processes too, where the start time of Node is irrelevant. Ideally type-checking, linting, highlighting and formatting would run in one language service doing incremental parsing and updates to a shared AST on every keystrok…

> Ideally type-checking, linting, highlighting and formatting would run in one language service doing incremental parsing and updates to a shared AST on every keystroke.

I think this is the reason Biome (originally called Rome) started. Rome's vision was a shared toolchain to yield better performance and to fix config hell.

Re: $20k bounty was claimed

#83
post #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.

100% I also personally believe you should pick a formatter and NOT configure it. I don’t care anymore about style. Just want formatting to be consistent.

Re: $20k bounty was claimed

#84
post #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 throu…

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

I've never had an issue setting an inline breakpoint[1] in VS Code, is it an issue in other IDEs?

[1] https://code.visualstudio.com/Docs/editor/debugging#_inline-...

Re: $20k bounty was claimed

#85

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.

If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.

Re: $20k bounty was claimed

#86
post #70
post #59

Earlier quoted context omitted.

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.

Sure you will. Whoops, my regex got too long and now the diff is - filter: /\.(jimmy|jimbo|jeremiad)$/ + filter: + /\.(jimmy|jimbo|jeremiad|james)$/ . And it's not clear where the change is. GP's article has an example of that in a linked tweet.

This is fine for a text diff, but I want my code review tool to show me something different. Separate problem, and the flaw here isn’t the diff, or the tool that produced the diff, rather the tool displaying it to me. Let me do whatever I want to my code and show me BOTH the visual (unimportant) and semantic differences.

Re: $20k bounty was claimed

#87
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?

Presumably the creators of the bounty believe that this bounty is in fact a good way to directly improve Prettier. The acceptance criterion of the bounty doesn't need to literally be "improve Prettier" for the work to improve Prettier.

Re: $20k bounty was claimed

#88
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"?

That's not an issue with Prettier; it's an issue with having a consistent style and not using syntax aware diff tools.

Re: $20k bounty was claimed

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

> 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. I've never had an issue setting an inline breakpoint[1] in VS Code, is it an issue in other IDEs? [1] https://code.visualstudio.com/Docs/editor/debugging#_inline-...

I use emacs, but chrome/firefox are a bit finicky about where you can set a breakpoint.

(Most people I know just use console.log - print debugging works all the time but I like having a repl)

Re: $20k bounty was claimed

#90

"This means that we can now focus on the next important aspect: Performance. Prettier has never been fast per se, but fast enough for most use cases. This has always felt unsatisfying so we wanted to do something about it. What better way than a friendly competition. On November 9th, we put up a $10k bounty for any project written in Rust that would pass 95% of Prettier test suite." I don't see how better performance…

> One could have simply transpiled the existing codebase into Rust, and collect the reward.

I'm not sure if this is already an internet saying somewhere, but whenever I read the word "simply", I assume that whatever comes next won't be simple, because if it was actually simple it wouldn't need to be qualified.

In this case, I don't know that transpiling a JS codebase to Rust is simple. The mental models, the libraries used, the way that code written is quite different between the two languages and I doubt that JS-to-Rust transpilers are robust enough to be used on a codebase the size of Prettier, if such transpilers even exist at all.

Post reply on HN