4 ms·

LiveView can’t handle spotty connections, I thought? Career python expert, not huge into Django/we dev in general… I thought the whole thing with most HTML ov

LiveView can’t handle spotty connections, I thought? Career python expert, not huge into Django/we dev in general… I thought the whole thing with most HTML over the wire is that its tied to the connection latency? Unless there’s some js component underlying the Elixir code that I don’t know or don’t understand. With the advent of things like flask+html, I find it a little hard to believe that Elixir hackers could whip up a MVP faster than I’ve seen it done with flask. I’m not opposed to functional programming by any means, but just because the language embraces it doesn’t qualify all the constituent frameworks to replace world-class solutions like Django.

freedomben 4y ago
> LiveView can’t handle spotty connections, I thought? LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored. You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot. If you have a very complex client-side need, it's also pretty easy to use React.js for that. > With the advent of things like flask+html, I find it a little hard to believe that Elixir hackers could whip up a MVP faster than I’ve seen it done with flask. You'll have to get more specific if you want an accurate answer. Does this MVP require a database? Does it require specific UI or can you just massage the OOtB UI that Phoenix gives you? You'd be surprised at how much of a headstart the generators can provide. I've built working protoypes (with database persistence) in 30 minutes. If it's purely a static page, I would just use nginx directly but you could easily do that in Phoenix as well in about the time it takes you to write the HTML since the default new project comes with a page controller already set up for that.
- enraged_camel 4y ago
  >> LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored. What the parent means is that, because state is kept on the server with LiveView, and events that change that state are processed by the server, if your connection is lost, then you may find that even basic things, such as having a dialog open when you click a button, stop working. This means that unstable connections result in very poor UX. This is in direct contrast to a typical SPA for example, where the browser keeps and handles most front-end state, and talks to the server only when it needs to (e.g. form submission).
  - bostonvaulter2 4y ago
    You also might see full page refreshes when the heartbeat fails which can be very annoying.
  - freedomben 4y ago
    With pure LiveView, I would agree, but you can easily supplement with a JS framework. As I mentioned above: > You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot. If you have a very complex client-side need, it's also pretty easy to use React.js for that. While you could, I never use LiveView to open dialogs (unless the dialog state needs to be distributed across multiple clients, but I haven't had that use case come up yet). As you mention, that would lead to a poor UX. The best is the best of both worlds. LiveView for data/state changes that need to go to the database, client-side script for state changes that are UI related and don't get persisted.

freedomben 4y ago

> LiveView can’t handle spotty connections, I thought? LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored. You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot. If you have a very complex client-side need, it's also pretty easy to use React.js for that. > With the advent of things like flask+html, I find it a little hard to believe that Elixir hackers could whip up a MVP faster than I’ve seen it done with flask. You'll have to get more specific if you want an accurate answer. Does this MVP require a database? Does it require specific UI or can you just massage the OOtB UI that Phoenix gives you? You'd be surprised at how much of a headstart the generators can provide. I've built working protoypes (with database persistence) in 30 minutes. If it's purely a static page, I would just use nginx directly but you could easily do that in Phoenix as well in about the time it takes you to write the HTML since the default new project comes with a page controller already set up for that.

enraged_camel 4y ago
>> LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored. What the parent means is that, because state is kept on the server with LiveView, and events that change that state are processed by the server, if your connection is lost, then you may find that even basic things, such as having a dialog open when you click a button, stop working. This means that unstable connections result in very poor UX. This is in direct contrast to a typical SPA for example, where the browser keeps and handles most front-end state, and talks to the server only when it needs to (e.g. form submission).
- bostonvaulter2 4y ago
  You also might see full page refreshes when the heartbeat fails which can be very annoying.
- freedomben 4y ago
  With pure LiveView, I would agree, but you can easily supplement with a JS framework. As I mentioned above: > You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot. If you have a very complex client-side need, it's also pretty easy to use React.js for that. While you could, I never use LiveView to open dialogs (unless the dialog state needs to be distributed across multiple clients, but I haven't had that use case come up yet). As you mention, that would lead to a poor UX. The best is the best of both worlds. LiveView for data/state changes that need to go to the database, client-side script for state changes that are UI related and don't get persisted.