Note that because Durable Objects are long running computations, they are stateful and deployments are disruptive (clients disconnected). So even though you could potentially put them in the "serverless" category, the deployment experience isn't quite the same as short-lived serverless functions / lambdas.
The real novelty of Durable Objects appears to be their intended usage of fine granularity (and the underlying tech that enables this). For example, if you were building a chat room service, you could have 1 Durable Object per room. Of course, you could conceivably build a chat room service running 1 Node.js process per chat room on traditional VMs or containers, but that probably wouldn't scale well.
With the Workers Bundled plan (https://developers.cloudflare.com/workers/platform/pricing#b...), your WebSocket connection will stay open until your 50ms of CPU time expires. On Unbound (https://blog.cloudflare.com/introducing-workers-unbound/), which does not have a CPU time limit, your WebSocket connection will stay alive as long as it remains active and your Worker doesn't exceed its memory limits. If the connection goes idle, it may be terminated. We're currently considering an idle timeout on the order of 1-10 minutes.
Workers handle WebSockets in a pretty straightforward way. The server-side API is literally the same WebSocket JavaScript API as in browsers. sock.addEventListener("message", callback), etc.
But if you aren't using Durable Objects, then WebSockets on Workers aren't particularly useful, because there's no way to contact the specific Worker instance that is handling a particular client's WebSocket session, in order to send a message down.
Durable Objects fixes exactly that. Now you can have worker instances that are named, so you can call back to them.
Here's a complete demo that uses WebSockets to implement chat: https://github.com/cloudflare/workers-chat-demo/blob/main/ch...
> Are they automatically terminated after the worker spends too much time active?
We're still tweaking timeouts and limits, but in general you should be able to keep a WebSocket alive long-term, and reconnect any time it drops (which any WebSocket application has to do anyway, the internet being unreliable).
> If so, doesn’t handling the WS handshake have a lot more overhead than a fetch call?
Not sure what you mean here. A WS handshake in itself isn't terribly expensive. I suppose a typical application will have to establish some state after the socket opens, and that could be expensive, but it depends on the app.