Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

121–130 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#121

This seems fairly cool, and I appreciate the write up, but god I hate it so much when people write code samples that try and be fancy and use non-code-characters in their code samples. Clarity is much more important then aesthetics when it comes to code examples, if Im trying to understand something I've never seen before, having a bunch of extra non-existant symbols does not help.

I’m guessing that you are referring to the “coding ligatures” in the author’s font selection for code blocks?

You can likely configure your user agent to ignore site-specified fonts.

Re: Server-Sent Events: an alternative to WebSockets

#122

This seems fairly cool, and I appreciate the write up, but god I hate it so much when people write code samples that try and be fancy and use non-code-characters in their code samples. Clarity is much more important then aesthetics when it comes to code examples, if Im trying to understand something I've never seen before, having a bunch of extra non-existant symbols does not help.

Are you referring to the `!==` and `=>` in their code being converted to what appears to be a single symbol?

Upon further inspection, it looks like the actual code on the page is `!==` and `=>` but the font ("Fira Code") seems to be somehow converting those sequences of characters into a single symbol, which is actually still the same number of characters but joined to appear as a single one. I had no idea fonts could do that.

Re: Server-Sent Events: an alternative to WebSockets

#123
post #67

Earlier quoted context omitted.

Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push. Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http:/…

HTTP/3 is E2E encrypted and built on UDP. What does “most routers don’t play nice with it yet” mean in that context? Do you mean middleware boxes/routers rather than end user routers?

For me the question is not so much "yet" as "maybe never", since some networks block UDP altogether, and HTTP/3 has a robust fallback mechanism.

Re: Server-Sent Events: an alternative to WebSockets

#124
post #40

SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.

Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs. (There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't develope…

You can also make your HTTP/1.1 SSE endpoints available on multiple domains and have the client round-robin them. Obviously adds some complexity, but sometimes it's a tradeoff worth making for example if you're on lossy networks and trying to avoid HTTP/2 head-of-line blocking.

Re: Server-Sent Events: an alternative to WebSockets

#125
post #91

Can someone give a brief summary of how this differs from long polling. It looks very similar except it has a small layer of formalized event/data/id structure on top? Are there any differences in the lower connection layers, or any added support by browsers and proxies given some new headers? What are the benefits of SSE vs long polling?

SSE doesn't support binary data. Text only.

Re: Server-Sent Events: an alternative to WebSockets

#126
post #4

I can’t find any downsides of SSE presented. My experience is that they’re nice in theory but the devils in the details. The biggest issue being that you basically need http/2 to make them practical.

In some cases you might actually be better served sticking with HTTP/1.1 and serving SSE over several domains, to avoid HTTP/2 head-of-line blocking.

Re: Server-Sent Events: an alternative to WebSockets

#127

SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug. 1. https://jmap.io/spec-core.html#event-source

> the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug

You can't say that and not say more about it, haha. Please expand on this?

Also, I'm a Fastmail customer and appreciate the nimble UI, thanks!

Re: Server-Sent Events: an alternative to WebSockets

#128
post #120
post #114

Earlier quoted context omitted.

I respect your right to license you product however you want, but please don't call that open source.

Open-source also means the source is open, what you are looking for is free and honestly nothing is free... if you have a better term I'm open for suggestions. But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.

That battle has been fought already, and the accepted term is "source available", not "open source". (And gnu adds Free or "libre" software, which is software licence in a way that tries to ensure the "four freedoms" for all downstream users of software - such as freedom zero - the right to run software (no need for eg: cryptographic signature/trusted software - without a way for the user to define trust).

Re: Server-Sent Events: an alternative to WebSockets

#129
My personal browser streaming TL;DR goes something like this:

* Start with SSE

* If you need to send binary data, use long polling or WebSockets

* If you need fast bidi streaming, use WebSockets

* If you need backpressure and multiplexing for WebSockets, use RSocket or omnistreams[1] (one of my projects).

* Make sure you account for SSE browser connection limits, preferably by minimizing the number of streams needed, or by using HTTP/2 (mind head-of-line blocking) or splitting your HTTP/1.1 backend across multiple domains and doing round-robin on the frontend.

[0]: https://rsocket.io/

[1]: https://github.com/omnistreams/omnistreams-spec

Re: Server-Sent Events: an alternative to WebSockets

#130
post #120
post #114

Earlier quoted context omitted.

I respect your right to license you product however you want, but please don't call that open source.

Open-source also means the source is open, what you are looking for is free and honestly nothing is free... if you have a better term I'm open for suggestions. But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.

> FOSS

FOSS or F/OSS is a combination of Free (as defined by the FSF) and Open Source (as defined by the OSI) (the last S is Software), which recognizes that the two terms, while they come from groups with different ideological motivations, refer to approximately the same substantive licensing features and almost without exception the same set of licenses.

Post reply on HN