Reasons/requirements for selecting Svelte over Liveview

Continuing the discussion from Looking for a guide to setup a pure esbuild and svelte for Phoenix API app:

My main reasons for wanting to implement a Client-side rendering framework over LiveView:

  • Lots of client-side reactive interactions that don’t require a constant connection to the server. e.g. manging large data tables and displaying charts and dashboards based on the data.
    • Here LV could cause a noticeable lag as requests are sent to the server, processed, and then all the relevant areas of the DOM are updated from the resulting diff. One can use lots of LiveView.JS and hooks code to glue things together, but this could become quite complex where using a self-contained client-side application would improve the development experience.
  • Creating a web application that is primarily going to be used in areas that have very poor internet connectivity.
    • This would require good caching and syncing strategies such that the user is able to do their work and then the changes are synchonised with the server whenever the connection is restored.

I’m sure others will be able to add to this list from their own experiences.

3 Likes

Thank you for responding to my question!
I guess as a first step, I need to dig deeper into Svelte to understand the details.
However, if I am not mistaken, Svelte is not like React. If I understood correctly from the quick glance I had, it is also an SSR solution. Although it can support SPA, as I understood, it is not really recommended (not studied the details for this though).
Anyway, I only wanted to see if there something explicit in that project that rendered Svelte as the optimal solution.

Svelte started as a pure client-side reactive rendering library and a direct competitor to React’s client-side framework.

They have both evolved to also include server-side rendering functionality as javascript/node backend developers wanted the same ability that we’ve always had with LiveView, for the server to create the initial page rendering and then the client-side code takes over the reactivity.

1 Like

I don’t see it as a matter of what is recommended, but what are the project’s requirements.

As a js/node dev, I would want to have my server generate the html (SSR) and then my client-side app take over the interactions (CSR). In this case I would logically reach for the same tool to do the job, so use svelte/react/etc. for both SSR and CSR.

As a LiveView dev, I would want to generate as much as possible from LV, and if the need arises refactor some of my code and templates to run purely in the client. Here there a couple of options

  • using LiveSvelte.render in LiveView to SSR the svelte component, and then svelte CSR takes over the reactivity
  • importing the compiled svelte components into the HTML and calling the CSR component, passing the relevant data props to make it work

Hope this helps :smile:

1 Like

Thank you for the elaborated responses! Indeed, Svelte can very well be a replacement for React (or Liveview).

1 Like

You can use Both - where aplicable and they work together quite easily and well.

2 Likes