In short, these solutions take JavaScript out of the mix entirely and basically let you deal with a single logical "app", rather than a separate frontend & backend.
[0] https://github.com/phoenixframework/phoenix_live_view [1] https://github.com/dbohdan/liveviews
First, engineers build application using just LiveView and it works just fine. You click a link you have table with your data, you click button you have filtered table, click another link you see a chart.
But then UX concerns are raised from PO/PM/users. Users find it jarring that they need to wait a little to see a loading spinner on clicked button. And we litter our views with some alpine.js DSL in attributes or load stimulus controllers. Some stuff is moved to hooks and kept in ad-hoc global variables.
Finally, most of the live views evolve into single html node, with mini-SPA written in some lightweight javascript framework. And everything is wired with phoenix websocket.
LiveView is still a fantastic and very productive tool to quickly create applications but I'm not sure if it scales to users expectations.
If I _really_ need something to be driven by the frontend like a transition then I'll use Alpine.js.
For CSS I tend to use tailwindcss / tailwindui because I know it well and it doens't need npm. If I didn't know tailwind I'd probably look at something like bootstrap or something I can build on top of with vanilla css.
For example: 1) selecting a checkbox alters other fields in the form 2) validation that needs to hit the backend and then present warnings/errors to user 3) field arrays -> sending back a list of fields
So the flow is 1) click the checkbox 2) call sent across the open socket 3) backend does it's logic to figure out what it needs to do 4) backend returns the small diff of changes 5) frontend alters dom.
Just because it can be done 100% server side doesn't mean it should be, especially if its driven out of a "look, no JS!" type of approach.
Staying in one language for frontend and backend is just so appealing. To my knowledge, the other option to achieve that would be having something like Blazor WASM or Rust Yew that compiles to WebAssembly to have a client-side app a la React/Vue/Svelte.
I wonder which of these approaches will end up be more prevalent in the future. To me it seems like compiling something React-like to WASM might be more attractive, because you can stay in your backend language, but ditch the permanent websocket connection.
Admittedly it is still a bit raw. But seemed like a really interesting concept when I was looking for LV equivalents.
Hugely simplifies the overall stack. Combine with TailwindCSS, TailwindUI.com, and you have some very powerful tooling at a low development cost.
I probably need to focus more on 'vanilla' back- and frontend stuff, but man has it been fun so far! Definitely made me enjoy my work more.
We run a half dozen elixir apps in the healthcare and research sectors.
people@polkadotskysoftware.com
I've been screwed over twice by Angular, RXJS, etc. Every month we had to redo most of our work as the community kept deciding on new directions of correctness.