> 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.
> 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.
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.
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.
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.
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.
Well, sure...there's always a one-off where you have to throw out the rulebook on salary. But any HR team worthy of the name can still compute the actual overhead on that base pretty much to the dollar.
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.
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.
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.
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.
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 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.
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.
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
Well if you've never used Java (or c#), that might be your main problem. I'm telling you my experiences hiring as a manager over 10 years ago - all the senior Java devs on the program (about 8) were $90-120/hour. Architects were $150. PMs were $150. All independents through an agency with minimal markup ($3-4 per hour). I'm also speaking as an IC at times that's charged $150-250 an hour for over 20 years depending on the role. Rates these days are even higher.
These rates are at financial services , banks, transportation / logistics, manufacturing, telecom, etc. in Canada, US, and Japan.
> 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:
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
> 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.
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.
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.
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.
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
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
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 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.