I find HEY's general workflow very good for my medium-volume personal email. It encouraged me to filter a lot more stuff out of my inbox than I did with Gmail, while spending less time configuring filters. The ability to leave internal comments on external email threads (business accounts only) is very useful as a first-class feature, instead of relying on fiddly BCC. The apps are quite nice to use. Overall, there's less clutter and it is a more pleasant experience than other email clients I've used... until I try to search in the Hotwire-powered web view.
This kind-of tangential reply is in bad taste, but DHH is currently being an asshole about this very topic on Twitter, so:
This seems cool, but the progress that HEY has made since launch isn't very impressive if that's the flagship example.
HEY's search UX, which uses these capabilities, has been abysmal since the day it launched. It's a much better experience if you disable JavaScript/Hotwire and fall back to the server-side-rendering instead of the hybrid mess they push down. I'm very disappointed that this hasn't been improved. (I sent feedback about this while they were still in their invite-only phase.)
We were also promised custom domain support by the end of the year, and we don't have a timeline or even pricing yet. (That's obviously backend and unrelated to this announcement.) I don't want to go back to Google, but the lack of improvement isn't giving me a lot of confidence as a HEY customer, so I'm considering alternatives.
With sufficiently high-frequency gyroscope data, it is possible to infer what a user types in with moderate precision. In some cases, it has even been shown to be possible to recover coarse audio data from the surrounding environment.
Browsers have added rate limiting to mitigate this threat. (Prior to that, my former team in Google Ads added our own rate limiting to the gyroscope API we provided for ads.) The risk now seems pretty minor, but I wouldn't be shocked if someone clever still managed to find some way to abuse it.
It is relative common for software to need integers larger than 53 bits. It seems quite uncommon for software to require Decimal arithmetic. Do you have a motivating example?
There are a dozen MarkDown implementations that are better than Grubber's piece of shit, and a couple that are actually nice. The lack of a decent implementation is not the issue. This issue is that Gruber is (regrettably but naturally) seen as the authority on MarkDown by a whole lot of people, and he's still encouraging them to use his insecure, bug-ridden disaster instead of pointing them in the direction of something that anybody outside of his use case would ever want to use.
He just needs to add a sentence or two to his website and he'll save countless developers a ton of headache. He just doesn't give a shit.
I think I remember seeing a post just like this a couple of years ago, after which the bug was fixed. I wonder if there was a regression or if this is somehow different.