[marknadal]

This is cool, but I'm a bit confused. Websockets have been around for a long time now, and there are tons of popular libraries (like socket.io, but more importantly, you should check out the high performance https://github.com/uWebSockets/uWebSockets instead).

Is all this doing trying to encourage awareness that using websockets is good? If so, awesome. Else, what is it? Because it does not discuss how Websockets lose state on reload. Your game will be in a completely wrong state. Managing and maintaining state is the important thing (which is what https://github.com/amark/gun does, which is of course also "websockets-first"). When you reload your game, it should return/remain as it was, or else half your players are going to see a half-broken system!

[jasonl99]

Author here...Well, I started down the websockets path because of how awesome I found crystal to be. I wasn't intending to do this a few months ago, it just sort of took on a life of its own :)

The framework as I've written takes state into account; in fact it was/is a design goal. There are three types of server objects currently - WebObject, StaticBuffer and DynamicBuffer. A WebObject stays instantiated on the server even when no users on viewing it (at some point it will be garbage collected).

At any time, rendering that object will produce the exact representation as seen by someone who has viewed it and been updated with websockets. In fact, the card game is a good example of this. Start a game, draw a few cards, start another game, and then go back to the first. It'll be in the same state you left it in, complete with the events that occurred while you were gone. This was one of the top goals.

DynamicObjects are just arrays of WebObjects in a configurable buffer - think of a list of sports scores, where each item handles its own update.

StaticObjects are an array of simple strings of html (think of tail to view a log file).

[marknadal]

ahhhh! Okay, yeah then that is super awesome and very impressive. You definitely should highlight/emphasize that more in the piece then. Cause that is super exciting, and the ideal way to build/have things work. FRP reactive streaming stuff, as the buzzwords go.

So next up, how do you handle conflicts? Two users write to the same thing at the same time? Great work!

[jessaustin]

If the site is hardcore SPA, and has a single "mysite.com/" URL, then you're right that state is only represented in terms of websocket events. However, if we have URLs like "mysite.com/users/alice" or "mysite.com/conversations/alice-bob-23", those resources will stay current, so that reloading them will reflect websocket events that took place since the last load. If the events are coming really quickly, there might be a race condition, but that's easy enough to solve by including a "last event" token in the page itself, that can be included in the websocket URL.

[nohant]

If state matters, shouldn't we consider using Server Sent Events (SSE)?

[mememachine]

Thanks for linking that lib btw