Mastodon

Fascinating talk from @feross on @cfedev today: The Dark Side of Open Source

https://www.youtube.com/watch?v=hlLnFJSX0YY

Especially enjoyed the Q&A portion, really great stuff. One thing I keep coming back to is that when the lead maintainer changes, it should have some formal release process around it—maybe even to the point of it being a semver breaking change that requires a major release for updates (though I understand that’s a bit extreme too)

Looks like there has been a fair bit of discussion about the architecture of Mastodon previews and “DDoS-ing” web sites:

1️⃣ https://flipboard.social/@coffeegeek/113030436873628885
2️⃣ https://news.itsfoss.com/mastodon-link-problem/
3️⃣ https://kevquirk.com/blog/mastodon-is-ddosing-me
4️⃣ https://michaelnordmeyer.com/on-mastodon-ddosing-sites

While clearly there is room for improvement there, it’s worth noting that Jamstack architecture and static sites sidestep this issue nicely (by making it someone else’s problem 😅).

When thinking about the “Lottery factor” of an open source project you must take into account the difference between paid and unpaid labor.

I’d argue that 1 paid dev is worth more than 2 unpaid devs. To further complicate things the other side of the coin is that 10 paid devs burning VC runway is worth… you know what—actually I should probably just stop there.

TIL about Vercel’s Pro Tier:

1 vCPU (default) = 1.72 GB memory

The UX of the GB-Hrs metric for usage pricing feels a bit like a dark pattern to me (given that default).

For example, the 1000 GB-Hrs of included execution time is 581 hours (using 1 vCPU). Overages advertised at $0.18/GB-Hr are $0.31/hour (using 1 vCPU).

Gonna change my stuff there to use 0.6 vCPU (since they’re services, not SSR): https://vercel.com/docs/functions/configuring-functions/memory#setting-your-default-function-memory-/-cpu-size

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.”