Looks very nice for quick prototype kind of things in any language or to make existing tools quickly available to a small circle of users!
for larger-scale usage the overhead probably is to big.
for larger-scale usage the overhead probably is to big.
The runtime profile of WebSockets tends to be different to typical HTTP requests too. With typical HTTP you're often optimizing for 1000s of short requests per second, whereas with WebSockets the requests are much longer lived.
You wouldn't want to boot a JVM process per connection but rather implement the listening socket yourself and dispatch connections within that same process with all of the required services already initialized. A WebSocket server is no different.
But this is clearly will not cut for typical HTTP static stuff.
So if your server side keeps connection for a long period of time (think IRC server, or netcat?) - this might be good.
Compare this with an efficient green threads implementation. In Erlang you can have 100k sleeping "processes" in just 200MB of memory.