Get the top HN stories in your inbox every day.
dewey
wentin
> Why not set a bounty to improve Prettier instead of building a competing project just to increase the motivation to improve Prettier?
There are three reasons, I think:
1. Writing a rust compiler is separate from prettier project because of its nature. Prettier is not written in Rust, and Rust has proven to be a robust option to write a formatter, so the goal really is to write a formatter in Rust itself, and it can't be replaced with improving prettier within its current codebase
2. Asking someone to write a Prettier-branded and owned Rust compiler for $20k is not enticing enough. It is essentially equivalent to contracting someone to write some code for Prettier, with an open bid. It would cost a lot more to hire someone to write these code. Great programmer who has the skill to answer this bounty get paid at least $200 an hour (extremely conservative estimate), $20k is enough for 100 hours of work for one person, not enough to finish the project. But getting rewarded for $20k for stuff you write and will own is enticing!
3. Good ecosystem going forward. If prettier owns the winner project, prettier is responsible to maintaining and improving it. The good that the bounty did ends when the project is handed over. Prettier team get burdened with a project that they didn't write themselves, and the original team (the best people for the job) is not incentivized to keep maintaining it. There is no ongoing competition to keep this field active.
andai
>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?
TylerE
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.
hectormalot
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.
lcnPylGDnU4H9OF
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.
butterlesstoast
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.
etruong42
I imagine someone who has this skill has a shot at being L4 or L5 at Google. levels.fyi estimates a year salary of an L5 engineer at Google to be 362,248. If we naively divide that by 50 (weeks in a year) * 40 (hours of work a week), we'd get $181.12 an hour. Googlers also get health insurance, free food, other perks that may push the effective hourly compensation even closer to $200. Googlers also get equipment to do the coding, whereas this competition does not provide a workstation, so another possible line item to consider.
It's not a perfect comparison/analogy, so I'd rather not get nitpicked, as the overall thrust of my argument is that $200/hr is not outlandish imho.
undefined
twodave
I came here to say that $200/hour is only "extremely conservative" in very few and small geographic parts of the world. Where I'm from (in a large city in the US) this number would be described as extravagant. I've charged $200 or more on only one occasion myself, and it was a very short-term arrangement.
parasubvert
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.
wokwokwok
> 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.
varispeed
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.
icambron
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.
vidarh
Most of my git repos are things where I'm happy if someone finds something useful, but for several of them I'm very explicit that there are a whole lot of things I will plain refuse to merge not because I think they're not great or useful, but because I don't want my packages to be everything for everyone - I'd rather people took my stuff and built a "competing" solution with different tradeoffs if they have different needs. I'd happily even offer help and suggestions if people want to do that.
I think that a lot of projects would be a lot better if they insisted on not solving everything, and stuck to solving one problem well, and instead of merging every new feature on offer instead help make it easier for others to "compete" with them by e.g. separating out shared functionality or writing about lessons learned...
I'd love to find each and every one of my projects are no longer needed because there's a better option (now, I may be very difficult about what is "better", so that's a tall order), because my list of projects I'd like to pursue is longer than I will stand any chance of getting to in my lifetime, so if some are taken off my plate, awesome...
technion
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.
nhumrich
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.
gmgmgmgmgm
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.
blowski
I'd guess a significant proportion of OSS maintainers _are_ in it for some combination of ego-trip, or a misguided belief that it will make them rich. Both outcomes may seem less likely if you're just fixing somebody else's software for free.
demosthanos
What have you seen that would lead you to believe that?
My own experiences with open source suggest that no one would stick around for very long if they were motivated by fame or wealth. Being a FOSS maintainer seems to be a constant exercise in dealing with people whining at you for not fixing their problems for free, not something that brings any significant personal attention and certainly not something that provides a sustainable source of income.
matheusmoreira
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.
yebyen
There is a whole gulf of room between "we are the incumbent and there is no viable alternative in any language for JavaScript developers" and "the Rust folks have done it, there's an alternative now and it seems quite viable"
I think it's about escaping local minima? You can always look at the biggest sink for performance and say "there's definitely something we can do better in there" but unless you have something objectively better to compare it to, you'd never be sure.
Imitation is the sincerest form of flattery. And knowing that of the hard problems you solved, someone else can solve them and in a different language, I think there's quite a bit of value to be obtained just through the competitive process that emerges when there is competition.
You can't fully have competitiveness without an actual alternative to compare yourself against. If the Rust folks can do the problem slightly faster by shaving off just 5% or less of the test suite, what all does that tell us about the theoretical limits of a solution when compared against the canonical version?
I have only limited understanding of the problem space, but I think there's always something intangible to be gained from having a quite similar implementation in a different language.
mlhpdx
> I think it's about escaping local minima?
Yes. It’s also been said (not often enough) “if we don’t compete with ourselves someone else will”. Getting out of one’s own head (and repo) is gold. It shows humility and respect as well as creates innovation and resilience.
j1elo
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.
Philpax
Different approaches with different constraints and less baggage can potentially discover areas of improvement that weren't otherwise visible in the original project. (i.e. they weren't locked into the "Prettier mindset", if such a thing exists)
explaininjs
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.
nailer
> 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.
globular-toast
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.
gostsamo
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.
syrusakbary
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!!
cedws
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?
n42
The advantage is this guy’s VC backed company gets to sink its teeth into the early stages of WASM platform adoption, helping him line his and his company’s pockets.
WASIX is a hostile fork of an open standard that does care about sandboxing.
syrusakbary
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!
syrusakbary
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.
shepherdjerred
It sounds the same to me: JVM, but with better browser support.
triyambakam
Do you know the reason for enabling compilation to WASIX?
slimsag
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]
syrusakbary
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.
intelVISA
Extend, Embezzle, Escape
syrusakbary
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 :)
nicoburns
Speed is always welcome, but I just wish prettier was a little less opinionated. Specifically around line length, it will just not leave my formatting alone. I find prettier formatted code much less readable than unformatted code, and this isn't a problem I have with other code formatters like rustfmt.
meowtimemania
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.
nicoburns
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}`;
const foo =
`aaaaaaaaaaaaaaa${
bbbbbbbbbbbbb
}ccccccccccccccc${
ddddddddddd
}`;
bakkoting
I have a PR fixing that: https://github.com/prettier/prettier/pull/15209
Just needs another maintainer's stamp.
harimau777
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.
HellsMaddy
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.
floydnoel
In those situations I make use of comments to force new lines where I want them. Stupid but it works!
pkilgore
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.
undefined
mostlylurks
If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.
floydnoel
Add a comment anywhere in the destructuring and it will force each property onto its own line.
bennyg
Have you tried the print width option: https://prettier.io/docs/en/options.html#print-width?
nicoburns
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.
fenomas
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.
Cthulhu_
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.
fenomas
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!
digging
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
fenomas
> 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.
uxp8u61q
> Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice.
Erm, that bounty was for the production of a program that behaves exactly like prettier in at least 95% of cases, as far as I understood what "prettier test suite" means.
girvo
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.
beirut_bootleg
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.
plugin-baby
Reformatting in precommit is destructive.
harimau777
Agreed! I'd go so far as to say that we would be better off if Prettier was never created.
paulddraper
I wish it were more opinionated.
It treats new lines as significant in a lot of its formatting
vbezhenar
I also don't understand their stand about curly braces. They don't add or remove them. I think they should make it uniform.
MalseMattie
There is a plugin for that: https://github.com/JoshuaKGoldberg/prettier-plugin-curly
paulddraper
That's bizarre. They add/remove parens...but not curly braces...
How do you even justify that...
candiddevmike
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...
thenbe
The deprecated style rules have been ported by a new project: https://eslint.style/guide/why
Dextro
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.
7sidedmarble
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.
xdennis
> I find Prettier to be way too heavy handed
But that's the purpose of such tools: to stop endless debates about style.
harimau777
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.
shepherdjerred
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.
digging
> 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.
fenomas
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.
pcthrowaway
I mean.. sure https://xkcd.com/927/
constantly
It's not a new standard so this comic really doesn't apply here. It's just being opinionated, for once, about what to use. I welcome it strongly, as I do tools like Black for Python, which do similar things. Just set that up in CI for anything and all my code looks the same, removing some overhead of readability.
mm263
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
undefined
Vinnl
In what cases are you "reasoning about" Prettier? I can only think of the occasional issue with merge conflicts, perhaps.
namanyayg
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!
spankalee
I have never noticed any lag from Prettier running on single files. The perf starts to matter with whole-repo format passes.
For interactive use we really should be using long-running, warmed up, processes too, where the start time of Node is irrelevant. Ideally type-checking, linting, highlighting and formatting would run in one language service doing incremental parsing and updates to a shared AST on every keystroke.
strager
> 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.
uoaei
This effort reflects the excitement in the Python community around `ruff`. Excited to see efficiency and speed gains with a wide impact.
foreigner
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.
conaclos
Biome is also working on a feature that only formats changed files. See the associated PR [0] for more details.
_fat_santa
Tangental but for anyone using lint staged + typescript, I recommend tsc-files[1].
meindnoch
"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.
tubthumper8
> One could have simply transpiled the existing codebase into Rust, and collect the reward.
I'm not sure if this is already an internet saying somewhere, but whenever I read the word "simply", I assume that whatever comes next won't be simple, because if it was actually simple it wouldn't need to be qualified.
In this case, I don't know that transpiling a JS codebase to Rust is simple. The mental models, the libraries used, the way that code written is quite different between the two languages and I doubt that JS-to-Rust transpilers are robust enough to be used on a codebase the size of Prettier, if such transpilers even exist at all.
nicoburns
> 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.
tills13
> One could have simply transpiled the existing codebase into Rust, and collect the reward
Why didn't you, then?
meindnoch
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?
bufferoverflow
When it comes to string manipulation, Rust is much faster than JS
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
strager
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.
KTibow
To be fair compiled languages are just faster than interpreted (in most cases, and as others have pointed out especially with strings)
fastball
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.
globular-toast
Why did it have to be Rust? Couldn't have just been "faster"? Is the Rust one actually fast? Does memory safety and leaks etc even matter for a program like Prettier?
WorldMaker
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.
nulld3v
Are there benchmarks for Biome anywhere? How much better does it perform than prettier exactly?
nulld3v
Found some here: https://github.com/biomejs/biome/blob/main/benchmark/README....
They claim 25x but the numbers are old so I'm not sure if I believe them now that a bunch of new functionality has been added. Either way, if it's anywhere within that ballpark it's still a huge achievement.
conaclos
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
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 Prettiervinniepukh
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.
undefined
andrewstuart
The post says the reason they did this was to motivate themselves to make the javascript version better?
Strange.
sophacles
Competition is good for the consumer (i.e. the users). For example: when clang and LLVM came along, gcc got significantly better.
Get the top HN stories in your inbox every day.
> 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.