$20k bounty was claimed

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.

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.

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?

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.

Yeah, it's closer to 1.5x. Most companies budget total comp at 150% of salary.

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.

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 Kaiser health insurance seems fairly close to what I pay for COBRA from my former big tech employer.

Interesting.

My Kaiser almost doubled from COBRA and coverage went from better-than-platinum to high deductible gold.

Google / SF market.

I have Google COBRA in SF too and when I last looked a year or so ago it was about $100/year more on the marketplace for the KP platinum plan.

Age makes a huge difference to the marketplace premiums though.

But COBRA is more expensive than the same plan when paid by the employer with pre-tax dollars.

Healthcare cost doesn't scale with the $200 base salary, though.

Most? I can't think of a gig beyond maybe a couple of folks in a coworking space where I wouldn't be laughed out of the room with "just make it 150% of salary and we'll figure out the real number whenever". Virtually every company I've ever worked with budget the actual number, because they know how much the overhead cost is. There's a huge difference between "a number I use when asked 'ballpark how much a new hire is gonna run us'" and "what is the amount of money I'm asking the CEO to allocate me in next years budget".

Depends on the kind of work you do and the competition. A former employer was really desperate for pretty journeyman-level Django Dev help a few years ago and for some reason it was just super tight. Ended up paying more like 350% after looking a few weeks. We obviously weren't going to hire someone at that rate for a 6 month contract but for short term help? Sure.

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.

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.

1.5x for long term contracts. 2~2.5x for short term gigs.

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)

how did you factor in when you can't work (sickness, holiday, increasing your skill, finding the next job etc)?

2088 potential work hours in a year Less 88 hours holiday Less 80 hours vacation Less 56 hours sick =1864 hours (these are federal guidelines under the Service Contract Act regs)

232/1864 is a base increase of 12.5% for PTO

Payroll taxes, Medical, workers comp, etc add about 30% - though medical is flat so at higher wages like discussed here the % increase it represents goes down further

I did not have to factor in increasing skill on the job or time between jobs - but I did have to account for overhead and g&a which would be similar to time between jobs since those would be for bills

Big companies would have a lot of markup on OH/g&a/fee, but a software dev working remote for themselves on contract could competitively go down to 5-10% or less here to simply cover the minor added burden to bills.

That totals up to about a 50% increase on the salary rate. You can't outright bill someone for time you spend looking for a new job or improving your skills. You may charge a premium that you use to do such things but that would have to go under fee which tends to top out at 15% with the government, not something that can be expected to be accounted for. In my experience at least.

Again though, this was for service contracts - particularly with the US government, subject to certified cost and pricing data disclosures.

I was genuinely curious about the 2.5 number though, as i have spent a lot of time dealing with market rates in various conditions I was interested to know the context. I could see a few ways that could happen, but I wouldn't want to speculate too much

I think the number is pretty dependent on the flow of jobs. If you work in some kind of incident response, for example, it's going cost more than if you've got downtime between 6 month contracts.

That sounds about right. On the other hand it does mean that you are producing this kind of work for big FAANG companies you should expect to earn $80/hour. This is around the low end of a senior software engineer or the higher end of a junior software engineer.

I have heard of a database "engineer" paid $250 an hour to spend weeks creating what is basically a connection string to a database in a corporate virtual lan. The people paying him were never concerned about the cost, just how long it was taking. This was in Nebraska.

In the right locations, developers can benefit from a profound lack of competition, especially if they have some enterprise software bullshit on their resume and some less savvy company nearby refuses to hire someone to do it remotely.

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 €75 - €150/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.

but those are for at least a few weeks of engagement, no? 8h/day, right?

I think most people on here are citing US based conditions, particularly with respect to healthcare costs and various taxes.

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.

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.

I mean, if you work 20 hours a week, then you don't have 40 hours a week of work

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.

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.

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.

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.

where are you finding these rates at? i have rarely seen anything even passing $100/hr in canada, contract or not

IT developers are often around $100/hour outside Toronto, Toronto being a bit more. Upwards of $150-200 if its speciality work or you're a team lead.

It varies though, the market also exists for $80/hour java developers, which tend to be new grads

