Skip to content

Instantly share code, notes, and snippets.

IDrive e2 - $0.005/GB - $0 for download bandwidth - 1:3 upload:download ratio allowed <- questionable data privacy - custom domains offered - has audit logging - supports event notifications with AWS SQS - $0.01/GB overage on bandwidth - has replication
Backblaze B2 - $0.006/GB - $0 for download bandwidth if through Worker (or $0.01/GB past a 1:3 upload:download ratio) <- decent data privacy record - no custom domains - has audit logging - has replication
Vultr - $0.006/GB - $0.01/GB for download <- https://www.vultr.com/products/object-storage/#pricing
Wasabi - $0.0069/GB - $0 for download bandwidth - 1:1 and billed for 90 days <- has audit logging - no custom domains - min object size billed at 4 kilobytes
Storj - $0.004/GB - $0.007/GB for download <- not good for small files due to segment pricing
Scaleway - $0.013/GB - $0.011/GB for download <- estimate, had to do EUR to USD conversion https://www.scaleway.com/en/pricing/storage/
Cloudflare R2 - $0.015/GB - $0.00/GB
@Widdershin
Widdershin / ssr.md
Last active May 1, 2024 17:36
The absurd complexity of server-side rendering

In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.

After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.

But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.

And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?

In dark rooms, in hushed tones, we speak of colours.

@sindresorhus
sindresorhus / esm-package.md
Last active June 13, 2025 21:39
Pure ESM package

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

  1. Use ESM yourself. (preferred)
    Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
  2. If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
  3. Stay on the existing version of the package until you can move to ESM.
@gragland
gragland / use-toggle.jsx
Last active October 5, 2022 05:58
Thought process when creating a useToggle() React hook with useState
import { useState, useCallback } from "react";
function useToggle(initialValue = false){
// State with initial boolean value (true/false)
const [state, setState] = useState(initialValue);
// Let's create a toggle function
// This works, but we're using the state value from above
// instead of the current state. Usually they are the same,
// but if this hook was triggered multiple times rapidly then
@yossorion
yossorion / what-i-wish-id-known-about-equity-before-joining-a-unicorn.md
Last active April 15, 2025 22:49
What I Wish I'd Known About Equity Before Joining A Unicorn

What I Wish I'd Known About Equity Before Joining A Unicorn

Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.

This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would

@chantastic
chantastic / on-jsx.markdown
Last active May 13, 2025 12:04
JSX, a year in

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

@dypsilon
dypsilon / frontendDevlopmentBookmarks.md
Last active June 13, 2025 02:47
A badass list of frontend development resources I collected over time.