Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LiveView Is Best with Svelte

blog.sequin.io

Post reply on HN
Print view View original

101–110 of 158 posts

Re: LiveView Is Best with Svelte

#101

Post by mb7733 »

furyofantares wrote: post #95
dkersten wrote: post #82

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

Haven't used it in years, but Meteor.js worked like this. Even to the point where it had a client-side database implementation that mirrored (parts of) the server-side database.

It would apply the updates optimistically to the client side DB, and the much of code that sat between the database could be shared between client and server. Neat stuff, even if overall Meteor wasn't my favourite thing to work with.

Re: LiveView Is Best with Svelte

#102

Post by kevinak »

AirMax98 wrote: post #49
kevinak wrote: post #43

Earlier quoted context omitted.

Why wouldn't you just use a Service Worker for this?

There's a couple different ways to skin this cat, but WebAssembly is definitely the "coolest". I'd imagine even a Service Worker is overkill compared to just inlining an optimistic response in whatever rest client you're using. Kind of similar to the content of this article, I wish people were more upfront with their reasoning. Doing something because "it's rad" is definitely fine by me!

I just mutate the data object when using SvelteKit. Blasphemy, I know. But it works, and it works well. :P

Re: LiveView Is Best with Svelte

#103

Post by OJFord »

pjmlp wrote: post #71
pdimitar wrote: post #64

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.

Tomato, Tomato, it has another VM.

This saying really doesn't work in writing, I just read ..err.. 'tomato, tomato'

Re: LiveView Is Best with Svelte

#104

Post by thibaut_barrere »

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.

It's over-engineered unless done properly, it which case it becomes a detail. I wouldn't be surprised to see some automatic conversion of server-side code to front-end by LiveView in the future for events where this behaviour is applicable, actually!

Re: LiveView Is Best with Svelte

#105

Post by ahallock »

pjmlp wrote: post #13
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.

It is just a new generation rediscovering ColdFusion, Web Forms, JSF, PHP, Spring, Rails...

Sounds pretty reductive and dismissive. Have you actually used LiveView and compared the DX? I've used a a few of the technologies you listed, and LiveView is a different animal.

Re: LiveView Is Best with Svelte

#106

Post by willsmith72 »

OJFord wrote: post #93
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…

You need to be smart about this though, I don't want it to look like a live/interactive form has worked for example - updating derived data on the page - if it's then going to turn out that actually the server had an error or there was network trouble, and it all gets undone (or worse I close the page/navigate away not realising at all).

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 knowledge that it failed. for hn, who cares, it's just a lost upvote, but for most modern web apps you would show the user that the action failed

Re: LiveView Is Best with Svelte

#107

Post by willsmith72 »

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.

local-first with a client-side sqlite db sounds way simpler for what seems like the same purpose

Re: LiveView Is Best with Svelte

#108

Post by OJFord »

willsmith72 wrote: post #106
OJFord wrote: post #93

Earlier quoted context omitted.

You need to be smart about this though, I don't want it to look like a live/interactive form has worked for example - updating derived data on the page - if it's then going to turn out that actually the server had an error or there was network trouble, and it all gets undone (or worse I close the page/navigate away not realising at all).

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.

Re: LiveView Is Best with Svelte

#109

Post by buzzerbetrayed »

POiNTx wrote: post #96
spiderice wrote: post #94

Earlier quoted context omitted.

Don't you lose a lot of the niceties of Elixir when switching to Gleam, just because Gleam is a younger project? LiveView would be the big one I'm thinking of. Do you see that as a worthy trade?

You can still use LiveView/Phoenix/Elixir, but have your game logic be in Gleam. I haven't used it though so I could be wrong here. A little bit more about it here: https://katafrakt.me/2021/10/13/app-with-elixir-business-log... You'd call Gleam code like this inside Elixir: `:game.move(game, player_1, :left)` And you'd receive an Elixir map `%Game{}` which you can then use in LiveView. If that makes sense.

Cool! I'm going to have to look more into Gleam. I saw it hit v1.0.0 on ElixirForum last month, but I figured it was an alternative to Elixir rather than something that played so nicely with it.

Re: LiveView Is Best with Svelte

#110

Post by lacoolj »

When I watch people using Nextjs, it makes me cringe. "This is just PHP but less clear what happens where"

And yet for some reason the thought of Phoenix + LiveView + Svelte makes me want so badly to try it. Just the thought of playing with it has me giddy. This must be a mental disorder I'm experiencing.

Dissociative Framework Disorder.

Post reply on HN