Live data from Hacker News

LiveView Is Best with Svelte

blog.sequin.io

131–140 of 158 posts

Re: LiveView Is Best with Svelte

#131

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…

I've always heard of and referee to this pattern as "otimistic updates" - tho my frame of reference is 25y in webdev, w/ almost no exposure to game dev.

Re: LiveView Is Best with Svelte

#133
post #46

Earlier 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.

I can see the next big thing coming: no latency! Render in client! :)

Re: LiveView Is Best with Svelte

#134

Earlier 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,…

The way I’ve always done it is that I have client side event handlers that perform the UI-visible side of the logic client side, but also asynchronously request the server to do it.

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

#135
post #5

So 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…

Interesting. What kind of app was it? How did you decide whether the server needed to keep track it? I’m assuming that was predetermined? What about new requirements, which would need to be tracked by the server? Could the app deal with this dynamically without code changes?

Re: LiveView Is Best with Svelte

#136

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…

Fighting games dial up these low-latency conflict resolution considerations to 11, and there’s an entire subfield of techniques for writing “netcode” to reconcile real-time event streams.

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

#137
post #46

Earlier 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! :)

Seems maybe messy to have templating in the client but I'd take a look if someone has done it.

Re: LiveView Is Best with Svelte

#138

Earlier 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

Maybe it works better with tmux?

Re: LiveView Is Best with Svelte

#139
post #127

The 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

This needs to be higher up ;)

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

#140

Earlier 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?

You keep frontend UI changes that don't affect state in the frontend. If you don't need the server then you don't waste your user's time with trips to the server. If you need server, you can do things on the frontend at the same time you send the request, e.g. hide something, add/remove a class.
Post reply on HN