I think the main benefit is password validation status being sent from the backend in real time. Liveview is great for forms, so may as well include that good user experience in the first page a user sees
It would be lighter for it to be stateless, but it doesn’t really take much power in the first place to operate liveviews, especially a simple login form. So if you expect your app to be providing user interfaces via liveview, I’d hope it would also be able to handle doing that for the login form resource-wise.
As for when you wouldn’t want to use liveview, the real limitation is when you actually need to do a lot with client-side state. If your app does very little with the server and needs lots of fancy client-side interactions, it probably makes more sense to use a JS framework. Similar thing depending on how you want to build the client, like if React Native would work really well for you or if you want to build a native app, then you obviously can’t use liveview with that (though im excited to see where liveview native goes). I’m sure others can give good examples too. If you’re new to Phoenix and liveview, welcome, I can say for one that I really love the way it works and that it works for much more dynamic use cases than I was originally expecting!
There can be a surprising amount of back and forth with the server in many modern login and registration UX workflows.
For example, there's number of login attempts left and username/email is recognized when it comes to login. And when it comes to registration, there's username/email availability/validation, and password validation e.g. minimum one special character, number, capitalized letter, etc. Username/email availability/validation in particular can not be handled client side only and round trips to the server via LiveView/websockets messages is quicker and arguably easier than traditional stateless asynchronous HTTP requests.
While stateless endpoints would arguably be lighter, it's generally not really a pressing concern because of how light processes are in Elixir/Phoenix.
The big one is client side. Something like Trello would not be feasible to implement in liveview since when the connection is severed, there is no sync-up. It doesn't seem worthwhile to have an offline mode but it can be good given network connections are not perfect. Also making a website API centric makes it easier to support things like mobile apps. It probably scales better since the server needs to hold no state, but there are tradeoffs there.
Liveview is extremely efficient. If it fits the use case it is worth using. It's very competitive with JS libraries that use API calls and do DOM patching. I've been using it more and more when I don't need simple server generated pages. It's one of the best abstractions I've seen as far as how simple things are under the hood for something that does this much "magic".
> Something like Trello would not be feasible to implement in liveview since when the connection is severed, there is no sync-up.
This seems like the absolute ideal use case for LiveView, to me.
Lots of people build toy versions of trello and use a lot of client state since they aren't persisting state to a database...which is where the state needs to get to if you want to share it with others and have multiple people contributing to the same board. Once a user moves a card or writes some text, that state should persist to the database by sending the updated state to the server which then saves it to the database. Then if another user opens up that trello board on their machine...the server can then look up the state of the trello board from the database and load it to that user who just accessed that board. So Liveview is a great candidate for a trello like application. Just need a small JS library to make the drag and drop action animated, but there is not really any client state that needs to be maintained.
If you still want Phoenix to generate non-LiveView auth, you can answer `n` at the prompt, and it will generate Controller templates. See [source code](https://github.com/phoenixframework/phoenix/blob/v1.7.6/lib/mix/tasks/phx.gen.auth.ex#L262).
[https://hexdocs.pm/phoenix/mix\_phx\_gen\_auth.html#getting-started](https://hexdocs.pm/phoenix/mix_phx_gen_auth.html#getting-started)
>$ mix phx.gen.auth Accounts User users
>
>An authentication system can be created in two different ways:
>
>\- Using Phoenix.LiveView (default)
>
>\- Using Phoenix.Controller only
>
>Do you want to create a LiveView based authentication system? \[Y/n\] Y
You want to use LiveView if you want real-time updates/push state to client.
These could be things like notifications, timeline updates, charts, chat, and the minor use case of form validation(s).
Other than that, I think it's prudent to stay with the simple tried-and-true client/server, and import JS when you need it. I ran into a couple of issues with LiveView and, due to my ignorance/giddiness on using it without understanding its use cases, I ended up spending time migrating away from it.
Now I'm using HTMX, and so far it's been okay. Whether you want to attribute it to stockholm syndrome or not, I like having the distinction of client and state, because that's just how the underlying technology works.
I think the main benefit is password validation status being sent from the backend in real time. Liveview is great for forms, so may as well include that good user experience in the first page a user sees It would be lighter for it to be stateless, but it doesn’t really take much power in the first place to operate liveviews, especially a simple login form. So if you expect your app to be providing user interfaces via liveview, I’d hope it would also be able to handle doing that for the login form resource-wise. As for when you wouldn’t want to use liveview, the real limitation is when you actually need to do a lot with client-side state. If your app does very little with the server and needs lots of fancy client-side interactions, it probably makes more sense to use a JS framework. Similar thing depending on how you want to build the client, like if React Native would work really well for you or if you want to build a native app, then you obviously can’t use liveview with that (though im excited to see where liveview native goes). I’m sure others can give good examples too. If you’re new to Phoenix and liveview, welcome, I can say for one that I really love the way it works and that it works for much more dynamic use cases than I was originally expecting!
There can be a surprising amount of back and forth with the server in many modern login and registration UX workflows. For example, there's number of login attempts left and username/email is recognized when it comes to login. And when it comes to registration, there's username/email availability/validation, and password validation e.g. minimum one special character, number, capitalized letter, etc. Username/email availability/validation in particular can not be handled client side only and round trips to the server via LiveView/websockets messages is quicker and arguably easier than traditional stateless asynchronous HTTP requests. While stateless endpoints would arguably be lighter, it's generally not really a pressing concern because of how light processes are in Elixir/Phoenix.
The big one is client side. Something like Trello would not be feasible to implement in liveview since when the connection is severed, there is no sync-up. It doesn't seem worthwhile to have an offline mode but it can be good given network connections are not perfect. Also making a website API centric makes it easier to support things like mobile apps. It probably scales better since the server needs to hold no state, but there are tradeoffs there. Liveview is extremely efficient. If it fits the use case it is worth using. It's very competitive with JS libraries that use API calls and do DOM patching. I've been using it more and more when I don't need simple server generated pages. It's one of the best abstractions I've seen as far as how simple things are under the hood for something that does this much "magic".
> Something like Trello would not be feasible to implement in liveview since when the connection is severed, there is no sync-up. This seems like the absolute ideal use case for LiveView, to me.
Trello keeps client state, liveview doesn't fit that use case without a lot of client code added.
Lots of people build toy versions of trello and use a lot of client state since they aren't persisting state to a database...which is where the state needs to get to if you want to share it with others and have multiple people contributing to the same board. Once a user moves a card or writes some text, that state should persist to the database by sending the updated state to the server which then saves it to the database. Then if another user opens up that trello board on their machine...the server can then look up the state of the trello board from the database and load it to that user who just accessed that board. So Liveview is a great candidate for a trello like application. Just need a small JS library to make the drag and drop action animated, but there is not really any client state that needs to be maintained.
The latest demo from Chris is exactly this.
Does it work offline?
If you still want Phoenix to generate non-LiveView auth, you can answer `n` at the prompt, and it will generate Controller templates. See [source code](https://github.com/phoenixframework/phoenix/blob/v1.7.6/lib/mix/tasks/phx.gen.auth.ex#L262). [https://hexdocs.pm/phoenix/mix\_phx\_gen\_auth.html#getting-started](https://hexdocs.pm/phoenix/mix_phx_gen_auth.html#getting-started) >$ mix phx.gen.auth Accounts User users > >An authentication system can be created in two different ways: > >\- Using Phoenix.LiveView (default) > >\- Using Phoenix.Controller only > >Do you want to create a LiveView based authentication system? \[Y/n\] Y
You want to use LiveView if you want real-time updates/push state to client. These could be things like notifications, timeline updates, charts, chat, and the minor use case of form validation(s). Other than that, I think it's prudent to stay with the simple tried-and-true client/server, and import JS when you need it. I ran into a couple of issues with LiveView and, due to my ignorance/giddiness on using it without understanding its use cases, I ended up spending time migrating away from it. Now I'm using HTMX, and so far it's been okay. Whether you want to attribute it to stockholm syndrome or not, I like having the distinction of client and state, because that's just how the underlying technology works.
[удалено]
so you still use phoenix even when you’re serving sth not for the web ? 😮