Live data from Hacker News

LiveView Is Best with Svelte

blog.sequin.io

111–120 of 158 posts

Re: LiveView Is Best with Svelte

#111
post #108

Earlier quoted context omitted.

you would be in the minority then, most people these days want (and expect) live feedback if the action's result is predictable enough e.g. throttle your network and upvote a hn comment. you're not sitting there waiting with a spinner while the server responds, it's all in the background. the hn implementation isn't great though - if the upvote request fails, the optimistic update isn't rolled back, and you have no k…

If you're (would be) 'sitting there waiting with a spinner' then that endpoint is too slow, regardless of what the frontend does in the meantime.

depends on the definition of "slow". unless you have servers and databases everywhere (overkill for 99% of apps), your endpoint will be probably be >400ms for some people somewhere, enough to feel as a user.

that's without accounting for patchy reception (in a tunnel?), network blips, server blips (overworked?), etc.

i'm not saying everything should be optimistic, but for something like a hn upvote, i dont care if my public wifi freaked out and took 3 seconds for that 1 request, and i think more people are like that than not

Re: LiveView Is Best with Svelte

#112

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…

Thank you for providing your pattern.

Re: LiveView Is Best with Svelte

#113

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…

As a player of a game (Overwatch) that simulates ragdoll physics locally and non-deterministic, I wish they did it correctly.

What ends up happening is someone dies and their body flies off or gets stuck in a hilarious pose... and no one else saw it, nor can you rewatch it in the replays as every client renders it differently.

Unless you catch it with a live recording then it's lost forever. With a sometimes goofy game like Overwatch it's sad knowing no one else is seeing it.

Re: LiveView Is Best with Svelte

#114
post #52

Earlier quoted context omitted.

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.

This isn't particularly convincing, as the pattern -- loosely: keep a websocket open and keep the formerly clientside app state serverside while passing events and pushing diffs -- seems to appear successfully outside of the BEAM vm. For example, blazor serverside (.net) and laravel livewire (php).

I haven't checked but I'm sure there will be a python one too

Re: LiveView Is Best with Svelte

#115
post #114

Earlier quoted context omitted.

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.

This isn't particularly convincing, as the pattern -- loosely: keep a websocket open and keep the formerly clientside app state serverside while passing events and pushing diffs -- seems to appear successfully outside of the BEAM vm. For example, blazor serverside (.net) and laravel livewire (php). I haven't checked but I'm sure there will be a python one too

You are not convinced because you don't know the details. But I am not paid to advocate or to even try to convince. You've been informed now -- from here on it's on you as to whether to remain biased or to expand your horizons.

Re: LiveView Is Best with Svelte

#116
> If a new row comes in, you just need to push it to your table, and LiveView will update the client for you.

Don’t do this in line-of-business apps where those rows are interactive. The cognitive latency readily induces users into clicking the wrong thing, emailing the wrong customer, refunding the wrong transaction etc. My preferred UX instead is a sticky banner conveying “the data has changed, click here to refresh”. Or, in a pinch, ensure that new rows are rendered append-only with no change in scroll position.

Re: LiveView Is Best with Svelte

#117

> If a new row comes in, you just need to push it to your table, and LiveView will update the client for you. Don’t do this in line-of-business apps where those rows are interactive. The cognitive latency readily induces users into clicking the wrong thing, emailing the wrong customer, refunding the wrong transaction etc. My preferred UX instead is a sticky banner conveying “the data has changed, click here to refres…

This CAN work, if you animate in the new lines slowly and (maybe) disable clicks while new data is coming in.

Re: LiveView Is Best with Svelte

#118
post #114

Earlier quoted context omitted.

This isn't particularly convincing, as the pattern -- loosely: keep a websocket open and keep the formerly clientside app state serverside while passing events and pushing diffs -- seems to appear successfully outside of the BEAM vm. For example, blazor serverside (.net) and laravel livewire (php). I haven't checked but I'm sure there will be a python one too

You are not convinced because you don't know the details. But I am not paid to advocate or to even try to convince. You've been informed now -- from here on it's on you as to whether to remain biased or to expand your horizons.

[deleted]

Re: LiveView Is Best with Svelte

#119

> If a new row comes in, you just need to push it to your table, and LiveView will update the client for you. Don’t do this in line-of-business apps where those rows are interactive. The cognitive latency readily induces users into clicking the wrong thing, emailing the wrong customer, refunding the wrong transaction etc. My preferred UX instead is a sticky banner conveying “the data has changed, click here to refres…

This CAN work, if you animate in the new lines slowly and (maybe) disable clicks while new data is coming in.

[deleted]

Re: LiveView Is Best with Svelte

#120
post #114

Earlier quoted context omitted.

This isn't particularly convincing, as the pattern -- loosely: keep a websocket open and keep the formerly clientside app state serverside while passing events and pushing diffs -- seems to appear successfully outside of the BEAM vm. For example, blazor serverside (.net) and laravel livewire (php). I haven't checked but I'm sure there will be a python one too

You are not convinced because you don't know the details. But I am not paid to advocate or to even try to convince. You've been informed now -- from here on it's on you as to whether to remain biased or to expand your horizons.

I've written elixir apps, also read Armstrong's thesis, etc etc. Beam is undoubtedly an excellent piece of engineering.

I don't want to engage more than that, as the horizons comment seems bizarre in the context of the thread

Post reply on HN