Contract Developers going to technical companies will earn more like $180+.

every time rates come up on this website, people come out of the woodwork claiming "most" developers in every north american country make half a million or more a year. it's hard to not feel like this is just a few people using this as an opportunity to brag about their rates in niche industries (or people are just lying)

i have been a contract developer, and have worked at technical companies in canada, and have never seen rates that are even close (and im not a jr / have never used java for work outside of small amounts for mobile.) there's no way these rates are as common as you are all making them out to be, unless it's some niche, or you're talking about extremely short contracts, or there's some other missing piece of context

Dude I got $1000 a day in Canada in the early 90s. You just need the right skills and contacts.

Yeah when I was a contractor in 1996 Mountain View $200 was table stakes for someone with non trivial technical skills.

very few and small geographic parts of the world

There's reasonably good data about this that contradicts this?

$1000 as a day rate isn't unusual or unreasonable for a specialist IT contractor; and I don't say that idly; I say it from both experience and you know; aggregated data:

- https://www.hays.com.au/documents/276732/1102429/Hays+Techno...

- https://www.itcontracting.com/rate-checker/

- https://news.ycombinator.com/item?id=32606348

Yes, if you want someone to slap a php website together (or javascript, or many other entry level frameworks), you can pay less.

...but that's not what they were asking; they were asking for a technically sophisticated analysis of an existing project and a performant re-implementation in rust.

They got a bargain.

The problem is that many individual freelancers look at their work from an employee perspective, not from a business perspective. From an employee perspective $200/hour may seem extravagant, but from business perspective it is nothing.

So if you hire an agency to perform a contract, they'll bill you $2000 per day and send you their employee who makes $100 an hour. Agency pockets the $1200 (it's a simplification, but should paint the picture).

Freelancer and agency both run the same business model. If you think like employee and charge extravagantly less, you will never grow.

You should typically charge enough, so that for any given project you could hire an employee to do the work, while you look for new leads or you can keep the money in the company and do the work yourself until you amass enough capital to move up the business ladder.

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.

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

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.

I never heard of "Age" before this post. Thank you to share. If others are interested to learn more, here are two other interesting posts about Age:

https://github.com/FiloSottile/age/discussions/432

https://words.filippo.io/dispatches/age-authentication/

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.

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.

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.

Can confirm. I wrote an OS library once for a thing. It started getting popular, then suddenly a large, well known project shipped an alternative solution (competitor?). It was the best thing ever to happen to my project. I got what I wanted (what my library aimed to solve) and no longer had to be the maintainer for that thing.

I'd be less interested if in order to fix a new issue related to my problem, that I had spend weeks to learn a whole new language, dev env, build system, etc just to add a feature that would have taken me 15 mins in the language I'm used to.

Of course I'd love to learn rust! But, for the most part, I just need to get stuff done so I'd prefer to stick with what I know and can mod easily and leave the "learn an entire new language" part for something that actually needed that language.

Yes, I'm sure rust is amazing but, Just a guess that the number of programmers that can contribute to a rust project is probably 3-4 orders of magnitude less than the number of programmers that can contribute to a JavaScript project. Well, maybe if you subtract all the "competent enough to a submit a coherent pull request" programmers the number is only 2-3 orders of magnitude?

Basically I'd assume, if a project targeted at JS, switched to rust, the number of useful pull requests would be 50-100x less.

I wonder if anyone has any data on that (and similar projects re-written in C++ or Go etc...).

Speaking as a contributor to Prettier, it is _not_ an easy codebase for someone who knows JS to just jump into and contribute.

Furthermore, projects like Ruff show you can have a lot of contributors for projects like this. Maybe because there are lots of devs who use TS or Python in their day job, but want excuses to use Rust on the side.

Anecdata, but as a maintainer of both Python and Rust projects, while it’s true that the Rust projects have fewer contributors/issues, the quality of contributions is on average higher

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.

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.

why would the Prettier team fund another project!?

Less "the team" per se, and more vjeux, I think.

Sorry for being late to the party. What I really care about is that we have fast code formatting in the industry.

