Let us admit that realtime even it its most traditional use is quite foggy.
It basically just referes to a system that reacts in a predictable time. Traditionally that time is short, but that isn't part of the definition.
As a audio DSP programmer my deadline is determined by the samplerate and the size of my buffer, and that is a hard deadline, as any dropouts might be audible. For game people their deadline is more flexible as there the framerate can drop without it being completely unacceptable. How low of an framerate is too low isn't a clear deadline, but the clear deadline isn't part of the definition. You can run any realtime code in an environment where it can't perform.
So what about a webservice that guarantees that every internal state update is communicated to clients via a websocket within an acceptable timeframe? Like the game people they don't have a clearly formalized deadline, but when a websocket update takes a minute that would surely be unacceptable. So the original definition of "a system that reacts in a predictable time" can still hold — just not for the reason that people colloquially think ("I get updates as they happen or, in realtime").
And to be frank, I think when some dev says "realtime updates" we all understand what they meant and that is the point of language right?
Having worked on hard realtime systems for years, the definition is quite clear. Everything you describe falls into the soft realtime bucket because missing a deadline isn't a system fault, it's just undesirable, not to mention that system load can and does affect hitting deadlines. "Soft realtime" is fairly broad term that gets abbreviated and thrown around in domains in which it is not appropriate. What this article describes is really just a UI and architecture that enables live updates. There's no deadline, there's not even a concept of wall clock time baked into the system.
We understand despite the muddling of terms, but let's not pretend that precise language isn't desirable to the best extent possible.
It basically just referes to a system that reacts in a predictable time. Traditionally that time is short, but that isn't part of the definition.
As a audio DSP programmer my deadline is determined by the samplerate and the size of my buffer, and that is a hard deadline, as any dropouts might be audible. For game people their deadline is more flexible as there the framerate can drop without it being completely unacceptable. How low of an framerate is too low isn't a clear deadline, but the clear deadline isn't part of the definition. You can run any realtime code in an environment where it can't perform.
So what about a webservice that guarantees that every internal state update is communicated to clients via a websocket within an acceptable timeframe? Like the game people they don't have a clearly formalized deadline, but when a websocket update takes a minute that would surely be unacceptable. So the original definition of "a system that reacts in a predictable time" can still hold — just not for the reason that people colloquially think ("I get updates as they happen or, in realtime").
And to be frank, I think when some dev says "realtime updates" we all understand what they meant and that is the point of language right?