4 ms·

"What problem does React solve? You can just use HTML and jQuery to build websites." To me LiveView is not about interactive apps so much as it is a way to bui

by sb8244 4y ago

"What problem does React solve? You can just use HTML and jQuery to build websites." To me LiveView is not about interactive apps so much as it is a way to build applications, period. You can build in a way that may bring you more joy, performance, and dev speed than you could otherwise. Interactivity is a side effect, and it's a great one. But I wouldn't recommend LiveView if someone only wanted interactivity. I'd recommend LiveView if someone wants a different way to build than the React+API status quo.

revskill 4y ago
React solves the composition of components, which lacks in HTML technologies. What about liveview ? That's the question. They're different.
- sb8244 4y ago
  "you just need to write better code to have composition with jQuery" 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.
  - revskill 4y ago
    I know what it does. Instead of boilerplate to declare channels to handle live websocket, now you can just bind the real data to a DOM html. Isn't it ? Is there any more to bring ? 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.
    - sb8244 4y ago
      LiveView is also state and components. + It has a view of the DOM to optimize the data it sends over wire. 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.
    - brightball 4y ago
      It’s much more than that.
    - Existenceblinks 4y ago
      > I see people mess with DOM Api in their application, which is not the right way 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.
- realusername 4y ago
  Liveview solves the dynamic areas in a easy way, that's the differentiating factor.
  - revskill 4y ago
    No ? I can easily use a React <LiveComponent websocketUrl="" /> to have a dynamic live area.
    - realusername 4y ago
      Can you point me the react API page for that? I've never seen that.
      - UlisesAC4 4y ago
        He is trolling us. That does not exist.
- dmitriid 4y ago
  Liveview solves the "write a fully dynamic and interactive application with next to zero Javascript that you need to write by hand" or, if you will, "server-driven UI apps". 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 https://www.youtube.com/watch?v=MZvmYaFkNJI [1] Built-in in Phoenix, https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html
- sph 4y ago
  You can compose components in recent versions of Live View as well.

by sb8244 4y ago

revskill 4y ago

React solves the composition of components, which lacks in HTML technologies. What about liveview ? That's the question. They're different.

sb8244 4y ago
"you just need to write better code to have composition with jQuery" 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.
- revskill 4y ago
  I know what it does. Instead of boilerplate to declare channels to handle live websocket, now you can just bind the real data to a DOM html. Isn't it ? Is there any more to bring ? 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.
  - sb8244 4y ago
    LiveView is also state and components. + It has a view of the DOM to optimize the data it sends over wire. 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.
  - brightball 4y ago
    It’s much more than that.
  - Existenceblinks 4y ago
    > I see people mess with DOM Api in their application, which is not the right way 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.
realusername 4y ago
Liveview solves the dynamic areas in a easy way, that's the differentiating factor.
- revskill 4y ago
  No ? I can easily use a React <LiveComponent websocketUrl="" /> to have a dynamic live area.
  - realusername 4y ago
    Can you point me the react API page for that? I've never seen that.
    - UlisesAC4 4y ago
      He is trolling us. That does not exist.
dmitriid 4y ago
Liveview solves the "write a fully dynamic and interactive application with next to zero Javascript that you need to write by hand" or, if you will, "server-driven UI apps". 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 https://www.youtube.com/watch?v=MZvmYaFkNJI [1] Built-in in Phoenix, https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html
sph 4y ago
You can compose components in recent versions of Live View as well.