Comment by brundolf | Hacker News Reader

Comment by brundolf | Hacker News Reader

Parent Full thread

> The key thing to tackle is dealing with the server side state

The core problem of web UIs has always been managing state. People like statically-rendered pages because most state gets kept in a) the URL, and b) transient HTML elements, and both are highly visible and easy to deal with in robust ways. When you're forced to have server-side state it's exceptionally painful, but people usually just avoid it altogether which in most cases pushes things towards the virtue of having less state anyway.

For complex UIs with lots of little interactions the above story doesn't really work, so we've invented state management systems for the client. Managing complex state still sucks, but it sucks less with these tools.

Sounds like this approach is just moving that state store back to the server, with a greased pipeline so it isn't so horribly painful to add new pieces of state even though both sides are involved. But you'll still face all the same problems you face with a front-end store: transientness, cache-clearing, even modeling is hard when you're dealing with a big blob of mutable state. And there will be the additional challenge of associating this stuff with a user (which you get for free on the front-end, even with modern state stores).

> Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience. You have minimal data transfer, and minimal rendering updates. There is a great deal of power in having your UI be a stateless function over a giant JSON object.

> this is where I have my shitty idea of a programming language for board games

It's funny, I started building a web-based board game to play with family during quarantine, and I landed on this exact approach totally by coincidence :) I'm using polling requests instead of websockets because I'm lazy/it doesn't need to scale, but it's the exact same idea where the server just publishes a giant JSON object of state and the clients are pure functions of it (and send messages to the server to mutate it). I wonder if there's some aspect of board games that pushes one towards that line of thinking.

I'm working on the complex UIs now, and it is a challenge. Fortunately, I can focus on gaming designs which is less complicated.

I think the key thing here is figuring out how the UI can be made mostly declarative and a stateless function of the state. I'm drawing some inspiration from

https://flutter.dev/docs/development/data-and-backend/state-...

and the challenge is the polish to make products great. My strategy is that I'm going to make a UI editor so I can make faster progress on designing the board game UI and then build a minimal set of controls to do data binding. The key is to get into the fight about what is the polish needed, and what reasonable escape hatches are needed.

> I wonder if there's some aspect of board games that pushes one towards that line of thinking.

There is, they are exceptionally complicated!!! SO COMPLICATED! The key is the implicit state machine between all the players, and you just can't quickly model it with traditional tools and databases. All it takes is a single card or game piece (which changes rules) to invalidate EVERYTHING. Games are exceptionally messy!

If your game has limited number (say, < 10) participants per game board, then concurrent updates to shared state etc can be solved with a traditional game state hosting server model. But if that number is higher say 100+ then you need a sharded distributed setup. That's when things get really tricky if you don't keep things simple.

So, like all engineers, I imagine that my products that I ship will reach massive levels of scale. Such massive level of scale that I need to use elastic compute, so I should expect processes to come and go.

Thus, my processes clearly has to sustain 100k+ connections. And, at a moment's notice, I should expect the process to go "poof". Maybe someone is going to do a kernel upgrade or someone decided to unplug a machine, I don't know!

Having operated with the above assumptions, I found it hard to be wise to avoid that and then invented a programming language that would operate in a modern cloud environment.

I need better hobbies, or not... who knows.

It seems like you could get most, if not all the way, there with an "isomorphic" Redux store on client and server side, along with a custom Redux middleware (very easy to write and well-documented) that reads actions from and writes actions to whatever connection you have set up. That way, your initial "giant json object" on the client is just the current store state and your "streaming updates" are just redux action objects going over the wire. You'd probably want some extra metadata attached to the objects (e.g., a uuid field and an ack field containing the last action's uuid) and youd have to deal with all of the usual synchronization problems in your middleware, but you'd have a solid starting point, at least.

Yep. As an example, see this pair of posts from 2017 on a distributed VR app with Redux actions over the network:

http://jimpurbrick.com/2017/01/04/vr-redux/

http://jimpurbrick.com/2017/07/04/react-vr-redux-revisited/

the real world is messy, games are a way of identifying the messiness (and then provoking one user to be upset at how the developers chose to model the messy world)

> where the server just publishes a giant JSON object of state and the clients are pure functions of it (and send messages to the server to mutate it)

So, XSLT for JSON basically. I like it.

> I'm using polling requests instead of websockets because I'm lazy/it doesn't need to scale, but it's the exact same idea where the server just publishes a giant JSON object of state and the clients are pure functions of it (and send messages to the server to mutate it).

I like this approach as well, but I do worry that users today expect optimistic updates on the client, and the injection of a X00ms delay would make the app feel sluggish.

Reply on news.ycombinator.com