hntrl

7 ms·

1.
by hntrl 1y ago
The helper example was a sore attempt to plug the project I've been working on (tinkering with it is how I came up with the example). The library I plugged has much more to do with enabling a more flexible reactive programming model in
2.
by hntrl 1y ago
It even has mention as being the spiritual successor to WebSocket for certain cases in mdn docs: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
3.
by hntrl 1y ago
who's to say your data is coming from multiple streams? You can propagate any updates you need to make in the application to a single stream (like SSE or a long-lived response) in place of a WebSocket. your http responses can just be a
4.
by hntrl 1y ago
It's a good thing I didn't then :shrug: Websockets are a web standard, socket.io is a userland framework
5.
by hntrl 1y ago
> sending a RequestID to the server so that you get request/response cycles isn't weird nor beyond the pale. To me the sticking point is what if the "response" message never comes? There's nothing in the websocke
6.
by hntrl 1y ago
I have a demo of this for CF workers https://github.com/hntrl/eventkit/tree/main/examples/workers... (it's not SSE in particular, but it demonstrates that you can have a long running stream lik
7.
by hntrl 1y ago
I've noticed some weird behaviors with the EventSource impl that browsers ship with. Chief among them being the default behavior is to infinitely reconnect after the server closes the stream, so you have to coordinate some kind of spec
8.
You might not need WebSockets(hntrl.io)
419 points by hntrl 1y ago|266 comments
9.
Show HN: Eventkit- a better way to work with data streams in JavaScript(github.com)
2 points by hntrl 1y ago|0 comments