A pattern sometimes used in multiplayer video games is there's a bunch of code that is by default run on both the client and the server. The client code runs as a prediction of the server state. When the server state is received it slams the client state. For games "prediction" is an apt description of this, because the client can make a good guess as to the result of their input, but can't know for sure since they d…
LiveView Is Best with Svelte
131–140 of 158 posts
Re: LiveView Is Best with Svelte
#132Re: LiveView Is Best with Svelte
#133Earlier quoted context omitted.
But isn't there a delay in UI responses because of latency then?
Sure, it's not for a smooth user experience over 2G connection, if that's your audience you'd use ordinary template rendering with Phoenix, or use it for a JSON API and build a JS client that talks to it.
Re: LiveView Is Best with Svelte
#134Earlier quoted context omitted.
Isn’t that just optimistic updates? This has been common in client side logic for a long time, no?
I was more talking about the method to achieve optimistic updates, rather than the concept of optimistic updates in general. That is, having the client and server code be identical where applicable, with client code being run in a prediction context. I'm not a web expert but the optimistic updates I've seen in web stuff is more like, I'm gonna fetch this url and here's the data I expect back. Nothing wrong with that,…
In simple cases, that logic simple sets a toggle or whatever. In slightly more advanced cases it might modify something such as appending to a list. But in some cases it could be performing more complex logic such as applying a filter to a list. Sometimes this logic is only done client side (if the filtering is view-only for example) and sometimes both client and server. Basically, if you remove all of the network requests, it would still look like it’s working, more or less.
Of course only logic that is needed for data to be correctly displayed in the UI is needed client side. Performing logic that is only used server side (even if it has later UI effects — only effects that the user expects immediately need local representation) is unnecessary client side.
Eg even in a game, you might not want to run, for example, bot AI speculatively on every client but rather just the movement prediction like for other players, while everything else may be needed for rendering.
Re: LiveView Is Best with Svelte
#135So instead of managing state on the client, you manage state on the client and the server? That doesn't seem like an improvement, even if it saves you from having to build yet another API.
It's never that simple. In web applications there's always these types of states: * States that the client needs to keep track of * States that the server needs to keep track of Then on top of those there's two more kinds of states that overlap but they're not quite the same thing: * States that only need to exist in memory (i.e. transient) * States that need to persist between sessions There's a seemingly infinite n…
Re: LiveView Is Best with Svelte
#136A pattern sometimes used in multiplayer video games is there's a bunch of code that is by default run on both the client and the server. The client code runs as a prediction of the server state. When the server state is received it slams the client state. For games "prediction" is an apt description of this, because the client can make a good guess as to the result of their input, but can't know for sure since they d…
https://arstechnica.com/gaming/2019/10/explaining-how-fighti... is an incredible walkthrough of this! Discussion: https://news.ycombinator.com/item?id=34399790 and https://news.ycombinator.com/item?id=26289933
When it comes to server persistence, as in an MMO setting, you add I/O bottlenecks into the mix. https://prdeving.wordpress.com/2023/09/29/mmo-architecture-s... is a fascinating read for that end of things. Discussion: https://news.ycombinator.com/item?id=37702632
Re: LiveView Is Best with Svelte
#137Earlier quoted context omitted.
Sure, it's not for a smooth user experience over 2G connection, if that's your audience you'd use ordinary template rendering with Phoenix, or use it for a JSON API and build a JS client that talks to it.
I can see the next big thing coming: no latency! Render in client! :)
Re: LiveView Is Best with Svelte
#138Earlier quoted context omitted.
I would strongly recommend using mise instead of asdf. It's a drop in replacement that is just flat out better for most people.
curious, what makes it better? asdf has always just worked for me, but this is the first time i’ve heard of mise, so i’m wondering what i’m potentially missing out on
Re: LiveView Is Best with Svelte
#139The cleanest way to handle the backend and frontend charade I've seen until now is using https://github.com/hyperfiddle/electric which is a clojure DSL on top of react
Also worth checking out Dustin’s talk about optimistic UIs.
https://youtu.be/v-GE_P1JSOQ?si=3tZeAZqoroN1Vubp
And quick tutorial: https://electric.hyperfiddle.net/
Have you used electric clojure?
Re: LiveView Is Best with Svelte
#140Earlier quoted context omitted.
I never used ASP.net so I cannot offer a comparison about what is "better" but your assumption is correct that diffs are through a WS and merged client-side. What this has resulted in is actual order of magnitude of implementation time reduction over the crazier SPA complexity available today. Less time to build, less cost to the company, less bugs in the long run, and a single place to manage and reason about state.…
But isn't there a delay in UI responses because of latency then?