71–80 of 158 posts
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.
I honestly don’t understand how’s this different from react server components with nextjs but with less features? It seems like the same thing but with an even clearer border between server/client components and therefore missing all the optimizations (like streaming). Like islands architecture but made out of different technologies, is my understanding correct ? I would appreciate some feedback :)
...given that managing state is the thorniest of issues, what could go wrong with this approach?
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.
LiveView builds on top of Phoenix Sockets. When the page is loaded for the first time, it starts a lightweight server-side process on the BEAM VM. This long-lived process renders the HTML template (which can consist of multiple SPA-style components) and keeps all of the relevant "props" (called assigns) in-memory.
Every time a new event is received, either client-side (e.g. button click) or server-side (typically via a PubSub subscription), that long-running process will update its assigns (props) to reflect the new state. The framework then intelligently re-renders parts of the HTML template which depend on those modified assigns, and sends a minimal HTML diff to the client.
All of this can be done without writing any custom JS. Basic client-side events are usually set up with special HTML attributes like `phx-click=my_custom_event` and automatically wired up by LiveView JS bundle to be received by that long-running process.
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.
Or, when you don't have a runtime -- as is the case with Rust, kinda sorta I mean because technically `tokio` can be classified as a runtime -- then you rely on a stricter compiler.
Both strategies work pretty well.
I am not shitting on C# / .NET, they are solid as hell. But some things the BEAM VM just does better and everyone who worked with old-school VMs (in my case the JVM) and the BEAM VM can tell you that.
But again, you do you, think what you will. ¯\_(ツ)_/¯
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.)
Liveview isn't that special, the liveview paradigm works best for what would already be online actions in a normal page.
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 predicti…
Earlier quoted context omitted.
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 predicti…
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.
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 predicti…
1) Spawning closer to the center is just strictly significantly worse, corners are best. It's essentially an auto-lose to spawn anywhere but an edge or corner in a FFA.
2) Getting literally all of someone's armies when you kill them is so good that it pushes players to just try to all-in the first person they meet every single time. There is no way to "fast expand" once you've met another player because of the first factor, and also that 40-50 armies on a neutral castle is very high. I think the "early-game" can be much better designed.
3) Perhaps you should be able to change your capital, which could solve problem 1.
4) There are many ways you could keep the simplicity of play, but boost the richness and depth of the actual gameplay. For instance, more chokepoints that would allow actual strategic use of territory and army positioning. Different tiles which have different advantages to owning. Borrowing from something like civ - forests or hills which have a defensive boost when you're inside. Rivers which attacking across is disadvantageous.
Just some feedback from someone who enjoys games like Chess and Starcraft, and thinks the core gameplay loop of generals.io is really fun, but believes that it is seriously lacking in strategic depth.
I am not familiar with LiveView, so I'm curious. Looks like it processes UI actions server side. So, are all client interactions sent through the websocket? I remember years/decades ago we used to do that with ASP.NET, where every single component interaction was handled by the server. How is this different / better?
It seems to go against the wisdom of the last few decades, but the network latency seems to permit it now. Throw some edge computing to the mix and maybe it's all a good idea.