Not only is the response fast, but also don't you have to look at the keys or for some entries even the screen. https://youtu.be/oOjnpOyUzS0

For a while I always said, that I preferred a counter for getting tickets (train or something) as the trained clerk is faster on the keyboard than me on the touchscreen of a ticket machine. Nowadays however clerks on counters have to push the mouse more and more and seemingly have less training.

This comment has some good insights. Actually a lot of "business" software were like that in the 90s and early 00s. They were optimized for productivity of the user and not necessarily aesthetics of appearance or ease of use (well, trade-off). Even old version of excel etc. were designed like that. Unfortunately modern web software has such high importance on making it eye-candy.

I knew someone working on a system like that who could 'type ahead' a couple of screens worth because the layout had not changed in a decade, it 'just worked' and the system had trouble keeping up with the user because of that. Very impressive.

Buffering input is something we are still missing on the web. Concurrency is indispensable, but if the program is modal (and almost all are, to certain extent), processing an input command should wait for the previous one to be processed.

I used to be like that string commands together in Wordstar

Was that user on a therac-25?

> Of course there's nothing preventing web based UIs from supporting the same speed and productivity, but I know of few examples that actually do this.

Can you give a few of those examples? What must be done to accomplish this?

No the GP but I'd say that they should:

* be 100% keyboard driven (so, indexed inputs for easy TAB navigation)

* really quick and responsive (probably with all the needed code locally available, storing data locally and then sync when no action is going on). It's probably one of the best example where a SPA would be really useful

* be really lightweight so it can run on older hardware (like 10+ years old)

But doing those points "right" with nowadays frontend-mindset I'd say that's pretty difficult.

Yep, this! That said,

> (probably with all the needed code locally available, storing data locally and then sync when no action is going on).

I'm not sure this is a requirement. Eg the D forum is extremely snappy yet server side rendered: https://forum.dlang.org/. HN itself is pretty snappy too.

I think "no cruft" is probably the better guideline. And it's a hard guideline to follow in Single-Page Webapp Land :-)

I'd say not only the code needs to be local, but it can't make synchronous requests on the network at all until you've completed a task.

One of the underappreciated things about such productive software which enables it to be used without looking is predictable reaction times. Consider the "amazing data entry" video posted elsewhere in the thread, or good old feature-phones. If you have an action that you perform frequently, the key to learning how to do it without looking is to learn how quickly you can feed the input, where do you have to wait for it to be processed, and how long it takes.

It's one of the things I still miss about my last feature-phone (Sony Ericsson K800i). I could do a lot with it without even taking it out of my pocket, because I committed to muscle memory sequences like "up arrow, up arrow, OK, wait half a second, down arrow x3, OK, OK, exit". There's no way I could do this with an Android phone, because input and processing delays are random. Similarly, on the web, if your action shoots out a network request, it can complete anywhere between half a second and half a minute. You can't do actions like these without looking because there's a non-zero chance a delay will mess it up.

And I'll add that a POS should be 100% working even with no internet connection, which it's much more likely to fail than electricity.

POS Developer here. Offline capability (both kinds, with regard to a store server and with regard to an internet connection out of the store) is actually a very important requirement for any serious retailer, but not necessarily 100%, in terms of functionality. Today, you usually want to support some features that are impossible to realize in an offline capable way, like accepting gift cards. For these it's acceptable to be unavailable in an offline scenario. However, this actually creates the next big problem: you need to isolate these services and any connectivity-related errors with them from your offline-capable core ringing process in a way that ensures that your predictable response times of the core ringing process (which are super important for good UX, as the previous commenter already explained correctly) are compromised as little as possible if your online-only feature goes into a failure state - a typical example for "you're doing it wrong" would be waiting for a timeout on an online service on every single request while the connection is down before signaling the cashier that this service cannot be used right now.

isn't SPA and lightweight a contradiction? My ten year old N900 can not run a modern SPA frontend but is pretty "snappy" with plain old small HTML sites.

But that probably lies more in the framework used rather then in the "SPA concept". Disclaimer: I'm not a front-end developer so I may be totally wrong.

The only things needed to make SPA possible are same page requests and DOM updates.

We have pretty much always had iframes and form posts that can be targeted to submit to hidden iframes that JS can read, so XMLHttpRequest is easy to polyfill.

We used to use jQuery and globals or straight DOM manipulation. Or Backbone.js or just straight classes.

It has always been possible to make a SPA. And if you actually are able to download and cache most of the app upfront, it should be pretty quick. The question is, I suppose, how big is the SPA codebase and do newer browsers know how to cache identical codebases into their "entry points"?

The real draw of React and Vue, and more recently, Lit-Element (Google), is that they update the DOM in a smart efficient way, doing updates much more efficiently than you might could do without an intermediate layer.