Hacker News new | ask | show | jobs
by niftich 3611 days ago
This; and HTTP has a massive install base, readily available clients on every platform, casual debuggability from tools many people already possess (browser address bar, browser js console, browser addons, curl).

Specific protocols have their merits, but they can only really compete in the backend-to-backend space, and even there they have to compete against HTTP endpoints. In anything that can be construed as vaguely front-end, HTTP has a massive first mover advantage with the ecosystem it brings.
2 comments
xg15 3611 days ago
I wonder though, doesn't SSE technically violate a lot of HTTP's assumptions? From the point of view of a HTTP middlebox, a SSE response would basically be a single endless entity, transmitted at a very low bandwidth. I'm no expert at real-world deployment of SSE, but that they sounds to me like it could break a lot of proxies that don't have special handling for SSE. (Or at least cause unnecessary resource consumption for those proxies)

Also I wonder why there are not more websocket-based APIs. WS has the same widespread support and ready-made debug tools as HTTP and seemed to be designed exactly for push or non request/response use cases. So, out of couriosity, why would SSE be preferred over WS?

link
niftich 3610 days ago
Streamdata.io (linked in a different post) has blogged [1] about why they chose SSE instead of WS. Additionally, WS drops you down to something very similar to raw TCP, so you have to bring your own application-level message framing, while SSE comes with its own minimalistic format. From a middle box's perspective, SSE isn't that different from streaming video or long polling, although the SSE recommendation [2] does have a line about older proxies:

"Legacy proxy servers are known to, in certain cases, drop HTTP connections after a short timeout. To protect against such proxy servers, authors can include a comment line (one starting with a ':' character) every 15 seconds or so."

[1] http://streamdata.io/blog/push-sse-vs-websockets/

[2] https://html.spec.whatwg.org/multipage/comms.html#authoring-...

link
xg15 3609 days ago
As far as I know, two of the few things WS does on top of TCP are in fact: making endpoints URL-addressable - and providing message framing. You can even have text-only frames with a well-defined encoding.

In any way though, thanks for the links. I haven't given them a deep read yet but will definitely do so soon.

link
xg15 3611 days ago
I wonder though, doesn't SSE technically violate a lot of HTTP's assumptions? From the point of view of a HTTP middlebox, a SSE response would basically be a single endless entity, transmitted at a very low bandwidth. I'm no expert at real-world deployment of SSE, but that they sounds to me like it could break a lot of proxies that don't have special handling for SSE. (Or at least cause unnecessary resource consumption for those proxies)

Also I wonder why there are not more websocket-based APIs. WS has the same widespread support and ready-made debug tools as HTTP and seemed to be designed exactly for push or non request/response use cases. So, out of couriosity, why would SSE be prepared over WS?

link
nitrogen 3611 days ago
It looks like you accidentally duplicated your comment when you changed "prepared" to "preferred".
link
xg15 3609 days ago
I'm sorry. That was my attempt at "editing" the post after the noprocrast mode kicked in - before an unintelligible post would sit there for ~3 hours...

If any mods could delete this, I'd be grateful.

link