Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

111–120 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#111

the biggest drawback with SSE, even when unidirectional comm is sufficient is > SSE is subject to limitation with regards to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browser and set to a very low number (6). https://ably.com/blog/websockets-vs-sse SharedWorker could be one way to solve this, but lack of Safari support is a blocker, as usual.…

This isn’t a problem with HTTP/2. You can have as many SSE connections as you want across as many tabs as the user wants to use. Browsers multiplex the streams over a handful of shared HTTP/2 connections. If you’re still using HTTP/1.1, then yes, this would be a problem.

hmmm, you might be right. i wonder what steered me away. maybe each SSE response re-sends headers, which can be larger than the message itself?

maybe it was inability to do broadcast to multiple open sse sockets from nodejs.

i should revisit.

https://medium.com/blogging-greymatter-io/server-sent-events...

Re: Server-Sent Events: an alternative to WebSockets

#112
post #45

Earlier quoted context omitted.

Can you explain how H2 would make it harder to scale SSE?

The mistake they did was to assume only one TCP socket should be used; the TCP has it's own head-of-line limitations just like HTTP/1.1 has if you limit the number of sockets (HTTP/1.1 had 2 sockets allowed per client, but Chrome doesn't care...) it's easily solvable by using more sockets but then you get into concurrency problems between the sockets. That said if you, like SSE on HTTP/1.1; use 2 sockets per client (…

> and DNS (which is centralized and should be replaced btw

So much nonsense in a single paragraph, amazing.

If anything DNS is less centralized then http and SMTP. Its a surprisingly complicated system for what it does because of all the caching etc, but calling it more centralized then http is just is just ignorant to a silly degree

Re: Server-Sent Events: an alternative to WebSockets

#113
post #67
post #56

Earlier quoted context omitted.

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).

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:/…

While I agree, we shouldn't discount one less RTT for encrypted connections. Latency is a problem that never really goes away, and we can only try to reduce RTTs.

Re: Server-Sent Events: an alternative to WebSockets

#114
post #107
post #101

Earlier quoted context omitted.

> MIT but [bunch of stuff] Not MIT then. The beauty of MIT is that there is no stuff.

We already discussed this in an earlier thread, and however bad this looks it's better than my own license. Here it's clear, you can either use the code without money involved and then you have MIT (+ show logo and some example code is still mine). If you want money then you have to share some of it.

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

Re: Server-Sent Events: an alternative to WebSockets

#115
post #67
post #56

Earlier quoted context omitted.

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).

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:/…

For FANG scale, a 1% performance improvement for certain services has measurable business results.

Take Snap. Say they reduced time to view a snap by 10ms. After 100 snaps that’s an additional 1 second of engagement. This could equate to an additional ad impression every week per user. Which is many millions of additional revenue.

Re: Server-Sent Events: an alternative to WebSockets

#116
post #67
post #56

Earlier quoted context omitted.

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).

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?

Re: Server-Sent Events: an alternative to WebSockets

#117
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.

Re: Server-Sent Events: an alternative to WebSockets

#118

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.

Agreed. I use them in my editor but I ban them from my blog posts. They aren't helpful to others

Re: Server-Sent Events: an alternative to WebSockets

#119

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.

Which characters, the funky '≠'? I've seen those pop up a few other times recently, which makes me wonder if there's some editor extension that just came out that maps != and !==

Re: Server-Sent Events: an alternative to WebSockets

#120
post #114
post #107

Earlier quoted context omitted.

We already discussed this in an earlier thread, and however bad this looks it's better than my own license. Here it's clear, you can either use the code without money involved and then you have MIT (+ show logo and some example code is still mine). If you want money then you have to share some of it.

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.

Post reply on HN