Same as with Single Page Apps - websockets have their place but shouldn't be abused.

I can imagine a large Django app that uses mostly plain request/response but needs, say, a small customer service bot or occasional real time notifications. This new feature is perfect for that.

> However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason.

"Careful" == do not break urls, use pushState and make sure equivalent document is returned for GET.

Sounds good to me. :)

Could you elaborate on specific issues you see with the use of web sockets over http/s for request response? I see this argument from time to time and I have a hard time with it when you take resource hogging out of the equation, which isn't much of a factor in many situations.

The issues with WebSockets are more political than technical. WebSockets are the superior technical solution with wide availability. However, at present, HTTP has better tooling (e.g. debug tools, devops tools) and developers are more familiar with it. HTTP is the de-facto standard for APIs as well.

If you're the sole developer of a Single Page App with no API, then this difference may not be important. But if you're working with a team, or across teams, then building a WebSocket-only app will bring pain. As another commenter mentioned, as long as equivalent actions are possible via HTTP then some of the issues are alleviated.

upvoted for being a nuanced response, thanks!

yea, of course. It's a new option to build good systems not a tool to build shitty ones