Web Development (6 blogmarks)

I’ve always been a fan of the way Stripe does identifiers (e.g. cus_12345abcde for a customer). I was recently thinking about what it would look like to do something similar in my own app. This post made me aware that TypeID is what this sort of thing is called and that a spec exists.

Spec: https://github.com/jetify-com/typeid/tree/main/spec

Every browser sends an Accept-Language header. It tells you what language the user prefers, not based on location, not based on IP, based on their OS or browser config. And yes, users can tweak it if they care enough.

It looks like this: Accept-Language: en-US,en;q=0.9,de;q=0.8

That’s your signal, use it. It’s accurate, it’s free, it’s already there, no licensing, no guesswork, no maintenance.

As an example of when the location associated with an IP address is a reasonable heuristic: many course selling platforms use that to determine what if any Purchase Power Parity (PPP) discount to offer.

Over the last year or so I’ve seen several sync engines pop up as a paradigm shift in how we think about client and server data.

TanstackDB which is a generalized client but was built in partnership with ElectricSQL is described as:

A reactive client store for building super fast apps on sync

TanStack DB extends TanStack Query with collections, live queries and optimistic mutations that keep your UI reactive, consistent and blazing fast 🔥

What struck me is how incredibly cumbersome, repetitive and brittle this programming model is, and I think much of this is due to using REST as interface between the client and the server. REST is a state transfer protocol, but we usually want to synchronize a piece of state between the client and the server. This mismatch means that we usually implement ad-hoc state synchronization on top of REST, and it turns out that this is not entirely trivial and actually incredibly cumbersome to get right.

This page has a matrix of the different sets of meta tags and on which sites/apps those will display as part of a link preview (social card). There is quite a bit of mismatch between all of these. If you wanted to go with a single spec, it looks like Open Graph has the most comprehensive coverage across major apps.

Via lobsters

There is a lot of interesting data in this article about the wide variations in viewport size. The particular thing that stuck out to me is that even for a single iPhone, you can easily have at least three different viewport sizes based on viewing context — Safari vs. in-app browser vs. 3D touch preview are the ones they show.

Found on Bluesky.