When I saw the title, I saw this misery before me where recruiters serve up people like the author to companies looking for ‘realtime system engineers’ just because people put keywords on their linked in and have blog posts which look insightful etc. We all have our skills, but realtime system engineering is not an easy one. Replacing that with something websockets would be better imho.

Unfortunately both "realtime" and "systems" have become buzzwords, void of their actual meaning. "Websocket" isn't real time of even close to it.

Maybe it means "not with the usual latancy of a REST app" in this context. In a prevoius life I did systems that ran on microcontrollers. Back then even having an OS would disqualify you from getting to claim "real time". Everything ran on the interrupts.

Wanted to say the same thing, in my case thinking of Sun's ChorusOS and Solaris schedulers and definitions of realtime wrt bounded dispatch latency. I can't believe, even having been a v8 committer ten years ago, that node can make guarantees about response time to events, i.e., bounds on dispatch latency, that are super enthusiastic. I hope I learn there's more to be enthused about.

In all fairness, I've heard the use of "real time" applications with respect to chat (websockets) or video (WrbRTC). This is the first time I've been introduced to this definition of real-time computing.

I'd be interested to see how many people are aware of this definition and why there appears to be such a divide in the first place.