But performance is a field that's really hard to accurately measure as there are so many variables, machines, benchmarks... You can see this in the JavaScript ecosystem where every project says that they are faster than the other one and they are in practice all right depending on which benchmarks they use.

So, creating a big bounty with something that's very hard to accurately measure is likely not going to work out very well.

In practice in the ecosystem, the Rust community really cares about performance. So it feels that this is the right audience to build something really fast. But, so far, none of the Rust-based printers were even close to outputting the same thing as prettier. They all decided to implement a different set of options, made different design decisions...

So every time somebody mentioned using one of those, I was getting annoyed that I would --love-- to recommend them, but it wasn't going to be the same. And I believe from experience that one of the main reason Prettier has been so successful is because of this --very very very very-- laborious last few percent of edge cases.

So goal #1 is to convince at least one of those projects to start being compatible with Prettier so that we had a viable alternative. In practice, there was no way I could talk to them directly and convince them to align with Prettier. So the idea of the bounty came to be, if I made a bounty big enough, it would be a way to convince them to do so (and it worked!).

The bounty to work needs to be very easy to test (percentage of tests that pass is very easy to test), cannot easily be cheated (unless you run prettier itself, you need to go through the laborious work of doing the same logic) and cover real world use case (all the tests were added over time based on using it in prod). It also mentioned a "project" and not a "person" to encourage collaboration.

It's a bit unorthodox but I've learned my lesson with code formatting that people are obsessed about discussing this topic so you need to find alternative ways to convince them.

Now, going back to Prettier, I've been very annoyed that nobody had looked at performance of the project since after I stopped working on the project. For example, I wrote a way to keep the prettier process alive for editor integration instead of paying for the startup cost every single time https://github.com/prettier/prettier-rpc and nobody used it. I needed to find a way to convince people that prettier's performance actually matters.

One of the most powerful way to get people to improve performance is to have two competing offerings battling against each others. We've seen this very successful between JS engines, JS frameworks... But, due to the success of prettier, there was no competition, the JS Survey admins even stopped asking about it because it was the only choice.

So having a proper competitor which is faster and uses a relatively controversial language, was a good setup to get a competition going. And it also worked, since the bounty was announced, Fabio Spampinato got nerd snipped thinking he can make the JS version faster than Rust and has been working every day profiling and rewriting the Prettier CLI to be orders of magnitude faster. We are using the open collective money to contract him to work on this.

Outside of performance, by having another group of people work on the same tests, they uncovered a lot of broken behaviors and edge cases on prettier that should be fixed.

Last but not least, having a bounty incentivizing another project was intriguing enough to generate a lot of discussion and therefore receive a lot more coverage than just asking people to work on your project.

----

So, overall, it achieved all the outcomes I wanted: by the end of the year, prettier itself is going to be a lot faster, and we actually have -less- fragmentation in the space where the other big project is now aligned in terms of the way code is formatted.

Would have I been able to spend $10k more effectively, I can't think of how. But I'm pretty sure I'm missing some better strats!

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.

One would be a singular bespoke (and highly specified) improvement, and the other is likely a generalized flywheel that may keep incentivizing many further improvements

I think there's some merit in creating a fresh solution with little or no bias from the original. Trying to adapt an existing codebase is limited by the existing applications architecture and how much you can change without breaking everything

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.

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.

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.

Maybe prettier will consume the biome work and offer it as an option for prettier going forward.

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.

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.

How much would you pay to have your project on the front page of Hacker News for most of the day? More or less than $20,000?

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)

Maybe they paid Biome $20k to have it be more "opinionated" with Prettier's opinions.

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

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

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.

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.

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.

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

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.

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

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.

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?

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.

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.

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?

Not promoting my setup, but just to point out that 80 is a sensible default, and it is not based / targeted for ancient old rare setups.

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.

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

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.

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.

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.

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.

Good point. Are there any code-semantics-aware diff tool out there though?

If you're looking for a VS Code extension or a GitHub app, check out https://semanticdiff.com/. I'm a co-founder of this project.

If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.

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?

It's impossible to turn off line length rules. You can only change the width, which means if you set it to a big number it will aggressively unwrap code you want to keep wrapped sensibly. Awful and unacceptable.

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.

