7 ms·

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

by dewey 3y ago

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

evan_ 3y ago
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?
nijave 3y ago
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
gmgmgmgmgm 3y ago
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...).
- rattray 3y ago
  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.
- mplanchard 3y ago
  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
patcon 3y ago
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
vjeux 3y ago
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 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!
hermanradtke 3y ago
Maybe prettier will consume the biome work and offer it as an option for prettier going forward.
Philpax 3y ago
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 3y ago
Maybe they want an implementation to have an understanding of potential perf of a non-js solution, but know that it’d cost them more than $10k to have an employee do it. So instead you offer 10k, someone else offers 10k, and the final product is “owned” by a third party but your questions are answered.
wincent 3y ago
> why would the Prettier team fund another project!? Less "the team" per se, and more vjeux, I think.
yebyen 3y ago
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 3y ago
  > 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 3y ago
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 https://biomejs.dev/formatter/#differences-with-prettier Turns out Biome found several pain points that they chose to not follow the same decisions than Prettier, instead diverging from it. This alone could be already a reason why a parallel development is worth it.
tshaddox 3y ago
> Why not set a bounty to improve Prettier instead of building a competing project just to increase the motivation to improve Prettier? Presumably the creators of the bounty believe that this bounty is in fact a good way to directly improve Prettier. The acceptance criterion of the bounty doesn't need to literally be "improve Prettier" for the work to improve Prettier.
icambron 3y ago
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.
- nhumrich 3y ago
  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 3y ago
  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 3y ago
  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 3y ago
    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.
marcosdumay 3y ago
> performance and fix various edge cases Those are the two main things that rust is expected to help improve. It's quite easy to empathize with somebody that sees a JS software having problem with those two and picking a language that is known to help with those instead of being known to increase those problems.
wentin 3y ago
> 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 3y ago
  >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?
  - etruong42 3y ago
    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.
globular-toast 3y ago
It sounds like the Prettier test suite is the most valuable part of the project. Perhaps the original project will just become a test suite with everyone using whatever tool is fastest with the best coverage.
DustinBrett 3y ago
Maybe they paid Biome $20k to have it be more "opinionated" with Prettier's opinions.
nailer 3y ago
> 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.

by dewey 3y ago

evan_ 3y ago

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?

nijave 3y ago

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

gmgmgmgmgm 3y ago

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

rattray 3y ago
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.
mplanchard 3y ago
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

patcon 3y ago

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

vjeux 3y ago

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

hermanradtke 3y ago

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

Philpax 3y ago

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 3y ago

Maybe they want an implementation to have an understanding of potential perf of a non-js solution, but know that it’d cost them more than $10k to have an employee do it. So instead you offer 10k, someone else offers 10k, and the final product is “owned” by a third party but your questions are answered.

wincent 3y ago

> why would the Prettier team fund another project!? Less "the team" per se, and more vjeux, I think.

yebyen 3y ago

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 3y ago
> 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 3y ago

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 https://biomejs.dev/formatter/#differences-with-prettier Turns out Biome found several pain points that they chose to not follow the same decisions than Prettier, instead diverging from it. This alone could be already a reason why a parallel development is worth it.

tshaddox 3y ago

> Why not set a bounty to improve Prettier instead of building a competing project just to increase the motivation to improve Prettier? Presumably the creators of the bounty believe that this bounty is in fact a good way to directly improve Prettier. The acceptance criterion of the bounty doesn't need to literally be "improve Prettier" for the work to improve Prettier.

icambron 3y ago

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.

nhumrich 3y ago
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 3y ago
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 3y ago
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 3y ago
  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.

marcosdumay 3y ago

> performance and fix various edge cases Those are the two main things that rust is expected to help improve. It's quite easy to empathize with somebody that sees a JS software having problem with those two and picking a language that is known to help with those instead of being known to increase those problems.

wentin 3y ago

> 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 3y ago
>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?
- etruong42 3y ago
  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.

globular-toast 3y ago

It sounds like the Prettier test suite is the most valuable part of the project. Perhaps the original project will just become a test suite with everyone using whatever tool is fastest with the best coverage.

DustinBrett 3y ago

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

nailer 3y ago

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