4 ms·

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appre

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience. I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even without LiveView and realtime/channels, just using Elixir as a backend for a simple API has been really fun.

manchmalscott 2y ago
You can use Phoenix without LiveView by running mix phx.new with the —no-live flag (or manually pull it out of an existing project).
- bnchrch 2y ago
  But too the OPs point. This is not a technology that should be included by default. No matter how cool. Saying this as a die hard Elixir fan who's been using it since 2015.
  - arrowsmith 2y ago
    Why not? If you don't like it just build the app without LiveView. Having `phoenix_liveview` as a dependency in mix.exs doesn't do any harm if you're not using it.
- mike1o1 2y ago
  Yes, I totally get that (and have been doing that). My complaint/suggestion is more around the marketing and messaging. There is so much more to Elixir than LiveView!
  - barrell 2y ago
    I get this. Currently have a front-end built, with the need (& existing functionality) for offline local first etc. Switched to phoenix on the backend, and the amount of liveview stuff I have to 'wade through' is really distracting. It also seems to be eating up about 75% of the hype in the Elixir community :laugh:
sbuttgereit 2y ago
There are a couple comments to you so far and both of them miss the point. > decouple itself from LiveView in a sense in the __minds of developers__ This isn't a technical knowledge issue or if a given technology should be the default on install. Assuming I understand your original post correctly this is a mindset issue: too many people dismiss Elixir and the rest of the ecosystem because the first thing they think about is LiveView while ignoring the rest of the ecosystem and that's a shame, because it's much more than that... and I would agree with that point. Even Phoenix is more than LiveView. It's possible to have solidly productive, cost effective Elixir applications not involving LiveView or even Phoenix for that matter. The choice of Elixir in the backend should be more common than it is, though I understand some of the conventional wisdom and fears that motivate other choices.
elbasti 2y ago
I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software. I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].) In fact, the fact that the above sentence has zero meaning to a new-to-phoenix-and-liveview dev is proof enough to me that liveview should not be the default way of doing things. It creates a very steep learning curve where, crucially none is required. elixir/phoenix are easy. I would even say that the correct learning order for a new-to-elixir/phoenix dev should be: - Phoenix with deadviews (MVC style). - "Elixir in action" to learn the basics of OTP. This book is was both easy and utterly eye-opening to me and changed the way I code basically everything. - Then, and only then, LiveView. [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#live_session-and-live_redirect https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
- arrowsmith 2y ago
  Shameless self-promotion - if you're struggling to learn LiveView then you could try my tutorial: http://phoenixliveview.com/ http://phoenixliveview.com/
  - epiccoleman 2y ago
    You'll be pleased to know that you got at least one sale from this post. I've struggled a bit to go from knowing Phoenix reasonably well to grokking LiveView. Looking forward to finding some time to dive into your course.
- birdfood 2y ago
  I've been having a similar experience trying to build an app with liveview. I've been simultaneously building the same app with Phoenix + LiveView and Dream (OCaml) + HTMX. With the OCaml stack I'm finding it really easy to follow the data flow through the whole app thanks to the compiler. With the Phoenix app I'm struggling to internalise how all the code fits together and having to navigate the code base off searching for strings alone (vscode editor tooling seems to just not work for me?). I'm also struggling to grasp how state is stored in a liveview and it isn't helped that a lot of the resources I've found online are now out of date. Going with a simpler approach of MVC sounds promising - I do want to get to the point where I'm actually taking advantage of the BEAM (I'm aiming for long running processes + user interactivity + maybe multi-user editing). I'd be keen to hear your development workflow for building an MVC style app, what you use for the front end, and how you go about refactoring, e.g. when editing a struct which is stored in the DB and shown in a view is when I particularly feel like I'm flying blind.

manchmalscott 2y ago

You can use Phoenix without LiveView by running mix phx.new with the —no-live flag (or manually pull it out of an existing project).

bnchrch 2y ago
But too the OPs point. This is not a technology that should be included by default. No matter how cool. Saying this as a die hard Elixir fan who's been using it since 2015.
- arrowsmith 2y ago
  Why not? If you don't like it just build the app without LiveView. Having `phoenix_liveview` as a dependency in mix.exs doesn't do any harm if you're not using it.
mike1o1 2y ago
Yes, I totally get that (and have been doing that). My complaint/suggestion is more around the marketing and messaging. There is so much more to Elixir than LiveView!
- barrell 2y ago
  I get this. Currently have a front-end built, with the need (& existing functionality) for offline local first etc. Switched to phoenix on the backend, and the amount of liveview stuff I have to 'wade through' is really distracting. It also seems to be eating up about 75% of the hype in the Elixir community :laugh:

sbuttgereit 2y ago

There are a couple comments to you so far and both of them miss the point. > decouple itself from LiveView in a sense in the __minds of developers__ This isn't a technical knowledge issue or if a given technology should be the default on install. Assuming I understand your original post correctly this is a mindset issue: too many people dismiss Elixir and the rest of the ecosystem because the first thing they think about is LiveView while ignoring the rest of the ecosystem and that's a shame, because it's much more than that... and I would agree with that point. Even Phoenix is more than LiveView. It's possible to have solidly productive, cost effective Elixir applications not involving LiveView or even Phoenix for that matter. The choice of Elixir in the backend should be more common than it is, though I understand some of the conventional wisdom and fears that motivate other choices.

elbasti 2y ago

I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software. I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].) In fact, the fact that the above sentence has zero meaning to a new-to-phoenix-and-liveview dev is proof enough to me that liveview should not be the default way of doing things. It creates a very steep learning curve where, crucially none is required. elixir/phoenix are easy. I would even say that the correct learning order for a new-to-elixir/phoenix dev should be: - Phoenix with deadviews (MVC style). - "Elixir in action" to learn the basics of OTP. This book is was both easy and utterly eye-opening to me and changed the way I code basically everything. - Then, and only then, LiveView. [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#live_session-and-live_redirect https://hexdocs.pm/phoenix_live_view/security-model.html#liv...

arrowsmith 2y ago
Shameless self-promotion - if you're struggling to learn LiveView then you could try my tutorial: http://phoenixliveview.com/ http://phoenixliveview.com/
- epiccoleman 2y ago
  You'll be pleased to know that you got at least one sale from this post. I've struggled a bit to go from knowing Phoenix reasonably well to grokking LiveView. Looking forward to finding some time to dive into your course.
birdfood 2y ago
I've been having a similar experience trying to build an app with liveview. I've been simultaneously building the same app with Phoenix + LiveView and Dream (OCaml) + HTMX. With the OCaml stack I'm finding it really easy to follow the data flow through the whole app thanks to the compiler. With the Phoenix app I'm struggling to internalise how all the code fits together and having to navigate the code base off searching for strings alone (vscode editor tooling seems to just not work for me?). I'm also struggling to grasp how state is stored in a liveview and it isn't helped that a lot of the resources I've found online are now out of date. Going with a simpler approach of MVC sounds promising - I do want to get to the point where I'm actually taking advantage of the BEAM (I'm aiming for long running processes + user interactivity + maybe multi-user editing). I'd be keen to hear your development workflow for building an MVC style app, what you use for the front end, and how you go about refactoring, e.g. when editing a struct which is stored in the DB and shown in a view is when I particularly feel like I'm flying blind.