Worth noting that Netlify’s On-demand Builders provide global persistence across all edge nodes: https://www.netlify.com/blog/2021/10/25/faster-more-reliable-page-loads-with-update-to-on-demand-builders/

Alternatively, CloudFront has 13 Regional Edge Caches that (in my tests with a VPN) seem to be segmented too: https://aws.amazon.com/cloudfront/features/?whats-new-cloudfront.sort-by=item.additionalFields.postDateTime&whats-new-cloudfront.sort-order=desc

CloudFront also offers an Origin Shield product that appears to provide a similar feature but I have not enabled it: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html#cache-hit-ratio-use-origin-shield

A few things here: Vercel’s Edge Network cache is segmented into 18 regions. Further, the cache eviction policy is “best-effort” and assets may be evicted before they’re stale: https://vercel.com/docs/edge-network/caching#limits

I suspect I was getting very few cache hits—not ideal at all for a screenshots service (or any resource intensive serverless function?). I wanted those images to request once and cache for as long as possible.

Preliminary comparisons with Netlify, Vercel, and AWS Lambda+Cloudfront suggest that Vercel is *drastically* overcounting serverless invocation amounts. I suppose it’s possible that I misconfigured something but Netlify was like 4h/day, Vercel was 42h/day and this new AWS setup is looking like it’s going to weigh in at 2h/day?

Alarm bells are going off over here.

If we can agree that browser fingerprinting is bad, we should be able to agree that third-party cookies are also bad.

There is consensus amongst browser-makers that fingerprinting is a bad thing, right?

…right?

TypeScript TIL: `compilerOptions.noResolve: true` will also make all of your explicitly listed `compilerOptions.types` disappear.

So even with `"types": ["node"]` you’ll still get errors that complain about clearly installed types.

> Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node` and then add 'node' to the types field in your tsconfig.

Everything is fine.

Wow, just learned that Google Photos is actively generating `goo.gl` share URLs.

Edit: it’s possible this URL will be unaffected, as the original blog post notes the retirement of `https​://goo.gl` links. However, I do have Google Photos shared albums currently using `https​://goo.gl` links, so 😬🤷

Create link to share Let anyone with the link see photos and people in this album. Learn more https://photos.app.goo.gl/JX6ch7EptGQNvL7F7

There are incredible parallels between the failure modes of smart home technology and modern web site architecture:

When the power goes out 🤝 When JavaScript fails

My smart lock failed and I’m locked out of my house 🤝 This form button doesn’t submit

The company went out of business and now this {smart device 🤝 JavaScript framework} isn’t receiving updates and poses a security risk

What’s the latest writing/research/best-practices on bundling versus code splitting? Large requests versus splitting into smaller ones?

Hoping for something a bit more nuanced than “reducing download size is good” or “reducing network count is good.”

Trust in a social network based on how they treat links:

🚩 “Link in bio”
🚩 Incentivizing indirection (e.g. this dot com) to hide hyperlinks from algorithms
🚩 Widespread use of brittle URL shortening services

Any other red flags?