LiveView Is Best with Svelte • Hacker News Board

Re: LiveView Is Best with Svelte

#61

Post by POiNTx » Wed, Apr 03, 2024, 3:56 PM UTC

logicallee wrote: post #55

debussyman wrote: post #35

I love LiveView + Svelte! (I gave the talk at ElixirConf 2022 on how to combine them, but the live_svelte contributors have done the work to make it a reality) IMO there is always a need for client side state, especially for apps with rich UX. I also live in NYC where network connectivity is not a given, especially in transit. One super powerful feature that the authors don't cover is being able to use Phoenix's pubs…

How usable are LiveView pages while offline? (Due to intermittent lack of network connectivity.)

Out of the box, they don't work offline. But there's recently been a project showing it's possible to create a PWA with CRDT's and LiveSvelte:

https://github.com/tonydangblog/liveview-svelte-pwa

Re: LiveView Is Best with Svelte

#62

Post by furyofantares » Wed, Apr 03, 2024, 3:57 PM UTC

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 don't know the other players' inputs. But this paradigm can also be used to simply respond immediately to client input while waiting for the official server state - say by enabling/disabling a dropdown, or showing a loading spinner.

There's also plenty of client state that's not run on the server at all. Particle systems, ragdolls - stuff that doesn't need to be exactly the same on all clients and doesn't interact with other player inputs / physics.

If we're gonna have a persistent server connection I don't see a reason this wouldn't work in a reactive paradigm.

Re: LiveView Is Best with Svelte

#63

Post by jonnycat » Wed, Apr 03, 2024, 3:59 PM UTC

This is great. LiveView is truly amazing and greatly speeds up development, but as the post describes, there are a couple of rough edges. They're all solvable, but sometimes there aren't clear or well-established patterns for how, so it can feel a bit ad hoc. While I'm not currently using Svelte for this kind of thing, I'm really glad to see people formalizing some of the issues + solutions.

Re: LiveView Is Best with Svelte

#64

Post by pdimitar » Wed, Apr 03, 2024, 4:02 PM UTC

pjmlp wrote: post #52

dns_snek wrote: post #29

Earlier quoted context omitted.

Could you elaborate? I don't see many similarities between those and LiveView. The difference between traditional technologies that render HTML server-side and LiveView, is a persistent connection to the server which allows it to re-render templates in response to server-side events and patch client-side HTML without writing any Javascript.

Mostly based on WebSockets and Server Push. As one example of such approaches, .NET has SignalR since 2013. And WebForms could use designer tooling since 2001, and then there was ASP.NET AJAX Control Toolkit.

But it doesn't have the BEAM VM. The runtime matters a lot, and LiveView wouldn't work as well if it wasn't running under the BEAM.

Re: LiveView Is Best with Svelte

#65

Post by krainboltgreene » Wed, Apr 03, 2024, 4:03 PM UTC

My own company has found significant advantage by using LiveView with Alpine, specifically in CSP mode since we can't allow `eval` to happen on the client. When I originally looked at LiveSvelte it seemed very new and untested. It also had some unsolved implications in strict CSP environments. Glad to see that it's become very useful!

Our own pattern (LiveAlpine?) is as follows:

Does the component need HTML? Then use an HTML Component. Does the component have server-side state? Then use a Live Component. Does the component need client-side behavior and/or state? Then also define an Alpine component. Does the component need to receive client-side events from the server or make HTTP requests? Then also define a Phoenix Hook.

Re: LiveView Is Best with Svelte

#66

Post by POiNTx » Wed, Apr 03, 2024, 4:07 PM UTC

furyofantares wrote: post #62

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…

That's what I did with: https://territoriez.io/

It's a clone of https://generals.io/

It's built with LiveSvelte. It doesn't need any predictive features as it's basically a board game and runs at 2 ticks per second. It does use optimistic updates to show game state before it actually updates on the server. The server overrides the game state if they're not in sync.

All game logic is done inside Elixir. To do predictive correctly, you'd need to share logic between the server and the client. Otherwise you're writing your logic twice and that's just a recipe for disaster.

One possible solution which I didn't investigate, but should work, is to write all game logic in gleam (https://gleam.run/). Gleam is compatible with Elixir, AND it also can compile to js, so you could in theory run the same code on the server and the client.

Now this is a big mess to understand, you could say "why don't write it all in js and be done with it" and you'd make a very good point and I'd probably agree. The main advantage you get is that you can use the BEAM and all it's very nice features, especially when it comes to real time distributed systems. It's perfect for multiplayer games, as long as you don't take into account the frontend :)

Re: LiveView Is Best with Svelte

#67

Post by floodfx » Wed, Apr 03, 2024, 4:07 PM UTC

klabb3 wrote: post #10

Generally speaking this is the model I’ve always been wanted to build apps in. Event oriented, bidirectional realtime updates with server, ordered events, local and remote state... I didn’t know about LiveView and never used erlang-family languages, but definitely they’re onto something. The traditional request-response model is many times causing a lot of subtle problems with consistency and staleness. A wishful (pr…

There are LiveView backends written in Javascript (http://liveviewjs.com), Go (https://github.com/canopyclimate/golive), Java (https://github.com/floodfx/undead), and Python (https://github.com/ogrodnek/pyview).

Disclaimer: I wrote or helped write the first three.

Re: LiveView Is Best with Svelte

#68

Post by tyre » Wed, Apr 03, 2024, 4:09 PM UTC

fizx wrote: post #36

> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users. The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return. Sounds a little crazy, but we've actually pulled it off for a project, and its magic.

What about persistence? To me that’s the main purpose of the backend and running a server on the client doesn’t fix that. You still have the network latency of persistence, which is the ultimate server state that should win.

Re: LiveView Is Best with Svelte

#69

Post by realusername » Wed, Apr 03, 2024, 4:16 PM UTC

bogwog wrote: 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.

You already manage two kinds of state when you are building a React app:

- State coming from the server as a result of user actions

- Local state which isn't intended to be shared to the server, usually UI stuff.

Re: LiveView Is Best with Svelte

#70

Post by paulgb » Wed, Apr 03, 2024, 4:17 PM UTC

postalrat wrote: post #48

fizx wrote: post #36

> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users. The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return. Sounds a little crazy, but we've actually pulled it off for a project, and its magic.

It sounds over-engineered. Lots of over-engineered stuff gets pulled off for no good reason.

There is a good reason: it becomes much easier to think about state transitions, because optimistic and “verified” updates both follow the same code path.

I've built a turn-based game that worked this way, where essentially every player and the server contains a copy of the same state machine, and the server determines the order of state updates. Like OP said, once you have the framework in place, it's magic.