mcheely

https://iselmdead.info/

https://dev.to/lucamug/elm-2021-a-year-in-review-4pho

I think most of the Intl api could work reasonably well with ports and custom elements. The formatters in particular, which make up most of the API, would probably work quite nicely as custom elements. It's really only string comparison that I can imagine needing ports for, outside of some particularly unusual use case.

A really small thing that would be immensely useful to me would be a quick way to to copy or save as plain text a full HTTP request & response, with a little bit of nice formatting to make it human readable. I often find myself passing this data along to API developers via email or chat to debug issues.

I can always just copy and paste directly from the request inspection dialog, but that loses all of the useful formatting, making it hard to parse, or requiring me to go in and add line breaks if I want to be nice to my fellow developers.

Small, but it's the sort of detail that makes for a nice, easy experience.

Well, now that we have WebRTC, peer-to-peer data transfer is possible in the browser. Perhaps you could imagine a p2p scenario where browser crypto is useful?

It's not always as simple as a PUT landing. Imagine you're tracking something like a phone call in real time. You want to fetch the current state of the call and start tracking it, but it's changing relatively rapidly. You also don't want to have to push the full state of the call down the notification pipe on every update, because you're handling a lot of these.

Merging the incoming deltas with fetched API state becomes a bit tricky, because you have to account for changes that might be happening while your GET is in transit. Alternatively, it may be that your notifications are slower than the GET request, depending on network conditions. An option that works in both of these cases (and doesn't involve version tagging all of your assets) is the approach described in the blog post.

Disabling the cache by default can be troublesome. I'd say it breaks the principle of least surprise - I wasn't aware of this behavior in Chrome, and it's a good thing I develop with Firefox, as I just resolved a bug that only manifested itself when bypassing the browser cache. If the browser cache had been linked to dev tools being open in my case, I probably would have ended up down some false causality rathole around dev tools.