Hacker News Reader

Comment by ocharles | Hacker News Reader

It's a shame Server-Sent Events aren't universally supported. I find them a lot simpler than WebSockets - modifications are just normal HTTP calls, and then you can broadcast the actual result of the transactional call back down with a SSE. But Edge doesn't support them :(

View on HN

Based on http://caniuse.com/#feat=eventsource only IE/Edge doesn't have it, and there are polyfills for those, e.g. https://github.com/Yaffle/EventSource/blob/master/README.md

Or there are more problems?

Want to use SSE for one small project soon (haven't used it before, and don't want Websockets as they're an overkill for a basic event stream), would appreciate any info about how things could go wrong.

Again imagine if MS focused on user experience and used blink / WebKit - instead of rolling their own.

We'd have a more standard and open web with fewer set backs. More engineers working on the same engine. A larger team working on a shared native application for everyone to build on for them to sell ads too. It even makes good business sense for them now. One can dream right?

Edge has much better battery life than other browsers on Windows, much like Safari on Mac. Neither of those are the best browser, but when my choice is between six or ten hours of battery life, it's easy for me to decide.

I dream that one day Webkit / Blink will actually be efficient.

> I dream that one day Webkit / Blink will actually be efficient.

Apple's Safari uses Webkit and does get increased battery life on Macs. Theres no reason MS couldn't do the same with Webkit and optimize for battery life using the same engine.

Yea, it's only Edge, but if you look at WebSockets you'll see that everything except Opera Mini supports them - so you can get (some of) the same functionality without polyfills at all.

But why willingly introduce extra complexity to the system?

Websockets are way less trivial than SSE. Polyfills for a less popular browser seem to be a simpler solution to the problem, compared to websockets stack everywhere. Even if I don't have to implement websockets on my own and would use some mature library (because bugs happen even in such libraries).

I believe in the majority of cases SSE are a better technology than web sockets (e.g. WS do not seem to conform to HTTP/2.0, SSE offer transparent (browser-supported) reconnects, SSE event ids allow for replay, etc). The downside is no support in IE/Edge (you can vote at https://goo.gl/bd8V1K), no binary content (but again usually JSON is enough) and no fully bidirectional communication.

A good talk at the matter can be found at https://youtu.be/NDDp7BiSad4

Speaking of web sockets and simplicity:

I never understood why web sockets aren't just a straight break out of HTTP(S) to a naked TCP or SSL socket. Why all the extra complexity? All it does is degrade performance and bloat software.

I hate the way protocols are designed by committee, virtually guaranteeing that everything has layers upon layers of cruft that have never actually been needed by anyone for anything but must be implemented because it's in the spec.

For one you need some concept of same origin/CORS. Don't want web sockets to provide an easy DoS vector

That would be in the headers and prior to protocol breakout. I'm talking about after that. Why does web sockets have an extra layer of framing and other nonsense? Not to mention other "modes of operation." It's a socket. Give me a socket.

No kidding. It's just a new version of TCP, implemented on top of HTTP, which is implemented on top of TCP.

Because of firewalls, proxies, and NAT.

You already have a TCP connection, so NAT and firewalls don't matter here. Proxies have to be web socket aware anyway.

Does anyone know why Edge would make that kind of decision? SSE has been supported forever.

For this sort of thing, albeit only with a .NET backend, I've always used SignalR to handle these browser/server OS incompatibilities. It'll negotiate a common protocol, whether that be WebSockets, SSE, or falling back to long-polling.

When I checked probably around 6 months ago, SignalR seemed to have no real story for ASP.NET Core and it also depended on jquery on the frontend, which I found to be simply ridiculous.

However SignalR does not give you access to a raw websocket, in the same sense that socket.io does not give you one. Both are higher level abstractions that can use websockets as a transport, but are not restricted to them. If you want to run a custom protocol on plain websockets, e.g. because it's already well-defined what the other peer speaks/understands, then both are not applicable. If you don't care whether your realtime application is portable to another framework then yes, SignalR and socket.io are very viable solutions.

Reply on news.ycombinator.com