Regarding the OP it’s really hard to answer. I have been there and ended up choosing LiveView for my current project (where it was only me as a web developer but right now we have another developer working with me). I will try to tell a brief story of my experience around the same decision I had to take.
My background for the last 10 years (well, till 2018) has been mostly SPA JavaScript applications (corporate oriented) with some sprinkles of Fullstack development (NodeJS and Django mostly) so when picking up the technologies for my new project (which I started in 2020) I was faced with this decision.
I had React and VueJS experience from past gigs, I had written in-house component libraries for React and also VueJS for the respective projects but then I found Elixir.
Being frustrated with the Node ecosystem always breaking for any random reason and tired of the Python tooling and all (even though Django is great) I was looking into another Language and ecosystem with more guarantees, I found Elixir and fell in love. ![]()
So I had Elixir for the backend (having some previous Functional Languages experience I picked it up fairly quickly) but this was around the time LiveView initially released, so being very new I decided my first draft/PoC would be Elixir Phoenix as the Backend but on the FE I would use a REST service with React (NextJS) on the FE side. The story around headless UI libraries wasn’t as great as it is today in JS land so that was also a bit of a challenge to change the design to match the style we went with in my project, but I ended up re-styling an existing UI library (Chakra UI if I recall correctly).
For a project of one (in the web side, I had someone else working on the data science part) I grew frustrated with managing the complexity of backend development plus all the duplication of logic in the REST API + NextJS. Also, NextJS is a bit more complex that just picking some “regular” SPA library like VueJS. But React was my choice because there were a lot more quality options in terms of libraries for it than for VueJS.
Because of this I started to explore other options and by now LiveView was consolidating as a nice option and with a new developer with me (that lacked experience with React, VueJS, etc), it was time for taking the final decision in what would serve us best.
So I decided to recreate some screens using LiveView in a weekend as a Proof of Concept, to see how fast I could port some screens we already had (we spent most of the time around business logic, backend and other details so the front end wasn’t that far along). I really loved how fast I could go with LiveView and decided to port all the FE to LiveView, dropped the REST service, dropped NextJS and went with LiveView! Life was simpler! Long live the monolith!
Was it a good decision? Yes it was, don’t regret it at all. But what was the challenging parts? Well, this was before Core Components and around LiveView 0.10.
-
LiveView not being a 1.0 release and living on the edge has its drawbacks. There was quite a bit of refactoring when LEEX became HEEX, when the new Functional Components were released, etc, etc, etc. But it wasn’t that bad, maybe I spent 2-3 days tops working on re-writing code to port our user land code to the new versions of Phoenix and LiveView, still beats the complexity of maintaining a REST service and all the complexity of NextJS for me.

-
Yes, the lack of UI libraries was a bit of a challenge but we managed. More time than I would like was spent working on components, (like inputs, etc,), specially the more complex ones like Autocomplete, etc, but that was to price to pay, again, for adopting bleeding edge tech.
-
Forms with LiveView were a bit complex for my brain initially when managing a multi-step form with lots of state and validations, but after it clicked it all made sense.

So in the end, this is a complex decision but there isn’t one day I regret betting on LiveView. Also it is quite exciting to see it develop and mature.
While LiveView isn’t perfect (there are no silver bullet solutions), but taking into account complexity and speed of development, nowadays LiveView ranks pretty high on my list of frameworks I would default to whenever considering new product development.
I also started working on writing a UI component library for LiveView. I already re-started several times as I want to get the API right (taking several ideas from other libraries (from Elixir and JS land)).
This will for sure be an endeavour that will take several months, but I want to create something with quality, that hopefully will be a net positive in helping other people adopting Phoenix LiveView as a viable option for new projects.
My idea is to release a Headless UI component library and then a fully styled but customisable component library (probably using TailwindCSS).
Already have the name for the Headless UI one: flint_ui | Hex (ignore it for now, still mostly empty and WIP).
Flint, to help us start… fires! ![]()
Sorry for the very long post. ![]()


















