No -- soft realtime applications are things like video conferencing, where you care mostly about low latency in the audio/video stream but it's ok to drop the occasional frame. These are still realtime requirements, different from what your typical browser does (for example): who cares if a webpage is rendered in 100ms or 2s? Hard realtime is more like professional audio/video recording where you want hard guarantees that each captured frame is stored and processed within the alotted time.
> who cares if a webpage is rendered in 100ms or 2s?
Do you really stand by the statement of this rhetorical question? Because if yes: this attitude is a big reason for why web apps are so unpleasant to work with compared to locally running applications. Depending on the application, even 16ms vs 32ms can make a big difference.
Yes I do, because I don't think the attitude is the reason, the choice of technology is the reason. If you want to control for UI latency, you don't use a generic kitchen-sink layout engine, you write a custom interface. You can't eat your cake and have it too, even though most web developers want to disagree.
I sense that people will insist on their requirements being hard unnecessarily... and that the bug is the fault of it being on a near-realtime system instead of it being faulty even on a realtime one.