Using sockets instead of LiveView

2. Regular controllers with a handful of live pages. This is the original way to use liveview and it’s still valid. You don’t have to go all-in on the SPA feel.

Great, thanks! And how would that work? Should I just create a regular app (without --live) and then create live components that I can embed into regular views or would I create live pages?

Creating your app with --live is better. It setups all the live helpers and all the machinery required to run both normal views and live_views. Wherever you need live_view you can do
<%= live_render(@conn, MyAppWeb.ThermostatLive) %>. And

# In the router
live "/thermostat", ThermostatLive, session: %{"extra_token" => "foo"}

# In a view
<%= live_render(@conn, MyAppWeb.ThermostatLive, session: %{"extra_token" => "foo"}) %>

You can embed live_views anywhere you want. I am doing embedded live_views too. They work perfectly fine. They take a bit of time to understand, but they work just fine. I recommend watching the Pragmatic Studio’s LiveView course. They are really nice and explain some tricky concepts nicely.

Great, thank you!

I’d create the project with --live, but just add controllers afterwards. Afaik the latest default generators do generate a liveview ready setup as well, but I’m not sure if things like the bootstrapped modal component are present there.

Liveview components always need to have a liveview parent. It however can be a liveview handling the whole page, but also can be one embedded within a static page.

Imho there are three parts here: Plain websockets, Phoenix Channels and Phoenix LiveView. With liveview custom channels become for the most part obsolete, like channels make bare websockets for the most part obsolete. There can still be niche use cases for doing multiple of those, but for the common case this should hold true.

The problem of us developers is that we tend to jump into the new shine thing without trying to grasp it correctly first, aka we learn as we go… I was like this in the begin of my career and that hurts more in the long term then it helps. We think we go fast, but we just take more time to complete the journey, then if we take the time to prepare for it.

That being said I strongly recommend you to first set some time aside and try to fully grasp first the technology, and for that @mikeclark provides us with an excellent free in-depth LiveView course, as recommended by @subbu while I was writing my reply:

Hey, thanks for sharing your thoughts.

Very good point! I have mixed feelings about this. To be honest with you, I spent the last 4 months or more learning the basics of web developments. I have a reasonable amount of professional programming experience (unrelated to the web) and I already had some knowledge of HTML/CSS/JS fundamentals, so I spent most of that time on a selection of backend and frontend frameworks. On the backend, I initially chose Django, then tried Phoenix and decided to stick with it. On the frontend, I mostly spent time with Vue (also tried a bit of React), but I realised that I may not actually need it and I really liked the idea of avoiding SPA complexities. While the time I spent may not seem like a lot, I got to the point where I felt like I understood the basics but I was still not at all confident applying them. I thought that to get over this barrier I should just start applying them and even if I screw up my first project then I’ll just start again. I’m still not sure what is the best approach to learn web technologies (or anything else for that matter), but I got a little fatigued from doing tutorials for months. I feel that even if I get burnt by making a bad choice early on in my project, I will still learn a lot from it and that’s the entire point of the whole exercise.

I overviewed the Pragmatic Studio course on LiveView and I thought it was great, but based on what I can recall, the course goes all-in with LiveView and in this thread, I wanted to compare the LiveView-centric approach with alternatives (e.g. integrating LiveView with traditional controllers or just using sockets).

Let me know if you have any other thoughts on this matter

Off-course I am not saying you should keep doing it for months, neither you need top be an expert.

I should have been clear in my point. The message I was trying to pass is that we shouldn’t just jump in and learn as we go, we should first understand the basics and the mechanics of it, by reading docs, a book or following some good course/workshop.

No matter what I am learning I always follow the method of doing it in the hard way, as I learned from the Python book with the same name. This consists in you doing all the exercises in the book, tutorial, course, etc. and then explain by your own words what each function and lines of code are doing. While doing this you will discover more often then not that when you though that you grasped the subject you haven’t, because if you struggle to write it down in your own words in comments, then it means you have not fully understand it yet. Another benefit of learning the hard way is that the memory retention of what you learned in the long term increases dramatically, when in contrast with when you just practice, or worst when you just read.

You can read more about learning the hard way here.

That works. However, my approach is different: Rewrite a pet project you have already done in a different language/technology stack. The pet project cannot be too trivial: A few thousand lines of code is fine. Since you know the problem very well, this exercise will get you up to speed in the new language pretty fast.

I agree with rewriting a project as you said, but only after the language is well understood, aka, after reading some books or watch video courses from more then one source.

Just quickly diving into the docs of the lang and then jump to code will put you on this situation I said above:

The Journey here is to understand the programming language in depth enough that you know how to properly leverage it and code efficiently with it, to then put in usage to rewrite a project as you advocate