Have you guys considered htmx before going that way? If you can share pro/cons I'd love to hear.
LiveView Is Best with Svelte
91–100 of 158 posts
Re: LiveView Is Best with Svelte
#92Earlier 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!
> WebAssembly is definitely the "coolest"
As always: when I doubt, it was likely because of CV-driven development
Re: LiveView Is Best with Svelte
#93A 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).
Re: LiveView Is Best with Svelte
#94Earlier quoted context omitted.
As someone who started using Elixir this year (for work) this is really cool. I have had some ideas for some SPAs and games just like these io ones and it'd be great to use Elixir for them. Do you think a top down fps io game would be plausible with this setup? There would need to be at least 60 ticks per second I'd think.
Definitely possible. Tick rate isn't the problem, Elixir is very performant. Just the predictive elements are an issue if you're working with 2 different languages. I'd go with Gleam from the start and look into compiling to js.
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?
Re: LiveView Is Best with Svelte
#95A 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…
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, but it's achieved in a different way, where the server is all about providing data and the client is all about managing state.
The OP is talking about maintaining a persistent connection to a server which is doing most of the state management. They detail things this does well (makes the server easier to write) and things it does poorly (makes optimistic updates harder) and a solution to the things it does poorly. So I'm drawing a parallel to other systems where state is managed on the server and must be predicted on the client.
Re: LiveView Is Best with Svelte
#96Earlier quoted context omitted.
Definitely possible. Tick rate isn't the problem, Elixir is very performant. Just the predictive elements are an issue if you're working with 2 different languages. I'd go with Gleam from the start and look into compiling to js.
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.
Re: LiveView Is Best with Svelte
#97Nice solution! In my app, I use reusable Stimulus controllers alongside LiveView, and it works seamlessly as well. On a general note, while it's a pleasure to build with LiveView, the more I use it in real-life scenarios, the more I realize the benefits of stateless HTTP frameworks like Hotwire, which feel more performant and resilient to reconnections, and avoid the need to place more servers close to users for stab…
Yeah I use Stimulus and Live View together as well. It is the right level of complexity, while I feel Svelte deals with a lot of stuff which is not even an issue when paired with LV. All you need is vanilla JS or a thin layer on top of it, not an entire framework. You will not have to write a lot of JS after all. My production app has no more than 200 lines of JS, and I could probably get rid of a couple Stimulus con…
I have the same view of an app implemented with Rails+Turbo and a duplicate in Elixir+LiveView.
Performance is comparable when I am close to the server (elixir is slightly faster), but when on another continent any content changes/navigation over websockets suddenly feel very laggy, while navigation over HTTP in the supposedly slower Ruby+Rails is actually consistently fast.
I’ve only recently discovered this as I went travelling to another continent, so will do more perf testing.
But the nature of the always-connected websockets hasn’t been a pleasurable one for me: for instance, a LiveView process crashes and you lose all the data in a big form, unless you write glue code for it to restore. And the experience of seeing the topbar getting stuck in the loading state the second your internet connection is spotty or if you are offline just gives me anxiety as a user.
Re: LiveView Is Best with Svelte
#98Generally 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…
You can use asdf to install erlang/BEAM/OTP and elixir, takes a few minutes if you have some previous experience with the tool. Either way it'll probably take about two hours to have your first rudimentary Phoenix chat application loaded in a browser if you follow some guides and tinker around a bit.
I would strongly recommend using mise instead of asdf. It's a drop in replacement that is just flat out better for most people.
Re: LiveView Is Best with Svelte
#99So 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.
> build yet another API.
It appears that's one of their major problems. They're not "building" APIs. They're just slapping "one shots" onto the side of a router whenever the need arises. This speaks to a complete lack of a planning and design phase.
I guess if you want to build something without any plan whatsoever, this might be a way to "improve" that process, but there's a much simpler one that doesn't require your team to become polarized over a framework.
Re: LiveView Is Best with Svelte
#100I've wanted something like this for Vue/React too with LiveView, because then you get access to this massive ecosystem of great components to put in your phoenix apps while still utilizing LiveView. (the LiveView component ecosystem is tiny). So maybe this can be the start of a general bridge that can bridge LV with React or Vue components too? And make it easy to put these in a page and interact with LV events, etc.
I've recently developed a LV/React bridge and am using it on a production app, but nothing open sourced at the moment. I'll open it up at some point soon and try and post back here!