Earlier quoted context omitted.
It is just a new generation rediscovering ColdFusion, Web Forms, JSF, PHP, Spring, Rails...
What does php spring and rails have to do with this? I'm confused haha
Keeping sessions on both sides.
LiveView Is Best with Svelte
51–60 of 158 posts
Re: LiveView Is Best with Svelte
#52Earlier quoted context omitted.
It is just a new generation rediscovering ColdFusion, Web Forms, JSF, PHP, Spring, Rails...
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.
Re: LiveView Is Best with Svelte
#53I'm a noob but it looks like this overlaps with nextjs a lot?
LiveView and Elixir/Erlang have stateful processes on the server unlike pure stateless HTTP request/response. This fundamental difference is what makes LiveView unique. Next.js isn't passing messages over a websocket nor holding stateful processes on the server.
Re: LiveView Is Best with Svelte
#54So 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's never that simple. In web applications there's always these types of states:
* States that the client needs to keep track of
* States that the server needs to keep track of
* States that only need to exist in memory (i.e. transient)
* States that need to persist between sessions
In the last sophisticated SPA I wrote I had it perform a sync whenever the client loaded the page. Every local state or asset had a datetime-based hash associated with it and if it didn't match what was on the server the server would send down an updated version (of whatever that thing was; whether it be simple variables, a huge JSON object, or whole images/audio blobs).
Whenever the client did something that required a change in state on the server it would send an update of that state over a WebSocket (99% of the app was WebSocket stuff). I didn't use any sort of sophisticated framework or pattern: If I was writing the code and thought, "the server needs to keep track of this" I'd have it send a message to the server with the new state and it would be up to the server whether or not that state should be synchronized on page load.
IMHO, that's about as simple a mechanism as you can get for managing this sort of thing. WebSockets are a godsend for managing state.
Re: LiveView Is Best with Svelte
#55I 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.)
Re: LiveView Is Best with Svelte
#56I 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 does not work at all while offline. If you just experience a short temporary drop it can reconnect you automatically.
Re: LiveView Is Best with Svelte
#57> 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.
Wait, what's the difference to a fat client then?
Ease of distribution.
Re: LiveView Is Best with Svelte
#58Re: LiveView Is Best with Svelte
#59I 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?
You could do that but in general no not in production. If you just have a UI update that server doesnt need to know about (for example opening a menu) then you do it with javascript.
Re: LiveView Is Best with Svelte
#60The biggest benefit to this would be gaining access to all the UI component libraries in the JavaScript ecosystem. The lack of such components in LV is one of the things that slows us down the most.