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.

So I wrote a bunch of LiveView, and Surface UI
and also kept using React on the side and my impressions recently are that LiveView/Surface really matured over the last few years but - even so - the choice between tech stack to use is not super obvious.

First off, it’s easier to find JavaScript developers, and also pure backend Elixir developers than developers who are comfortable and good doing both front-end and back-end with LiveView/Surface. So that’s a factor you have to take into consideration.

Secondly, if the objective is to reduce the cognitive load on the developer, by reducing the number of moving parts, LiveView/Surface are not exactly doing that, not if you’re building a moderate to big app at least. BTW, this was not the original LiveView use case, the authors originally said it’s not meant to replace complicated JS apps but here we are nevertheless, and often you don’t even know how the app/project will grow in it’s life time. When you write LiveView you have to deal with, and understand, something like the following stack:

• build system (be it default esbuild, bun or webpack) for JS/hooks compilation, minifying etc.
• JavaScript runtime for the Hooks and otherwise JavaScript front-end code you will need
• stateless Components life cycle/mounting/usage
• stateful Components life cycle/mounting/usage
• LiveViews life cycle mounting/usage
• message passing between Components of various types, and LiveView and Hooks
• ad-hoc JavaScript generation and execution with %JS{} stuff
• how the CoreComponents work and how to customize it/change/write your own
• how the Phoenix controllers work and how to expose some data through them or maybe API and how to mount LiveViews in it and maybe how to use Components from them
• how the layouts work, and when is what rendered, how do you update things like page title and meta tags
• how to trigger the navigation and manage the push state from LiveView, how to do something like that from Component, or Controller, and another way to do it from JavaScript Hooks
• how the Plug works
• how GenServers work and what is the handle_info and the message passing and the queue of messages and blocking and doing the stuff async and recovery from crashes
• maybe how the Cowboy handlers work in rescuing from exceptions
• how to manage the state on hand, including Cookies and Session state and just the UI state / data from the database, how to load it, keep around, pass betweeh LiveView, Components, Controllers or Plugs
• how to build forms that are backed up or not by database tables and how to handle them, how the handling differs between Components and Controllers and LiveView

generally, it’s a surprisingly large body of knowledge to both acquire and keep up to date with.

Now if you’re building a React single page app with an Elixir backend, you also end up with a big body of knowledge to acquire and keep up to date with but you get many benefits you do not have with LiveView, like the ability to reach towards numerous UI component libraries, commercials and free alike, use some excellent state management libraries / techniques, which IMHO are really nice since the invention of Hooks (React Hooks, not LV Hooks), use the finest HTTP client libraries, GraphQL libraries (Apollo!) and also push a lot of the CPU cycles and memory away from your servers to your client browsers.

There’s also more stuff you can do, not just complete offline mode, but handling weak/poor/changing network conditions, users suspending/resuming their laptops, or even things like server deployments or Kubernetes cluster rebalancing resulting in state loss/disconnections on LV and with a JS app this can be factored in in a seamless way.

A word about Surface, I actually like it more than pure LiveView. It’s features are leaking to LV too, which is good. It’s got some stub for a good state management with defined properties, data attributes and such, also more React/Web Components like interface when it comes to rendering children. But then you end up having to deal with another layer, on top of LiveView, that sits on top of all the other layers I discussed above and when you use some function it’s like okay where is it coming from and where in the documentation do I have to look for it and it may be in Plug or Phoenix or LiveView or in Surface or some other moving part and there’s just a lot of them.

I dabbled with Next.js about a 1 year ago exactly this time, around Christmas, and with React Server Components, which are not exactly the same as LiveView and, despite it being JavaScript and then quite buggy (I used the “app structure” that was in alpha/beta) the overall experience was more welcoming. It’s designed top-to-bottom, rather than bottom-to-top, and there’s like one main place for documentation, and the documentation is overall way shorter, there are fewer moving parts to wrap your head around. It’s quite funny, because we’ve been making fun of JavaScript ecosystem being fragmented, but there are also a very programmer-friendly environments there that do reduce the cognitive load of the programmer rather than increase it.

I think a Next.js-like solution for Elixir, maybe one that uses Surface or React as a rendering engine/layer, where the users can forget about the existence of Plug, Controllers and such things because they’re either implementation details and not exposed directly to them or are not used at all would be a step in interesting direction, but I haven’t seen anything like that yet.

There’s also a security consideration: with LV/Surface you end up with more code being executed on the server, with the full privileges of the BEAM process that calls these functions. A bug in either your own code or the code of a library could expose the whole VM and whatever it has access to on the database. A similar bug but on the client-side could end up with single user’s credentials/access to data being compromised more likely than a total hole in the system giving attacker access to everything. I don’t know what are the actual stats on what is actually happening in real life, but the vector of attack is just bigger when all of your functions run with the higher rather than lower privileges and access to data.

I actually don’t have the recommendation for you what to choose. If you go with LiveView/Surface, prepare yourself for having to deal more with a bunch of moving parts, and application state management may not be as clear and obvious as, say, in React with React Hooks or with Mobx or something like that. On the other hand, if you go with a JavaScript app, you have a different set of problems depending on the framework you choose, but will also have to come up with a clean data loading solution and the serialization, deserialization, etc. that will have to happen between the server and the front-end.

I also keep reading all over the forums how there’s a huge gap in X, Y and Z with LiveView. I find it hard to reason with it.

With 3 “full stack” developers we’ve built and maintained an app built entirely with LV since v0.1.0. Since then A LOT has happened with the ecosystem (for the greater good) and besides some upgrades being time-consuming, it’s been a great ride.

We own CoreComponents (and a bunch of other component modules) and I don’t see the problem in reading the diff and updating whatever is necessary in our app - it’s not like it requires constant updates as it’s just a headstart for new apps, eventually it’ll be custom enough for the app’s needs. The app went through own-rolled CSS to Bulma and now Tailwind, all went fine.

We have no complaints from clients about the “We’re trying to find the internet” issue (well, we had once for a client that blocked WebSocket connections).

It does have a lot of accessibility features and tweaks. Enough to grant us contacts with schools districts where it’s required (ed-tech field).
If we were to start a new project now, porting most of the components would be easy. So yeah starting a new project won’t give you all the bells and whistles one would want, but also for many apps and POCs you don’t need the full package. By the time you need everything you’d have sorted it out with your team.

There’s tools around that will get you very far beyond the starting skeleton, like PETAL and friends, and if they help throw them some money. Extend where they don’t.

I have past experience with Ember, Elm, React and Vue both with Rails and Phoenix, and I’m very sure we wouldn’t be able to build everything we’ve built with such a small team and keep shipping features while maintaining everything up to date if we were using anything else.

I can’t see the tooling (or the lack of it?) we have right now being a problem or getting in the way of building a successful business/app.