React solves the composition of components, which lacks in HTML technologies.
What about liveview ? That's the question. They're different.
What about liveview ? That's the question. They're different.
To be clear I don't believe that, but that's analogous to what I hear when I see this.
LiveView has composition of components, so there's an immediate answer to your question. You've already answered another piece with built-in soft real-time.
In all honesty, if you have looked at LiveView and don't understand what it brings then I'm not sure if you looked sincerely.
React and similar technologies actually not just scrap your boilerplates, it's real abstraction (forget the DOM API) with state and componentation. It's not like you scrap your jquery boilerplate).
I see people mess with DOM Api in their application, which is not the right way, because it's mixing different abstractions together to create a mess.
It's a complete way to build complex apps. I've personally built fairly decent complexity SaaS (18mo of dev) completely on LiveView + some react when it made sense.
Saying it's just HTML pushed over WebSocket is like saying React is just virtual DOM with components. There's much more to it when you get into it.
Plus it's enjoyable. I had significantly more fun and development speed building on it than the typical React+API approach.
That said it's still situational and I don't blindly recommend it to everyone. I think Elixir has one of the best graphql implementations (Absinthe), so I still recommend React+GQL as well.
I found people who's stuck in DOM abstraction like React keeps reinvesting what platform is already capable of. Some abstract is so nasty e.g. forwardRef .. like really? Real Event bubbling is so much better, it visit every damn node you got the ref for free.
And it's hard to overstate, but to also properly explain, how important this is and how it feels like magic when you do it. Because it lets you tap into everything Elixr (and Erlang VM) have to offer on the backend without ever having to think of "how the hell do I bring all that to the client".
My use-cases are: a big chunk of data is being processed, and while its being processed regular updates are sent over PubSub. Most actions a user initiates are long-ish-running and their updates are also sent over PubSub. Things that other users are doing are sent over PubSub and possibly need to be reflected in the UI.
In "traditional" JS-on-the-client-whatever-on-the-server model you have a plethora of questions of how to get that to UI: which endpoints to query, which updates to send over the wire, the formats, the frequence, authorisation, auth...
With LiveView your "client" is an Elixir view living on the server which just updates the view based on those PubSubs (or timers, or Kafka streams, or user-initiated actions, or...) and LiveView takes care of upating the DOM/HTML in the browser.
"Build a real-time Twitter clone in 15 minutes with LiveView and Phoenix 1.5" will give a good overview of this: https://www.youtube.com/watch?v=MZvmYaFkNJI
[1] Built-in in Phoenix, https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html