[mike1o1]

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.

[elbasti]

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#liv...

[josevalim]

Thanks for the link. This is my fault because the sentence is ambiguous. Where it tries to explain that "you need to remember to perform auth checks both", it rather means that you need to protect controller routes and LiveView routes the same way, but for a single LiveView, you don't need to do both. I will try to clarify it!

If you have other footguns in mind, feel to shot me an email at jose dot valim on gmail!

[elbasti]

Hi José, thank you for the reply. I hope I didn't come across as critical of the incredible work the elixir (and LV) teams have done. You are all absolute treasures to the programming ecosystem.

I think you'll find that my argument ("LiveView shouldn't be the default way of doing things") is fairly common.

It's not necessarily about the footguns (or lack thereof), or improving the docs: it's about there being a shared vocabulary among people that do web development that LiveView is alien to.

Web frameworks have historically been great tools to drive adoption of programming languages (Ruby/Rails, react/ts). The same could be true of Elixir.

However, in order for that to obtain, the learning curve can't be too steep, at least in the initial portions of it. I think you'll find that with LV the learning curve looks like a step, and imho that step is a bit too high.

Of course, all these arguments apply both at the individual level and the company/org level. Think about a new hire's time-to-productivity if they first have to learn elixir, then phoenix + liveview vs just elixir & MVC phoenix.

If there's a way I could contribute to an effort that helps people learn elixir sans lv--perhaps writing, sketching, or even reading a guide/documentation--I'd be happy to give it a crack.

[josevalim]

Hi elbasti, sorry for the late reply. I didn't find your comment critical at all. I appreciate the feedback, especially when it allows us to improve things.

We should always improve the learning curve, regardless of its steepness! Any work in this direction is always welcome. I don't have anything in mind at the moment but if you do stumble upon anything, feel free to PR. :)

[crenwick]

I really appreciate that you took the time to clarify this. I was surprised by parents comment about needing auth twice but they seemed confident. Honestly worried I have apps with auth gaps!

But what you wrote matches my understanding. I have some routes that are pure LiveView and some that go through controller routes with HTML, and it was clear to me where I needed auth when I made them.

[birdfood]

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.

[goosejuice]

Jump to definition works well with each of the lsps out there. Has for years. No refactoring functionality but llms filled that gap.

Each liveview is an isolated process. You can easily inspect this in the process tree with the phx dashboard that is bundled. State & messaging is certainly the hard part to grok with the beam. I found elixir in action to cover these concepts very well and nothing has really changed since it's first release.

Your experiencing trying to follow data through Phoenix is the complete opposite than what I had when I picked it up many years ago. The request response cycle is pretty straightforward to follow being a struct piped through the endpoint. Liveview isn't much different. Breath of fresh air for me really. Coming from a year or two studying rails which is a nightmare in comparison with all the metaprogramming.

While I do think you can be productive in this stack without knowing much about the BEAM, just taking a week or so to get to know it will pay dividends. It's a paradigm shift compared to a lot of what's out there -- but isn't one that I found difficult to grok as a new developer in the middle of my CS undergrad at the time. Many of my friends shrugging it off for python found their way to elixir eventually :)

[goosejuice]

I found this free resource that explains the phoenix liveview lifecycle pretty well if helpful: https://www.youtube.com/watch?v=ffB9gmzYJJg.

[myaccountonhn]

I echo this. It’s always the struggle of DIY + understanding what’s going on versus taking the magic off the shelf solution where it works until it doesn’t.

[tpdly]

Very re-assuring to find this opinion elsewhere. I am absolutely drowning in Liveview. So difficult to /really/ grok. I'm becoming more convinced that it just isn't worth the effort, especially considering the interface will glitch if the user drives through a tunnel.

Meanwhile deadviews + channels is /miles/ better than python/rails/laravel (imho).

[goosejuice]

I'll take liveview over any frontend framework. But it's not either or.

Whether it works for you really depends on your needs. I always hear the offline tradeoff but for most businesses it's not a deal breaker. What % of websites do you use every week where you expect it to work offline?

[arrowsmith]

Shameless self-promotion - if you're struggling to learn LiveView then you could try my tutorial: http://phoenixliveview.com/

[epiccoleman]

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.

[conradfr]

I recently started a project and could have pushed for LiveView but knowing I would need very detailed and complex auth/auth which SUCK in Phoenix I went back to Symfony + VueJS&TS for some parts and I'm amazed how fast and productive I am.

Sure when I need to write a REST route + its consumer in the client I die a little because I know that's the part I could have avoided...

[goosejuice]

Haven't had any issues with authn/authx in phx land. What are you trying to do?

[manchmalscott]

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).

[mike1o1]

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]

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:

[bnchrch]

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]

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.

[sbuttgereit]

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.