>A typical elite cross-country skier will burn about 30 calories a minute during training–by comparison, a 155-pound person on an elliptical machine burns about 11 calories a minute.
On the rowing machine, I can get up to about 500 to 600 Calories in 45min to 1 hour. But I also feel like most people would not work out hard enough to burn 10 calories per minute, especially if we are talking about older people.
I don't think you're talking about what GP comment is.
For clarification, Bun can act as a package manager like npm (probably the case of "bun + app router + NextJS" comment), and it can act as a replacement to a node runtime a la Express on a VPS (I'm assuming this is what you mean by "yes"). But Bun currently does not implement enough of the Node API's to use Bun as the runtime for a Next.js app.
From Bun themselves: "The Next.js App Router currently relies on Node.js APIs that Bun does not yet implement. The guide below uses Bun to initialize a project and install dependencies, but it uses Node.js to run the dev server."
The main argument (“I hate static sites”) can be more efficiently (dynamic page, guaranteed fast response, mainstream tech) addressed by deploying normal JavaScript jsx on the edge.
It's a good idea, but the hash doesn't need to be unique or secure.
The IPv4 space is 2^32. The trick is to keep e.g. 24 bits. 2^24 gives 16M possibilities -- unless your web site is _VERY_ big, that means it's a unique ID for most visitors. If you come across an IP (e.g. a scammer), you can also backtrack.
On the other hand, mapping back, you get 2^8 options, so you can't tie back to a unique user.
A nonce is a good idea, but it's not part of the security perimeter here.
Very cool. I had similar idea and glad to see it implemented and working well.
Workers KV imposes 25MB limit per key. Worker memory limit is 128MB. Concatenating several values from the store or using sqlite's ATTACH DATABASE should make possible querying of about 100MB large databases, would be my guess.