Isn't this a natural consequence of having line length limits? This seems like a general problem, not a problem with Prettier.

Sure

It's an issue with prettier because it cannot be disabled.

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.

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.

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

one new line of code is a one-line patch

On the flipside, having three trivial early-return ifs at the beginning of a function will become 9 lines long with braces instead of 6 (or just 3, when doing single-line ifs). Very often, such cases never expand to multiple lines in the future.

Enforce semicolons.

gawd and this is why the semicolon debate wasn't just bike shedding.

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.

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?

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

Extremely configurable? It has like 3 config options, and an explicit policy of not being configurable.

prettier is extremely configurable

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

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)

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.

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.

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"]`

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

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.

You can already mostly do this with dprint's TypeScript plugin if you tweak the config (and I'm open to adding more config to support this scenario in case something is missing). For example, the TypeScript team uses a line limit of 1000: https://github.com/microsoft/TypeScript/blob/1797837351782e7...

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!

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

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.

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

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?

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.

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!

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.

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

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-notes/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

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!

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?

I'm not even going to enter into the flame-bait. I obviously disagree with your points.

Hope you have an awesome day

Haters gonna hate

If you dismiss all criticism of your behaviour in this way, you'll never gain any insight into why so many people find your behaviour so objectionable.

It's not because "haters gonna hate". It's not because you're operating in a competitive and highly visible space, and so of course you're going to receive some "hate", or whatever other dismissive narrative you might have cooked up. Look around you: people in similar positions just don't generate the reaction that you do.

When Wasmer eventually folds, it will be your fault, because you refused to reflect on how your antisocial behaviour destroyed all trust in the brand.

I don't know how to stop that from happening. Maybe a good therapist could help? Heck, your board would probably even be happy to pay for it, given the potential upside for Wasmer.

Without entering in any detail on what you mentioned (other than sincerely thank you for the belief in the potential upside for Wasmer!), I think we may have very different definition of what a hater is.

A hater, for me, is someone that lacks of constructive criticism.

A charitable interpretation could be that a rising tide lifts all boats. Syrus/Wasmer may sincerely believe that WASIX contributes to the rising tide, and it will therefore benefit Wasmer and all other Wasm-related ventures alike.

Under this interpretation, there would still be a financial incentive, but it would not be underhanded.

This is, despite how it may otherwise appear, how I see it. I think that the decision is a good one, made by people and a company I don't trust.

The broader context of Syrus' actions within the community (which reflect on Wasmer as its CEO) are what raise concern for me.

I think that the decision is a good one

I'm incredibly happy to hear that

I'm happy to see some convergence here :)

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

Of course. I hope the edit is more appropriate. Thank you!

I thought it was well said fwiw

thank you.

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.

It sounds the same to me: JVM, but with better browser support.

Do you know the reason for enabling compilation to WASIX?

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

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.

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?

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.

The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt.

Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.

If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I think that's great. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime with the strongest long-term outlook), nor will it run in browsers, because they're going to follow standards.. not WASIX. I don't think anyone believes exposing POSIX fork() to WASM is a good idea, even if it lets you build existing apps 'without modification'.

Please stop accusing me of being polarizing. I just don't want to live in a world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall. I want good tech to win, not shitty power plays.

