[HN Gopher] $20k bounty was claimed
___________________________________________________________________
$20k bounty was claimed
Author : conaclos
Score : 553 points
Date : 2023-11-27 16:50 UTC (6 hours ago)
(HTM) web link (prettier.io)
(TXT) w3m dump (prettier.io)
| namanyayg wrote:
| 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!
| uoaei wrote:
| This effort reflects the excitement in the Python community
| around `ruff`. Excited to see efficiency and speed gains with a
| wide impact.
| spankalee wrote:
| 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 keystroke.
| strager wrote:
| > 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.
| syrusakbary wrote:
| 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 their team has been
| working to achieve this as well... hopefully we'll get Biome
| running in Wasmer soon!
|
| Also congrats to the Algora team, as they have been doing very
| good work with their landing and trying to help on the challenge
| moving forward [4].
|
| Keep up the great work!!
|
| [1] https://github.com/biomejs/biome/issues/720
|
| [2] https://wasmer.io/
|
| [3] https://wasix.org/
|
| [4] https://console.algora.io/challenges/prettier
| triyambakam wrote:
| Do you know the reason for enabling compilation to WASIX?
| syrusakbary wrote:
| 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 :)
| slimsag wrote:
| The parent poster (syrusakbary) is the CEO of Wasmer and
| trying to push WASIX, a quasi-proprietary 'open standard'
| while it seems the rest of the WASM ecosystem is in fact
| moving to WASI preview 2 [0]
|
| [0] https://news.ycombinator.com/item?id=37545670
| intelVISA wrote:
| Extend, Embezzle, Escape
| syrusakbary wrote:
| I think you may be a bit confused on what's the purpose
| behind WASIX, Stephen. And you are mistakenly polarizing
| between two very valid options for different use cases.
|
| We are not trying to push WASIX, we are trying to move
| forward sockets, threads, subprocesses so they can run
| fully in Wasm environments. And WASIX is the solution to
| that problem.
|
| WASI Preview 2 on the other hand seems to be focused on
| other set of problems and doesn't solve any of the needs
| that got WASIX started in the first place.
| slimsag wrote:
| According to their roadmap, WASI preview 2 will have
| threads and sockets.
|
| So, in light of that, what is the reason for diverging
| from WASI and creating WASIX?
| syrusakbary wrote:
| I'm not sure what roadmap you are talking about. Threads
| are actually removed from WASI Preview 2.
|
| WASI Preview 2 still doesn't support threads, fork,
| subprocesses or longjmp/setjmp (among others). Not even
| that, when WASIX was created not even sockets were
| supported in WASI.
|
| I'd recommend trying to compile bash or curl to WASI
| Preview 2 and WASIX and see how far you get in each
| before trying to polarize the readers between WASI
| Preview 2 and WASIX.
| cedws wrote:
| This is the first time I've come across WASIX. Upon reading
| about it, I can't help but see it as a reincarnation of the
| JVM. Is that accurate? What advantage is there to executing
| code in WASIX if it can access the system and isn't actually in
| a sandbox?
| shepherdjerred wrote:
| It sounds the same to me: JVM, but with better browser
| support.
| n42 wrote:
| The advantage is this guy's VC backed company gets to sink
| its teeth into the early stages of WASM platform adoption,
| helping him line his and his company's pockets.
|
| WASIX is a hostile fork of an open standard that does care
| about sandboxing.
| syrusakbary wrote:
| I'm incredibly curious to hear more on how you think WASIX
| helps on the company pockets (since is open-source, and
| even it's governance model is open).
|
| I'd love to hear your thoughts, maybe we are missing on
| some nice business opportunities here!
| n42 wrote:
| It's fine to be forthcoming about the financial interests
| of your projects - this is Hacker News, after all. We
| live on VC. The tone of your previous comment suggests
| there is none.
|
| I find it hard to believe that anything you would spend
| your company's time on would not push the mission of the
| company forward. This creates a financial incentive.
| syrusakbary wrote:
| I'll address the first non-clickbait question and try to
| provide some insight, as I think you might be a bit
| confused on how COSS startups work.
|
| We don't plan to monetize WASIX. WASIX is just an enabler
| to allow any program compile to WebAssembly. If other
| open-source technology existed and fulfilled what we want
| to accomplish is more than certain we would not have
| created WASIX.
|
| In our case, the community was asking to have sockets,
| threads, forking, subprocesses and more fully working on
| Wasm. And there was nothing that supported that (or that
| aimed to support it), so we worked on it.
|
| Now, let me give more insight on what we actually plan to
| monetize: Wasmer Edge [1]. Wasmer Edge is the alternative
| to the expensive big-tech providers that allows any
| person or company to host their websites at a fraction of
| the cost.
|
| Hope the insight was useful!
|
| [1] https://wasmer.io/products/edge
| n42 wrote:
| Wasmer is a VC company building a platform that depends
| on the existence of these platform APIs - sockets,
| threads, forking, etc. They have a vested interest in the
| existence of these APIs, and the health of the developer
| ecosystem, to stay alive. From here, it kind of seems
| like the fundamental foundation of everything Wasmer is
| building.
|
| Meanwhile, Bytecode Alliance is a registered non-profit
| with many large corporate backers. They are building out
| the WASI standard with careful due diligence to learn
| from and avoid the mistakes we have found in POSIX. BCA
| has their own financial incentives, and they are aligned
| differently than yours.
|
| BCA ultimately is moving slower than works for Wasmer. So
| I guess you were faced with three options: A) wait for
| BCA, and do nothing B) work with BCA and push it forward
| C) fork it and do it yourself.
|
| So you chose to fork it and reimplement POSIX with all
| its warts. I assume because this applies pressure to the
| community (candidly, a good thing) while letting you make
| progress immediately.
|
| Where I, and I assume others, have issue with all of this
| is:
|
| You have chosen a name that has created confusion in an
| already confusing space.
|
| You have whitewashed it by promoting it as a new open
| standard, but the controlling entity realllyy is just
| Wasmer[0].
|
| You have demonstrated through your actions a complete
| lack of willingness to work with people in the community,
| preferring to strong-arm with veiled threats[1] or
| perverting incentives financially[2].
|
| The issue isn't with WASIX, but with you and your
| actions. I have no confidence in your ability to lead
| this community forward in a way that has my (our)
| interests ahead of your company's. [0]:
| https://github.com/wasix-org/wasix-governance-meeting-not
| es/blob/5135516d091d1bc3810677ea2cc755a67e10c669/meeting-
| notes-27-07-2023.md#meeting-attendees [1]:
| https://github.com/bytecodealliance/wit-
| bindgen/issues/306 [2]:
| https://github.com/ziglang/zig/issues/17115
| syrusakbary wrote:
| > The issue isn't with WASIX, but with you and your
| actions.
|
| Is refreshing to see at least some honesty. Haters gonna
| hate, so I personally don't mind. Have a great day!
| n42 wrote:
| This is kind of my point. It would be refreshing to see
| the CEO that would like our industry to build on top of
| his platform to show some humility. Do you care to admit
| to making any mistakes in your interactions, or is it all
| because we are just a bunch of haters?
| syrusakbary wrote:
| I'm not even going to enter into the flame-bait. I
| obviously disagree with your points.
|
| Hope you have an awesome day
| dang wrote:
| Can you please follow the site guidelines when posting
| here? They include:
|
| " _Have curious conversation; don 't cross-examine._"
|
| " _Please respond to the strongest plausible
| interpretation of what someone says, not a weaker one
| that 's easier to criticize. Assume good faith._"
|
| https://news.ycombinator.com/newsguidelines.html
| n42 wrote:
| Of course. I hope the edit is more appropriate. Thank
| you!
| AndyKelley wrote:
| I thought it was well said fwiw
| syrusakbary wrote:
| Here's the original comment, as it might be useful for
| reference purposes: https://imgur.com/a/SjSnJsj
| syrusakbary wrote:
| WASIX is similar to the JVM in the sense that is able to use
| a common abstraction for all operating systems, and it uses a
| VM under the hood (Wasm).
|
| But the main difference is that it has sandboxed capabilities
| (similar to docker), do you can granularly add permissions to
| only certain directories or even disable networking when
| running.
| ehutch79 wrote:
| I'm looking through the docs, specifically the formatter stuff (
| https://biomejs.dev/formatter ), and it feels like all the
| examples are backwards?
|
| Am I missing stuff?
| conaclos wrote:
| What do you mean by "backwards"?
| surye wrote:
| The "diff" appears to be backwards (it's subtracting what
| prettier would emit, and adding back the original).
| explaininjs wrote:
| The diff is between the test cases's expected output (red)
| and the utility's current output (green).
| ematipico wrote:
| The red represents what would Prettier emits, and the green
| represents what Biom e emits. If you think that's unclear,
| feel free to send a PR to help us make it clearer.
| globular-toast wrote:
| This was intuitive to me, especially because it's in a
| section titled "Differences with Prettier".
| explaininjs wrote:
| That's giving the diff between prettier ("correct", yet red)
| and their implementation (green, yet arguably incorrect)
| surye wrote:
| It feels backwards to me from a purely linear time
| perspective, you have an input, transform it, diff would be
| the patch, to the desired output.
| jrockway wrote:
| 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
| conaclos wrote:
| If you switch from Prettier to deno-fmt you will notice many
| changes to perform on your code base. Biome tries to minimize
| these changes.
| tills13 wrote:
| FWIW it doesn't matter which formatter you choose, so long as
| everyone working on the project is required to use it.
| jkrubin wrote:
| 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.
| jrockway wrote:
| Yeah, that's my take as well. The less there is to
| configure, the better. Something I like about Go is that I
| don't need any project-specific settings, because there are
| none. (Not strictly true, as some people use gofumpt
| instead of gofmt. I think this is a bad idea, even though I
| agree with all of gofumpt's formatting changes. What
| matters is will everyone use it on every commit? Not if
| gopls doesn't do it for you.)
|
| At my last job, we had a lot of fun with Prettier. We
| basically made our Typescript codebase look as much like Go
| as possible. I am not sure this is a particularly valuable
| endeavor, but it was fun. So if people are willing to spend
| $20,000 on making that faster, whatever. They can have that
| fun, I guess.
| culi wrote:
| In the same way it doesn't matter which side of the road you
| drive on. What matters is that everyone else is also driving
| on that side
| andrewstuart wrote:
| The post says the reason they did this was to motivate themselves
| to make the javascript version better?
|
| Strange.
| sophacles wrote:
| Competition is good for the consumer (i.e. the users). For
| example: when clang and LLVM came along, gcc got significantly
| better.
| dewey wrote:
| > 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 Prettier
| instead of building a competing project just to increase the
| motivation to improve Prettier? Or is the end goal to shut down
| the Prettier project and encourage people to switch to the Rust
| based one? Seems like an unnecessary fragmentation of an already
| confusing landscape.
|
| Maybe I'm misunderstanding something though.
| hermanradtke wrote:
| Maybe prettier will consume the biome work and offer it as an
| option for prettier going forward.
| Philpax wrote:
| Different approaches with different constraints and less
| baggage can potentially discover areas of improvement that
| weren't otherwise visible in the original project. (i.e. they
| weren't locked into the "Prettier mindset", if such a thing
| exists)
| explaininjs wrote:
| Maybe they want an implementation to have an understanding of
| potential perf of a non-js solution, but know that it'd cost
| them more than $10k to have an employee do it. So instead you
| offer 10k, someone else offers 10k, and the final product is
| "owned" by a third party but your questions are answered.
| wincent wrote:
| > why would the Prettier team fund another project!?
|
| Less "the team" per se, and more vjeux, I think.
| yebyen wrote:
| There is a whole gulf of room between "we are the incumbent and
| there is no viable alternative in any language for JavaScript
| developers" and "the Rust folks have done it, there's an
| alternative now and it seems quite viable"
|
| I think it's about escaping local minima? You can always look
| at the biggest sink for performance and say "there's definitely
| something we can do better in there" but unless you have
| something objectively better to compare it to, you'd never be
| sure.
|
| Imitation is the sincerest form of flattery. And knowing that
| of the hard problems you solved, someone else can solve them
| and in a different language, I think there's quite a bit of
| value to be obtained just through the competitive process that
| emerges when there is competition.
|
| You can't fully have competitiveness without an actual
| alternative to compare yourself against. If the Rust folks can
| do the problem slightly faster by shaving off just 5% or less
| of the test suite, what all does that tell us about the
| theoretical limits of a solution when compared against the
| canonical version?
|
| I have only limited understanding of the problem space, but I
| think there's always something intangible to be gained from
| having a quite similar implementation in a different language.
| mlhpdx wrote:
| > I think it's about escaping local minima?
|
| Yes. It's also been said (not often enough) "if we don't
| compete with ourselves someone else will". Getting out of
| one's own head (and repo) is gold. It shows humility and
| respect as well as creates innovation and resilience.
| j1elo wrote:
| 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.
| tshaddox wrote:
| > 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.
| icambron wrote:
| I can't speak for the Prettier folks, but as an OSS maintainer,
| I'm more interested in _the problem being solved_ than everyone
| _using my particular solution_. I actually don 't benefit at
| all from you using my code; I did all the work to make the
| world a place where $PROBLEM has an accessible solution. So if
| I were passionate about, say, JS code formatting, I would be
| pretty happy if someone came along and solved that problem in a
| more performant way.
| blowski wrote:
| I'd guess a significant proportion of OSS maintainers _are_
| in it for some combination of ego-trip, or a misguided belief
| that it will make them rich. Both outcomes may seem less
| likely if you're just fixing somebody else's software for
| free.
| demosthanos wrote:
| What have you seen that would lead you to believe that?
|
| My own experiences with open source suggest that no one
| would stick around for very long if they were motivated by
| fame or wealth. Being a FOSS maintainer seems to be a
| constant exercise in dealing with people whining at you for
| not fixing their problems for free, not something that
| brings any significant personal attention and _certainly_
| not something that provides a sustainable source of income.
| matheusmoreira wrote:
| Is it really so misguided these days? I see plenty of
| developers making decent amounts of money via GitHub
| sponsors, patreon and others. Could be pretty nice if a
| project gains momentum. And it's ethical: no ads, no
| proprietary software, nothing.
| vidarh wrote:
| Most of my git repos are things where I'm happy if someone
| finds something useful, but for several of them I'm very
| explicit that there are a whole lot of things I will plain
| refuse to merge not because I think they're not great or
| useful, but because I don't want my packages to be everything
| for everyone - I'd rather people took my stuff and built a
| "competing" solution with different tradeoffs if they have
| different needs. I'd happily even offer help and suggestions
| if people want to do that.
|
| I think that a lot of projects would be a lot better if they
| insisted on _not_ solving everything, and stuck to solving
| one problem well, and instead of merging every new feature on
| offer instead help make it easier for others to "compete"
| with them by e.g. separating out shared functionality or
| writing about lessons learned...
|
| I'd _love_ to find each and every one of my projects are no
| longer needed because there 's a better option (now, I may be
| very difficult about what is "better", so that's a tall
| order), because my list of projects I'd like to pursue is
| longer than I will stand any chance of getting to in my
| lifetime, so if some are taken off my plate, awesome...
| technion wrote:
| Projects would do well to adopt your views, I believe that
| always leads to a better product.
|
| Age for example always has someone complaining about a
| feature they want - the refusal to oblige is exactly why
| it's a better product than gpg.
| marcosdumay wrote:
| > performance and fix various edge cases
|
| Those are the two main things that rust is expected to help
| improve.
|
| It's quite easy to empathize with somebody that sees a JS
| software having problem with those two and picking a language
| that is known to help with those instead of being known to
| increase those problems.
| wentin wrote:
| > 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.
| andai wrote:
| >Great programmer who has the skill to answer this bounty get
| paid at least $200 an hour (extremely conservative estimate)
|
| Dang! What do you base this estimate on? The Rust aspect, or
| parsing aspect, or intersection of both?
| butterlesstoast wrote:
| Adding this for data. I charge $500 an hour for
| contracting. It's gotta be at least that as it's costing
| time I would otherwise spend with my family. Family time /
| time away from my core job is incredibly valuable.
| Cthulhu_ wrote:
| For said data... does anyone actually pay that? I mean if
| you don't get hired for that amount you've got tons of
| family time so I guess it works?
|
| What I'm trying to say, I don't see the correlation
| between having a huge hourly rate vs family time. 40
| hours a week of work is still 40 hours regardless of how
| much you're paid.
| lcnPylGDnU4H9OF wrote:
| A freelance developer can easily ask $250/hour, similar for
| a contract agency, and that is kind of a low amount. It
| sounds like a lot for a single developer but if one
| considers all of the non-billed time of chasing leads and
| bills it's maybe a different picture.
| TylerE wrote:
| Keep in mind as a freelancer you have to make about for
| $2.50 for every $1 a salaried person makes, as you're on
| the hook for 100% of taxes, health care, business expenses,
| etc.
| EricMausler wrote:
| Is the 2.50:1 just a broad estimate or based on
| something?
|
| When I was doing pricing for service contracts it was
| usually around 1.50:1 burdened billing rate vs direct
| labor (income)
| bosie wrote:
| how did you factor in when you can't work (sickness,
| holiday, increasing your skill, finding the next job
| etc)?
| selectodude wrote:
| Yeah, it's closer to 1.5x. Most companies budget total
| comp at 150% of salary.
| llimllib wrote:
| many things are more expensive when you don't work at a
| company - for example the health care for a marginal
| employee at GE is a lot cheaper than you'll get for
| yourself.
|
| I always used 2x, but probably 2.5x is a sensible way to
| think about it in a patio11 "charge more than you think
| you should" mold.
| LanceH wrote:
| Healthcare cost doesn't scale with the $200 base salary,
| though.
| laurencerowe wrote:
| > many things are more expensive when you don't work at a
| company - for example the health care for a marginal
| employee at GE is a lot cheaper than you'll get for
| yourself.
|
| This is less true following the Affordable Care Act than
| it used to be. The unsubsidised marketplace rate for my
| health Kaiser health insurance seems fairly close to what
| I pay for COBRA from my former big tech employer.
| Bognar wrote:
| Part of being a freelancer is spending time finding work
| and doing a variety of things that clients would consider
| non-billable but still cost time. If you're going to work
| 40 hours a week, not all 40 will typically be billable in
| freelancing.
| Jaepa wrote:
| My mother did NGO environmental policy freelancing in the
| 00's. She would land a contract for 40k for two months of
| work, then spend the next 4 months looking for more work.
|
| Being a subject matter expert means that you can be paid
| well for your work, but the numbers of jobs that require
| expertise in the Kura-Aras river basin can be few are far
| between.
| ww520 wrote:
| 1.5x for long term contracts. 2~2.5x for short term gigs.
| hectormalot wrote:
| Depends on the geography and/or whether the knowledge is
| highly specific.
|
| As a datapoint, the average Dutch contracting rates I see
| for IT development (think: Java, Swift, Kotlin) range
| somewhere from EUR75 - EUR150/h. Higher is possible, but
| then you're talking very specific expertise and typically
| shorter projects.
|
| I'm on the hiring side, this is a figure across some 20
| external devs. I think it's representative of the middle of
| the market.
| twodave wrote:
| I came here to say that $200/hour is only "extremely
| conservative" in very few and small geographic parts of the
| world. Where I'm from (in a large city in the US) this number
| would be described as extravagant. I've charged $200 or more
| on only one occasion myself, and it was a very short-term
| arrangement.
| parasubvert wrote:
| I'm from a large city (but not the largest) in Canada and
| $200/hour or higher is common for high end devs,
| architects, and project managers. I charged $200/hour
| twenty years ago. These days I'd charge $250-300/hour if I
| was a contractor. It is not extravagant in most of North
| America, but again, it is a rate for higher end talent. I
| have not charged less than $150/hour since the 90s.
|
| I once had some contractors in my team that were paid
| $500/hour due to vendor markup. I consider that
| extravagant.
| wredue wrote:
| I'll second this that even in Canada, which has quite low
| tech pay, the lower end of quality dev work is $180/hr.
| Most of us managing contractors wouldn't blink twice at
| $200/hr. Many of the bills are much higher.
| globular-toast wrote:
| It sounds like the Prettier test suite is the most valuable
| part of the project. Perhaps the original project will just
| become a test suite with everyone using whatever tool is
| fastest with the best coverage.
| DustinBrett wrote:
| Maybe they paid Biome $20k to have it be more "opinionated"
| with Prettier's opinions.
| nailer wrote:
| > Why not set a bounty to improve Prettier instead of building
| a competing project just to increase the motivation to improve
| Prettier?
|
| That's a good question. But a new, Rust (or whatever is fast)
| version of prettier is effectively Prettier. If it has the same
| config, switches, and defaults, it's Prettier.
|
| The value of prettier is that it's a standard most of JS/TS
| agrees on, saving discussions for more important topics. The
| code that gets us there is a side effect.
| nicoburns wrote:
| 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.
| meowtimemania wrote:
| 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.
| harimau777 wrote:
| 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.
| floydnoel wrote:
| In those situations I make use of comments to force new
| lines where I want them. Stupid but it works!
| pkilgore wrote:
| Disable it! (https://prettier.io/docs/en/ignore.html)
|
| I do this occasionally, and especially with things like
| test tables. Linters/formatters are there to help in the
| common case, not to be some oppressive dogma.
| hu3 wrote:
| If the fix is to disable prettier for an entire file,
| you're proving your parent poster point.
| dewey wrote:
| It doesn't have to be disabled for the whole file, you
| can annotate lines too as shown in the link the parent
| commenter shared.
| HellsMaddy wrote:
| I had the same gripe, and recently tried switching to
| dprint. It is much less aggressive with changing where
| lines break, and honestly it's a huge relief to be able to
| break lines wherever I think makes the code most readable.
| It's also significantly faster than prettier. I've been
| very happy with it.
| mostlylurks wrote:
| 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.
| floydnoel wrote:
| Add a comment anywhere in the destructuring and it will
| force each property onto its own line.
| nicoburns wrote:
| 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${b
| bbbbbbbbbbbb}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!
| paulddraper wrote:
| I wish it were more opinionated.
|
| It treats new lines as significant in a lot of its formatting
| vbezhenar wrote:
| I also don't understand their stand about curly braces. They
| don't add or remove them. I think they should make it
| uniform.
| MalseMattie wrote:
| There is a plugin for that:
| https://github.com/JoshuaKGoldberg/prettier-plugin-curly
| paulddraper wrote:
| That's bizarre. They add/remove parens...but not curly
| braces...
|
| How do you even justify that...
| bennyg wrote:
| Have you tried the print width option:
| https://prettier.io/docs/en/options.html#print-width?
| nicoburns wrote:
| Yes, but unlike most formatters where the width option is a
| maximum and it _mostly_ leaves your code alone below that
| width, prettier will aggressively widen your code to fit if
| you up the print width setting.
|
| I think rustfmt will actually also widen code you have put
| newlines in sometimes. But it's heuristic is somehow much
| better than prettier's.
| harimau777 wrote:
| Agreed! I'd go so far as to say that we would be better off if
| Prettier was never created.
| fenomas wrote:
| I think the real issue with prettier is that it's almost become
| a de facto standard. E.g. personally I don't like it _at all_ ,
| but do like Svelte, and Svelte's official (and AFAIK only)
| formatter uses prettier. Hence I use prettier for Svelte, and
| ditto for a few other things.
|
| So the whole "extremely opinionated, if you want configuration
| go somewhere else" is great in principle, when people are
| choosing to use the tool. But if it becomes the only option for
| certain swathes of users, a touch more configuration would
| really be appropriate.
| digging wrote:
| Well, this bounty is just about the only way that the
| Prettier team could contribute to solving that issue, so
| rejoice.
|
| Besides that, I get the impression being a universal standard
| is kind of a non-issue for Prettier:
|
| - If it was widespread, but highly configurable, that
| increases friction when switching projects, because there
| will be tiny formatting differences everywhere
|
| - If it was not widespread, it would not be well known,
| increasing friction for users entering a project where it was
| used
| uxp8u61q wrote:
| > Well, this bounty is just about the only way that the
| Prettier team could contribute to solving that issue, so
| rejoice.
|
| Erm, that bounty was for the production of a program that
| behaves exactly like prettier in at least 95% of cases, as
| far as I understood what "prettier test suite" means.
| girvo wrote:
| If it was widespread but slightly more configurable, how
| would that increase friction? It's still always setup to
| run automatically and transform your input to the output.
| The whole point of it is you don't have to think about its
| rules, just code and it will do the rest.
| Cthulhu_ wrote:
| To use the Go language's formatter and a saying, "Gofmt's
| style is no one's favorite, yet gofmt is everyone's
| favorite." That is, you may not like the style, but it's
| preferable over having no tool ensuring consistent style.
| anshulbhide wrote:
| Would be cool to use a Replit Bounty next time!
| candiddevmike wrote:
| I'm still salty that all my eslint plugins decided to remove
| perfectly fine linters in lieu of Prettier. I find Prettier to be
| way too heavy handed and hard to reason about, and yet another
| tool that I never asked for...
| xdennis wrote:
| > I find Prettier to be way too heavy handed
|
| But that's the purpose of such tools: to stop endless debates
| about style.
| pcthrowaway wrote:
| I mean.. sure https://xkcd.com/927/
| constantly wrote:
| It's not a new standard so this comic really doesn't apply
| here. It's just being opinionated, for once, about what to
| use. I welcome it strongly, as I do tools like Black for
| Python, which do similar things. Just set that up in CI for
| anything and all my code looks the same, removing some
| overhead of readability.
| mm263 wrote:
| It isn't really applicable here since Prettier was de-facto
| standard at pretty much every place I've worked at - start-
| ups to FAANG
| harimau777 wrote:
| 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.
| digging wrote:
| > The problem is that style matters and therefore those
| debates matter.
|
| Does it? IME/O, styling only matters up until the point
| that it is consistent and reasonable. And I'm saying this
| as someone who used to want to debate and micromanage a lot
| of formatting standards in my projects. Ego is removed from
| the equation (unless you're the one trying to introduce
| Prettier to a reluctant team), and without ego, the debates
| no longer seem very important.
| shepherdjerred wrote:
| 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.
| deathanatos wrote:
| > _as long as your style is consistent, very few people
| actually care what that style is._
|
| This is an oft-repeated myth. There are some style rules
| for which that is true, but for some, there are
| objective, logical reasons to prefer one style over the
| other.
|
| For example, mandating the optional comma after the last
| time in a list whose items has been split over multiple
| times results in more readable and logical patches: if
| you mandate the comma, a patch that only adds items will
| only have added lines, whereas if you don't, a patch
| adding items can have a mix of add/remove lines.
|
| Pushing operators to the subsequent line makes it
| fundamentally easier to read as they all align, vs. a
| ragged right edge, and this is doubly important if the
| operators aren't the same, as it makes that _far_ more
| visible. (Though this is harder in some languages with
| odd behavior around this, such as JavaScript.) (This
| _also_ affects patch readability in many languages, and
| in fact, I 'd say patch readability is _the_ driver of
| many objective reasons behind styling choices.)
|
| And so forth. I'd wager as many rules have logical
| reasons backing them as those that actually do boil down
| to literally just stylistic decisions.
| thenbe wrote:
| The deprecated style rules have been ported by a new project:
| https://eslint.style/guide/why
| Dextro wrote:
| Thanks for this. It completely escaped me and all I saw was
| the changelogs deprecating the very limited set of style
| rules I've used for years.
| Vinnl wrote:
| In what cases are you "reasoning about" Prettier? I can only
| think of the occasional issue with merge conflicts, perhaps.
| smnscu wrote:
| I feel like people complaining about Prettier being "heavily
| opinionated" are missing the point. Perhaps I'm biased by my
| decade of using Go, but not having to worry about superfluous
| stylistic choices is a welcome reduction in cognitive load. (Up
| to a point I guess, e.g. I'd never put up with K&R-style newline
| opening brackets).
| pigeonhole123 wrote:
| 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
| preommr wrote:
| Then just change it in the prettier config.
|
| 80 characters is a really good default. I have an extra wide
| monitor, and with 2 side panels open in my IDE, that's the
| perfect length.
| pigeonhole123 wrote:
| It will then force longer lines, which is even worse.
| atom_arranger wrote:
| 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.
| nicoburns wrote:
| 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".
| pigeonhole123 wrote:
| It can safely ignore the line length, gofmt does this and
| I've never heard anyone complain about it. The VSCode
| formatter also doesn't touch line breaks and it works fine.
|
| Last time I looked into it, the only reason I can't turn it
| off is that Prettier works off an AST that doesn't keep the
| line breaks that the user put into the code at all, and it
| "rebuilds" the whole code from this AST.
|
| The problem is not the diff per se, the real problem is
| that I can't find a configuration of Prettier where I can
| have long lines where it makes sense and short ones where
| that makes sense.
| tuetuopay wrote:
| Funny, that's the one thing I complain about gofmt. I can
| cope with the occasional diff noise but avoid kilometer-long
| lines. This is especially noticeable for function names that
| get long quite quickly.
|
| Also, this means that there is more than one way to format
| the code, which stands pretty weird given the philosophy of
| Go.
| nicoburns wrote:
| I don't understand the hate for "kilometer-long" lines (say
| in the 120-200 char range). My screen is much wider than it
| is long, so having longer lines allows me to fit more code
| onto the screen at once (which is fantastic for
| readability). Also, sometimes the extra content is
| _uninteresting_. And it makes sense to hide it away where
| it 's only sometimes seen.
| tuetuopay wrote:
| I'm modern, and a 120 char line is not kilometers long.
| It's in the range for modern stuff (yep, I'm an advocate
| for dropping 80 chars). km long lines start at 200 chars
| IMHO. To me, too long lines actually hinders readability:
|
| - kilometer-long lines makes your eyes travel a lot more
| to read what is happening. travel is not that an issue,
| but context is. it is quite hard to get at a glance e.g.
| the argument list of a function. or know if e.g. a
| specific parameter is in the argument list.
|
| - I almost never have my editor's viewport set to
| kilometers. It's usually in the ~110 chars range to fit
| multiple files at once (two side-by-side on 1080p, three
| on 1440p). Not that I am editing three files at once, but
| I'm usually editing the middle one with other files on
| the side for context and reference. In such a setup, the
| line ends up wrapped anyways, but with ugly wrapping that
| does not match indentation and in the middle of words.
|
| As for hiding it, that's what editor folds are for.
|
| Anyways, I guess we found bikeshedding topic not solved
| by formatters :D
| WorldMaker wrote:
| Wider screens can also be used to have more code files or
| sections of the same file side-by-side. You can get two,
| three, sometimes four 80-char width files very nicely
| side by side.
| pigeonhole123 wrote:
| Line breaks often carry meaning, for example many people
| like to line up things that belong together but which live
| on separate lines, and gofmt helps with this. Having many
| ways to format a given AST (unlike Prettier) is not against
| the Go philosphy which I would say is "be pragmatic".
|
| If you want a line to be shorter because you as a human
| find it easier to read that way then you can add a
| linebreak yourself, and trust that your meaning will be
| preserved.
| j1elo wrote:
| Funny thing: I recently learned Go, coming from doing some
| TypeScript and the refreshing feel that was discovering
| Prettier.
|
| I really miss that gofmt applied some limit to line length.
| In TS I just write a too long line, and Prettier reformats it
| into a sensible set of consecutive lines, I don't even have
| to think if breaking before or after this or that parentheses
| or bracket. With Go, I have to, and I'd rather not.
| warp wrote:
| Couldn't you just set the "printWidth" in .prettierrc.json to
| something super long?
| laurent123456 wrote:
| 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.
| solatic wrote:
| `lineWidth` is actually one of the available options in the
| biome formatter: https://biomejs.dev/formatter#configuration
| nicoburns wrote:
| Yeah, but if you increase the lineWidth then it will make
| _all_ your lines that long, even if you don 't want them to
| be. There is no possibility for variability of line lengths
| depending on the code at hand.
| pkilgore wrote:
| Why throw out the tool when you can have the tool ignore [1]
| whatever is outside the common case?
|
| [1] https://prettier.io/docs/en/ignore.html
| pigeonhole123 wrote:
| My approach is to just not use Prettier but instead use the
| much more well behaved formatter included in VSCode. I
| don't have time to fight the formatter and I don't like
| having these "cheat code" comments all over my code
| nulld3v wrote:
| Are there benchmarks for Biome anywhere? How much better does it
| perform than prettier exactly?
| nulld3v wrote:
| Found some here:
| https://github.com/biomejs/biome/blob/main/benchmark/README....
|
| They claim 25x but the numbers are old so I'm not sure if I
| believe them now that a bunch of new functionality has been
| added. Either way, if it's anywhere within that ballpark it's
| still a huge achievement.
| conaclos wrote:
| This heavily depends on your workstation. Biome scales very
| well. With 16 threads on a i7-120P, I got the following
| figures:
|
| Webpack repository: Biome ran 2.19 +-
| 0.11 times faster than dprint 4.18 +- 0.14 times
| faster than Biome (1 thread) 32.12 +- 1.18 times
| faster than Prettier 32.45 +- 2.56 times faster than
| Parallel-Prettier
|
| I am not sure why Parallel-Prettier is slower than Prettier
| for the webpack repository.
|
| Prettier repository: Biome ran 1.89
| +- 0.21 times faster than dprint 3.47 +- 0.34 times
| faster than Biome (1 thread) 36.70 +- 3.41 times
| faster than Parallel-Prettier 46.66 +- 4.32 times
| faster than Prettier
| gostsamo wrote:
| Many people comment the reasons without acknowledging that part
| as well:
|
| > By matching all the tests, the Biome project also found a lot
| of bugs and questionable decisions in Prettier that we will be
| able to improve upon.
|
| For me, this means that they have another implementation for
| sanity checking their own.
| jdorfman wrote:
| Thank you for posting this. Sourcegraph is now a sponsor on Open
| Collective.
| thenbe wrote:
| 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"?
| jakub_g wrote:
| This is indeed the biggest annoyance of mine. I quite often end
| up rewriting code or changing variable names to counterbalance
| prettier making code ugly/unreadable.
| tills13 wrote:
| eh -- this is a one-time occurrence with prettier. Subsequent
| changes are guaranteed to be changes-only since formatting is
| consistent between authors.
| c-hendricks wrote:
| 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.
| WirelessGigabit wrote:
| This isn't just a JSX problem. This is in any language that
| once you go over the column limit that it'll try to break
| it somewhere.
| ljm wrote:
| 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?
| tubthumper8 wrote:
| > 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#_inli
| ne-...
| ljm wrote:
| 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)
| yawboakye wrote:
| 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).
| nicoburns wrote:
| Extremely configurable? It has like 3 config options, and
| an explicit policy of not being configurable.
| hu3 wrote:
| > prettier is extremely configurable
|
| That's the opposite of what they claim:
| https://prettier.io/docs/en/option-philosophy
| SamBam wrote:
| 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.
| richardwhiuk wrote:
| > Then you won't ever see line-width changes mixed in with
| functional changes.
|
| You will - every time you extend a line which now exceeds the
| limit.
| twicetwice wrote:
| Isn't this a natural consequence of having line length
| limits? This seems like a general problem, not a problem
| with Prettier.
| richardwhiuk wrote:
| Sure
| lainga wrote:
| 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.
| JasonSage wrote:
| 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.
| Cthulhu_ wrote:
| Is that down to the formatter - which you've configured to
| enforce a certain line length
| (https://prettier.io/docs/en/options.html#print-width) - or
| the diff visualiser that doesn't show a difference between
| whitespace and other changes?
| j1elo wrote:
| 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 amount of _actual noise_ when having to discuss these
| things with other people.
|
| EDIT: This comes from a backend dev (C/C++, sometimes Go,
| recently did some stuff with TypeScript). Prettier was a
| refreshing discovery, and other languages like Python are able
| to express the rule very sensibly (albeit I round it and go for
| 80 or 100):
|
| https://peps.python.org/pep-0008/#maximum-line-length
| nicoburns wrote:
| > 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
| breaks things in weird places. This is IMO not a small
| reduction in readability.
| j1elo wrote:
| 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.
| culi wrote:
| I wasn't aware Rust chose a 100 line default. I'll
| definitely be using this to argue on my teams for why we
| should stretch the line length limit past 80. Thank you
| Rust for moving the industry forward
| j1elo wrote:
| I guess Rust made the same reasoning than Python. For
| this kind of things, the PEP documents tend to be well
| based on experience and be a good guideline which even
| applies for other languages. Check the PEP 8 that I
| linked in my comment: although they recommend a very
| conservative limit of 80 (79 actually) it says that if it
| makes sense, 100 (99) can be used too. And that's from
| 2001.
| wentin wrote:
| Do you work with a large team? There is no correct answer
| for formatting for a team, there is only correct answer for
| individual person. The line limit 80/120/160 will work for
| certain people with their setup, but not others. Stuff like
| using a ultrawide screen with two columns, or code on
| laptop screen with single column, or code with half screen
| code editor and half screen browser, etc, there are endless
| mutation, all of them can benefit from different settings.
| It is essentially not possible to find the best option for
| everyone on the team. You may think 120 is the best, but
| there is no way to prove it. It just worked for you because
| of your coding setup and preference.
| kuchenbecker wrote:
| I don't care what the limit is unless it's consistently
| applied.
|
| My least favorite though no limit + soft wrapping, the
| philosophy being the code adapts to the user, but in
| actuality means the file looks completely different based
| on your monitor and setup removing visual aid to code
| navigation and familiarity.
| dieselgate wrote:
| I work on a ruby/ts/js codebase and seem to recall
| different file extensions having different line lengths.
| Something like that is annoying but at least it's more
| consistent within the file extension
| culi wrote:
| > It makes a lot of my code 3-5x as long.
|
| Do you mean entire files are made 3-5x as long or just
| individual lines every now and then?
| ipaddr wrote:
| 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.
| j1elo wrote:
| 100 is OK. But better to wager for 80, so people complain
| about their preferred 120+, and ending up with an
| acceptable 100 as a middle ground.
|
| On my screen with 1920x1080, 2 side-by-side panels can fit
| 100 chars, but only if the sidebar is hidden (project
| layout, list of open files, that kind of stuff).
|
| On my laptop, 2 side-by-side files won't fit if they exceed
| 90 chars.
|
| I just don't want to concede to those devs who use a single
| editor pane with an ultrawide monitor, and believe that
| everybody must work like they do.
| hoherd wrote:
| 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
| wentin wrote:
| People use ultrawide screen, with half screen dedicated to
| browser, half screen for code editor, and two columns open
| in editor. This is very modern setup, and 80 is perfect for
| it. Don't limit your thinking to your own setup.
|
| I think discussion on the perfect limit on public forum is
| non-sense. It might be slightly less non-sense to discuss
| it with your team, but even that I think it is bike-
| shredding most of the time, unless the entire team for some
| reason (like they share the same equipment setup and happen
| to have same preference) overwhelmingly share the
| sentiment.
| The_Colonel wrote:
| > People use ultrawide screen, with half screen dedicated
| to browser, half screen for code editor, and two columns
| open in editor. This is very modern setup, and 80 is
| perfect for it. Don't limit your thinking to your own
| setup.
|
| It kind of sounds like you're promoting your own setup.
|
| The funny thing I see the most is that people with these
| crazy widescreen monitors still maximize just one window,
| with just one file open. Not sure why, maybe for focus?
| The_Colonel wrote:
| > If the limit is 80, then the limit is 80, not 81.
|
| I don't see a reason to enforce this strictly. The goal is
| readability, the max line length is an _approximate_ proxy
| for that.
| j1elo wrote:
| I agree, actually :)
|
| I ignored this point on purpose, to be more succint. But
| yes, it could be possible to have a _soft limit_ (e.g. 80,
| or 100) and then you would have to set a _hard limit_ (say,
| 85 or 105). But in the end you 'd end up having someone who
| complains because their beautiful line was 84 chars and
| after adding the closing paren and the semicolon, it got
| wrapped into something that they don't like because
| _subjective tastes_.
|
| So in the end, we just moved the goalpost +5 chars.
| mvdtnz wrote:
| I understand not wanting to bike shed on the actual number
| but I refuse to accept 80. I simply do not agree that the
| greybeards with 70s technology got it figured out perfectly
| in their day and nothing has changed.
| c-hendricks wrote:
| Some things overlooked in that blog post for others to take
| into consideration:
|
| - eslint only works on javascript + typescript (eslint +
| typescript needs _more_ configuration than eslint + prettier),
| while prettier works on
| https://github.com/prettier/prettier/blob/03ebc7869dc9e8f2fc...
|
| - eslint + prettier doesn't need lots of configuration from the
| user. You add eslint-plugin-prettier and say `"extends":
| ["plugin:prettier/recommended"]`
| thenbe wrote:
| By default, eslint only lints files with a .js extension[1].
| Eslint plugins are what allow eslint to support more
| languages. A list can be found here[2].
|
| For the record, prettier can also be extended to support more
| languages[3].
|
| [1] https://eslint.org/docs/latest/use/command-line-
| interface#--...
|
| [2] https://github.com/dustinspecker/awesome-eslint#plugins
|
| [3] https://prettier.io/docs/en/plugins#official-plugins
| varrock wrote:
| 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/
| sltkr wrote:
| 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.
| tharkun__ wrote:
| Enforce semicolons.
| chris_wot wrote:
| gawd and this is why the semicolon debate wasn't just bike
| shedding.
| HALtheWise wrote:
| How much does prettier formatting help here for practical
| cases? In particular, if the autoformatter allowed that
| second example with the indentation on the last line, I'd
| treat that as an autoformatter bug.
| blauditore wrote:
| That's technically true, but extrememly rare to cause real
| problems (short of bad intent). It reminds me of
| people/teams enforcing braces on single-line ifs, because
| one might add another line someday, forget to add braces,
| and break the logic. Even when it happens, there should
| still be tests that catch this.
| Shish2k wrote:
| On the one hand, yes, there _should_ be tests. On the
| other, `goto fail;` :P
|
| Also, adding braces from the start means that adding one
| new line of code is a one-line patch, instead of a four-
| line one - I do that for the same reason that I always
| put trailing commas on my array definitions
| IshKebab wrote:
| That's not an issue with Prettier; it's an issue with having a
| consistent style and not using syntax aware diff tools.
| adam_arthur wrote:
| Yes, Prettier largely won by not having many competitors
| strictly focused on formatting in a simple to consume package.
|
| I don't think many people who are serious about high "signal to
| noise" code formatting are supportive of the design decisions
| prettier makes. e.g. the staggered import lines, left-shifting
| and up-shifting of implementation details, not allowing
| trailing comments on the same line
|
| We can have consistent formatting and also avoid tons of visual
| noise that prettier produces... I've wanted to build a
| competing solution for awhile, but never made the time for it.
| Perhaps Anthony's project achieves that... I'll give it a try!
| Cthulhu_ wrote:
| It's not a dichotomy though; performance is imo essential for a
| tool that will run on every save, every commit, every pull
| request. It might be fast enough, but adding all runs up adds
| up to a lot of unnecessary energy waste.
|
| With regards to the whitespace issue, that's down to the line
| length rules used I think. It's also down to the diff viewer
| how to show it, not the formatter.
| meindnoch wrote:
| "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 follows from the fact that
| something is written in Rust. One could have simply transpiled
| the existing codebase into Rust, and collect the reward.
| tills13 wrote:
| > One could have simply transpiled the existing codebase into
| Rust, and collect the reward
|
| Why didn't you, then?
| meindnoch wrote:
| Because this is the first time I've heard about this contest.
|
| But I'll do it for you, if you put up the 20k USD. Will you?
| strager wrote:
| Here is the answer I got from vjeux:
|
| > There's a lot of fast web tooling being written in rust those
| days. https://twitter.com/Vjeux/status/1722769322299609565
|
| I don't buy it. I think vjeux is riding the hype.
| tubthumper8 wrote:
| > 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.
| nicoburns wrote:
| > I don't see how better performance follows from the fact that
| something is written in Rust.
|
| Idiomatic Rust will often by 5-10x faster than very similar
| looking JavaScript/TypeScript code without even trying to
| optimise it. It depends what you're doing, and this doesn't
| always apply. But parsers where you're doing a lot of string
| manipulation are one of the cases where it definitely does.
| refulgentis wrote:
| "[to] get Biome running in Wasmer", it seems
| thowaway91234 wrote:
| So this isn't replacing the main implementation? They just funded
| a new project written in Rust that is compatible?
| codeptualize wrote:
| Awesome! Lets gooo!
|
| Can't say prettier performance ever bothered me, but if it can
| run faster and leaner I'm all for it! Increase my battery life :D
|
| In general it's really exciting to see the advancements in JS
| tooling, the quick successions of tooling in JS might be
| controversial, but I love it. Each step was a significant
| improvement over what was there before, and the current Rust
| rewrite wave has already given us great tools that I use daily.
|
| I also like that there is some money being thrown at the
| problems!
| 11235813213455 wrote:
| I dislike prettier and wonder why it's so popular because
|
| - I sometimes prefer lines to exceed maxLength (ex: template
| string, which prettier would horribly break on vars)
|
| - allow `1 + 2 * 3` or `a || b && c` to be parenthesis-less
| because everyone know the precendence here
| digging wrote:
| > I sometimes prefer lines to exceed maxLength (ex: template
| string, which prettier would horribly break on vars)
|
| Prettier doesn't break a long template literal though...?
|
| > allow `1 + 2 * 3` or `a || b && c` to be parenthesis-less
| because everyone know the precendence here
|
| "Everyone knows" is usually an unwise assumption. And adding
| parentheses does make it easier to read even for people who
| know their order of operations.
| sarahdellysse wrote:
| Not OP, but prettier doesn't break template literals, but it
| will break non-literal sections of template strings. For
| example, if we wrote this: const foo = `aaa
| aaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`;
|
| prettier would fix it to const foo =
| `aaaaaaaaaaaaaaa${ bbbbbbbbbbbbb
| }ccccccccccccccc${ ddddddddddd }`;
|
| (or something similar) and it would be fully equivalent.
|
| I don't like it doing that either tbh but hey prettier is
| good enough in most cases its worth putting up with it
| shrimpx wrote:
| > You may not be aware but thanks to all those donations, we've
| been able to pay two people $1.5k/month for the past two years to
| keep shipping. Fisker Cheung and Sosuke Suzuki have done an
| incredible job!
|
| It's incredible how little money some people get paid to build
| foundational pieces in a multi-trillion dollar industry.
| uxp8u61q wrote:
| I don't want to disparage prettier, but to call it a
| foundational piece...
| fallat wrote:
| I agree. Foundational isn't the right word here. I would
| though accept "impactful". A lot of people care about code
| formatting "taken care of".
| wentin wrote:
| Maybe essential is a better word.
| austin-cheney wrote:
| That is still far too much an exaggeration. This is an
| opinionated beautifier. Its a vanity item with some
| downstream utility benefits.
| cdmckay wrote:
| A formatter is pretty essential when working in a team.
| It saves tons of time wasted on code formatting in code
| reviews.
| 0x0000000 wrote:
| > A formatter is pretty essential when working in a team.
|
| I worked on a team without a formatter for more than 5
| years. I'm certain _many_ people have done the same.
| "Essential" is overselling.
| aniforprez wrote:
| I think at this point I would consider a formatter
| essential for working with a team. It helps make code
| style opinionated and fixed and I have no surprises when
| reading code. No one doing weird formatting to align
| random things. Any formatting tool that allows for pages
| upon pages of options is simply not something I want to
| deal with. Something like black, gofmt and prettier is
| vital
| austin-cheney wrote:
| Bike shedding. I say this as somebody who has written a
| once prominent JavaScript code beautifier. Automating
| code beautification is a nice to have. It becomes
| essential when developers cannot be bothered to focus on
| more important things because either more important
| things are too challenging for the given developers or
| because the given developers want to feel more important
| than their contributions/decisions are actually worth.
| shrimpx wrote:
| Auto formatting tools like prettier and black didn't use
| to be essential but they're quickly becoming essential.
| Just look at the growth curves for pip and npm installs.
| I for one feel like my editor is broken if it doesn't
| auto format on save.
| gardenhedge wrote:
| How about ubiquitous?
| silverlyra wrote:
| When seeing Prettier as a software tool, to consider Prettier
| more "foundational" than (e.g.) TypeScript or V8 does seem
| like an inversion of hierarchy [1] - but viewed as history,
| as a practice, Prettier's accomplishment of making automatic
| code formatting (a la `go fmt` or Python `black`) widespread
| in JavaScript, the lingua franca of programming, is
| foundational.
|
| All that time spent staring at code that could have been more
| readable, or writing style guides and reformatting code, is
| now spent doing what we were trying to do in the first place.
| And now, speeding up the time we wait to apply formatting or
| check it in CI by _rewriting it in Rust(tm)_ gives us a bit
| more of that time back. :)
|
| [1]: https://youtu.be/ar9WRwCiSr0
| Cthulhu_ wrote:
| I wouldn't call it foundational, but it would be one of the
| first things I'd set up in a new JS based project, alongside
| unit tests, com/transpiling and eslint.
| fallat wrote:
| Nerd sniping is incredibly effective. I would say it's abused
| quite often too.
|
| I don't know what to say other than, if these people are out of
| a job, and you're a company funding prettier or need good JS
| people, please hire them.
| shepherdjerred wrote:
| Like the others said, Prettier isn't foundational.
|
| That said, it brings in _much_ more value than $1.5k/mo. It has
| eliminated styling arguments on teams that adopt it. The amount
| of time saved in PRs/reduction of bikeshedding is very
| valuable.
| The_Colonel wrote:
| Meh, most devs I've met can format code better than Prettier.
| Having a consistent set of rules sounds alluring at first,
| but the issue is that mechanical application is, well,
| mechanical and therefore dumb.
|
| My personal impression is that the code style bike shedding
| is a sign of team immaturity. In the more mature teams
| (composed of more mature persons), I haven't really seen
| formatting bike shedding.
| joshxyz wrote:
| Yeah right until you're working in a team of 30+ people
| without a code formatter like Prettier.
|
| Since when did caring about readability equated to bike-
| shedding and immaturity?
| Cthulhu_ wrote:
| Just because they can, doesn't mean they should; how many
| comments in your code reviews are about code style?
|
| In mine, it used to be... at least half, because I was anal
| about code style and consistency and all we had at the time
| was ESLint, which only did partial code stile.
|
| Nowadays, it's none. If you need to worry about code style
| in code reviews, use a tool.
| Cannabat wrote:
| Those devs _can_, but why should they? Code formatting
| takes a lot of time - it doesn't matter how skilled of a
| dev you are - you can only accurately <tab> and <space> so
| fast.
|
| But the big win for code formatters is fewer decisions.
| Decision fatigue is real.
|
| What's wrong with the application of e.g. Prettier? Is it
| wrong enough that it's worth your time to manually format
| however many thousands of LOC, making countless micro
| decisions along the way?
| shrimpx wrote:
| It's "foundational" in the sense that it gets 30M weekly `npm
| install`s which is up 500% from 4 years ago and growing.
| Js/Ts projects depend on it heavily.
| jejeyyy77 wrote:
| this, lol.
|
| Even a $20K bounty for that amount of work doesn't even seem
| worth it to boot up my IDE.
| assimpleaspossi wrote:
| Their next bounty should be for fixing their insistence on
| putting a closing slash on HTML tags that have never, ever
| required them in any HTML specification.
| neontomo wrote:
| I couldn't find the answer - does Biome work with a
| prettierrc.json file so that it can be implemented in an
| organisation that uses Prettier? In this case it would only be
| for speed reasons, not the formatting.
| bntyhntr wrote:
| I would love to hear about any of this. I couldn't find a clear
| migration path with some quick googling, but I managed to
| eventually track down the rules I need to get mostly compatible
| with my org's prettier formatting. Notably, stuff I needed was
| in the `javascript.formatter` section of config. But even after
| matching everything, Biome was wrapping lines differently. Not
| sure but I don't actually run the front-end show so I stopped
| poking at that point.
| bovermyer wrote:
| So, how does Biome compare to Dprint?
| afjeafaj848 wrote:
| Maybe I missed it but I don't get how this improves the JS
| implementation
|
| Are they planning to run Rust in the browser? Or make some sort
| of node module that calls down into rust?
| adam_arthur wrote:
| Rust can run in the browser via compiling down to, and running
| as, WebAssembly. So I don't see why not.
|
| Prettier is run mostly on the serverside though, not the
| browser. I assume supporting both is still desirable though
| WorldMaker wrote:
| There are node modules already that call into WASM-wrapped
| rust. (One of the most common source map generation packages
| does exactly that and it is very heavily installed by a lot of
| frameworks and packagers today.)
|
| I don't think prettier is intending to do that in this case,
| they seem to want to continue to compete as a pure JS
| implementation but having a "worst case, we WASM wrap biome as
| the future of prettier" possibility opens up future
| opportunities and pushes "internal" competition.
| wg0 wrote:
| > 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.
| hendry wrote:
| Anyone know the minimal package.json or Github template to get
| this going in a new repository please?
| globular-toast wrote:
| Why did it have to be Rust? Couldn't have just been "faster"? Is
| the Rust one actually fast? Does memory safety and leaks etc even
| matter for a program like Prettier?
| WorldMaker wrote:
| There's a lot of vocal people especially here on HN that think
| that Rust is the fastest, safest language currently around, so
| this was maybe in part a "put your money where your mouth is"
| challenge.
| kamikaz1k wrote:
| Does any body have a collection of all the profiling Fabio
| Spampinato did?
| fabiospampinato wrote:
| I haven't really kept track of everything. It may be worth
| making a blog post with the main findings though.
| vinniepukh wrote:
| I want to use Biome, but until it either has plugins or
| implements the tailwindcss class sorting itself, I will not be
| able to adopt it.
|
| This is a common sentiment in the fullstack community right now.
| mvdtnz wrote:
| So now there are two distinct, somewhat compatible but surely
| diverging implementations of the same thing. Yup, sounds like the
| JS ecosystem.
___________________________________________________________________
(page generated 2023-11-27 23:00 UTC)