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 - no audit logging - not recommended
Backblaze B2 - $0.006/GB - $0 for download bandwidth if through Worker (or $0.01/GB) <- decent data privacy record - no custom domains - no audit logging - no longer recommended due to rate limiting policy. https://www.backblaze.com/blog/rate-limiting-policy/
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 <- cheapest with audit logging - no custom domains and no CORS support
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 for download, $4.50 / million for
@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 November 16, 2024 22:43
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 November 3, 2024 17:14
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 November 10, 2024 13:39
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 November 10, 2024 03:45
A badass list of frontend development resources I collected over time.