4 ms·
I thought this was going to be a rant about how slow modern keyboards are with long debounce cycles and waiting for the USB poll interval. Or if not that, how
by jrockway 6y ago
I thought this was going to be a rant about how slow modern keyboards are with long debounce cycles and waiting for the USB poll interval. Or if not that, how every change to the screen is buffered and waits until the next vertical sync before being drawn. Those things are quite noticeable once you start looking for them (you can thank me later!)
But instead it's "when I write an email to someone, the software looks through every person I've ever corresponded with and suggests an email from that list". The 1983 version of that was waiting 5 minutes for a bounce because you typo'd the address. Now it's taken care of for you in a few hundred milliseconds. Not that bad.
As for autocomplete being slow... there isn't really a good reason for this. I've seen PHP apps that add a solid 100ms to every request because they are built in the one-process-per-request model, and the framework does a lot of setup and teardown for every request regardless of whether or not the request uses those resources. Obviously, don't do that. There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms. Websockets and HTTP/2 eliminate TCP setup/teardown overhead.
Things could be faster, for sure. How much extra would you pay? Most customers wouldn't pay extra for a faster app, so apps aren't faster.
As for why people make mouse-based apps instead of TUIs... it's because the average person has to interact with tens or hundreds of pieces of software on a daily basis these days. If they all work differently, people will never use them. They ask for and prefer fast to learn but slow to use. So developers build on a common set of idioms, even if they are slow in the long run. You'll note that "power user" software is often hard to learn (think Emacs, Vim, Blender, Solidworks) but quite efficient once the user has been trained. People aren't interested in doing that much work these days.
Finally, business processes account for a lot of this stuff. I've been to stores that use a nice efficient TUI for their in-store pickup. But my question is: why is software with a UI even involved? You should scan my order number barcode, scan my driver's license barcode, and then hand me my merchandise. (Why even scan my driver's license. Just eat the fraud and save me 5 seconds! That's a business decision, not a software implementation quirk.) Having to navigate around to a bunch of fields and manually type that information in isn't efficient. The UI shouldn't even exist.
- altfredd 6y ago> There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms. This is a wishful thinking. You can't expect consistent 10ms (or even 100ms) response times from network-driven autocomplete. Nevermind a fixed speed of light (which already makes 10ms figure impossible for transatlantic users), you will have to account for all kinds of temporary bottlenecks in network. DNS can take a lot longer than 10ms, and many hosts use short DNS TTL by design. There are some totalitarian countries (Belarus, Great Britain etc.) that use DNS-based website blocking — each time you send a DNS request, it will have to be compared against a bunch of censorship lists. Then there is an ISP throttling/AQM, that will add small delays to each SYN packet... As result, if your autocomplete responds in under 10ms during local testing, it may take between 100ms and 900ms for most of your users.
- jrockway 6y agoYeah there's the network round trip and that is going to be the bulk of the time. You have to serve interactive apps from servers that are close to your users. DNS, even when censored by the government, should be cached by the client for the TTL. And, for interactive apps, you should keep the TCP connection open between requests. (Not really sure what the browser state of the art is here, but the idea behind HTTP/3 is to skip TCP entirely, and let the server control how long it remembers the state necessary to keep the session alive. One autocomplete request should be one UDP packet.) I'll also point out that networks aren't very good. For example, I have a RTT of 50ms to Chicago, but the speed-of-light round trip between New York and London is 36ms. (For Chicago, it's 8ms!) At least on my setup, the vast majority of the time is spent waiting for a DOCSIS timeslot. Once my packet gets to the internet, it's pretty fast. Remember, people are playing real-time shooting games over the Internet. If they can make that smooth, you can make your autocomplete smooth.