5 ms·

I have never used LiveView, but I'd love to see the web moving towards this kind of interfaces. HTML over the wire is powerful! The deep integration between all

I have never used LiveView, but I'd love to see the web moving towards this kind of interfaces. HTML over the wire is powerful! The deep integration between all the parts (Phoenix, LiveView, the HEEx engine...) is nice, and compile-time template validation looks really cool. One thing that concerns me about doing everything over WebSockets, is that it seems you now need to keep a connection with every connected client, even if they are not doing any "highly interactive" actions. I think (in most cases) it would be more efficient to do a bunch of AJAX requests to receive those HTML chunks. Now that we have CDNs, HTTP/{2,3}, etc. the benefits of using WebSockets for everything seem less obvious. This is what HTMX[0] does by default, and then you can use WebSockets[1] if you need it. Another great thing about HTMX is that the backend can be whatever you like, as long as you can handle HTTP requests and return HTML. In any case, I like both approaches and I would love to see the web development ecosystem moving back to sending HTML over the wire, regardless of the framework. [0] https://htmx.org/ https://htmx.org/ [1] https://htmx.org/attributes/hx-ws/ https://htmx.org/attributes/hx-ws/

y4mi 5y ago
Elixir (the language phoenix is written in, which is the framework that has these live views) is great with concurrency. You can have incredible quantities of parallel sockets open with basically no overhead. There have been various write-ups about it if you're interested.
dnautics 5y ago
> is that it seems you now need to keep a connection with every connected client But seriously, what is the problem with this? I am guessing you don't really have much experience with the BEAM. It's completely not-objectionable, there aren't many stability issues, and they are very light weight (maybe a couple of kB/process). I believe (have not done this myself) you can do liveview over long-poll, since liveview only cares about there being Phoenix Channel, which abstracts over websocket/longpoll. https://equip9.org/2020/01/06/phoenix-liveview-longpoll https://equip9.org/2020/01/06/phoenix-liveview-longpoll One of the things I want to try for the gee-whiz factor is to build an Elixir WebRTC client and serve liveview over a WebRTC data channel. I see no reason why that shouldn't work.
- deleted 5y ago
  [deleted]
- hamandcheese 5y ago
  Do Phoenix channels have server-side state though? LiveView has server side state, so long polling would only work if there were also some form of server pinning involved (or a single server). Websockets are persistent connections so no need to worry about pinning a server across several requests.
besil 5y ago
You can go with Server Sent Events too, that are more suitable for notifications. WS may be blocked in corporate networks
- besil 5y ago
  I hope too HTML Over the Wire will be trending, I hate all the SPA and JS madness nowadays. SPA/React/Flutter are great tools and technologies, when you have a team for the backend and one for the front end. If you are a little startup or a single man project, that’s quite huge to maintain
- porker 5y ago
  The Symfony community has been going for Server Sent Events rather than websockets, via https://mercure.rocks/ https://mercure.rocks/. I don't understand the benefit when every other framework wanting interactivity is still going for websockets. As you say SSE seem more suitable for notifications rather than bi-directional communication.

y4mi 5y ago

Elixir (the language phoenix is written in, which is the framework that has these live views) is great with concurrency. You can have incredible quantities of parallel sockets open with basically no overhead. There have been various write-ups about it if you're interested.

dnautics 5y ago

> is that it seems you now need to keep a connection with every connected client But seriously, what is the problem with this? I am guessing you don't really have much experience with the BEAM. It's completely not-objectionable, there aren't many stability issues, and they are very light weight (maybe a couple of kB/process). I believe (have not done this myself) you can do liveview over long-poll, since liveview only cares about there being Phoenix Channel, which abstracts over websocket/longpoll. https://equip9.org/2020/01/06/phoenix-liveview-longpoll https://equip9.org/2020/01/06/phoenix-liveview-longpoll One of the things I want to try for the gee-whiz factor is to build an Elixir WebRTC client and serve liveview over a WebRTC data channel. I see no reason why that shouldn't work.

deleted 5y ago
[deleted]
hamandcheese 5y ago
Do Phoenix channels have server-side state though? LiveView has server side state, so long polling would only work if there were also some form of server pinning involved (or a single server). Websockets are persistent connections so no need to worry about pinning a server across several requests.

besil 5y ago

You can go with Server Sent Events too, that are more suitable for notifications. WS may be blocked in corporate networks

besil 5y ago
I hope too HTML Over the Wire will be trending, I hate all the SPA and JS madness nowadays. SPA/React/Flutter are great tools and technologies, when you have a team for the backend and one for the front end. If you are a little startup or a single man project, that’s quite huge to maintain
porker 5y ago
The Symfony community has been going for Server Sent Events rather than websockets, via https://mercure.rocks/ https://mercure.rocks/. I don't understand the benefit when every other framework wanting interactivity is still going for websockets. As you say SSE seem more suitable for notifications rather than bi-directional communication.