I really want to like LiveView and I’m already a big fan of Svelte. Every time I look into it, though, the stuff I see doesn’t really inspire a lot of excitement for working with the stack.
I know that at least part of that hesitation is the fact that I’ve been in the stateless server/REST mindset for a long time now, but looking at the provided code demos doesn’t make LiveView look better.
What’s most game-changing, though, is that you have a backend, stateful process that is collaborating with a frontend, stateful process.
That feels to me like the core of the value prop of LiveView, but it also feels like something that’s going to be a source of massive complexity and horrific bugs. If the WebSocket stream powering the page goes down, does your form just stop accepting changes? Or worse yet, does the frontend go out of sync with the backend and cause you to submit bad data?
Then there was this code block which almost made me close the tab as soon as I saw it:
This looks like the worst parts of PHP and EJS templating mashed together and connected by a WebSocket. No type information, no editor integration, no syntax highlighting… It looks very dire.
I get that a big part of this might just be me being unfamiliar with the stack. I should probably try it on a project at some point.
Anyway, I still really want to like this tech. If anyone can dispel any of my concerns or give more info that would help explain some of the decisions, I’d be eager to hear.
There -is- a syntax highlighting integration on ~H components in VS Code.
If the WebSocket stream goes down, my understanding is that the form would stop accepting changes. There is some latitude there, but with the arch (Frontend using controlled components, and so on) they are describing, that would be my understanding.
In my experience with LiveView, but -not- Svelte, form submissions would ideally be handled atomically at the end, a “fire off the gathered state so far”. LiveView definitely assumes that you’re accepting a stable websocket connection as a precondition for using it, though it gives you tools to handle the connection going up/down (some of them taking advantage of that backend stateful process, to boot)
LiveView’s key feature, IMO, is one that it shares with the rest of Phoenix: It live-updates as you change your code, which means you can see the effects of changes very quickly.
I would undertake projects in LiveView with the understanding that I’d be leaning a bit more on tests and bit less on pervasive compile-time type checking, at least for now.
Or worse yet, does the frontend go out of sync with the backend and cause you to submit bad data?
In LiveView, all of the state lives on the server, so there’s nothing to get out of sync. The front end is just sending messages down the socket, and getting bits of rendered html back up the socket to update the page. There’s no state on the client to get out of sync.
It’s all a smoke and mirrors trick that makes it look like there is a rich javascript fronted app with all the complexity that usually implies. But the LiveView model is much simpler: all the state and smarts live on the backend, and the “fronted” is just a dumb rendering layer.
If the websocket drops then the client tries to establish a new connection, which looks a lot like a page refresh.
This looks neat. I just picked up a small LiveView project and definitely felt myself running into the “is there a more idiomatic way to do this” barrier quite quickly, particularly around UX subtleties like the author mentions. I eventually came to the conclusion that LiveView isn’t mature enough to have anything that’s super idiomatic, but this does seem like an interesting compromise.
For now, I’ve just added a top-of-screen loader while state is changing, which for my little hobby project is likely more than sufficient
I really want to like LiveView and I’m already a big fan of Svelte. Every time I look into it, though, the stuff I see doesn’t really inspire a lot of excitement for working with the stack.
I know that at least part of that hesitation is the fact that I’ve been in the stateless server/REST mindset for a long time now, but looking at the provided code demos doesn’t make LiveView look better.
That feels to me like the core of the value prop of LiveView, but it also feels like something that’s going to be a source of massive complexity and horrific bugs. If the WebSocket stream powering the page goes down, does your form just stop accepting changes? Or worse yet, does the frontend go out of sync with the backend and cause you to submit bad data?
Then there was this code block which almost made me close the tab as soon as I saw it:
This looks like the worst parts of PHP and EJS templating mashed together and connected by a WebSocket. No type information, no editor integration, no syntax highlighting… It looks very dire.
I get that a big part of this might just be me being unfamiliar with the stack. I should probably try it on a project at some point.
Anyway, I still really want to like this tech. If anyone can dispel any of my concerns or give more info that would help explain some of the decisions, I’d be eager to hear.
There -is- a syntax highlighting integration on ~H components in VS Code.
If the WebSocket stream goes down, my understanding is that the form would stop accepting changes. There is some latitude there, but with the arch (Frontend using controlled components, and so on) they are describing, that would be my understanding.
In my experience with LiveView, but -not- Svelte, form submissions would ideally be handled atomically at the end, a “fire off the gathered state so far”. LiveView definitely assumes that you’re accepting a stable websocket connection as a precondition for using it, though it gives you tools to handle the connection going up/down (some of them taking advantage of that backend stateful process, to boot)
LiveView’s key feature, IMO, is one that it shares with the rest of Phoenix: It live-updates as you change your code, which means you can see the effects of changes very quickly.
I would undertake projects in LiveView with the understanding that I’d be leaning a bit more on tests and bit less on pervasive compile-time type checking, at least for now.
In LiveView, all of the state lives on the server, so there’s nothing to get out of sync. The front end is just sending messages down the socket, and getting bits of rendered html back up the socket to update the page. There’s no state on the client to get out of sync.
It’s all a smoke and mirrors trick that makes it look like there is a rich javascript fronted app with all the complexity that usually implies. But the LiveView model is much simpler: all the state and smarts live on the backend, and the “fronted” is just a dumb rendering layer.
If the websocket drops then the client tries to establish a new connection, which looks a lot like a page refresh.
This looks neat. I just picked up a small LiveView project and definitely felt myself running into the “is there a more idiomatic way to do this” barrier quite quickly, particularly around UX subtleties like the author mentions. I eventually came to the conclusion that LiveView isn’t mature enough to have anything that’s super idiomatic, but this does seem like an interesting compromise.
For now, I’ve just added a top-of-screen loader while state is changing, which for my little hobby project is likely more than sufficient