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.
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.
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...
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.
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 :)
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...
If you have other footguns in mind, feel to shot me an email at jose dot valim on gmail!
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.
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. :)
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.
Meanwhile deadviews + channels is /miles/ better than python/rails/laravel (imho).
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?
Saying this as a die hard Elixir fan who's been using it since 2015.
> 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.