[0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...

[1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...

[2] https://bytecodealliance.org/articles/webassembly-the-update...

[3] https://github.com/bytecodealliance/wasmtime/pull/7285

[4] https://github.com/WebAssembly/shared-everything-threads

thank you! slimsag is not the one being polarizing at all… pretty sure everyone in the wasm space is sick of this too, but hey, keep building I guess?

I wish the votes in the comments were public, so maybe you could actually get a grasp of what the community really feels like!

oh we all feel it

Hope you feel better!

I gotta say you come off really childish in this thread man. Maybe cool the ego a bit.

Just to be clear, and to reinforce what I mentioned.

WASI Preview 2 doesn't officially support threads. There are some ways to get it running as you mentioned, but threads are NOT part of WASI Preview 2. Which is what you initially stated and I corrected.

We don't want to have competing standards either, and we'd love to merge things upstream. However, based on my interactions with the WASI subgroup it seems clear they want to keep some of this things that WASIX needs out of the spec (and that's ok!). If you would not like to have that, then you shall probably direct your requests towards them, not us.

I want good tech to win

Me too! I now understand this over-idealistic belief is the root of the issue. Good tech doesn't win, a good product does.

I wrote more about this, if you are curious, here: https://wasmer.io/posts/is-not-about-wasm-is-about-what-you-...

Extend, Embezzle, Escape

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 :)

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.

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.

If the fix is to disable prettier for an entire file, you're proving your parent poster point.

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.

Adding comments just to fight with prettier is... uglier. I rather just not use prettier at all. It's more harmful than good IMO.

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.

dprint is soo much better (configurable) and already written in Rust so very fast

I am sad it's not getting more popular

In those situations I make use of comments to force new lines where I want them. Stupid but it works!

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!

I have a PR fixing that: https://github.com/prettier/prettier/pull/15209

Just needs another maintainer's stamp.

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.

Add a comment anywhere in the destructuring and it will force each property onto its own line.

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.

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.

Agreed, but that's a different conversation because gofmt is a lot less opinionated than prettier. Prettier goes well beyond style issues, and messes with semantics - it will add or remove parentheses in math expressions, add or remove linebreaks within lines of code, etc.

If prettier worked more like gofmt I'd probably love it and have no complaints!

and messes with semantics - it will add or remove parentheses in math expressions

Wait, so prettier rewrites code incorrectly? Aka, it’s buggy?

I've never seen it be buggy, but it will often remove unnecessary parens. For example: (a * b) + (x * y) becomes a * b + x * y.

This the same code, but I often use parens for semantic grouping or to be 110% sure the operator precedence is correct for a particular formula. It's not a dealbreaker, but it does remove some of the meaning I was trying to imbue on the code.

No, by semantic information I mean information that's meaningful to humans but not to the JS engine. E.g.:

    // before prettier
    var matrix = [
        1, 0, 0,
        0, 1, 0,
        0, 0, 1,
    ]
    var result = (num % divisor) | bitmask
    
    // after
    var matrix = [1, 0, 0, 0, 1, 0, 0, 0, 1]
    var result = num % divisor | bitmask

No difference in actual behavior, but the linebreaks and extra parens were there to indicate the developer's intent, not to affect behavior.

Prettier's outlook is that this is intentional, and the developer should add "// prettier-ignore" comments to every line of code that has semantic information they want preserved.

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

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.

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.

If it was widespread, but highly configurable, that increases friction when switching projects

This is clearly not true. Far and away the single most contentious JS style issue is ASI, and prettier has a config option for it and nobody bats an eye. Ditto for the prototypical style issues of indent size and tabs/spaces.

The value of prettier is enforcing a consistent style within a repo, and config options don't affect that. To the contrary, config options are part of why prettier is so popular - if they'd never added ASI then a lot of projects would never have adopted it.

I wish it were more opinionated.

It treats new lines as significant in a lot of its formatting

I also don't understand their stand about curly braces. They don't add or remove them. I think they should make it uniform.

That's bizarre. They add/remove parens...but not curly braces...

How do you even justify that...

Curly braces are reflected in the AST, parens are not.

There is a plugin for that: https://github.com/JoshuaKGoldberg/prettier-plugin-curly

Have you tried the print width option: https://prettier.io/docs/en/options.html#print-width?

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.

There's a more insidious side effect to prettier related to the line length thing which I'm not sure other commenters touched upon, and the reason I avoid opinionated formatters.

Prettier will affect your diff in ways you didn't intend to.

Remove a member from a destructuring assignment that brings it below the line length limit, and suddenly your diff is +1/-5 instead of 0/-1, making it slightly more difficult for your reviewer to see what the exact difference is between those 5 lines removed and 1 line added - it's not immediately clear which member was removed.

You try to rewrite a previous commit to fix a typo using Git's interactive rebase, and now the next commits won't replay on top if it because Prettier decided to reformat an entire code block.

Another fun thing to try with prettier: add a precommit hook that runs prettier, and then try to stage partial file changes.

No thanks.

Reformatting in precommit is destructive.

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

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.

I don't want to disparage prettier, but to call it a foundational piece...

Maybe essential is a better word.

That is still far too much an exaggeration. This is an opinionated beautifier. Its a vanity item with some downstream utility benefits.

A formatter is pretty essential when working in a team. It saves tons of time wasted on code formatting in code reviews.

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.

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

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.

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.

How about ubiquitous?

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 (à 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™ gives us a bit more of that time back. :)

[1]: https://youtu.be/ar9WRwCiSr0

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

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.

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.

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.

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?

I work in like ~100-person team without code formatter and it's fine. The age average is ~35.

Since when did caring about readability equated to bike-shedding and immaturity?

Since never, I didn't claim that. On the contrary, Prettier leads to less readable code than what a human can produce. Bike-shedding is endless bickering about some specific, meaningless thing.

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?

Code formatting takes a lot of time

It doesn't, really. On larger projects, you read much more code than you write.

Formatting well is not something complex - I basically just format with WebStorm, and only tweak that (mostly line breaks). People (including me) are going to read that code many times, I think it's worth the little effort.

On the opposite, I often have to work hard to make Prettier produce readable code. Like, "how do I need to write this code, so Prettier doesn't mess it up?", which is often difficult / frustrating.

I used to be one of those devs, thinking I had the most beautiful coding style.

When I embraced formatters, I started spending so much less time and effort keeping the style "correct" and worrying about how other people on the team format code. I love just hitting save in my editor and having the code formatted without having to fiddle with quotes, wrapping, etc.

With regard to bike-shedding about style, it mostly goes away once a team adopts one of the standard formatters for a given language. That's sort of the whole point.

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.

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.

this, lol.

Even a $20K bounty for that amount of work doesn't even seem worth it to boot up my IDE.

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.

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

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

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.

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.

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

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.

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.

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

Prettier needs to be consistent regardless of the original input. Otherwise it won’t really work well.

I don't think it does. Plenty of code formatters are not completely, and work just fine.

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.

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.

`lineWidth` is actually one of the available options in the biome formatter: https://biomejs.dev/formatter#configuration

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.

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.

It will then force longer lines, which is even worse.

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

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

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.

Line length with modern toolchains is too often stylistic bikeshedding with awkward limits stuck in 1975 cargo culted from the VT52. My external monitor can legibly display 637 x 81 while my laptop does 217 x 63. The largest barely legible terminals with tiny fonts are 3x the size.

Around 100 is a sane minimum while 160 is a sensible upper limit. There's no specific limit other than to prevent poor coding technique, illegible code, or inclusions of generated or minified atrocities.

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

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.

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.

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.

Is 6pt font easier to read than 12pt font? Are all style choices equivalent from first principles?

No, not really. Many of the decisions prettier makes are quite objectively bad for readability from first principles (e.g. breaking up lines where the RHS isn't relevant to most readers, left shifting RHS of assignments when the implementation details are less important than the abstraction over them).

I am totally in favor of a universal formatter, but at least justify the design decisions being made. Prettier formatting choices are often very lackluster and hard to defend objectively.

It will be replaced by something better eventually

I mean.. sure https://xkcd.com/927/

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

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.

Sure, but the issue with prettier is that it goes beyond style and also mangles semantic details. That's their explicit design choice - they feel that conforming formatting in all cases is more important than preserving semantic information about code, and that devs should add "// prettier-ignore" comments to every line of code with semantic details that prettier would throw away.

The deprecated style rules have been ported by a new project: https://eslint.style/guide/why

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.

Yeah they're not even deprecated really, that's the wrong word. That implies there not actively encouraged to be used. They just moved them to their own repo outside of eslint itself.

In what cases are you "reasoning about" Prettier? I can only think of the occasional issue with merge conflicts, perhaps.

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?

What do you mean by "backwards"?

The "diff" appears to be backwards (it's subtracting what prettier would emit, and adding back the original).

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.

This was intuitive to me, especially because it's in a section titled "Differences with Prettier".

The diff is between the test cases’s expected output (red) and the utility’s current output (green).

That’s giving the diff between prettier (“correct”, yet red) and their implementation (green, yet arguably incorrect)

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.

Those diffs are rare corner cases where the input is invalid Javascript. Prettier's parser is permissive and emits beautifully indented nonsense (which is arguably a bug in prettier). For example, in the original program there is a "private public" but the prettier output in red only says "private". Biome decided that in these cases it should not touch the indentation at all. The output is indented exactly the same as the input. The concern is that if you reindent something that you don't understand, it might break it. https://github.com/biomejs/biome/issues/739

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

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

Why didn't you, then?

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?

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.

To be fair compiled languages are just faster than interpreted (in most cases, and as others have pointed out especially with strings)

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.

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.

When it comes to string manipulation, Rust is much faster than JS

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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 recommend using the lint-staged tool so Prettier only runs on every save on changed files. It makes a huge difference on large projects.

Biome is also working on a feature that only formats changed files. See the associated PR [0] for more details.

[0] https://github.com/biomejs/biome/pull/753

Tangental but for anyone using lint staged + typescript, I recommend tsc-files[1].

[1]: https://github.com/gustavopch/tsc-files

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.

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.

This effort reflects the excitement in the Python community around `ruff`. Excited to see efficiency and speed gains with a wide impact.

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.

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.

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

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.

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

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.

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 = `aaaaaaaaaaaaaaa${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

I have a PR fixing that specific issue: https://github.com/prettier/prettier/pull/15209

Just needs another maintainer's stamp.

Are there benchmarks for Biome anywhere? How much better does it perform than prettier exactly?

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.

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

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?

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

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.

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.

IMO it should be called uglier. The default line wrapping logic (which cannot be disabled at all, by design) is awful. It unwraps short lines that I want wrapped, and it wraps long lines that I want unwrapped. It's banned from all my projects.

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.

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.

Does any body have a collection of all the profiling Fabio Spampinato did?

I haven't really kept track of everything. It may be worth making a blog post with the main findings though.

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?

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.

So, how does Biome compare to Dprint?

Claims to be faster (when using multiple cores) but beyond that, I'm also curious.

The post says the reason they did this was to motivate themselves to make the javascript version better?

Strange.

Competition is good for the consumer (i.e. the users). For example: when clang and LLVM came along, gcc got significantly better.

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.

This is something that really got me thinking about how to make my own prettier from scratch because I thought it was interesting. Needless to say, having looked at the “tests” for prettier I was kind of lost because I was trying to reverse engineer from the tests. What I saw was the format tests are auto generated and have if statements in them. If you’re a unit test stickler then seeing an if statement in a test should be a smell. The hardest part was trying to get the why behind each test. No explanation is in the test but I’ll bet it’s in the docs, source code or whatever cloud chat community.

Also, I had to check the winning implementation just for sanity’s sake. It is older than a week or two. Still, my hats off to them for being able to meet the compatibility mark and get the cash.

So this isn't replacing the main implementation? They just funded a new project written in Rust that is compatible?

"[to] get Biome running in Wasmer", it seems

Congratulations to the winning team.

So now there are two distinct, somewhat compatible but surely diverging implementations of the same thing. Yup, sounds like the JS ecosystem.

noob question but how does one actually use prettier? i find that the formatting just make the code less readable. is the goal to train yourself to be able to read prettier-formatted code as well as you could read your own hand-formatted code?

when i'm in the thick of it working on a piece of code, writing some logic and have everything laid out the way that makes sense to me and then i hit cmd + s and BOOM all the lines get shifted and wrapped and i'm ripped out of my flow i wondering what the heck it is i'm now staring at. sometimes i disable prettier on save and just run it on a pre-commit hook because at that point who cares that the code is unreadable to me.

Thank you for posting this. Sourcegraph is now a sponsor on Open Collective.

Anyone know the minimal package.json or Github template to get this going in a new repository please?

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.

As an aside, the winning project (Biome) is a fork (renaming?) of the Rome project, which was started by Sebastian McKenzie (creator of Babel) a few years ago.

Forked because sebmck seems to have gone AWOL over the last year or so and contributors were unable to update many of the project's resources as only he had access. Hope he is doing ok though and glad the Biome project seems to be going strong regardless.

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!

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.

Would be cool to use a Replit Bounty next time!