He is not talking about offline applications but online applications with offline functionality.
Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input.
And I'm not a fast typist.
> Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist.
If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response, it's doing something horribly wrong and if that's how they write things, you probably want to avoid that for a multitude of reasons. Please name and shame though, so others can avoid it too :)
Same goes for Electron-based applications, there is no reason they'd block showing the text you inputted, and if they just use <input/> without doing anything egregious, you really shouldn't be able to type faster than characters appearing on the screen, something is really, really wrong then, and I don't think it's because of Electron.
1Password’s new UI does just that.
I enter some text into a field quickly, hit Tab, then watch some of the trailing characters (or the entire field content) disappear.
This keeps occurring and disgusting me to no end.
> If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response
I'm 99% sure nobody does that, that would be insane :D.
It's most likely caused by React and the use of controlled input components without thinking about performance. If your input sets it's value from React state, then you're updating the state on every keypress and re-rendering the component. In the most simple case, it's probably fine. But depending on your component hierarchy, it's pretty easy to end up in situation with over 50ms of typing latency.
> I'm 99% sure nobody does that, that would be insane :D.
I agree, hence the surprise!
Although parent explicitly calls out "cloud applications" so I'm guessing online has something to do with it.
And in the context of online/offline, it wouldn't matter if it's internet connected or not, using controlled input components with state changes going through a deep hierarchy would introduce that sort of delay no matter if you're online or offline.
VS Code is still much slower than necessary despite editing files locally - on my Thinkpad from 2016 I got extremely inconsistent input latency that felt like a shaky SSH session, in better cases it seems to be closer to 30ms[0]. For reference: gVim's latency hovers around 1ms and even intelliJ can still be 10x faster[1].
Gmail has had this issue for years, if you type in the search bar a bit fast or the system is a bit busy, some of your key presses will trigger keyboard shortcuts and randomly select/archive/mark as read/open emails in the current view. This is maddening because you can end up missing emails completely as there is only a single level of undo.
I issues with Outlook Web App (M365) often. Dropped characters are not so common, but it is common for the cursor to bug out and insist on returning the to start of a line with each new character.
Are you using Firefox? I had that problem consistently with OWA, but I recently switched to primarily Safari on an old MacBook and don’t recall having it happen recently.
It's more if I edit data grids or multiple fields where I switch between them with the tab key.
On desktop applications they may lack in the response on the screen if they or the computer are to slow, but with cloud apps sometimes keystrokes go missing and the entered data is in the wrong field.
The operating system recognises all keystrokes, but the browser seems to skip some.
This is increasingly happening with desktop apps as they get rewritten to be async throughout without a good understanding of what this implies. The old single-threaded UI model with a message pump was hard on the developer (if they wanted to keep the UI response) by requiring them to manage all asynchrony explicitly with threads, but at the same time it also forced to think things through more. Now it's often just throwing async/await or equivalent around mindlessly, and it leads to the same exact kind of bugs you describe.
I think that’s the take and from my own experience, it kind of sucks and feels like we’re running worst versions of basic software than we used to (old man rant?).
For example, I use Apple Music every time I leave my apartment. Put my headphones on and start some music. All my songs are downloaded locally so it should be fine, however, as soon as I close my front door until after I step off the elevator, no music will even attempt to play. That’s because Apple Music is blocking itself on some sort of network call/drm check because it thinks I’m online and it should work.
If I go into airplane mode and hit play, everything works perfectly.
Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist.