When node first came out, it was pretty revolutionary. Being able to almost instantly start a JavaScript thread from a single file that could support realtime experiences (a la socket.io et al) without a build step felt pretty paradigm shifting
I worked on telco grade systems running on Rhino, in interpreted mode, in 2006. Leveraging Java to JS bindings. Responding to HTTP/JMS/etc.
Node supports realtime applications? Really? Isn't it garbage collected? Or does the term mean something different in nodejs? I've only come to know the term in the context of time guarantees (i.e. if it's scheduled to run in x, it is guaranteed to run at that time) and that shouldn't apply to nodejs I think? When you schedule something there, I believe it'll run on the first free thread after the timer relapsed - which entirely depends on the load of the system
Real-time in this context is more like real-time communication rather than process scheduling.
That said, real-time communication _is_ a soft real-time system.
Basically like 24 FPS or higher is real-time. Even that'd be laggy for a game but not unplayable. I choose this specifically because that's what movies typically use and they're very watchable.
Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry.
Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.
Context matters.
they are vibe coding since the beginning.