Hacker News Reader

Comment by bterlson | Hacker News Reader

Great comparison. Would love to see http response streaming added to the mix. I think a lot of use cases involving finite streams sent from server to client can be handled by the server streaming JSONL in the response. I tend to prefer this over SSE for finite data streams.

View on HN

Server send event IS http response streaming. It is a standardized way to implement response streaming.

I agree, but SSE is a more complex protocol that requires additional handling on both client and server, with capabilities that may not be relevant for your use case (multiple event types, event id). For JS clients and JS servers it is not particularly onerous to implement, but for other ecosystems can require a fair bit of code. JSONL streaming is very easy to implement on both ends, so all else aside I think would be preferred if all you really want to do is stream JSON values.

I've implemented SSE from scratch on the server and XHR streaming/parsing from scratch on the client side (which would be necessary for JSONL), and SSE was way simpler. Unless there's another way to do JSONL in a browser that I'm not aware of?

If you use the fetch API you can get a readable stream and party on without too much difficulty. You can also implement a transform stream in ~10SLOC that will make the reader vend parsed JSON objects and can be reused easily.

This is a good point. In fact, you just helped me realize that I can probably replace this[0] at work with a fetch implementation. ReadableStreams weren't generally available across browsers when I wrote that. This would also allow us to return binary data if we so desired (XHR can handle binary but it can't stream it chunk by chunk). Thanks!

[0]: https://github.com/anderspitman/xhr-stream-dl

This library does that for SSE

https://github.com/rexxars/eventsource-parser

Reply on news.ycombinator.com