I think this topic really could be broken out into a dozen smaller pros/cons comparisons. It would be beneficial for the community, as the topic of full-stack Elixir comes up quite often. To really answer your question, it’d be worthy of a detailed blog post (I might be volunteering myself in writing this). However, if you have a specific question / sub-topic, I’d be happy to answer it here.

That said, here are 6 reasons that come to mind to continue reaching for JS in the UI:

1. JS devs tend to also be HTML/CSS devs with more UI experience than Elixir devs. It’s not just a language preference, it’s also domain experience. Do you know when to reach for flex-box vs grid? JS devs are more likely to have a better understanding of UX, experience in the many browser quirks, and an “eye” for UI. Also, UI devs tend to be cheaper than Elixir devs. The economics of specialization and comparative advantage are at play.

2. Plenty of turn-key UI libraries. For instance, Material components exist for Vue, React, etc.. I keep seeing these really primitive LiveView UIs with basic CSS. That’s just not what a modern app looks like. Are we going to build a multi-select, token dropdown menu that support slots, is accessible, and mobile friendly in LiveView? Yes? How about the other 20+ common Material UI components? What about charts? Are we going to build a LiveView library with parity to D3.js? What about animation libraries like GreenSock? Are we going to “stream” position updates, or have lightweight UI libs that handle transitions based on configs sent from LiveView? Is that even worth it?

3. UI components. For instance, Vue single-file-components (SFC) are a HUGE benefit in my experience. Keeping your script, CSS, and HTML together in the same file makes maintenance really useful. Vue will automatically scope your CSS to prevent accidental specificity conflicts. Transpilers like SCSS are easy as well. The modules will live update in the UI on a per-module basis. Meaning, without a full page refresh you get just the module that swaps out. Super useful on big apps that have long compile times.

4. Repurpose the UI for mobile. Many apps are built in React Native (or similar); often built by the same team that is building the web UI. Elixir doesn’t have an option for that.

5. Offline support / service workers.

6. Centralization / decentralization. By offloading rendering work to the browser, we decentralize computation resources. With LiveView, you’re now concentrating all that work on the servers. Servers are pretty cheap, but the client’s browser is free.

Hope that helps. I am very optimistic that JS is being attacked from multiple angles (LiveView, WebAssembly, etc.). However, we’re not doing ourselves any favors by comparing LiveView to narrow JS use-cases and ignoring the many aspects of modern JS. Like I said, for smaller / marketing projects, blogs, etc., LiveView could definitely work. For larger projects (or ones that could grow into larger projects), I don’t yet see LiveView as a viable replacement.

Early stage barriers to success on the web are typically time-based. You need to rapidly find the right solution that will draw customers/eyeballs. You need to be able to put features up quickly and iterate as rapidly as possible to find what will draw people in to your web application. You don’t want to spend inordinate time creating experiments that might fail while exploring your options.

To that end, LiveView will get you up and running as quickly as possible while allowing you to experiment to find what works for your business model.

Later, if you have a successful site that needs to scale, you might consider migrating to an SPA. But to give your ideas the best chance they have of finding footing in a marketplace, I don’t see how you could do better than to start with LiveView.

For me personally, I almost exclusively use Phoenix for APIs only. When I need this realtime updates stuff, I use GraphQL subscriptions.

As a fullstack developer that sometimes hire some frontenders to help building interfaces, it’s way more organized and flexible. With an API built, you dont need to share your business-backend code with frontend code directly. It also gives you a quick way of building mobile apps, external integrations, or even a complete rework of your web interface easily.

Of course one of this frontends can be a phoenix app, integrating with a backend app which is also an API, but I see little value there. At least not without using a JS framework anyway. You can SSR in phoenix with react, for example. But I’d still split the codebase in many scenarios.