Think of crawlers: a crawler typically makes hundreds or thousands of requests per second. The owners of the crawler then sell this data for X$, or gain X$ profit.
Proof of work adds a very small cost to each individual request, increasing the cost of crawling to a number higher than X. Because actual humans make very few requests, we don’t notice the increase in cost.
When you use a captcha, you presumably want to defeat someone curling your CreatePost endpoint, not just make it more annoying to do it at only botnet scale.
This captcha still lets all traffic through. Except now you waste the battery of honest users.
Even HN proponents of the idea don't use it on their own sites.
I rather see something like anubis than some unsolveable captcha. I never understood the battery-argument, I recon my screen uses more energy during pow-solving than it takes my phone to solve these pows.
Every time a new submission is created on HN, you have a curl script that posts a comment on it shilling your product. (According to the /newest tab there seems to be one submission every few minutes.)
What's harder for you to automate: the comment always posts successfully after 500ms, or you get a Cloudflare Turnstile captcha every time?
It's equally easy for both. But people using broswers only do it a few times, while bots need to do it many times. A second for a human every X pages is not much, but it's a death-knell for the general practice of bots (and they can't store the cookies because you can rate-limit them that way).
Imagine scrapping thousands of page, but with a X>1 second wait for each. There wouldn't be a need to use such solution if crawlers were rate-limiting themselves, but they don't.
Just adding a delay wouldn't achieve anything because bots can just do something else while they wait, whereas PoW requires them to actively spend their finite resources before they can continue doing whatever they want to do.
I do think that calling this a CAPTCHA when it's not actually intended to distinguish humans from computers is a bit misleading, but I can see why you would do that
Cursor is great because it’s a flat subscription. Aider/Claude Code would be much more expensive for daily usage. When Cursor enshittifies I will use something else. It’s not like I am locked in.
As somebody who maintains a very large Svelte app and upgraded from 4 to 5, I couldn’t be happier with the changes. For simple components the old approach was just fine, but the larger the codebase gets the harder it gets to work with.
Svelte 4 is simple in a single component. Svelte 5 needs a bit more boilerplate.
Svelte 4 was always very confusing in multi component/files workflows, especially when working with .ts/.js files. Svelte 5 is way better in this regard.
I'd pay the "slightly more boilerplate" price every day.
I appreciate someone working on a sizable codebase to put in their opinion. Too often it's just feedback on their experience with a Hello World analog and it's easy to get hyperbolic opinions off of that.
Yes, but not everybody builds the next social network or complex commercial app with 50 pages and 150 forms.
It used to be that svelte was the perfect choice to build simple spa fronts to backend services, there already was react for complex applications. Now we have 2 additional reacts with svelte and vue and no mainstream simple framework for smaller stuff.
Why does everybody feel they need to build eventually the same thing, but slightly different?
reply