No one wants to see results for the letter "a", no one wants their database processing that search, and updating the UI while you're typing can be really distracting.
Don't make assumptions about what the user may or may not want to search for.
E.g. in my music collection I have albums from both !!! [1] and Ø [2]. I've encountered software that "helpfully" prevented me from searching for these artists, because the developers thought that surely noone would search for such terms.
_______
[1] https://www.discogs.com/artist/207714-!!! ← See? The HN link highlighter also thinks that URLs cannot end with !!!.
<https://www.discogs.com/artist/207714-!!!>
Edit: It does. So, this would be yet another of the squillion-ish examples to support the advice "Please, for the love of god, always enclose your URLs in '<>'.". (And if you're writing a general-purpose URL linkifier, PLEASE just assume that everything between those characters IS part of the URL, rather than assuming you know better than the user.)
> Characters can be unsafe for a number of reasons. ... The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text
Also note the "APPENDIX" section on page 22 of RFC1738, which provides recommendations for embedding URLs in other contexts (like, suchas, in an essay, email, or internet forum post.)
Do you have standards documents that disagree with these IETF ones?
If you're using the observed behavior of your browser's address bar as your proof that ">" is valid in a URL, do note that the URL
https://news.ycombinator.com/item?id=44826199>hello there
https://news.ycombinator.com/item?id=44826199%3Ehello%20there
[0] <https://datatracker.ietf.org/doc/html/rfc3986#appendix-A>
[1] <https://datatracker.ietf.org/doc/html/rfc1738#section-2.2>
URLs with the characters ' ' and '>' in them are not valid URLs. Perhaps your web browser does things differently than my Firefox and Chrome instances, but when I copy out that pretty-printed URL from the address bar and paste it, I get the following string:
https://news.ycombinator.com/item?id=44826199%3Ehello%20there
In your example, the developers have exercised poor judgment by making a brittle assumption about the data. That's bad. But there is no UX without some model of the user. Making assumptions about user's rate of perception is much safer (in a web app context, it would be a different story in a competitive esports game).
Even the 10ms in TFA is too low. I personally wouldn't mind (or probably even notice) a delay of 100 ms.
Whatever delay you add before showing results doesn't get hidden by the display and user's reading latency, it adds to it.
Don't become unresponsive after one key to search for results. If the search impacts responsiveness, you need to have a hold-off time before kicking it off so that a longer prefix/infix can be gathered which will reduce the search space and improve its relevance.